Локальная LLM и облачный API: как распределять запросы между моделями
Одна модель классифицирует документы внутри компании, другая помогает с открытыми материалами. Разбираем маршрутизацию, ограничения резервного пути и сравнение стоимости готового результата.
В компании могут одновременно существовать две разумные задачи. Счета поставщиков нужно разбирать внутри управляемой инфраструктуры, а описание публичного товара — редактировать с помощью внешней модели. Попытка выбрать одну LLM «на всё» смешивает требования к данным, качеству и доступности. Полезнее определить маршрут для каждого класса запросов.
Речь не о сравнении моделей по таблице лидеров. Маршрутизатор решает, куда разрешено отправить конкретный набор данных, какое качество требуется и что делать при сбое. Он должен принять решение до внешней передачи. Рассмотрим проектирование гибридного сервиса без привязки к одному поставщику.
Разделите задачи хотя бы на извлечение полей, классификацию, поиск по документам, подготовку черновика и выполнение действия. Затем для каждой укажите допустимые источники и получателей. Название задачи недостаточно: письмо о товаре может включать публичное описание, персональную скидку и вложение с непубличной сметой.
Проверять нужно весь пакет: сообщение, историю диалога, найденные фрагменты, файлы и результаты инструментов. Если из запроса удалили фамилию, но оставили договор с реквизитами во вложении, маршрут не стал публичным. Неопределённый класс данных лучше направлять на разбор, чем автоматически считать разрешённым.
Удобно хранить разрешённые варианты как версионируемую конфигурацию. Ниже пример внутреннего формата, не параметров Ollama, n8n или облачного API. Названия классов и маршрутов условные.
Здесь отсутствие резервного маршрута для счёта — осознанное решение. При недоступности локальной модели запрос ждёт или передаётся сотруднику. Ошибка «сервер занят» не даёт оснований отправить документ в облако. Для разрешённого внешнего пути также фиксируют конкретного получателя, настройки хранения и состав передаваемого контекста согласно принятой политике компании.
Совместимый интерфейс не означает одинаковое поведение #
На уровне приложения можно использовать адаптеры с единым внутренним запросом. Но различия моделей всё равно придётся учитывать: доступный контекст, формат структурированного ответа, обработку инструментов, изображения, потоковую выдачу и коды ошибок.
Например, документация Ollama описывает поддержку части совместимого API. Из этого не следует, что любой сценарий другого провайдера заработает простой заменой адреса. Проверяют нужные методы и поля, затем прогоняют одни и те же примеры через оба адаптера.
Особенно опасно молча обрезать длинный документ. Если в конец попало ограничение по договору, ответ изменит смысл. Заранее определите, что происходит при превышении контекста: разбиение по разделам, поиск релевантных фрагментов или отказ с понятной причиной. После разбиения сохраняйте связь результата с конкретными страницами исходника.
Для облака учитывают входные и выходные токены, повторные попытки и дополнительные вызовы проверки. Для локального варианта — оборудование или аренду, обслуживание, загрузку, резервирование и работу инженеров. Малое число запросов может плохо загружать собственную инфраструктуру; постоянная нагрузка меняет расчёт, но не отменяет проверку качества.
Единица сравнения — документ или ответ, прошедший приёмку. Если дешёвая модель создаёт больше ручных исправлений, экономия на генерации может исчезнуть. При извлечении полей отдельно измеряют неверные суммы и пропуски обязательных реквизитов, а не только долю корректного JSON.
В нагрузочном тесте воспроизводят размер документов и одновременность запросов. Замер одного короткого ответа на прогретой модели не показывает поведение очереди после перезапуска. Ollama предоставляет метрики длительности и числа токенов ; их полезно собирать вместе с временем ожидания приложения и результатом проверки.
Подготовьте контрольный набор отдельно для каждой задачи. Зафиксируйте допустимую ошибку, максимальное время обработки и ситуации, где автоматический ответ запрещён. Сравнивайте маршруты на одинаковых входных данных; версии модели, шаблона запроса и политики сохраняйте в отчёте.
— Отключите локальный сервис: закрытый документ не должен уйти наружу.
— Превысьте разрешённую длину контекста: система должна выбрать предусмотренный сценарий.
— Верните неполный JSON: запись в учётную систему не должна пройти незаметно.
— Одновременно отправьте несколько крупных файлов: проверьте очередь и тайм-ауты.
— Измените класс данных: прежний кэш не должен обойти новую политику доступа.
По журналу должно быть видно, почему выбран маршрут и какой результат получен. Полные документы в журнале обычно не нужны: достаточно технических идентификаторов и разрешённых диагностических полей. Срок хранения и доступ к диагностике задают отдельно от доступа к самому помощнику.
Можно ли автоматически переключаться в облако при перегрузке? #
Только для задач и данных, которым такой получатель заранее разрешён. Для остальных нужны очередь, отказ или ручной путь. Автоматическое переключение — часть политики обработки данных, а не просто настройка доступности.
Как выбрать локальную модель без покупки сервера заранее? #
Начните с проверочного набора и замера кандидатов в разрешённой тестовой среде. Для закрытых данных используйте обезличенные или синтетические примеры, если реальную передачу не согласовали. Затем оцените оборудование под нужные качество, размер контекста и параллельность.
Если нужно объединить внутренние документы и внешние модели, NetLab поможет определить допустимые маршруты, проверить качество и подготовить развёртывание локальной языковой модели под выбранные задачи. Оставьте заявку с перечнем систем и ограничений на передачу данных — начнём с проверки сценариев, а не с выбора самого большого сервера.
