Запуск MoE-модели Kimi-k3 на двух RTX 6000 PRO 96GB с процессором Threadripper PRO 9965WX через ветку PR#26185 в llama.cpp дал 0.41 токена в секунду на префикс и 0.23 токена в секунду на генерацию. Обработка 440 токенов заняла 31 минуту. Это не ошибка конфигурации и не баг ранней сборки - это прямое следствие архитектуры модели с 896 экспертами, которая упирается в пропускную способность памяти даже на топовом одноплатформенном железе.
Результат ставит практический вопрос: можно ли выжать приемлемую скорость из Kimi-k3 без покупки специализированных кластеров за сотни тысяч долларов? Короткий ответ - да, но только через распределённый инференс с быстрой сетью. В этом разборе мы зафиксируем точные цифры, объясним, какие настройки llama.cpp критичны для тяжёлых MoE-моделей, и оценим, насколько 100GbE fabric с RPC-сервером и кластером Spark способны изменить картину.
Материал опирается на результаты тестов из PR#26185 и дополняет наши предыдущие анализы: разбор архитектуры Kimi K3 с критикой отчёта Moonshot AI, стратегии инференса после открытия весов и обзор бюджетных конфигураций для локального запуска.
Результаты бенчмарка: 0.23 tok/s и 31 минута на 440 токенов
Бенчмарк проводился на сборке llama.cpp из ветки PR#26185 - это экспериментальная ветка с улучшенной поддержкой MoE-моделей, но без агрессивных оптимизаций, которые появились позже. Конфигурация стенда: две видеокарты NVIDIA RTX 6000 PRO с 96 ГБ памяти каждая, процессор AMD Threadripper PRO 9965WX (24 ядра, 48 потоков), системная память - объём, достаточный для размещения полных весов модели в RAM. Kimi-k3 загружалась в 4-битной квантизации - единственный вариант, при котором веса модели (~1.4 ТБ в FP4) вообще помещаются на эту конфигурацию.
Цифры, которые мы получили:
- Скорость обработки префикса (prefill): 0.41 tok/s
- Скорость генерации (decode): 0.23 tok/s
- Общее время на 440 токенов: 31 минута
Для сравнения: на кластере из 80 RTX 5090 через 25GbE та же модель выдаёт на порядки более высокие показатели. Но здесь важна не столько абсолютная скорость, сколько диагностика узких мест - именно она определяет, какие оптимизации дадут максимальный эффект.
Конфигурация стенда и методика тестирования
Выбор двух RTX 6000 PRO 96GB не случаен. Это максимальный объём VRAM, доступный на одной потребительской карте в 2026 году. Суммарные 192 ГБ VRAM позволяют разместить часть экспертов MoE-модели непосредственно на GPU, а Threadripper PRO 9965WX с его 24 ядрами обеспечивает высокую пропускную способность CPU-части вычислений. Теоретически это близкая к оптимальной одноплатформенная конфигурация для модели такого размера.
Методика тестирования стандартна для llama.cpp: модель загружается с параметрами по умолчанию (если не указано иное), промпт фиксированной длины подаётся на вход, замеряется время prefill и decode. Никаких дополнительных оптимизаций ядра или кастомных аллокаторов памяти не применялось - это «честный» запуск из коробки, который показывает реальную картину для разработчика, впервые берущего Kimi-k3 в работу.
Почему именно PR#26185? Эта ветка - первая, где появилась стабильная поддержка Kimi-k3 в llama.cpp. Позднейшие оптимизации, включая агентный разгон до 406 tok/s через kernel fusion и сжатие графа, уже опираются на доработанные ядра и кастомные аллокаторы. Наш бенчмарк фиксирует базовую точку отсчёта - с ней имеет смысл сравнивать все последующие улучшения.
Почему так медленно: архитектура MoE и узкие места инференса
Kimi-k3 использует архитектуру Mixture-of-Experts с 896 экспертами. На каждом токене активируется подмножество экспертов - обычно 8 из 896. Веса неактивных экспертов не участвуют в вычислениях, но они должны быть доступны в памяти на случай активации. Это создаёт уникальную нагрузку: объём памяти требуется как для плотной модели в 2.8 трлн параметров, а вычислений - лишь на долю от этого объёма.
В конфигурации с двумя RTX 6000 PRO 96GB мы имеем 192 ГБ VRAM. Веса Kimi-k3 в FP4 занимают около 1.4 ТБ. Даже с 4-битной квантизацией модель не помещается в VRAM целиком. llama.cpp использует гибридный режим: часть слоёв на GPU, часть - в системной RAM с подкачкой по мере необходимости. Именно подкачка экспертов между RAM и VRAM становится главным бутылочным горлышком.
При генерации каждого токена llama.cpp определяет, какие эксперты активируются, и если нужного эксперта нет в VRAM - начинается transfer через PCIe. Пропускная способность PCIe 4.0 x16 составляет ~32 ГБ/с в идеальных условиях. Вес одного эксперта Kimi-k3 в FP4 - порядка 1.5 ГБ. Активация 8 экспертов требует до 12 ГБ данных, которые нужно передать за время вычисления одного токена. Грубый расчёт: 12 ГБ / 32 ГБ/с = 0.375 секунды только на передачу. Добавьте сюда время CPU-вычислений для тех экспертов, которые llama.cpp решил обрабатывать не на GPU - и 0.23 tok/s перестают удивлять.
Утилизация GPU в таком сценарии низкая. Карты простаивают, ожидая подкачки весов. Это фундаментальное ограничение одноплатформенного инференса для больших MoE-моделей - нехватка именно пропускной способности памяти, а не вычислительной мощности.
Влияние параметров llama.cpp: n-cpu-moe, -ngl, mmap
Три параметра определяют, как llama.cpp распределяет MoE-модель между CPU и GPU. Их правильная настройка способна дать кратный прирост производительности - или обрушить скорость до нуля, если выставить значения наугад.
--n-cpu-moe - количество экспертов MoE, которые принудительно обрабатываются на CPU. По умолчанию llama.cpp пытается разместить максимум на GPU, но для Kimi-k3 это приводит к постоянным подкачкам. Увеличение n-cpu-moe фиксирует часть экспертов в системной RAM и обрабатывает их силами CPU, освобождая VRAM для тех экспертов, которые реально используются чаще. Рекомендуемое значение для конфигурации с 192 ГБ VRAM: 64-128 экспертов на CPU. Это снижает пиковое потребление VRAM и стабилизирует скорость генерации ценой небольшого роста задержки на CPU-экспертах.
-ngl (number of GPU layers) - сколько слоёв модели загружается на GPU. Для MoE-моделей этот параметр работает нелинейно: загрузка дополнительных слоёв увеличивает потребление VRAM, но не всегда ускоряет инференс, потому что узкое место - подкачка экспертов, а не вычисления на слоях. Оптимальное значение для двух RTX 6000 PRO 96GB с Kimi-k3: 20-30 слоёв. Загрузка всех слоёв (ngl 99) приведёт к out-of-memory или постоянным свопам.
--mmap - отображение файла модели в память через mmap() вместо явной загрузки. Для моделей, не влезающих в VRAM, mmap критически важен: он позволяет операционной системе самой управлять страницами памяти, выгружая неиспользуемые эксперты и подгружая активные по мере необходимости. Без mmap llama.cpp пытается загрузить всю модель в RAM при старте, что для Kimi-k3 означает либо невозможность запуска, либо жёсткий своп на диск с падением скорости до 0.01 tok/s.
Пример команды запуска с оптимизированными параметрами:
./llama-cli -m kimi-k3-Q4_K_M.gguf -ngl 24 -n-cpu-moe 96 --mmap 1 -c 4096 -p "Your prompt here"Эти настройки не превратят 0.23 tok/s в 23 tok/s. Но они могут поднять скорость до 0.5-0.8 tok/s на той же конфигурации - разница между «полной непригодностью» и «можно запустить в фоне для пакетной обработки».
Масштабирование через RPC-кластер: 100GbE fabric и Spark
Радикальное решение - вынести экспертов Kimi-k3 на отдельные узлы и обрабатывать их параллельно. Концепция: один узел держит attention-слои и координирует инференс, а эксперты распределены по RPC-серверам, соединённым 100GbE fabric. Когда llama.cpp определяет, какие эксперты активируются для следующего токена, координатор отправляет запросы на соответствующие RPC-серверы, те обрабатывают свои эксперты и возвращают результаты. Оркестрацию можно возложить на Apache Spark - он управляет расписанием, ретраями и балансировкой.
100GbE fabric даёт пропускную способность ~12.5 ГБ/с на линк. В отличие от PCIe 4.0 x16 с его 32 ГБ/с, здесь мы получаем параллельные линки между всеми узлами кластера. Десять RPC-серверов с 100GbE каждый - это агрегированная пропускная способность до 125 ГБ/с, что перекрывает потребности Kimi-k3 с запасом. Задержка 100GbE (~1-3 микросекунды на хоп в RDMA-режиме) добавляет минимальные накладные расходы по сравнению с PCIe-транзакциями.
Ожидаемый прирост скорости зависит от топологии. При 8 активируемых экспертах на токен и 8 RPC-серверах, каждый из которых держит по 112 экспертов, теоретический предел ускорения - до 8 раз относительно одноплатформенного инференса. Практические тесты на схожих конфигурациях (80x RTX 5090 через 25GbE) показывают, что реальный прирост составляет 4-6 крат - остальное съедают накладные расходы на сериализацию тензоров и координацию.
Ограничения подхода: сериализация активаций между узлами добавляет 5-15% накладных расходов в зависимости от размера батча. Spark вносит задержку на планирование задач - для инференса с малыми батчами (1-4 запроса) это может быть критично. Альтернатива - tensor parallelism, где модель разрезается по измерениям тензоров, а не по экспертам. Tensor parallelism эффективнее для моделей с плотными слоями, но для MoE с 896 экспертами RPC-подход даёт лучшую утилизацию оборудования.
Оценка эффективности: когда кластер окупается
Переход от одноплатформенного инференса к кластеру - это капитальные затраты. Оценим их для минимально жизнеспособной конфигурации:
- 100GbE коммутатор: от $5,000 (б/у enterprise) до $25,000 (новый с RDMA-поддержкой)
- RPC-сервер: сборка на базе RTX 6000 PRO 96GB + CPU среднего уровня - около $15,000 за узел
- Минимальный кластер: координатор + 4 RPC-сервера + коммутатор - от $65,000
Прирост скорости с 0.23 tok/s до ~1.0-1.5 tok/s на 4 узлах. Это всё ещё не интерактивный режим (для него нужно 20+ tok/s), но уже приемлемо для пакетной обработки: генерация 1000 токенов займёт 11-17 минут вместо 72 минут на одиночном сервере.
Сценарии, где кластер оправдан:
- Постоянная нагрузка - обработка очереди запросов 24/7, где время выполнения критично для бизнес-процесса
- Большие батчи - одновременная генерация для множества пользователей, где параллелизм экспертов используется полностью
- Исследовательские задачи - прогон бенчмарков, валидация файнтюнов, где важна скорость итераций
Если задача - разовый эксперимент с Kimi-k3, кластер не окупается. Аренда облачных GPU с 400-600 ГБ совокупной VRAM обойдётся в $50-150 за час и даст схожую или лучшую производительность без капитальных затрат. Кластер имеет смысл, когда Kimi-k3 или аналогичные MoE-модели становятся частью продуктового пайплайна.
Сравнение с апгрейдом одиночного сервера: добавление третьей RTX 6000 PRO 96GB (+$15,000) увеличит VRAM до 288 ГБ и позволит загрузить больше экспертов на GPU, но не решит проблему PCIe-подкачки для оставшихся. Прирост скорости будет линейным в лучшем случае - 30-50% за $15,000. Те же деньги, вложенные в 100GbE fabric и два RPC-сервера, дадут 2-3-кратный прирост за счёт параллелизма.
Практические рекомендации и следующие шаги
Текущая производительность Kimi-k3 на одноплатформенном топовом железе - 0.23 tok/s - исключает интерактивное применение. Модель запускается, работает, но практическая ценность ограничена пакетной обработкой с непривязанным ко времени результатом. Тюнинг параметров llama.cpp (n-cpu-moe, ngl, mmap) способен поднять скорость до 0.5-0.8 tok/s - этого достаточно для экспериментов и валидации подходов.
Радикальное ускорение требует распределённого инференса. Минимальный кластер из 4 RPC-серверов с 100GbE fabric и оркестрацией через Spark выводит скорость в диапазон 1.0-1.5 tok/s. Полноценный интерактивный режим (20+ tok/s) на текущий момент достижим только на крупных кластерах - от 20 узлов с быстрой сетью, либо через агрессивные оптимизации ядра, подобные тем, что продемонстрировал GPT 5.6 Sol.
Что делать прямо сейчас:
- Скачайте актуальную сборку llama.cpp из основной ветки - поддержка Kimi-k3 уже влита, и baseline-производительность выше, чем в PR#26185
- Начните с параметров -ngl 24, -n-cpu-moe 96, --mmap 1 и итеративно подбирайте значения под свою конфигурацию
- Для продакшен-нагрузки рассмотрите кластерные конфигурации из нашего обзора - от бюджетных сборок с Optane до DGX Spark
Развитие поддержки MoE в llama.cpp продолжается. Уже анонсированы оптимизации аллокатора экспертов, которые снижают накладные расходы на подкачку на 20-30%. Следите за релизами - каждая новая версия может изменить цифры в этом бенчмарке в лучшую сторону. Kimi-k3 остаётся одной из самых требовательных к инфраструктуре открытых моделей, но разрыв между её потенциалом и доступностью запуска сокращается с каждым месяцем.