Перевод SaaS-платформы с облачных LLM API на собственные модели
Мы перевели европейскую SaaS-платформу, которая извлекает данные из финансовых документов и готовит по ним сводки для банков и кредиторов, с коммерческого LLM API на дообученные открытые модели. Их обслуживает vLLM на выделенных GPU под контролем клиента. За 12 недель на собственный контур ушло 96 % трафика при подтверждённом паритете качества, затраты на инференс снизились на 75 %, а данные перестали покидать ЕС — это открыло сделки с регулируемыми банками.
- срок проекта
- 12 недель
- функциональных модулей
- 7
- этапов разработки
- 4
- ключевых технологий
- 8
02 — Контекст
Задача проекта
Исходная ситуация, ограничения и проблемы, которые должна была решить новая система.
Продукт клиента быстро собрали на коммерческом LLM API, и он хорошо работал: промпты были отлажены, качество устраивало. Проблема была в экономике. Платформа прогоняла через API около 6 млрд токенов в месяц, счёт приближался к $28 000 в месяц и рос с каждым новым клиентом. При текущих темпах роста он удвоился бы за год.
Вторая проблема была серьёзнее. Две сделки с регулируемыми банками застряли на проверке поставщика. Банки возражали не против AI, а против архитектуры, в которой данные их клиентов покидают юрисдикцию и попадают к стороннему обработчику, которого банк не выбирал. Убрать этого обработчика, оставаясь на облачном API, клиент не мог.
Мигрировать нагрузку, которую нельзя измерить, невозможно: после переключения часто выясняется, что эталона поведения старой модели не было — было лишь общее ощущение, что всё работает. Поэтому до любой работы с моделями мы построили контур оценки качества, а переключение привязали к порогу паритета, который согласовали с клиентом до первого дообучения.
Счёт растёт вместе с бизнесом
Расходы на токены почти линейно следовали за объёмом. Каждый новый клиент приносил переменные затраты, которые не убрать доработкой приложения, а маржу определял чужой прайс-лист.
Сделки с банками встали на проверке
Трансграничная передача данных и сторонний обработчик в цепочке блокировали проверку поставщика в двух регулируемых банках. Для клиента это стоило в цикле продаж больше, чем экономия на токенах.
Зависимость от чужой модели
Промпты были настроены под конкретную версию модели поставщика, а её вывод из эксплуатации уже однажды объявляли. Любое такое решение поставщика грозило перенастройкой всего продукта.
03 — Возможности
Что делает система
Ключевые сценарии и рабочие модули, собранные в единую систему.
Контур оценки качества
Эталонный набор примерно из 2 000 примеров с метками, проверенными людьми, собран из реального трафика с разбивкой по задачам и сложности. Оценка по возможности детерминированная: точное совпадение, проверка по схеме, F1 по полям. Там, где без модели-судьи не обойтись, её калибруют по ручной разметке и публикуют степень согласия.
Маршрутизация по сложности
Разбор трафика показал, что 92 % вызовов — узкие задачи: извлечение данных в схему, классификация, маршрутизация, короткие сводки. Небольшой классификатор назначает уровень обработки до генерации, не спрашивая большую модель, нужна ли большая модель. В итоге 96 % трафика обслуживает собственный контур.
Основная модель на vLLM
Основную нагрузку обслуживает дообученная Qwen 3 32B в точности FP8. vLLM даёт непрерывный батчинг, страничный KV-кеш и совместимый эндпоинт chat completions, поэтому код приложения переехал на новый контур сменой одного базового URL. Веса модели хранятся на дисках клиента.
Структурированный вывод по схеме
Ответы, которые должны быть JSON, генерируются с декодированием по схеме. Корректный JSON становится свойством декодера, а не результатом повторных попыток: ответ проходит валидацию с первого раза, и ремонтировать сломанный JSON регулярными выражениями не нужно.
Облачный резерв по политике клиента
Самые сложные запросы маршрутизатор отправляет в коммерческий API только там, где это разрешает политика данных конкретного клиента платформы. Это настройка на уровне клиента, а не глобальный флаг сборки. Регулируемые клиенты работают полностью локально, для новых клиентов резерв по умолчанию выключен.
Изолированный контур инференса
Инференс работает в отдельном сегменте сети без исходящего доступа по умолчанию. Веса скачаны один раз и проверены по хешу, образы закреплены по дайджесту, а не по тегу, поэтому пересборка через полгода даёт тот же сервер, что прошёл проверку. Облачный резерв, если он включён, — единственный разрешённый внешний канал, и каждый запрос по нему журналируется.
Журнал аудита и защита данных
Персональные данные удаляются или токенизируются при приёме, а не после записи. Выборка для оценки ограничена тем, что нужно метрикам, сроки хранения задаются по каждому клиенту с реальным удалением. Журнал фиксирует, какой уровень и какая версия модели обслужили каждый вызов, — всё в PostgreSQL вместе с прогонами оценки и решениями маршрутизатора.
04 — Архитектура
Технологический стек
Технологии выбраны под нагрузку, интеграции и дальнейшее развитие продукта.
Зачем в проекте · 01 / 08
vLLM
Непрерывный батчинг, страничный KV-кеш и эндпоинт chat completions из коробки. Писать собственный слой батчинга и планирования не стали: эти задачи решены, а самодельная очередь работает хуже и требует отдельного человека на сопровождение.
- LLM Fine-tuning
05 — Процесс
Как шла разработка
Последовательность работ от исследования задачи до запуска и проверки результата.
Недели 1–3: контур оценки
Собрали выборку реального трафика, составили классификацию задач, построили эталонный набор и реализовали метрики. Базовый прогон прежнего API по эталонному набору задал планку, которую миграция должна была взять. Порог паритета для переключения согласовали с клиентом здесь же.
Недели 4–8: модели и инференс
Прогнали кандидатов через контур оценки на арендованных H100, дообучили Qwen 3 32B и развернули инференс на vLLM. Квантизацию считали решением о качестве, а не способом сэкономить память: прогоняли метрики на каждой точности и оставили FP8.
Теневой режим
Живой трафик зеркалировался на новый контур: оба ответа оценивались, но пользователям уходил только ответ прежнего API. Так получили отчёт о паритете на реальном распределении запросов, а не только на эталонном наборе.
Канареечный запуск и переключение
Переключение разрешил отчёт теневого режима, сравненный с порогом из первой недели, а не решение, принятое под давлением сроков. Трафик переводили ступенями с автоматическим откатом при росте ошибок или задержки — откат так ни разу и не сработал. Всё это время прежняя система обслуживала каждый запрос.
06 — Итог
Результаты
Что создано в рамках проекта: рабочий контур, реализованные возможности и подтверждённые факты.
- затрат на инференс: с ~$28 000 до менее $7 000 в месяц
- −75 %
- трафика обслуживает собственный контур
- 96 %
- паритет с прежним API на эталонном наборе
- 99,2 %
- до полного переключения
- 12 недель
Дообученная модель набрала 99,2 % от доли успешных ответов прежнего API на эталонном наборе, а отчёт теневого режима на живом трафике превысил согласованный порог ещё до переключения. После переключения собственные метрики качества клиента, которые видят его пользователи, не просели. Маршрутизация устоялась на уровне 96 % трафика на собственном контуре; остаток сложных запросов уходит в коммерческий API у тех клиентов платформы, чья политика это разрешает.
Счёт почти в $28 000 в месяц за токены превратился в менее $7 000 в месяц с учётом всего: аренды выделенных GPU, остаточных расходов на облачный резерв и доли времени инженера на сопровождение. При том же объёме это снижение примерно на 75 %. Важнее даже не уровень расходов, а их форма: инференс стал постоянной статьёй, и маржа растёт вместе с клиентом. Задержка p95 на основном контуре снизилась примерно на треть.
Инференс теперь работает внутри ЕС, сторонний обработчик исчез из карты данных, и возражение, на котором стояли две сделки с банками, снялось: обе проверки поставщика пройдены. Контур оценки остался у клиента как постоянная инфраструктура: каждое изменение промпта и обновление модели прогоняется через него, поэтому дальнейшие смены моделей решаются по метрикам, а не по ощущениям.
Детали проекта
Почему кейс без имени клиента
Название клиента мы не раскрываем. Это европейская SaaS-компания, которая автоматизирует обработку финансовых документов для банков и кредиторов. Её архитектура данных и список обработчиков — предмет переговоров с банками, поэтому закрытыми остаются название, клиентская база и всё, что позволяет их вычислить. Рекомендацию клиента можем предоставить по запросу под NDA.
При этом мы открыто рассказываем, как устроена миграция: контур оценки до любой работы с моделями, маршрутизация по сложности, дообученная Qwen 3 32B на vLLM, теневой режим и поэтапное переключение за 12 недель. По этому описанию несложно прикинуть, как такой переезд выглядел бы для вашего продукта, — а конкретику под ваш трафик и требования к данным разберём на встрече.
FAQ
Вопросы о проекте
Далее
Похожие проекты
Обсудим похожий проект?
Расскажите о задачах вашего бизнеса — предложим архитектуру и оценим сроки
