Что произошло

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

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

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

Почему это важно

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

Ещё один тихий источник ошибок — шаблон диалога. Gemma и Qwen обучались на разной служебной разметке сообщений; переносить инструкцию из одного сервиса в другой без адаптации рискованно. Модель обычно не сообщит о неверном шаблоне, а просто начнёт отвечать хуже.

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

На практике

1. Начинайте с задачи. Сначала зафиксируйте язык, качество, допустимую задержку и объём памяти, затем сравнивайте кандидатов на реальных примерах.
2. Разделяйте роли моделей. Отдавайте извлечение, классификацию и текстовое объяснение тем моделям, которые лучше показывают себя именно на этих этапах.
3. Закрепляйте настройки инференса. Версии весов, шаблоны диалога, квантование, температуру и распределение памяти храните в конфигурации и проверяйте повторными замерами.
4. Не просите «вернуть JSON». В llama.cpp можно ограничить генерацию грамматикой GBNF или схемой JSON Schema. Тогда недопустимые токены не попадут в ответ.
5. Проверяйте смысл отдельно от формы. Грамматика гарантирует синтаксис, но не достоверность полей и не защитит от обрыва по лимиту токенов.
6. Подбирайте температуру для этапа. Извлечение данных и выбор действия требуют предсказуемости, а формулирование ответа пользователю допускает больше вариативности.
7. Оставляйте фреймворк для сложной логики. Когда процесс известен заранее, прозрачная цепочка вызовов легче наблюдается и отлаживается.
8. Измеряйте после каждого изменения. Смена модели, шаблона или инструкции — это новая конфигурация, а не косметическая правка.

Итог

Открытые ИИ-модели дают независимость от внешнего API и предсказуемее контролируют данные и стоимость на больших объёмах. Но это не отменяет инженерной работы: качество определяется не только выбранной LLM, а всей связкой из оборудования, формата сообщений, ограничений вывода и наблюдаемости.

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