Kimi K3.1 Pro: открытые веса для долгих задач ИИ-агента

У Kimi K3.1 Pro теперь есть вполне осязаемый размер: 96 файлов весов, суммарно 1 561 293 160 568 байт — около 1,56 ТБ. Мы проверили официальный репозиторий Moonshot на Hugging Face 9 ноября. Эти файлы содержат параметры, с которыми сторонняя команда может развернуть модель у себя и наблюдать за её работой внутри собственного приложения.

Moonshot в анонсе обещала выложить полные веса к 4 ноября; на 9 ноября они доступны.

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

В карточке модели K3.1 Pro описана как развитие K3: 2,8 трлн параметров всего, 104 млрд активных, контекст до 1 048 576 токенов — фрагментов текста, которыми оперирует модель. Такой объём контекста задаёт предельную длину последовательности, с которой рассчитана работать модель. В реальном сервисе место под историю, скорость обработки и число одновременных запросов зависят от запуска.

Среди изменений в реализации NVIDIA NeMo AutoModel — индексатор в 24 слоях внимания: он выбирает до 2048 предшествующих позиций для каждой обрабатываемой позиции текста. Остальные 69 слоёв используют Kimi Delta Attention. Это способ сократить часть вычислений при обращении к длинной истории, где полный перебор связей между всеми фрагментами становится дорогим.

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

На странице Terminal-Bench модель уже показана с результатом 65,7. Публичные задания позволяют увидеть характер работы: в одном из них агенту передают геномные данные и локальные инструменты анализа, а на выходе ожидают файл отчёта. Проверка оценивает действия системы и полученные файлы в рабочем окружении.

В таблице Moonshot Kimi K3.1 Pro набирает 65,7% на Terminal-Bench 4.0, Claude Opus 5.5 — 66,4%, GPT-6 Astra — 58,2%. Числа позволяют сравнить опубликованные результаты в этом конкретном тесте. У близких значений нет опубликованных здесь интервалов погрешности, по которым можно было бы оценить устойчивость разницы.

Условия раскрыты в примечаниях к анонсу: Kimi запускали через агентную оболочку Claude Code, а для большинства соперников брали максимальное значение из их публикаций или официальной таблицы Terminal-Bench. По умолчанию собственные измерения Moonshot используют максимальную глубину рассуждений, temperature 1,0 и top-p 0,95 — параметры, которые задают случайность выбора следующего фрагмента ответа и круг допустимых вариантов. Такой сбор результатов отличается от единого повторного прогона всех систем редакцией.

При переносе модели в своё приложение полезнее всего оказывается небольшое требование из документации Kimi API: в следующий запрос нужно возвращать целое сообщение ассистента, включая reasoning_content и tool_calls. В этих полях сохраняются рассуждения модели и вызовы инструментов. Если интеграция оставит только видимый пользователю content, продолжение получит другую историю работы.

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

В руководстве по быстрому подключению описаны отдельно поток рассуждений и конечный ответ, а для строгого JSON предлагается разбирать поле content. Разделение важно для приложения, которое строит отчёт, форму или машинно проверяемый результат: история работы агента и итоговый документ выполняют разные функции.

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

Файлы весов занимают около 1,56 ТБ даже при поставляемой сжатой форме. Их размер мы получили сложением размеров 96 safetensors-файлов в официальном API репозитория. В эту сумму не входят память для промежуточных состояний, история активных запросов и рабочие буферы серверной программы.

Архитектура Mixture-of-Experts распределяет вычисления между экспертными блоками: из 896 маршрутизируемых экспертов для токена выбираются 16, вместе с двумя общими экспертами. Поэтому число параметров, участвующих в одном шаге, гораздо меньше общего. Остальные блоки остаются частью модели, к которой при следующих шагах тоже потребуется доступ.

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

В рецепте vLLM исходная конфигурация использует восемь графических ускорителей (GPU): два аппаратных блока GB300 или один узел B300. Авторы прямо отмечают, что пропускную способность базового запуска не оптимизировали. Документирован и узел MI355X. Это проверяемые отправные конфигурации, к которым можно привязать результаты собственного запуска.

Для длинных сессий vLLM описывает отдельный компромисс: режим DCP8 распределяет кэш истории между восемью графическими ускорителями. В приведённом измерении он вмещает примерно в семь раз больше токенов кэша, чем обычный режим TP8, распределяющий вычисления модели между восемью ускорителями, зато шаги выдачи ответа на той же величине пакета идут на 7–25% медленнее. Полученная ёмкость полезна, когда несколько агентов долго держат открытыми большие истории.

В руководстве SGLang сценарии также разделены по аппаратуре и числу одновременно работающих агентов. У конкретных команд запуска есть отметки «проверено» (Verified), «идёт окончательная проверка» (Final Verification In Progress) или «не проверено» (Not Verified). Документация отдельно предупреждает, что часть конфигураций ещё проверяется, а общей таблицы замеров скорости для всех вариантов пока нет.

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

Kimi K3.1 Pro распространяется по собственной лицензии. Она разрешает использование, изменение, дообучение и распространение с сохранением уведомлений. Для компании или её аффилированных лиц, которые ведут бизнес Model as a Service, установлен отдельный порог: совокупная выручка свыше 20 млн долларов за любые последовательные 12 месяцев требует договора с Moonshot перед коммерческим использованием.

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

В лицензии есть и другое условие. Коммерческий продукт с более чем 100 млн активных пользователей в месяц либо месячной выручкой свыше 20 млн долларов должен заметно показывать название Kimi K3.1-Pro в интерфейсе. Условия о договоре и маркировке имеют указанные исключения: внутреннее использование в определении самой лицензии и доступ к модели через официальные продукты Moonshot или сертифицированных партнёров по инференсу.

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