Kimi K3 — открытая модель, которая обошла закрытых лидеров рынка

Открытые системы редко конкурируют на равных с закрытыми лидерами индустрии: у их разработчиков обычно меньше вычислительных ресурсов и данных, чем у крупных лабораторий, и это сказывается на качестве. Kimi K3 — исключение: ее веса можно скачать и развернуть у себя, а на части независимых бенчмарков она обходит закрытые решения GPT и Anthropic. В этой статье я разбираю недавно опубликованный разработчиками официальный отчет, чтобы понять, что стоит за такими результатами.

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

Как хранить миллион токенов в памяти

У стандартного трансформера есть своего рода блокнот — KV‑кэш: в него механизм внимания построчно записывает уже обработанные токены, чтобы не пересчитывать всю историю заново на каждом шаге. Пока текст короткий, это удобно. Но чем длиннее последовательность, тем толще блокнот: и на обучении, и во время работы модели (инференса) он растет линейно с длиной текста, а квадратичными остаются сами вычисления внимания. Для миллиона токенов линейного роста кэша уже достаточно, чтобы блокнот съел всю доступную память.

Авторы Kimi K3 заменили KV‑кэш на матрицу состояния S — фиксированного размера, который не зависит от длины текста. Вместо того чтобы дописывать в блокнот новую страницу на каждый токен, модель переписывает одну и ту же страницу заново: берет предыдущее состояние, частично стирает из него старую информацию и записывает новую. Этот механизм называется delta‑rule.

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

Именно с α связана числовая ловушка всей конструкции. Коэффициент α почти всегда меньше единицы, а обновление состояния происходит на каждом токене, то есть за длинный текст его перемножают само на себя множество раз подряд. Число меньше единицы, умноженное само на себя много раз, стремится к нулю, и в какой‑то момент может выйти за нижнюю границу диапазона, который поддерживает формат чисел с плавающей запятой, используемый при обучении (BF16). На практике эта проблема проявляется острее: чтобы ускорить вычисления, их считают не строго по порядку, а кусками, параллельно (об этом поговорим дальше), и для этого внутри каждого куска приходится делить на то самое произведение, которое стремится к нулю. Деление на число, близкое к нулю, дает не маленький, а огромный результат — и он выходит уже за верхнюю границу диапазона BF16, что ломает вычисления куда серьезнее, чем просто потеря точности.

Решение оказалось точечным: авторы искусственно ограничили α диапазоном от e⁻⁵ до 1, не позволяя коэффициенту опускаться ниже допустимого предела. Это одновременно не дает исходному произведению α обнулиться и не дает обратной от него величине уйти в бесконечность при делении. Это устранило числовую проблему, но оставило нерешенной другую: обновление состояния S — операция строго последовательная, где каждый шаг зависит от предыдущего. А видеокарты устроены иначе: они эффективны, когда считают не один шаг за другим, а тысячи операций одновременно. Именно это несовпадение и стало следующей задачей для разработчиков.

Как распараллелили последовательное обновление

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

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

Решение — специализированное вычислительное ядро FlashKDA. Оно устроено в два этапа: сначала все токены внутри одного чанка обрабатываются параллельно, а уже потом состояние передается дальше, причем эта передача тоже распараллелена — по числу голов внимания, то есть по независимым частям механизма внимания, которые считаются одновременно. Так последовательность остается только там, где она действительно необходима, а все остальное считается параллельно. Сейчас код FlashKDA выложен в открытый доступ вместе с весами модели — ядро построено на CUTLASS, низкоуровневой библиотеке NVIDIA для быстрых матричных вычислений.

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

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

Здесь всплывает еще одна тонкость. В обычном линейном внимании состояния от разных частей текста можно было бы просто сложить. Но в Kimi K3 действует delta‑rule: то, как именно сегмент текста меняет состояние, зависит от того, что было в состоянии до него. Из‑за этого простое сложение не работает — эффект каждого сегмента зависит от входящего состояния, которое заранее неизвестно.

Разработчики разбили эту задачу на две части, которые можно посчитать независимо друг от друга. Первая — локальное состояние: прирост, который создают токены сегмента сами по себе, как если бы до них не было никакого состояния. Вторая — матрица перехода: правило, описывающее, как именно этот сегмент изменит любое входящее состояние, каким бы оно ни было. Каждая видеокарта (в этой схеме ее называют рангом) считает обе величины только для своего куска текста — это фиксированный по размеру расчет, не зависящий от длины всего текста. Дальше карты обмениваются результатами за одну операцию (all‑gather) и с помощью математической процедуры, которая называется prefix‑scan, восстанавливают настоящие состояния — то, какими бы они были, если бы весь текст обрабатывался последовательно от начала до конца.

где матрица перехода зависит от токенов, поэтому эффект сегмента зависит от входящего состояния.

В итоге объем данных, которыми обмениваются карты, не растет с длиной текста, а сами вычисления масштабируются линейно.

Как не растерять информацию по дороге между слоями

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

В Kimi K3 это устроено иначе. Каждый слой не просто берет результат предыдущего целиком, он избирательно достает из всех предыдущих слоев именно то, что нужно ему самому. Для этого у каждого слоя есть свой обучаемый псевдозапрос — внутренний параметр, который описывает, какую именно информацию этот слой сейчас ищет. Дальше происходит следующее: псевдозапрос сравнивается с результатами всех более ранних слоев, для каждого из них считается, насколько он релевантен запросу, и на основе этого формируется взвешенная сумма — то есть слой берет по чуть‑чуть от наиболее подходящих ему прошлых результатов, а не все подряд.

У такого подхода есть неудобный побочный эффект: чтобы это работало, нужно хранить в памяти результаты вообще всех предыдущих слоев целиком, а это дорого. Разработчики решили эту проблему компромиссом. Слои Kimi K3 сгруппированы в блоки — по 12 слоев в блоке, восемь блоков всего, но последний неполный (если считать еще и эмбеддинги, то в нем получается девять слоев). Внутри одного блока слои складывают свои результаты обычным способом, без всяких ухищрений. А вот между блоками работает уже описанный выше механизм — с псевдозапросами, которые выбирают нужное из результатов предыдущих блоков, а не отдельных слоев. Такая группировка снижает объем нужной памяти в разы: вместо того чтобы хранить результат каждого из всех слоев отдельно, модель хранит результат только для каждого блока.

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

896 экспертов: почему их так много и почему это сложно

Идея Mixture of Experts (смеси экспертов) простая: вместо одной большой модели, которая целиком работает над каждым токеном, внутри держат множество более мелких специализированных экспертов, а для каждого токена задействуют только часть из них. Это позволяет наращивать общее число параметров модели, не заставляя каждый токен проходить через все параметры сразу.

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

Первый шаг решения — сжатие. Вместо того чтобы обрабатывать токены в их полном, исходном представлении, Kimi K3 сначала проецирует их в более компактное — латентное — пространство, вдвое меньше исходного, и только после этого передает дальше к экспертам. Это снижает вычислительную нагрузку на каждого из них.

При этом эксперты в Kimi K3 не равны друг другу. Два эксперта — их называют общими (shared) — работают с полным, несжатым представлением токенов и задействуются всегда, для каждого токена. Другие 896 экспертов — маршрутизируемые (routed) — работают уже со сжатым, латентным представлением, и для каждого токена из них выбираются только 16. Соотношение получается 56 к 1: из 896 доступных маршрутизируемых экспертов реально работает лишь один из пятидесяти шести. После обработки результаты от выбранных экспертов возвращают обратно в исходное, несжатое пространство и складывают с результатом двух общих экспертов — это и есть итоговый выход блока.

Сжатие решило вопрос вычислительной нагрузки, но создало новую опасность: внутри блока подряд идут четыре матричных умножения, и без дополнительной защиты они могут привести к резкому, неконтролируемому росту значений (взрыву активаций), а это, в свою очередь, к переполнению при низкой точности вычислений, в которой обычно работают такие большие модели. Разработчики добавили нормализацию перед одним из умножений и заменили привычную для трансформеров функцию активации SwiGLU на собственную — SiTU‑GLU. У нее обе ветви вычислений плавно ограничены сверху так, что их произведение гарантированно не превышает определенного порога — это математически исключает взрыв значений, а не просто снижает его вероятность.

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

В Kimi K3 маршрутизатор задает другой вопрос: не «какой эксперт лучше справится», а «является ли эта задача одной из любимых для конкретного эксперта». Технически это работает через квантиль: для каждого эксперта отдельно вычисляется такой порог оценки, чтобы ровно заданная доля токенов гарантированно превышала этот порог и доставалась именно ему. Иначе говоря, у каждого эксперта заранее выделена определенная квота задач, которые он получит в любом случае, вне зависимости от того, насколько удачно с ними справятся другие.

Посчитать такой порог по‑честному для сотен экспертов и огромного потока токенов дорого — потребовалась бы полная сортировка всех оценок. Вместо этого используют приближенный, но быстрый способ: вместо точной сортировки строят распределенную гистограмму (данные группируют по нескольким сотням корзин‑интервалов), суммируют ее по всем видеокартам за одну операцию обмена данными, а затем восстанавливают нужный порог уже из этой суммарной гистограммы. Это на порядок дешевле, чем сортировать все оценки целиком, и дает результат, достаточно точный для практических целей.

Сколько резервных экспертов нужно на каждую видеокарту

Раз у каждого эксперта есть гарантированная квота токенов, нагрузку можно математически просчитать заранее. Авторы вывели формулу, которая показывает: если разделить всех экспертов поровну между видеокартами и добавить определенный запас резервных экспертов на каждую карту, этого запаса окажется достаточно, чтобы каждая карта гарантированно получила ровно то количество токенов, на которое рассчитана. Например, если система рассчитана на 1000 токенов в пакете и 16 экспертов на токен, а всего есть 8 видеокарт, то на каждую карту приходится 112 логически закрепленных за ней экспертов (896 поделить на 8) плюс небольшой резерв сверху.

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

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

Обучение: данные, рост контекста, отказ от позиционного кодирования

Теперь поговорим о том, как обучали Kimi K3, и почему то, что она умеет работать с миллионом токенов, не сводится только к одной архитектурной находке.

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

Здесь применили два практических приема. Первый — переписывание данных из доменов математики и общих знаний разными способами, с разными промптами, чтобы получить больше разнообразного материала из одного и того же исходного текста. Второй — программная генерация мультимодальных пар: например, автоматическое создание связок из программного кода и того, что этот код рисует или строит (SVG‑изображения, 3D‑модели, чертежи). Цель обоих приемов одна — чтобы каждая единица вычислений при обучении (FLOP) шла в рост качества модели, а не тратилась на запоминание шума и повторов в данных.

Модель не обучали сразу на миллионе токенов в контексте, длину наращивали в четыре этапа: с 8 тысяч до 64 тысяч на предобучении и с 256 тысяч до миллиона на финальной стадии (cooldown). Такой подход позволил модели надежно научиться запоминать длинные последовательности, а не пытаться освоить экстремальную длину контекста сразу без промежуточных шагов.

В обычных трансформерах модель обычно узнает порядок токенов в тексте с помощью отдельного механизма — позиционного кодирования, в Kimi K3 от него отказались (этот подход называется NoPE, No Position Encoding. Но важно отметить, что отказались именно в слоях с обычным вниманием (Gated MLA). Дело в том, что позиционное кодирование конфликтует с уже описанным механизмом KDA: там порядок токенов и так неявно зашит в саму логику обновления состояния через коэффициенты записи и забывания, о которых шла речь раньше, а слои KDA как раз и берут на себя всю работу по передаче позиции и учету недавности событий.

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

Девять специализированных моделей и управление вычислениями на инференсе

Контекст, глубина и ширина модели — это о том, как модель устроена и как ее обучали (этот этап называют pre‑train). Но у Kimi K3 есть и вторая половина истории — про то, сколько вычислений модель тратит уже во время ответа на конкретный запрос, то есть во время инференса (это уже test‑time).

Прежде чем переходить к обучению с подкреплением (reinforcement learning, RL), модель сначала готовили через supervised fine‑tuning (SFT) — обучение на заранее подготовленных, размеченных примерах. На этом этапе ее учили базовому планированию, работе с агентскими сценариями и отдельно экономии вычислительных ресурсов. То есть с самого начала приучали решать задачи в ограниченном бюджете, а не расходовать вычисления бездумно.

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

Отдельная деталь этого этапа касается точности вычислений. Обычно модель сначала обучают в высокой точности, а уже потом, перед запуском в продакшн, ее веса переводят в более низкую точность, то есть квантуют, чтобы она быстрее работала и занимала меньше памяти. У Kimi K3 иначе: веса экспертов с самого начала обучают сразу в низкой точности (формат MXFP4), а промежуточные вычисления — в чуть более высокой (MXFP8). Смысл в том, чтобы полностью убрать разрыв между условиями обучения и условиями реальной работы: модель с первого дня учится рассуждать именно в тех условиях точности, в которых потом будет работать в продакшне, и отдельный этап квантования после обучения просто не нужен.

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

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

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

Держать в продакшне девять отдельных полноразмерных моделей дорого и неудобно. Поэтому поведение всех девяти специализированных моделей объединяют в одну универсальную с помощью метода Multi‑Teacher On‑Policy Distillation. Идея в том, что единая модель (студент) учится у каждого из девяти специализированных экспертов (учителей), причем для каждой комбинации домена и уровня усилий используется именно тот учитель, который на ней специализировался. Сигнал для обучения студент получает не только по итоговому результату, а по каждому токену ответа отдельно, что делает процесс точнее и позволяет переиспользовать ту же инфраструктуру частичных траекторий, что применялась на этапе обучения с подкреплением.

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

Агентская инфраструктура

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

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

Отдельным направлением стала оценка модели на задачах, связанных с кибербезопасностью, в том числе поиск уязвимостей и симуляция атак. Для этого нужна среда, где можно безопасно запускать потенциально вредоносный или уязвимый код, не рискуя ничем за ее пределами. Разработчики отдельно отмечают, почему для этого не подошли обычные Docker‑контейнеры: агенты, которые все активнее исследуют границы дозволенного, на ранних этапах несколько раз обрушивали или подвешивали общее ядро операционной системы, которое делят между собой все контейнеры на одной машине. Решение — перейти на легковесные виртуальные машины (технология Firecracker), у каждой из которых свое, полностью изолированное ядро. Агент может сколь угодно агрессивно экспериментировать внутри своей песочницы, вплоть до монтирования дисков, запуска контейнеров или виртуальных машин, не рискуя задеть соседние задачи.

Систему для запуска таких песочниц в промышленном масштабе — AgentENV — разработчики Kimi K3 тоже выложили в открытый доступ отдельным проектом, вместе с командой kvcache‑ai. Снимок ее состояния сохраняется примерно за 133 миллисекунды, а возобновление работы после паузы занимает около 49 миллисекунд. Пока модель генерирует ответ, песочница стоит на паузе и не расходует ресурсы вовсе — а на такую паузу уходит до 98% всего времени ее существования. За все время обучения и оценки Kimi K3 было создано 51,2 миллиона таких песочниц на основе 1,5 миллиона уникальных образов.

KV‑кэш все‑таки не исчез полностью

В самом начале статьи речь шла о том, что стандартный KV‑кэш заменили на матрицу состояния S фиксированного размера, что позволило модели работать с миллионом токенов, а не упереться в нехватку памяти. Но избавиться от KV‑кэша полностью все‑таки не удалось, и это не недоработка, а осознанный компромисс.

Судя по схеме архитектуры, каждый повторяющийся блок слоев в Kimi K3 устроен так: три раза подряд идет блок KDA — то есть линейное внимание, работающее по описанному ранее принципу с матрицей состояния, — и один раз блок Gated MLA, где используется уже привычное, стандартное внимание с настоящим KV‑кэшем (просто в сжатом виде, через механизм под названием MLA). Слово «gated» здесь означает, что после самого внимания к результату применяется дополнительный управляющий фильтр: он решает, какая доля извлеченной информации пройдет дальше, в основной поток вычислений модели, а какая будет отброшена. Тот же прием применяется и в блоках KDA, так что гейтинг в Kimi K3 работает на обоих видах внимания, а не только на MLA.

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

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

Во сколько это обходится на практике

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

Разработчики Kimi K3 опубликовали графики, где сравнивают качество решения разных типов задач (или условный рейтинг Elo) со стоимостью одной задачи в долларах: программирование, работа с браузером, общие агентские сценарии. На большинстве таких графиков Kimi K3 попадает в выгодную зону: сопоставимое или более высокое качество при заметно меньшей стоимости за задачу по сравнению с закрытыми моделями вроде GPT или Claude.

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

Заключение

За каждым решением в архитектуре Kimi K3 стоит одна и та же логика: типовой прием почти всегда создает новую проблему и требует поиска пути ее обхода. Матрица состояния экономит память, но роняет числа в ноль. Избирательная память между слоями сохраняет важное, но грозит раздуть объем данных, если не сгруппировать слои в блоки. Сотни экспертов дают ширину, но норовят простаивать, если не заставить их работать через квоты.

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