Как среднему и крупному бизнесу выстроить мультимодельные AI-пайплайны через один ключ

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

Ниже — рабочая схема, которую можно собрать без отдельного договора на каждого поставщика моделей. Это не история про «внедрили ИИ и сократили отдел». Это история про конвейер: на каждый шаг — своя модель, одна модель проверяет другую, при отказе провайдера сценарий переключается на запасную, а бухгалтерия получает один счёт и один акт. Расчёт стоимости — на примере, не на клиентских цифрах. Цены моделей взяты из публичного каталога шлюза, через который мы считали пример на 13 ноября 2026 года, как на витрине: в рублях за 1 млн токенов, округление вверх до 0,5 ₽. Прайс плавает, перед бюджетом его нужно перепроверить.

В чём ломается схема «один вендор — одна модель»

Типичный путь такой. Пилот делают на флагмане: качество высокое, демо выглядит убедительно. Потом тот же флагман ставят на классификацию писем, извлечение полей из счета, черновик ответа клиенту и контроль качества. Счёт растёт не потому, что моделей «стали больше использовать», а потому, что дорогая модель делает работу, с которой справляется более дешёвая и быстрая.

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

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

Из чего состоит пайплайн, а не «чат с нейросетью»

Рабочий контур почти всегда одинаковый, меняется только предметная область.

1. Извлечение и классификация. Нужно быстро и стабильно получить структурированный результат: тип обращения, стороны договора, поля счета, язык, приоритет. Здесь важны формат JSON, низкая цена и скорость, а не «красивый слог».

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

3. Проверка другой моделью. Вторая модель не пишет текст заново, а ищет противоречия, выдуманные факты, нарушение тона или пропущенный риск.

4. Фолбэк. Если выбранная модель вернула 5xx, зависла или недоступна, сценарий повторяет запрос к модели другого вендора. Для этого не нужен второй договор — нужен тот же API и другой идентификатор модели.

5. Человек на выходе. На претензиях, договорах, персональных данных и деньгах модель не должна ничего отправлять клиенту и контрагенту сама.

В коде это выглядит как смена слага, а не как смена поставщика. OpenAI-совместимый клиент, base URL шлюза, один ключ:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://getheli.ru/v1",
    api_key=os.environ["HELI_KEY"],  # sk-heli-…
)

MODELS = {
    "extract": "deepseek/deepseek-v4-flash",      # 11,5 / 22,5 ₽ за 1 млн
    "draft": "google/gemini-3.7-flash",           # 52 / 258,5
    "review": "anthropic/claude-sonnet-5",        # 276 / 1 378,5
    "fallback": "openai/gpt-5.4-mini",            # 103,5 / 620,5
}

def complete(step, messages, **kwargs):
    try:
        return client.chat.completions.create(
            model=MODELS[step], messages=messages, timeout=60, **kwargs
        )
    except Exception:
        return client.chat.completions.create(
            model=MODELS["fallback"], messages=messages, timeout=60, **kwargs
        )

Это схема приложения, не встроенная «магия» шлюза. Шлюз здесь нужен для другого: все эти модели доступны одним ключом, одним балансом и одним комплектом закрывающих документов. Маршрутизацию компания держит у себя — в сервисе, в шине или в n8n.

Сколько это стоит, если не гонять всё через флагман

Возьмём пример объёма, характерный для среднего контакт-центра: 50 000 обращений в месяц. На одно обращение в примере закладываем классификацию (800 токенов входа и 200 выхода), черновик ответа (2 500 и 350) и выборочный контроль качества на 25% потока (2 000 и 250). Токены — оценка, не замер на боевых логах.

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

Отдельно стоит сказать про «модель проверяет модель». Это не удваивает счёт, если проверку ставить не на 100% потока, а на жалобы, крупные сделки, высокий юридический риск и расхождения. Типовой вход дешёвая модель закрывает сама, и именно на нём обычно сидит основная масса токенов.

Надёжность: независимость от одного вендора

Юридически компания заключает договор со шлюзом, а не «сразу со всеми лабораториями». Это важно не путать. Смысл не в том, что появляется магический контракт с OpenAI, Anthropic и Google одновременно, а в том, что операционный контур не прибит к одной модели и одной консоли.

Практически это даёт три вещи.

Во-первых, смена шага или запасной модели — это изменение конфигурации, а не новый цикл закупки. Во-вторых, отказ или деградация одной модели не обязан останавливать смену: сценарий уходит на запасную. В-третьих, в журнале расходов можно видеть не только сумму, но и долю ошибок 5xx, отдельно по сбоям шлюза и по сбоям модели. Это уже предмет разговора для ИТ, а не скриншот из личного чата сотрудника.

Фолбэк при исчерпании бюджета — отдельная настройка. В нашем шлюзе (Heli) на лимите 100% запросы либо останавливаются, либо переключаются на указанную резервную модель. Это защита счёта, а не замена обработке аварии в коде. Аварийный сценарий всё равно стоит писать у себя: поймать ошибку, повторить на другом слаге, записать исход в журнал.

Что должно быть у слоя доступа, чтобы пайплайн жил в компании, а не в пилоте

Даже идеально разведённые модели бесполезны, если к концу месяца нельзя ответить на простые вопросы финансового директора и ИБ.

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

В шлюзе, которым пользуемся мы, это уже есть в кабинете: один баланс, проекты как центры затрат, лимиты на день, неделю или месяц, письма при 50, 80, 90 и 100% расхода, роли (включая финансы, которые видят расход и биллинг, но не обязаны управлять ключами), выгрузка CSV или JSON и акт за календарный месяц. Счёт выставляется без НДС, УПД и ЭДО сервис сейчас не даёт — это лучше выяснить с бухгалтерией до первой оплаты, а не после.

Платить при этом можно не «за всё сразу». Баланс предоплаченный, подписки нет: компания докупает объём по мере того, как пайплайн выходит из пилота в прод. Пока денег на запрос не хватает, API отвечает кодом 402 и к модели запрос не уходит. В минус баланс не уходит.

Как запустить это за 30 дней, не рисуя «программу трансформации»

Неделя 1. Выбрать один поток, где уже есть регламент и измеримый объём: обращения поддержки, типовые договоры, лиды в CRM. Собрать несколько сотен реальных примеров (с маскированием персональных данных) и руками разметить, что считается правильным результатом.

Неделя 2. Собрать три шага: извлечение, черновик, проверка. Поставить на первые два дешёвую и среднюю модель, на третий — сильную, и отдельно прогнать тот же набор «всё через флагман». Сравнить качество и стоимость. Если вторая модель на проверке не находит ничего полезного — сузить её зону, а не отключать оптом.

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

Неделя 4. Показать финансовому директору не «мы внедрили ИИ», а две цифры: стоимость токенов на маршрутизации и стоимость того же объёма на одной дорогой модели, плюс доля случаев, где человек меняет черновик. Дальше либо расширять поток, либо останавливаться.

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