За последние месяцы open source модели совершили рывок. DeepSeek V4-Pro и GLM5.2 почти догнали по интеллекту закрытые модели уровня Opus, но Kimi K3 обещает уровень Fable/Sol и открывает новую эру. Модель огромная: 2.8T параметров, больше 1.5 TB VRAM только на веса, без KV cache под 1M контекста. Один узел B200 такое не вместит. Нужен узел B300 с 288 GB на GPU или два B200 (TP16). Но есть AMD MI355X — у него тоже 288 GB. Он дешевле B300 примерно в 2.4 раза и в 1.7 раза дешевле B200. С софтом у AMD вечно проблемы, но day-0 поддержка Kimi K3 сделала большую часть работы за нас.
На бенчмарке с 1024 входными и 400 выходными токенами MI355X выдает 952 tok/s на узел и 118 tok/s в один поток. Это в 3.8 раза больше агрегатной пропускной способности на узел и в 1.3 раза больше single-stream, чем у TP16 B200 (498 tok/s суммарно на 16 GPU). B300 все еще быстрее по агрегату в 1.65 раза, но стоит в 2.4 раза дороже — по производительности на доллар MI355X его размазывает. У B200 цифры занижены из-за cross-node all-reduce: Kimi K3 просто не помещается на один узел с 8x192 GB. А вот большая емкость HBM у MI355X дает ему реальное практическое преимущество.
Главный рычаг оптимизации — спекулятивное декодирование. У K3 нет встроенных драфтов, ни MTP, ни EAGLE, так что используется внешний RadixArk Kimi-K3-DSpark. На CUDA он работает, а на ROCm при первом запросе планировщик падает с NameError: name 'top_k_renorm_prob' is not defined. В sglang есть два пути построения распределения: dense через top_k_renorm_prob и sparse через torch.topk. CUDA-сборка импортирует функцию из sgl_kernel, а ROCm-сборка — нет, там только Triton top-p. Фикс — одна простая функция PyTorch: sort, masked_fill, divide. Никакого кастомного ядра не нужно, это просто пропущенное определение. Результат: ~2.2x single-stream, ~1.7x per-stream при нагрузке и +18% к пиковому агрегату.
Отдельная история — prefill. TTFT пользователи чувствуют сильнее, чем декод-токены. MI355X на холодном prefill 172k токенов показывал ~51 секунду против ~23 на B300. Почти весь разрыв — в одном ядре. K3 на ROCm откатывался на медленный generic Triton attention, потому что быстрый AITER MLA prefill kernel не загружался. Причина — несовпадение формы: K3 на TP8 дает 12 голов внимания на ранг, а AITER MLA поддерживает 4, 8 или кратные 16. Решение тривиальное: zero-pad головы с 12 до 16, прогнать быстрое ядро, извлечь реальные 12. Prefill ускорился в 2-3 раза, с ~4-7k до ~13k tok/s. Агрегат это не двигает, зато сокращает ожидание первого токена.
В итоге лучший показатель производительности на доллар на MI355X получился почти из коробки. Баги фреймворка были, но меньше, чем с GLM5.2, и никаких кастомных ядер не потребовалось. SOTA на AMD близка. Вопрос, умер ли CUDA moat, уже не выглядит риторическим.