Продление контракта на LLM-сервис: что проверить до подписи

Почему не стоит продлевать договор автоматически

Автопродление удобно только на словах. На практике оно закрепляет старые условия, хотя у команды уже другой трафик, другой набор моделей и другие риски. Перед подписью полезно остановиться и проверить, что вы действительно получили за срок договора.

Сначала сравните обещания с фактом. Если провайдер обещал определенный уровень доступности, скорость ответа и время реакции поддержки, поднимите свои логи, тикеты и отчеты по инцидентам. Часто картина оказывается простой: на бумаге SLA выглядит приемлемо, а в рабочие часы сервис тормозит, упирается в лимиты или ведет себя нестабильно на пике нагрузки.

Отдельно посмотрите, где сервис подводил сильнее всего. Для одной команды критична лишняя задержка в 2-3 секунды, потому что ломается пользовательский сценарий. Для другой болезненнее внезапные rate limits, долгая эскалация в поддержке или расплывчатые ответы после сбоя. Если эти проблемы уже били по продукту, продлевать договор без пересмотра условий странно.

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

Есть и совсем прямой вопрос: нужен ли вам тот же объем и тот же набор моделей. Команда могла уйти от экспериментов к продакшену, сократить число сценариев или, наоборот, добавить RAG, голосовые функции и batch-задачи. Тогда старый пакет уже не подходит, даже если сервис работал без крупных аварий.

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

Что собрать до разговора с провайдером

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

Поднимите историю работы хотя бы за последние 6-12 месяцев. Нужен не один громкий сбой, а вся картина: сколько было инцидентов, как долго они длились, в какие часы происходили и как часто команде приходилось эскалировать вопрос вручную. Даже короткие, но регулярные просадки тоже влияют на бизнес.

Соберите метрики из своих систем, а не только отчеты провайдера. Обычно достаточно четырех блоков:

• фактический uptime по вашим запросам
• средняя задержка и p95 по основным сценариям
• доля ошибок по кодам и типам моделей
• просадки по дням, релизам и пиковым нагрузкам

Лучше свести это в одну таблицу. Тогда видно, где проблема в самом сервисе, а где в вашей интеграции.

Дальше проверьте деньги. Поднимите счета за тот же период и разложите расходы не только по общей сумме, но и по моделям, токенам, кешу, rerank, moderation, embeddings и другим платным функциям. Средний чек часто скрывает перекос: одна модель незаметно начинает съедать половину бюджета из-за роста выходных токенов.

Еще один блок - зависимости. Запишите, какие SDK, base_url, форматы ответов, ретраи, таймауты, системные промпты и внутренние сервисы завязаны на текущего провайдера. Без такого списка легко услышать фразу "перейти можно в любой момент", хотя на деле замена займет недели.

Хороший признак готовности простой: за 15 минут вы можете показать провайдеру, где были сбои, за что вы платили и что сломается при смене маршрута запросов.

Как разобрать SLA по шагам

SLA полезно читать не как формальность, а как описание того, сколько простоя вы реально покупаете вместе с сервисом. Смотрите не только на обещанный процент доступности, но и на отчеты за последние месяцы.

Начните с заявленного uptime. Если в презентации стоит 99,9%, попросите помесячную статистику и журнал крупных сбоев. Сразу уточните, что именно считали доступностью: весь API, конкретные модели, отдельные регионы или только главный endpoint.

Потом разберите формулу простоя. В договоре часто исключают плановые работы, сбои у внешних провайдеров, сетевые проблемы на стороне клиента и частичную деградацию. Именно тут цифры обычно расходятся. Сервис формально отвечает, но задержка выросла в несколько раз, таймаутов стало больше, а в SLA это не считается инцидентом.

Дальше проверьте сроки по уровням инцидентов. Вас интересуют не общие фразы, а числа:

• за сколько минут поддержка подтверждает P1 и P2
• когда начинается работа по инциденту
• какой срок решения обещан по каждому уровню
• действуют ли отдельные правила ночью, в выходные и праздники
• кто и как сообщает о смене приоритета

После этого переходите к компенсации. Сервисные кредиты аккуратно смотрятся в договоре, но на счет влияют слабо. Если простой для вас дорогой, обсуждайте денежную компенсацию, право на досрочное расторжение или хотя бы повышенный кредит при повторных сбоях.

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

Если сервис и маршрутизирует запросы к внешним моделям, и держит собственные модели, просите отдельные SLA по этим частям. Один общий процент может скрывать две очень разные зоны риска.

Что спросить про инциденты

На созвоне не просите "общую картину по надежности". Просите документы. Нормальный вопрос звучит так: пришлите 3-5 последних постмортемов по серьезным сбоям. Если в них только общие слова без времени, причины, масштаба и действий после аварии, это плохой знак.

Хороший постмортем показывает цепочку событий: когда началась проблема, кто заметил ее первым, сколько запросов затронуло, какие модели или регионы пострадали, как команда сняла нагрузку и что изменила после инцидента. Формулировки вроде "наблюдалась деградация" и "сервис восстановлен" почти бесполезны. По ним нельзя понять, повторится ли тот же сценарий снова.

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

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

Отдельно проверьте схему уведомлений. Кто получает алерт: ваш дежурный инженер, аккаунт-менеджер, чат поддержки или почта закупок? Через сколько минут после начала сбоя клиенту пишут? И предупреждают ли они только о полной недоступности, или еще и о росте задержки и ошибок по отдельным моделям?

После этого задайте самый практичный вопрос: что изменилось после прошлых аварий. Ждите конкретики. Например, новый порог алертов по latency и error rate, автоматический перевод трафика на резервного провайдера, жесткие лимиты, чтобы квоты не заканчивались днем, или отдельный статус для частичной деградации. Если после двух похожих инцидентов меры не менялись, проблема уже не в невезении, а в процессе.

Как проверить работу с данными

Фраза "мы ничего не сохраняем" почти всегда требует расшифровки. Провайдер может не хранить сами промпты, но при этом сохранять логи запросов, вложения, служебные метки, трассировки ошибок и резервные копии.

Даже если команда просто меняет base_url и оставляет тот же SDK, путь данных меняется. Поэтому в договоре и приложениях нужны не общие обещания, а точные ответы: где лежат логи, где находятся резервные копии, какие технические метки сохраняются по запросу и сколько все это хранится.

Отдельно проверьте маскирование. Какие поля сервис скрывает сам: ФИО, телефоны, почту, номера документов, номера карт? Кто задает правила - ваш администратор, аккаунт-менеджер провайдера или только поддержка? Если правила меняются, кто это согласует и как быстро изменения вступают в силу?

Еще один неудобный, но важный вопрос: кто внутри провайдера видит содержимое запросов. Просите назвать роли, а не отделы в общих словах. Одно дело, если доступ есть у дежурной SRE-команды по заявке на инцидент. Совсем другое, если промпты и ответы видят аналитики, поддержка и подрядчики.

Что зафиксировать в договоре

• адреса и юрисдикцию хранения логов, резервных копий и служебных данных
• сроки удаления для каждого типа данных
• роли сотрудников с доступом к промптам, ответам и вложениям
• формат и срок выдачи аудит-трейлов по запросу
• правила маскирования и порядок их изменения

Если вы обрабатываете персональные данные, сверяйте это с требованиями 152-ФЗ, а не с рекламным текстом на сайте. Для российской компании мало фразы "данные храним в РФ". Нужны детали по логам, резервным копиям, доступу сотрудников и журналу действий.

Небольшой пример: банк запрещает хранить клиентские номера договоров в логах. Провайдер отвечает, что маскирует PII, но не может показать, какие поля входят в шаблон и как выглядит аудит-трейл удаления. На этом этапе продление лучше поставить на паузу. Иначе через месяц спор пойдет уже не о функции сервиса, а о том, кто и где держал ваши данные.

Где цены растут незаметно

Цена почти никогда не прячется только в строке "за 1 млн токенов". Она уходит в соседние услуги, в округление, в валюту счета и в доплаты, которые появляются уже после роста нагрузки.

Частая ошибка - сравнить два прайса по входным и выходным токенам и на этом остановиться. Если в проде есть кеш, embeddings, rerank или генерация изображений, итоговый счет легко вырастает на десятки процентов.

Смотрите не абстрактную цену, а свой обычный сценарий. Например: 10 000 запросов в день, короткий системный промпт, длинный пользовательский контекст, кеш для повторяющихся частей, embeddings для поиска и rerank на финальном шаге. Такой расчет быстро показывает, где провайдер дешев на витрине, но дорог в реальной работе.

Проверьте пять вещей:

• как считаются токены: точное потребление или округление вверх до пакета, запроса или сессии
• есть ли минимальный чек, обязательный commit или порог, после которого меняется ставка
• сколько стоят приоритетная очередь, выделенная мощность, повышенные лимиты и расширенная поддержка
• в какой валюте приходит счет, включен ли НДС и кто несет риск курсовой разницы
• как провайдер меняет тарифы: по уведомлению, сразу для новых запросов или только при продлении

Отдельно спросите про кеш. У одних провайдеров он действительно снижает расход, у других оплачивается сам по себе, и экономия выходит заметно меньше. То же касается изображений и embeddings: низкая цена на чат не спасает, если вспомогательные вызовы стоят существенно дороже.

Если вы сравниваете варианты через российский шлюз, имеет смысл сразу уточнить, как считаются ставки провайдеров и как оформляется B2B-счет в рублях. Например, у RU LLM тарифы идут по ставкам провайдеров без наценки на API, а биллинг остается внутри РФ. Для бюджета и согласования с финансами это просто снимает часть сюрпризов.

В договоре лучше отдельно зафиксировать валюту, НДС, порядок пересмотра цен и срок уведомления. Иначе "дешевый" тариф становится дорогим именно в тот месяц, когда сервис нужен сильнее всего.

Как подготовить выход к другому провайдеру

План выхода нужен до продления, а не после сбоя. Если провайдер поднимет цены, урежет лимиты или начнет часто падать, команда должна переключиться за часы, а не собирать детали в спешке.

Сначала составьте карту зависимостей от текущего API. Обычно забывают не код, а мелочи: base_url, имена моделей, лимиты RPM и TPM, формат ответов, настройки ретраев, таймауты, правила fallback, embeddings и особенности tool calling. Если запасной вариант совместим с OpenAI API, переход иногда действительно сводится к смене base_url и ключа. Но это нужно проверять на своем трафике, а не принимать как данность.

Не меньше риска в том, что живет вне кода. Сохраните промпты, системные инструкции, JSON-схемы, шаблоны ответов, тестовые наборы и эталонные результаты. Иначе новый провайдер формально заработает, но качество тихо просядет.

Полезно ответить на несколько простых вопросов:

• что у нас жестко привязано к текущему провайдеру, кроме base_url
• какие модели и лимиты используются в проде и в стейджинге
• где лежат промпты, тесты и ожидаемые ответы
• за сколько минут команда сможет перевести хотя бы часть трафика на запасной маршрут
• как мы выгрузим логи, аудит-трейлы и историю расходов

После этого устройте репетицию. Переведите 5-10% трафика на запасной вариант и посмотрите на задержку, ошибки, стоимость и поведение ответов. Один день такого прогона обычно полезнее длинной переписки с аккаунт-менеджером.

Отдельно пропишите срок доступа после расторжения. Вам нужен не символический период, а время, за которое команда успеет снять логи, акты, детализацию расходов и проверить спорные запросы. Если это не закрепить в договоре, через пару недель после отключения можно остаться без данных, которые нужны для аудита или спора по счету.

Где команды ошибаются чаще всего

Самая частая ошибка проста: команда спорит о скидке и почти не считает цену простоя. Если сервис падает в рабочий день, вы теряете не только токены, но и время поддержки, очередь задач и терпение пользователей.

Дешевая ставка за токен легко выглядит выгодной на бумаге. На деле один сбой в пиковый час может стоить больше, чем вся месячная экономия. Поэтому рядом с прайсом держите свои цифры: сколько запросов вы теряете, сколько времени уходит на ручной обход и сколько стоит час простоя для команды и клиентов.

Вторая типичная ошибка - верить обещанному uptime без собственных замеров. В договоре может быть красивое число, но вас интересует ваша нагрузка: задержка на длинных ответах, ошибки в часы пик и поведение резервных маршрутов. Если вы не снимали метрики сами, разговор с провайдером быстро превращается в обмен общими фразами.

Проблемы обычно всплывают в одних и тех же местах:

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

Право на выгрузку данных многие вспоминают слишком поздно. А без логов, метрик и истории запросов сложно сравнивать провайдеров, разбирать инциденты и восстанавливать картину по спорному списанию. Для компаний с требованиями 152-ФЗ это еще чувствительнее: без журналов и аудит-трейлов трудно доказать, что происходило с запросами.

С выходом к другому провайдеру то же самое. Если тест миграции отложили на конец срока, вы уже торгуетесь из слабой позиции. Намного спокойнее заранее проверить, можно ли сменить base_url, сохранить SDK и промпты, а потом прогнать часть трафика через запасной вариант.

Короткий пример перед продлением

У ритейл-команды чат поддержки работал через одного LLM-провайдера. Обычно все было спокойно, но за один квартал случились два сбоя в часы пик. Оба раза чат отвечал медленно, часть запросов уходила в таймаут, а операторы вручную разбирали очередь.

Почти в тот же период вырос счет. Причина оказалась не в трафике как таковом, а в длине ответов: модель стала писать подробнее, и стоимость completion заметно подросла. Если смотреть только на общий инвойс, это легко пропустить.

Перед продлением команда не пошла сразу в закупку. Она запросила у провайдера постмортемы по двум инцидентам, выгрузку расходов по моделям и типам запросов, а еще точные сроки удаления логов и резервных копий. Заодно попросили показать, как провайдер уведомляет о смене тарифов и где фиксируется retention по данным.

После этого картина стала яснее. Сами сбои не выглядели катастрофой, но из постмортемов было видно, что у провайдера нет четкого окна ответа по инцидентам. В расходах тоже нашелся перекос: около 18% бюджета съедали ответы, которые можно было сократить системным промптом и лимитом на длину.

Контракт команда продлила, но уже на других условиях. Основной сервис оставили для обычной нагрузки, а для резерва добавили совместимый с OpenAI шлюз, чтобы не переписывать SDK и код при переключении. Для команд в РФ таким вариантом может быть RU LLM: один endpoint, биллинг в рублях и хранение логов внутри страны. Это не замена проверке, а способ не остаться без запасного маршрута.

Самое полезное решение было не в бумагах, а в практике. Команда заранее провела тест переключения. На это ушел один вечер, зато при следующем сбое у нее уже был рабочий план.

Быстрая проверка перед подписью

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

• сверьте заявленный uptime со своими замерами за последний квартал или полгода
• проверьте, что сроки реакции по P1 и P2 записаны в договоре или приложении, а не только в письмах и презентациях
• покажите правила хранения, логирования и удаления данных юристам и ИБ
• пересчитайте цену на реальных сценариях, а не на среднем запросе
• зафиксируйте план выхода: ответственных, срок переключения, формат выгрузки и запасной endpoint

Одна из самых дорогих ошибок выглядит буднично: команда смотрит на базовую ставку, но не считает полный трафик. Тестовый сценарий выходит недорого, а после запуска в прод длинные ответы и ночные batch-задачи поднимают счет на 30-40%.

Такого мини-аудита обычно достаточно, чтобы не подписать слабые условия. Если у вас уже есть запасной провайдер с совместимым API, переход проще: команда меняет base_url, прогоняет smoke test и держит рабочий резерв, а не только план на бумаге.

Что сделать дальше

Перед подписью соберите на полчаса тех, кто потом будет отвечать за последствия: юриста, ИБ, финансы и владельца продукта. Если встречу ведут только закупка и sales со стороны провайдера, разговор почти всегда уходит в расплывчатые обещания. Нужны документы, цифры и ответы по спорным местам договора.

Откройте SLA, последние отчеты по инцидентам, счета за несколько месяцев и список данных, которые реально уходят в запросах. Если по какому-то пункту нет подтверждения в договоре, логах или письмах, ответа пока нет.

Юристу важны штрафы, сроки уведомления об инцидентах, право на одностороннее расторжение и порядок выгрузки данных. ИБ смотрит, где лежат логи, кто имеет к ним доступ, как маскируются персональные данные и что остается в резервных копиях. Финансы проверяют не только цену за токены, но и минимальные платежи, округление, плату за пики нагрузки и изменение ставок по моделям. Владелец продукта подтверждает, что качество, задержка и лимиты устраивают команду не в демо, а в рабочих сценариях.

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

Если вам нужен российский резервный маршрут, сравните его заранее с основным вариантом. У RU LLM, например, единый endpoint, совместимый с OpenAI, хранение логов и резервных копий в РФ и B2B-инвойсинг в рублях. Даже если менять провайдера вы сейчас не собираетесь, такой вариант полезен хотя бы как проверенный план выхода.