GigaChat и YandexGPT в корпоративном RAG: контрактные ограничения, latency и сравнение с локальным инференсом

Оба вендора - Сбер с GigaChat и Яндекс с YandexGPT - выкатили enterprise API с официальной поддержкой корпоративных сценариев, включая on-premise деплой для отдельных тарифных планов. Заказчик из финансового сектора, у которого мы давно поддерживаем RAG-пайплайн поверх внутренней базы знаний, захотел проверить: а не проще ли теперь взять отечественный API вместо локального инференса? Задача понятная, ответ оказался неоднозначным.

Что за контекст

RAG-система у заказчика работает уже несколько месяцев: векторная база на pgvector, retrieval поверх нескольких десятков тысяч документов, ответ генерируется локальной моделью через vLLM на GPU-кластере. Про сторону инфраструктуры писали отдельно, про выбор векторного хранилища - тоже.

Сейчас задача другая: попробовать GigaChat API и YandexGPT API как замену или дополнение к локальному инференсу. Заказчик - финансовая компания, ПДн там есть, КИИ тоже, поэтому вопрос о том, куда идут данные, - не риторический.

Контрактные ограничения: это первое, что надо читать

Прежде чем мерить latency, мы потратили время на договорную базу. И это оказалось правильным решением.

GigaChat Enterprise предусматривает обработку данных в контуре Сбера с возможностью подписать NDA и DPA, обучение на данных клиента по умолчанию отключено при enterprise-тарифе. On-premise деплой - отдельный продукт, не API, требует отдельного пилота и другого контракта. То есть «облачный API» и «on-premise» - это разные вещи, которые часто путают в переговорах.

YandexGPT API в схеме Yandex Cloud под FSTEC-облако (IL2) формально покрывает часть требований КИИ, но не все: зависит от категории объекта. Для заказчиков с третьей категорией КИИ это может работать, для первой - под вопросом, нужно отдельное согласование с регулятором. On-premise у Яндекса на момент нашей работы - тоже пилотная программа, общедоступного офера нет.

В итоге оба API в облачном режиме не подходят нашему конкретному заказчику для production из-за его категории КИИ. Но мы всё равно провели технический анализ - под менее чувствительный сценарий и для понимания характеристик.

Latency: где реально болит

Тестировали на синтетической нагрузке, схожей по структуре с production-запросами: системный промпт ~500 токенов, контекст из retrieval ~1500 токенов, вопрос ~50 токенов. Ответ - от 100 до 400 токенов.

Картина по latency получилась такая:

• Time to first token у облачных API ощутимо выше, чем у локального инференса на A100. Это ожидаемо: к сетевым задержкам добавляется очередь на стороне вендора. В часы пик у обоих API мы видели заметные колебания - разброс внутри одной сессии был большим, чем у локального инференса.
• Throughput у облачных API при одновременных запросах ограничен rate limit-ами тарифа. Enterprise-тариф у обоих вендоров даёт существенно больший лимит, чем базовый, но он всё равно конечный, и при пиковой нагрузке придётся либо платить за апгрейд, либо ставить очередь на клиентской стороне.
• Локальный инференс выигрывает по предсказуемости: latency стабильна при умеренной нагрузке, нет внешних зависимостей, нет rate limit-ов извне. Платишь за это GPU-кластером и командой, которая его обслуживает.

Качество ответов

Это самая субъективная часть, но кое-что конкретное сказать можно.

На документах заказчика - технические регламенты, внутренние инструкции, финансовые описания продуктов - GigaChat и YandexGPT справляются с генерацией связного ответа по контексту вполне прилично. Проблема не в грамматике и не в «понимании» - проблема в специфической терминологии. Внутрикорпоративные аббревиатуры, нестандартные определения, ссылки на внутренние системы - всё это модели обрабатывают хуже, чем локальная модель, дообученная на корпоративных данных.

Особо заметно на вопросах, где правильный ответ требует рассуждения по нескольким фрагментам контекста одновременно. GigaChat держится чуть лучше на русскоязычных юридических конструкциях, YandexGPT - на технических описаниях с числами и формулами. Это не вывод для учебника, просто наблюдение на конкретной коллекции документов.

Что в итоге

Отечественные облачные LLM-API - это реальный вариант для RAG-пайплайна при условии, что:

• Требования к данным позволяют обрабатывать запросы вне периметра (не первая категория КИИ, нет ПДн в запросах).
• Нагрузка умеренная и не требует сверхнизкой latency.
• Команда не готова держать GPU-инфраструктуру и локальный инференс.

Если хоть один из этих пунктов не совпадает - смотреть нужно на on-premise деплой (пока по-прежнему пилот у обоих вендоров) или на локальный инференс с открытыми моделями. Мы, собственно, и помогаем разобраться какой из вариантов закрывает конкретный набор требований в рамках интеграционного проекта.

Заказчик по итогам остался на локальном инференсе - его ограничения не оставляли другого выбора. Но понимание того, что облачные API технически дотягиваются до нужного уровня, полезно: при смягчении требований или появлении нормального on-premise продукта у вендоров пересмотреть архитектуру будет значительно проще.