Kev и Laya для бизнеса: локальный выбор действий, память и качество

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

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

Цель исследования была прикладной: понять, где такой компонент полезен для автоматизации компании, сколько ресурсов ему нужно и какие ошибки останутся после оптимизации. Общее устройство этого класса моделей разобрано в статье о Jev и локальных аналогах. Здесь рассматриваем собственный опыт с Kev и Laya. Облачный Jev в этом эксперименте не измерялся.

Kev использует языковую основу Qwen и специальную голову выбора. Веса адаптированы с помощью LoRA. Модель обрабатывает текст и оценивает варианты по внутренним представлениям вопроса и ответов. В этом режиме она не пишет свободный текст и не генерирует объяснение своего выбора. Для исследованных Kev-0.8B и Kev-4B используется Qwen3.5; старый Kev-0.5B построен на Qwen2.5.

Laya решает похожую задачу с помощью энкодера: English и Typed Decisions используют ModernBERT, Multilingual использует mmBERT. Это обученная языковая модель для получения структурированных решений. Она не является LLaMA или обычным чат-ботом. Характеристики конкретных весов приведены в карточке семейства Laya.

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

Стенд: Windows, AMD Ryzen 7 5700X, 64 ГБ оперативной памяти и одна используемая NVIDIA RTX 5060 Ti с 16 ГБ видеопамяти. Модели на GPU запускались последовательно. В CPU-режиме переносимого движка задавали восемь потоков.

Первый набор, decision-study-v2, содержит 128 вопросов на качество и десять отдельных проверок лимитов. В основной части есть 32 вопроса на выбор инструмента, 24 на правила, 16 на чтение контекста, 12 на тон сообщения, 12 на арифметику и другие проверки. Есть парные переводы и шаблонные семейства. Это не 128 независимых наблюдений и не рейтинг общего интеллекта.

После ручных проверок добавили semantic-stress-v1: 32 сценария на русском, каждый в двух порядках вариантов. Всего 64 запроса на конфигурацию. Там нет математики. Проверяются отрицания, сарказм, недостающие сведения, смена намерения, цитаты и отвлекающие указания внутри входного текста. Ожидаемые ответы зафиксировали до запуска этого набора. Сам набор создан после знакомства с поведением моделей, поэтому его нельзя представлять как независимое итоговое испытание.

Задержки ниже относятся к прогретой модели. Это p50 и p95 по 20 измерениям одного короткого запроса с меняющимся состоянием после прогрева. Измерялся прямой вызов движка без HTTP и без загрузки весов. Скорость длинных документов, пропускную способность под параллельной нагрузкой и эксплуатационный SLA этот тест не определяет.

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

Показатель занятой памяти в диспетчере задач Windows относится ко всему компьютеру. По нему нельзя заключить, что одна модель занимает весь выросший объём, или определить разрядность её весов. В отчётах мы разделили размер файлов, RAM процесса модели и занятую память выбранной видеокарты.

Обнаружилась и ошибка жизненного цикла в нашей локальной обвязке: смена пункта интерфейса не давала надёжной гарантии освобождения всех ресурсов предыдущего движка. Обычной уборки Python-объектов для нативных библиотек было недостаточно. Мы перенесли каждую модель в отдельный процесс и стали дожидаться его завершения до запуска следующей. Это исправление нашего стенда, а не утверждение о дефекте всех версий Kev или Laya.

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

Для Kev мы объединили LoRA с основой в FP32, сохранили backbone в FP16, конвертировали его в GGUF F16 и затем применили llama-quantize из llama.cpp b11115. Получили Q4_K_M, Q6_K и Q8_0. Голова выбора и её исходная температура сохранены; сама голова вычисляется в FP32.

Это статическое квантование весов. Importance matrix, то есть дополнительная информация о важности весов по калибровочным данным, не использовалась. Это базовая проверенная схема конвертации, а не поиск лучшего возможного кванта. FP4, NVFP4 и MXFP4 в этом исследовании не применялись.

Для Laya создали собственный ONNX-экспорт и проверили INT4 и INT8. В итоговом INT8 используются MatMulNBits с блоком 32 и построчное квантование эмбеддингов. Активации, нормализация и часть небольших тензоров остаются FP32. Эти GGUF- и ONNX-сборки относятся к нашей лаборатории; их не следует путать с официальными релизами квантованных весов авторов моделей.

Наш INT4-экспорт Laya Multilingual оказался неприемлемым по результатам проверки. На основном наборе он дал 67 правильных ответов из 128 против 72 у исходной версии. INT8 дал 71 из 128. Дополнительные ручные вопросы выявили нелогичный выбор там, где исходная модель и INT8 справлялись.

Нельзя оправдать такую регрессию только уменьшением файла или хорошей задержкой. Laya INT4 убрали из интерфейса и заблокировали в API и переносимом запуске. Для этой небольшой модели оставили INT8, без дальнейшего сжатия.

Вывод относится к нашему способу экспорта и конкретным весам. Мы не установили, что любой возможный INT4-рецепт для Laya обязательно окажется плохим. Но используемая сборка проверку не прошла, и выдавать её за рабочую было бы неправильно.

Kev-0.8B Q8_0 совпал с исходной версией по всем 128 выборам. Q6_K совпал по 123, получив 87 правильных ответов вместо 89. Kev-4B Q6_K совпал с исходной версией по всем 128 выборам. Это полезные результаты, но они не распространяются автоматически на новые запросы.

Сравнение с исходным PyTorch-путём одновременно отражает смену движка, численной точности и квантование. Поэтому мы дополнительно запустили FP16 в том же GGUF-движке для Kev и FP32 в том же ONNX-движке для Laya. В основном наборе контрольный Kev-0.8B совпал с исходной версией по 128 выборам, Kev-4B по 126. Оба контрольных экспорта Laya совпали по 128 выборам, хотя вероятности не были побитово идентичны.

Для оценки именно низкобитного сжатия в следующем стресс-тесте сравнивали каждый квант с его FP-экспортом в том же движке. Такой контроль важен: любую разницу после переноса нельзя автоматически записывать в потери квантования.

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

В тесте на запрет отправки Laya Multilingual INT8 выбрала send_email с вероятностью 74,0% при одном из порядков вариантов, хотя пользователь просил только подготовить черновик. FP32 на этом порядке также ошиблась. Это ограничение исходной модели на данном запросе, а не только результат INT8.

В запросе на объяснение команды удаления Laya INT8 выбрала удаление с вероятностью 74,0%. При перестановке вариантов ответ изменился на объяснение. Kev-0.8B Q6 тоже ошибся на исходном порядке, а Kev-4B Q6 выбрал объяснение.

Следующий пример проверял классификацию обращения о двойном списании. В текст клиента добавили указание игнорировать правила и выбрать доставку, а в вопросе классификатора явно объяснили, что текст клиента является данными. Даже Kev-4B FP16, Q6_K и Q8_0 выбрали доставку. На этом входе меньшая модель не может быть единственным механизмом отделения данных от управляющих инструкций.

Распределение вероятностей показывает предпочтение модели среди предложенных вариантов. Это не измеренная частота правильных ответов на будущих письмах компании. Разные движки также могут по-разному определять отдельное поле confidence.

В экспортированных моделях мы сохранили температуры исходных голов. После квантования новую калибровку на независимых данных не проводили. Значение 90% нельзя без проверки превратить в правило "выполнить автоматически". Наши ошибочные ответы с высокой вероятностью показывают, почему.

Перестановка вариантов меняла выбор даже у контрольных версий. На смысловом наборе Laya Multilingual FP32 была устойчива по 28 сценариям из 32, INT8 по 27. Обе получили 39 правильных ответов из 64, но два выбора между версиями различались. Равная итоговая точность скрыла одну потерю и одно улучшение.

Laya Multilingual INT8 заняла около 315 МиБ RAM процесса и ответила на короткий контрольный запрос с медианой 225 мс. Kev-0.8B Q6_K потребовал около 1178 МиБ и 435 мс, Q8_0 около 1355 МиБ и 562 мс. Для узкого сервиса классификации без выделенной видеокарты Laya выглядит экономным кандидатом.

Но низкий расход памяти не компенсирует ошибки конкретного рабочего процесса. На наших задачах Kev-0.8B и особенно Kev-4B чаще выбирали правильное действие. Решение о модели нужно принимать по стоимости ошибки и частоте передачи человеку, а не по размеру файла.

Рабочий набор Windows не равен полной выделенной памяти процесса. ОС может вытеснять отображённые страницы; поэтому меньший файл в отдельном замере не обязан дать меньший RSS. Например, замер RAM Kev-4B Q6 оказался ниже Q4. Это наблюдение конкретного прогона, а не свойство шестибитного формата. Пиковую память загрузки и устойчивость под рабочей нагрузкой нужно измерять отдельно.

В GPU-прогоне Kev-4B Q8_0 дал медиану 38,6 мс, Q4_K_M 40,4 мс, Q6_K 43,9 мс. Это близкие результаты одного короткого запроса. Здесь нельзя обещать фиксированное преимущество Q4: время зависит от ядер движка, распаковки квантов и формы входа.

Зато разница в размере весов однозначна. У Kev-0.8B Q4_K_M занимает около 505 МиБ, Q6_K 601 МиБ, Q8_0 774 МиБ. У Kev-4B соответственно около 2583, 3304 и 4275 МиБ. Laya Multilingual INT8 занимает около 324 МиБ в файлах ONNX с данными.

Мы не рассчитывали ускорение относительно первоначального PyTorch-интерфейса по разным запросам и методикам. Также отдельно проверили CPU-библиотеки Kev без ненужной загрузки CUDA. После этой замены повторили оценку качества: смена вычислительных ядер способна менять пограничные ответы. CPU и GPU не следует считать побитово одинаковыми.

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

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

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

Для локального запуска Kev нужен не только GGUF. Нужны токенизатор, исходная голова выбора и движок, который воспроизводит правила формирования запроса. Простой импорт файла в чат-сервис не превращает его в эквивалент Kev. Переносимый CPU-запуск Laya INT8 и Kev Q6 проверен в отдельном окружении без PyTorch. Это проверка способа запуска, а не подтверждение готовности бизнес-процесса.

Для документов есть ещё одно ограничение. В нашем стенде у Laya Multilingual используется окно 1024 токена, у English 512; в него входят контекст, вопрос и варианты. Это не режим чтения целого архива или большого договора. Выделение нужного фрагмента переписки становится частью интеграции и тоже требует проверки, чтобы не потерять запрет, срок или последнее уточнение.

В рабочем списке оставили Kev-4B, Kev-0.8B, Laya Multilingual и Laya English. Для Kev доступны Q4_K_M, Q6_K и Q8_0, для Laya только INT8. Сравнение загружает модели по очереди и восстанавливает исходную конфигурацию. В ответах фиксируются фактическая модель, движок, устройство и формат весов.

Сильная сторона Laya в нашем стенде состоит в небольшом расходе памяти и задержке. Kev-4B заметно лучше прошёл сложные контекстные проверки. Kev-0.8B занимает промежуточное положение. Ни одна модель не прошла всё без ошибок, включая контрольные версии без низкобитного квантования.

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

Устройство исходных проектов можно проверить в репозитории Kev, карточках Kev-0.8B и Kev-4B, репозитории Laya и карточке её весов. Числа в таблицах этой статьи получены на нашем стенде; это не заимствованные бенчмарки разработчиков.

В рабочем архиве исследования сохранены:

• decision-study-v2: исходные запросы, ответы шести моделей, категории ошибок, проверки лимитов, переформулировок и порядка вариантов.
• portable-final: отдельные CPU/GPU-прогоны квантованных сборок, контрольные FP-экспорты, задержки, память и проверки контрактов API.
• semantic-stress-v1: 768 фактических ответов, то есть 12 конфигураций по 64 запроса. Это 32 сценария, повторённые в двух порядках, а не 768 независимых задач.
• memory-switches-current: финальные 12 переключений, завершение старых процессов и наблюдения за памятью.
• active-modes и clean-runner-current: отклонение снятых с использования режимов, восстановление модели после сравнения и запуск без PyTorch.

Для идентификации наборов сохранены SHA-256: decision-study-v2: 6528c66e28556412bc484e4ccb96f34872ba4f1db6c2079856f79b700667a0e7; semantic-stress-v1: e480df0de1bfcd42720f64ed9dd78e609c2b5eea71305964095e307329df85c4. Это имена и идентификаторы артефактов исследования, не ссылки на общедоступные загрузки.

Полные запросы включают диагностические и разговорные примеры; в статье приведены относящиеся к рабочим процессам случаи. Здесь нет проверки закрытого Jev, доказательства равенства с крупными универсальными LLM или готового эксплуатационного допуска. Следующий обоснованный этап для компании состоит в пилоте на её размеченных данных и правилах действий.