При корпоративной закупке платформы LLM API чаще всего ошибаются, глядя только на цену за единицу и количество моделей. На запуск в реальности влияют стабильность, прозрачность счетов, права доступа, комплаенс и стоимость эксплуатации.

Ниже — практический чек-лист для технического руководителя, закупщика и юриста.

Примечание: все упомянутые бренды — товарные знаки соответствующих правообладателей. Материал носит технический характер; цены и политики смотрите на сайтах платформ.

1. Сначала определите бизнес-требования

1.1. Модели

  • Какие модели нужны: Claude, GPT, Gemini, DeepSeek, локальные модели?
  • Нужны ли мультимодальность, вызов инструментов, длинный контекст, структурированный вывод?
  • Должна ли версия модели быть фиксированной?

1.2. Масштаб

  • Запросы в день и пиковая параллельность.
  • Средний объём входных и выходных токенов.
  • Нужны ли несколько регионов и каналов.

1.3. Управление

  • Сколько участников и проектов?
  • Нужны ли лимиты по проектам и журнал аудита?
  • Нужны ли счета, договор и безналичная оплата?

1.4. Комплаенс

  • Допустима ли передача данных за границу?
  • Есть ли персональные или чувствительные данные?
  • Нужны ли соглашение об обработке данных, оценка соответствия и аудит?

2. Таблица оценки закупки

Критерий Вес Что оценивать
Покрытие моделей 20% Нужные модели в наличии, стабильные версии
Стабильность 20% Доля ошибок, P95, ограничения, повторы
Прозрачность биллинга 15% Цены, коэффициенты, кеш, возвраты
Права и лимиты 15% Разграничение по участникам, проектам и ключам
Журналы и мониторинг 10% Детализация вызовов, оповещения, экспорт
Поддержка 10% Документация, скорость ответа на тикеты
Комплаенс 10% Договор, счета, условия обработки данных

Оценивайте каждого поставщика отдельно и не смотрите только на итоговый балл: если критичный критерий не выполнен, кандидат отсеивается.

Отдельно оцените, как поставщик ведёт себя при изменении цен и моделей: предупреждает ли заранее, сохраняет ли старые версии на переходный период, что происходит с уже начатыми запросами. Эти детали редко попадают в презентации, но именно они определяют стоимость эксплуатации.

3. Как провести POC

3.1. Фиксированный набор тестов

Подготовьте 20–50 реальных бизнес-запросов, покрывающих:

  • короткие и длинные тексты;
  • вызов инструментов;
  • мультимодальность (если нужна);
  • некорректные входные данные.

3.2. Сравниваемые показатели

  • Качество вывода (ручная или автоматическая оценка).
  • Задержка первого токена и P95.
  • Доля успешных запросов, доля 429 и 5xx.
  • Стоимость одного запроса.
  • Понятность сообщений об ошибках.

3.3. Постепенное включение

Сначала переведите 5–10% трафика, наблюдайте 3–7 дней, затем увеличивайте долю.

Для POC назначьте ответственного и критерии успеха заранее. Иначе результат сведётся к субъективному «вроде работает», а сравнение платформ будет трудно защитить перед руководством.

4. Договор и счета

При корпоративной закупке уточните:

  • Сторону договора, объём услуг, SLA.
  • Модель биллинга и порядок уведомления об изменении цен.
  • Хранение, удаление данных и использование для обучения.
  • Тип счёта и срок выставления.
  • Условия возврата и расторжения.
  • Уведомление об инцидентах безопасности.

Если поставщик предлагает пилотный договор, проверьте, распространяются ли на него те же условия обработки данных, что и на основной контракт.

Платформу без договора и условий обработки данных не стоит сразу выводить в продакшен.

5. Как считать стоимость

Совокупная стоимость =
  расход на токены
+ повторные и неуспешные запросы
+ доп. расходы на длинный контекст и мультимодальность
+ трудозатраты на эксплуатацию
+ затраты на комплаенс и закупку

Низкая цена за единицу при жёстких ограничениях и сложном разборе ошибок может дать более высокую совокупную стоимость.

Учитывайте и стоимость переключения: переписывание интеграции, повторные тесты, обучение команды. Иногда более дорогой тариф с совместимым API оказывается дешевле в первый год.

6. Частые вопросы

Чем больше моделей, тем лучше?

Нет. Сначала определите, что нужно бизнесу, затем смотрите на стабильность версий и поддержку.

Нужно ли несколько поставщиков?

Рекомендуется основной и резервный каналы, чтобы избежать простоя из-за одного поставщика. Но сложность эксплуатации должна оставаться управляемой.

Собственный шлюз или готовая платформа?

При наличии команды и требований к контролю данных или кастомизации — собственный шлюз. Без ресурсов на эксплуатацию — управляемый сервис. Общие принципы выбора — в статье Что такое API-релей.

Как проверить стабильность?

Проводите тест на малом трафике 3–7 дней подряд, фиксируйте успешность, P95, 429 и 5xx. Одного запроса недостаточно.

Что дальше

Если вы выбираете платформу, начните с POC на ключе с небольшим лимитом в ZSQH AI Gateway, затем сравните с другими платформами. Модели и цены — на странице тарифов.

Похожие материалы: