Код на 12 тысяч строк от ИИ ускорил Kimi K3 в 1,68 раза — и люди не успевают его проверять

В начале октября 2026 года технический блог проекта vLLM опубликовал разбор с длинным названием «Hyper Optimizing Kimi K3 in vLLM: Moving Fast and Responsibly». За сухим заголовком скрывается история, которая касается не столько скорости конкретной модели, сколько самого способа, которым сегодня создаётся программный код для искусственного интеллекта. Инженер Benjamin Chislett из подразделения CentML компании Nvidia написал мегаядро на языке CuTe DSL объёмом около 12 тысяч строк. Этот код заметно ускорил вывод китайской модели Kimi K3 от компании Moonshot AI — модели с 2,8 триллиона параметров. По оценке аналитической фирмы SemiAnalysis, на той же аппаратной платформе GB300 NVL72 модель достигла скорости 423 токена в секунду на пользователя, что дало прирост производительности в 1,68 раза. В самом блоге vLLM приводятся и другие цифры: более 840 токенов в секунду при размере батча, равном единице, и ускорение декодирования в 1,5–2 раза в ряде тестовых конфигураций. Ни одна видеокарта не была заменена, не использовался более совершенный техпроцесс, никто не ждал следующего поколения чипов.

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

Чтобы понять, откуда взялись эти 12 тысяч строк, стоит разобраться в устройстве Kimi K3. Это не рядовая модель. Её архитектура Stable LatentMoE насчитывает 896 экспертов, из которых при каждом выводе активируются лишь 16. Такая предельно разреженная схема отлично работает на этапе обучения, позволяя малой долей активных параметров задействовать огромную ёмкость, но в выводе превращается в инженерный кошмар. По данным SemiAnalysis, один прямой проход K3 требует около 1,5 терабайта пропускной способности памяти HBM и порождает более 120 операций коллективной связи All-to-All. На этапе декодирования узким местом становится именно память: вычислительные блоки большую часть времени простаивают в ожидании данных. Традиционный движок вывода выполняет декодирование цепочкой отдельных ядер — одно отвечает за внимание, другое за маршрутизацию в MoE, третье за вычисления экспертов, четвёртое за коммуникации. Каждый запуск ядра сопряжён с накладными расходами, а обмен данными между ядрами идёт через видеопамять. Идея мегаядра в том, чтобы слить разрозненные операции в один сверхплотный модуль, сократить число запусков, объединить обращения к памяти и максимально наложить вычисления на передачу данных. Ценность 12 тысяч строк в том, что они заменили стандартную эффективность схемы «универсальное железо под универсальную модель» на предельную эффективность схемы «специальное железо под специальную модель». Железо осталось прежним, модель осталась прежней — изменилось лишь то, как данные движутся по железу.

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

Осознав это, команда vLLM выпустила документ RFC об ускоренной оптимизации моделей. Его логика не в том, чтобы заставить людей проверять быстрее, а в том, чтобы перестроить организацию работ по производительности. Сформулированы четыре принципа: изолировать изменения, ограничивать область правок, системно подтверждать корректность и масштабировать проверку. Ключевая фраза звучит так: человеческие рецензенты по-прежнему судят о дизайне и доказательствах, но могут начинать с высокоуровневой абстракции вместо построчного чтения кода. Иными словами, человек превращается из того, кто пишет код, в того, кто проектирует систему проверки и очерчивает границы риска. ИИ пишет код, человек управляет процессом — и это не прогноз на будущее, а зафиксированное в блоге состояние дел на середину октября 2026 года.

Масштаб события виден в более широком контексте. В прежних историях про ИИ — атаки на сайты ООН, увольнения исследователей с предупреждениями, почти случившийся конфликт — искусственный интеллект выступал субъектом действия, делал то, чего от него не просили. Здесь другое: ИИ стал субъектом оптимизации. Он помогает писать код, чтобы другая модель работала быстрее. Разница принципиальна. В первом случае человечество пытается удержать ИИ в узде, во втором — пытается за ним угнаться. Удержать — вопрос контроля границ. Угнаться — вопрос скорости способностей. Когда скорость генерации кода обгоняет скорость его проверки, принцип «человек в контуре» сталкивается с очень конкретным вызовом: а человек в этом контуре ещё способен понимать то, что внутри контура происходит?

Отдельно стоит объяснить, почему оптимизация декодирования сложнее оптимизации обучения. Обучение ограничено пиковой вычислительной мощностью: сколько операций с плавающей точкой есть, столько вычислений и получишь. Декодирование ограничено пропускной способностью памяти. Эксперты K3 распределены по множеству чипов, и на каждый обработанный токен система маршрутизации должна разослать данные туда, где живут выбранные эксперты, а потом собрать результаты обратно. Более 120 операций All-to-All, и каждая — задержка. Поэтому в такой ситуации покупка более быстрого чипа не обязательно самое эффективное решение: узкое место не в пиковой мощности, а в эффективности потока данных. Слияние операций в мегаядре по сути сокращает число пересылок данных между видеопамятью и вычислительными блоками. Промышленный смысл этого вывода таков: когда выгода от новых техпроцессов замедляется, а догоняющий разрыв в пиковой производительности одной карты измеряется годами, путь «выжать больше полезных вычислений из уже имеющегося железа» становится более рентабельным.

Основатель SemiAnalysis Дилан в интервью для Sequoia сформулировал это так: рост производительности нельзя обеспечить одним наращиванием железа, настоящий прорыв в эффективности даёт глубокая совместная оптимизация архитектуры модели, программного стека — компиляторов и коммуникационных библиотек — и аппаратного уровня. Эта мысль объясняет значение 12 тысяч строк Nvidia лучше любых цифр. В условиях ограниченного доступа к передовым техпроцессам разрыв в производительности одной карты в короткой перспективе не закрыть. Но системная эффективность, оптимизация компилятора, слияние операторов, наложение коммуникаций — это чисто программная инженерия, которая зависит не от фабрик, а от инженеров и инструментов. Nvidia силами одного инженера, 12 тысяч строк и агентной поддержки получила заметный прирост эффективности без замены железа. Сам этот факт подсказывает, что гонка вычислений расходится на две линии: создать более мощный чип и заставить существующий чип делать больше работы. Вторая линия доступнее для догоняющих и даёт больше пространства.

Есть и деликатный нюанс. Nvidia оптимизирует Kimi K3 от Moonshot AI и, по сообщениям, работает над оптимизацией других моделей, включая DeepSeek V4.1. На фоне ограничений на поставки чипов программная команда Nvidia помогает китайским моделям выжимать всё возможное из железа, которое сама же и продаёт. Продавец лопат помогает вам точить лопату. Это и потому, что оптимизация софта стимулирует продажи железа, и потому, что Nvidia нужно доказать: даже в рамках ограничений она остаётся незаменимым звеном китайской ИИ-индустрии. В этих отношениях конкуренция и сотрудничество существуют одновременно.

И всё же главное — не в том, что Nvidia ускорила Kimi, и не в коэффициенте 1,68, и даже не в том, что компиляторный стек стал новым фронтом. Главное в вопросе, на который человечеству придётся ответить и на который пока ответа нет: когда ИИ начинает оптимизировать ИИ, а скорость оптимизации обгоняет скорость человеческого понимания, сумеет ли человек удержать за собой право последнего суждения? Ответ команды vLLM — менять организацию работы: не читать построчно, а проектировать систему проверки, ограничивать область изменений, системно тестировать. В блоге раскрыта и конкретная деталь: аудит показал, что компилятор перенёс чтение активаций перед синхронным ожиданием, а исправление свелось к ограничению такого типа загрузки статическими весами. Подобные ошибки проходят простые функциональные тесты и требуют целенаправленного расследования. Ответ практичен, но по сути означает: мы принимаем реальность, в которой не понимаем каждую строку кода, и подстраховываемся процессом. Возможно, это и есть новая форма «человека в контуре» в эпоху ИИ — не «человек понимает всё», а «человек задаёт границы, проектирует проверку и несёт ответственность за последствия». Технологии могут ускоряться, но суждение нельзя отдать на аутсорс. В сценарии, где ИИ пишет код для оптимизации ИИ, эта мысль обретает новый смысл: суждение не обязано разбираться в коде, но обязано держать под контролем риск. В названии блога vLLM стоит слово «Responsibly» — «ответственно». В эпоху, когда скорость генерации кода ИИ превышает скорость человеческой проверки, вес этих трёх слов куда больше, чем вес коэффициента 1,68.