Как выбрать LLM-провайдера для бизнеса: evals, данные, SLA, TCO и exit plan

Выбирают не модель, а производственную зависимость

Демонстрация в чате показывает качество одного ответа. Бизнес покупает API, через который будут проходить данные, бюджет и критические процессы. Значение имеют lifecycle моделей, доступность региона, квоты, поддержка, договор и способность компании сменить route.

Один поставщик может отлично подходить для публичного контента и не проходить требования закрытых документов. Поэтому решение принимают по workflow × data class, а не одним рейтингом для всей компании.

Шаг 1. Опишите сценарий и цену ошибки

Начните с результата: классификация обращения, поиск по договору, генерация кода или агентное действие. Укажите объём, latency, языки, input types, data class, ручную проверку и последствия ошибки.

Workflow: [название]
User outcome: [результат]
Volume and peak concurrency: [данные]
Input/output modalities: [типы]
Languages and regions: [список]
Data class and prohibited destinations: [policy]
Success criteria: [метрики]
Critical errors: [hard limits]
Latency SLO: P50/P95/end-to-end
Budget: cost per successful task
Required capabilities: [tools, schema, batch, cache]
Human approval and fallback: [правила]
Owner and review date: [данные]

Шаг 2. Отделите must-have от желательных функций

Не позволяйте красивой дополнительной функции компенсировать провал обязательного требования.

Шаг 3. Сформируйте shortlist архитектурных вариантов

Сравнивайте не только прямые API. Та же модель через облачную платформу может иметь другой processor, IAM, регион, network perimeter, billing, feature set и support. Также возможны managed open models и self-hosting.

Шаг 4. Собственный eval-набор вместо рейтинга в интернете

Публичный benchmark не знает вашу taxonomy, документы и критические ошибки. Создайте закрытый versioned набор из golden, regression, edge и safety cases. Каждый кандидат получает одинаковые входы и эквивалентный контракт.

Capabilities: проверяйте поведение, а не галочку

Data flow matrix: каждый endpoint рассматривается отдельно

Общее обещание на странице privacy не заменяет анализ конкретной функции. Files, batch, cache, web search, code execution, logs и fine-tuning технически требуют разной обработки и хранения.

Для каждого endpoint/feature:
- отправляемые data classes;
- processor/controller roles;
- processing/storage regions;
- retention default и configurable;
- training/model-improvement default и opt-in/out;
- abuse monitoring и исключения;
- sub-processors;
- encryption и key options;
- deletion/export mechanism;
- logs, files, cache и backups;
- доступность ZDR и исключённые функции;
- ссылка, дата проверки и договорное подтверждение.

Не путайте «не обучаем» и «не храним»

Данные могут не использоваться для обучения, но временно храниться для предоставления функции или мониторинга злоупотреблений. Zero data retention также может распространяться не на все endpoints и быть доступным только после согласования.

OpenAI публикует отдельные data controls по endpoints; Anthropic документирует eligibility функций для ZDR и различия между прямым API и доступом через облачные платформы. Условия меняются - источником истины остаются ваш договор и актуальная документация, а не эта статья.

Регион, data residency и трансграничная обработка

Уточните, где обрабатываются prompt, response, files, logs, support tickets и backups. «Ресурс создан в регионе» не всегда означает, что все служебные данные остаются там.

Security due diligence: сертификат не заменяет архитектуру

Проверьте Trust Center и доступные отчёты, но свяжите контроль со своим threat model. Важны IAM, service accounts, key rotation, private networking, audit logs, tenant isolation, incident notification и vulnerability process.

SLA: читайте формулу, исключения и remedy

Маркетинговая доступность и договорный SLA - разные вещи. Разберите измеряемый сервис, период расчёта, регионы, исключения, плановые работы, обязанности клиента, сроки подачи claim и service credits.

SLA review:
- covered service/endpoints/models;
- availability formula and measurement window;
- excluded failures and force majeure;
- regional vs global calculation;
- latency or only availability;
- support severity and response targets;
- customer logging needed for claim;
- claim deadline and remedy;
- change/deprecation notice;
- no-SLA preview features;
- dependency SLA and your end-to-end SLO.

Service credit не восстанавливает потерянный бизнес-процесс. Нужны собственные fallback и degradation strategy.

Quotas, rate limits и реальная ёмкость

Открытая документация показывает общую модель лимитов, но фактическая quota зависит от аккаунта, региона, модели и тарифа. Запросите значения до запуска и подтвердите нагрузочным тестом.

Latency: измеряйте end-to-end и длинный хвост

Time to first token важен для streaming UX, но агентный workflow зависит от полной генерации, tools, retries и fallback. Снимайте P50/P95/P99 по cohorts, регионам, длине, model settings и часу нагрузки.

• Cold и warm behavior.
• Короткие и длинные prompts.
• Structured output и tools.
• Streaming cancellation.
• Batch отдельно от interactive.
• Ошибки, throttling и retries.
• Gateway и network overhead.
• Время ручного handoff.

Полная стоимость владения, а не цена миллиона токенов

Сложите API input/output/cache, инструменты, embeddings, хранение и networking. Добавьте интеграцию, evals, observability, security, поддержку, retries, ручные исправления, резервного провайдера и миграции.

TCO периода =
API usage всех попыток +
tools/search/storage/network +
engineering и integration +
security/compliance/procurement +
evals и monitoring +
support и incidents +
human review/rework +
redundancy and reserved capacity +
migration/deprecation/exit cost

Cost per successful task =
TCO / принятые результаты по quality contract

Support: проверьте до настоящей аварии

Название enterprise-плана ничего не говорит о практической эскалации. Уточните severity definitions, каналы, часы, response и update cadence, архитектурные консультации и порядок привлечения engineering.

Lifecycle моделей и уведомления об изменениях

Узнайте, как объявляются новые версии, deprecation и shutdown; сколько времени даётся на migration; может ли floating alias поменяться; какие preview-функции не имеют гарантий.

Договорная матрица: что фиксировать письменно

Это не юридическая консультация; итоговые формулировки проверяет юрист в применимой юрисдикции. Техническая команда должна передать ему точную data-flow и operational модель.

Vendor lock-in: что должно оставаться переносимым

Полная абстракция невозможна, но business contract, evals и данные должны пережить смену поставщика. Изолируйте provider adapter и храните исходные prompt/eval artifacts вне закрытой консоли.

Пилот: четыре недели доказательств, а не demo

1. Неделя 1: требования, data flow, shortlist и hard gates.
2. Неделя 2: интеграционный adapter, eval и security review.
3. Неделя 3: load, quota, failure и support drill.
4. Неделя 4: shadow/canary на разрешённом cohort и TCO report.

Пилот должен завершиться решением с доказательствами: approve для конкретного scope, условное approve с ограничениями или reject. Не распространяйте результат одного use case на все данные компании.

Scorecard: как не спрятать stop-фактор за средним баллом

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

Hard gates: data policy, critical quality, required capabilities, contract.
Weighted dimensions after gates:
- task quality by cohort;
- latency and capacity;
- cost per successful task;
- security and governance;
- operational maturity/support;
- lifecycle and portability;
- implementation effort.
Для каждой оценки: evidence link, owner, confidence, date.
Добавь sensitivity analysis: изменится ли победитель при других весах?

Exit plan до подписания договора

Итоговый чек-лист выбора LLM-провайдера

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