Модель с открытыми весами: выбор для внутреннего контура

Почему здесь легко ошибиться

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

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

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

Во внутреннем контуре ошибка обходится дороже, чем во внешнем чате. Здесь мало смотреть на качество текста. Нужно учитывать, где хранятся данные, кто получает доступ к запросам, можно ли вести аудит и как система обращается с персональными данными. Для команд в Казахстане это часто не формальность. Требования по хранению данных внутри страны или внутри компании сразу отсекают часть вариантов, даже если по качеству они сильные.

Хороший пример - разбор входящих писем в банке или ритейле. Команда берет крупную модель с высоким местом в бенчмарке, проверяет ее на нескольких письмах и довольна результатом. Потом выясняется, что модель путает категории на коротких сообщениях, иногда ломает JSON, а служба безопасности не разрешает выбранную схему доступа. Приходится откатываться и сравнивать заново.

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

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

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

Обычно хватает 3-5 сценариев. На каждый сценарий соберите 30-50 живых примеров. Берите не только аккуратные документы, но и шумные случаи: опечатки, OCR после скана, внутренние сокращения, письма с кусками таблиц, файлы, где русский и казахский смешаны в одном тексте. Иначе тест пройдет гладко, а в работе модель начнет путать термины и ломать структуру.

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

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

Маленький пример хорошо показывает, зачем это нужно. Допустим, отдел закупок проверяет входящие документы и ждет от внутреннего контура LLM JSON с полями "поставщик", "сумма" и "дата". Если одна модель отвечает за 2 секунды и ошибается в 3 случаях из 100, а другая отвечает за 7 секунд и часто возвращает свободный текст вместо JSON, вторая проигрывает, даже если ее формулировки звучат лучше.

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

Как размер модели влияет на результат

Размер модели влияет не только на качество. Он меняет задержку, цену ответа и то, сколько GPU нужно держать в контуре. Для внутреннего контура LLM это быстро становится практическим вопросом: ждать 1-2 секунды или 10, запускать одну карту или целый узел.

Малые модели, например 7B-8B, часто подходят для простых задач. Они быстро отвечают, дешевле в запуске и проще помещаются в локальную инфраструктуру. Если вам нужно разметить обращения, вытащить номер договора или привести текст к шаблону, такой размер нередко дает нормальный результат.

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

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

Крупные модели, 70B и выше, чаще выигрывают там, где нужен сложный разбор документа. Например, когда модель должна сопоставить пункты договора, найти конфликт условий и объяснить риск простым языком. На такой задаче разница между 14B и 70B бывает заметной даже без тонкой настройки.

При этом большая модель не всегда лучшая для вашей задачи. Иногда 14B-модель с хорошей донастройкой отвечает точнее, чем более крупная базовая версия. Если вы выбираете модель с открытыми весами, смотрите не на число параметров само по себе, а на ошибки в вашем наборе примеров.

Грубое правило простое: 7B-8B подходят для простой классификации, коротких ответов и базового извлечения полей; 14B-32B лучше держат строгие инструкции, длиннее контекст и стабильный формат; 70B+ нужны для сложных документов, спорных случаев и многошагового рассуждения.

Отдельно проверьте качество после квантования. На тесте до сжатия модель может выглядеть отлично, а после 4-bit начать ломать JSON, пропускать числа или хуже разбирать терминологию. Если команда хочет сократить требования к GPU, сравнивать нужно уже квантованную версию, которую вы реально будете запускать в проде. Именно она покажет честный баланс между скоростью, ценой и качеством.

Язык и терминология

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

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

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

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

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

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

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

Формат ответа без ручной правки

Если ответ модели идет в CRM, скоринг или внутренний сервис, красивый текст только мешает. Команде нужен не "умный" абзац, а стабильный JSON, который код примет без догадок и лишних проверок.

На этом месте модели часто срываются. Одна добавляет пояснение перед JSON, другая меняет тип поля, третья пишет пустую строку там, где вы ждали null или пустой массив. На тесте это выглядит мелочью, а в проде превращается в часы на постобработку.

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

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

Проверьте хотя бы три типа задач: извлечение полей из договора, счета или анкеты; постановку меток вроде класса документа, риска, темы обращения или языка текста; и короткое резюме в 2-3 предложения без воды и повторов.

Именно на таких задачах быстро видно, кто держит структуру, а кто пишет "по-человечески", но неудобно для системы. Для бизнеса второй вариант обычно хуже, даже если текст звучит приятнее.

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

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

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

Как прикинуть требования к GPU

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

Квантование снижает базовый объем памяти, но не решает все. Условная модель на 8B параметров в 4-bit может поместиться на одной карте среднего класса, если вы тестируете один короткий запрос. Та же модель с контекстом 16k, JSON-ответом и несколькими параллельными пользователями может упереться в память из-за KV-cache и дать резкий рост задержки.

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

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

Варианты размещения

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

Общий кластер лучше подходит, когда несколько команд делят GPU между задачами. Но тогда нужно внимательно следить за очередями. Один тяжелый job на fine-tuning или batch inference легко портит задержку интерактивному сценарию.

Внешнее размещение подходит, если вы не хотите держать собственную GPU-команду. Для компаний в Казахстане это обычно рассматривают вместе с требованиями по data residency и аудиту.

Финальную оценку дает только замер на реальных логах. Игрушечный тест на коротких промптах почти всегда врет. Возьмите 100-200 настоящих запросов: длинные письма, документы, русский и казахский текст, нужный формат ответа. После этого смотрите p95 задержку, расход памяти и поведение в пике. Обычно именно на этом шаге становится ясно, хватит одной GPU или нужен совсем другой план.

Пример для типовой бизнес-задачи

Возьмем частую задачу внутренней поддержки: сотрудник задает вопрос, система ищет ответ в базе знаний и старых письмах, а потом отдает короткий итог для менеджера. В реальной компании такие вопросы редко бывают "чистыми". Часть текста на русском, часть терминов на казахском, а в письмах много сокращений, имен продуктов и внутренних кодов.

Руководителю обычно не нужен длинный ответ модели. Ему нужен строгий JSON, который можно сразу передать в CRM или тикетную систему. Например, такой:

{
  "topic": "задержка поставки",
  "risk": "medium",
  "next_action": "проверить статус у логистики и ответить клиенту до 12:00"
}

На этом примере быстро видно разницу между классами моделей. Маленькая модель на 7B-8B часто неплохо ищет явные совпадения в базе знаний и делает простой пересказ. Но она чаще путает близкие темы, хуже держит смешанный русский и казахский текст и иногда ломает формат ответа. Вместо JSON она может вернуть абзац, добавить лишнее поле или написать риск свободным текстом.

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

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

Проверить это можно без долгого пилота. Возьмите 100-200 реальных обращений, оставьте смешанные русско-казахские формулировки как есть, проверьте не только качество текста, но и валидность JSON, а затем замерьте задержку в обычный час и в пик.

Для внутреннего контура LLM это хороший тест, потому что он сразу показывает слабые места. Если малая модель ошибается в теме и риске, экономия быстро исчезает: сотрудники тратят время на проверку. Если большая модель дает тот же результат, но отвечает вдвое медленнее, платить за нее нет смысла. Для таких сравнений команды в Казахстане часто прогоняют несколько open-weight моделей на одинаковых запросах внутри локальной инфраструктуры или через шлюз вроде AI Router, где можно менять модель без переделки кода.

Где команды теряют время и деньги

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

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

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

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

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

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

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

Быстрый чек-лист перед пилотом

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

• Соберите 100-200 живых запросов из реального потока. Не правьте опечатки, обрывки фраз, смешение русского и казахского, лишние поля и странные формулировки.
• Для каждого сценария заранее зафиксируйте формат ответа. Если системе нужен JSON с полями "category", "reason" и "risk_score", проверяйте именно это.
• До запуска задайте предел по задержке и цене. Для внутреннего помощника 2-3 секунды могут быть нормой, а для пакетной обработки разница в стоимости быстро становится заметной.
• Прогоните один и тот же набор отдельно на русском и казахском вводе. Смотрите, где модель путает термины, смешивает языки и теряет смысл в коротких репликах.
• Сразу определите, как команда проверит безопасность и аудит: утечки персональных данных, хранение логов, доступ к ключам, метки AI-контента и след по каждому запросу.

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

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

Что делать после первого сравнения

После первой таблицы с оценками не стоит выбирать одну модель на все случаи. На практике почти всегда выигрывает набор из 2-3 моделей под разные задачи. Одна закрывает дешевые массовые запросы, вторая лучше держит строгий JSON, третья нужна для сложных документов, длинного контекста или более уверенной работы с русским и казахским языком.

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

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

Во время пилота полезно свести метрики в одну простую карточку по каждой модели:

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

Часто именно последний пункт ломает красивый выбор на бумаге. Модель может отвечать хорошо, но если команда неделю чинит парсинг, auth, ретраи и аудит, это уже плохой кандидат для внутреннего контура LLM.

Если нужен единый OpenAI-совместимый эндпоинт, а данные должны оставаться в Казахстане, можно прогнать одинаковый пилот через AI Router или сравнить сценарии на airouter.kz. Это удобно, когда команда хочет менять модели без переписывания SDK, кода и промптов, а заодно проверить, насколько выбранная схема вообще пригодна для продакшена.

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

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