Если вы присматриваетесь к Kimi K2.6, первый вопрос — не «сколько видеокарт покупать», а «точно ли нам нужен self-hosting». По проверяемым материалам у модели уже есть страница на Hugging Face, файл с рекомендациями по развёртыванию, отдельная страница в vLLM Recipes, а CloudPrice показывает наличие 3 провайдеров — то есть путь через API или managed-доступ уже существует.[4][
1][
5][
15]
Короткий вывод: официального «минимум столько-то GPU» пока нет
На сегодня можно подтвердить, что у Kimi K2.6 есть публичная модельная страница и материалы для развёртывания, но в доступных источниках нет пригодной для закупки формулы вроде «нужно минимум N GPU такого-то класса и столько-то VRAM».[4][
1]
Поэтому вопросы в духе «хватит ли одной RTX 4090», «потянет ли рабочая станция», «можно ли поставить на один сервер и сразу в production» лучше не превращать в готовые ответы. Более безопасная логика такая: для пробы, интеграции в приложение, coding agent или внутренний инструмент сначала использовать API/провайдера; к самостоятельному развёртыванию переходить только если есть требования к приватности, сети, контролю inference-стека или стоимости на больших объёмах.[15][
1][
5]
Что подтверждено: есть и self-hosting, и API-маршрут
У Kimi K2.6 есть страница moonshotai/Kimi-K2.6 на Hugging Face и файл docs/deploy_guidance.md в репозитории модели.[4][
1] Для русскоязычных команд, которые не каждый день работают с такими инструментами: Hugging Face здесь выступает как площадка с весами, карточкой модели и сопутствующими файлами, а vLLM — как популярный inference/serving-стек для запуска LLM-сервисов.
Страница vLLM Recipes для Kimi K2.6 маркирует модель как 1T / 32B active · MOE · 256K ctx5] Это важная подсказка для планирования: речь не о компактной локальной модели, которую обычно запускают «для себя» на одной потребительской видеокарте.
Параллельно CloudPrice указывает, что Kimi K2.6 доступна у 3 провайдеров.[15] Но цены, лимиты, маршрутизация и доступность у таких провайдеров могут меняться, поэтому перед production-интеграцией надо сверяться с актуальной страницей конкретного поставщика.[
15]
Почему K2.6 не стоит считать маленькой локальной моделью
Маркировка vLLM — 1T параметров, 32B active, MoE и 256K context — уже сама по себе задаёт масштаб задачи.[5] Даже если активная часть MoE меньше полного числа параметров, развёртывание такой модели обычно планируют как серверный inference-проект: с параллелизмом, квантованием, настройкой KV cache, ограничениями по контексту и тестами под реальную нагрузку.
Есть ещё один важный нюанс. Документация vLLM по Kimi K2 относится к moonshotai/Kimi-K2-Instruct, а не к Kimi K2.6, поэтому её нельзя использовать как прямое доказательство минимальных требований для K2.6.[13] Но этот пример показателен как стиль serving-дизайна: он использует Ray на
node 0node 1--tensor-parallel-size 8--pipeline-parallel-size 2--dtype bfloat16--quantization fp8--kv-cache-dtype fp813] Иными словами, публичный пример для семейства Kimi K2 ориентирован на parallelism, квантование и много-GPU/многоузловую конфигурацию, а не на «одна карта — и готово».[
13]
Сторонние материалы дают похожие сигналы, но их нужно читать аккуратно. AllThingsHow приводит пример команды vLLM для moonshotai/Kimi-K2.6-INT4 с --tensor-parallel-size 4--max-model-len 1310729] Другой self-hosting guide утверждает, что INT4-модель Kimi K2.6 занимает примерно 594 ГБ и может запускаться на количестве от 4 GPU H100.[
6] Это полезные ориентиры для проектирования PoC, но не официальная гарантия Moonshot AI и не готовая спецификация для закупки.[
6][
9]
API или self-hosting: быстрый фильтр для решения
| Ситуация | Более разумный маршрут | Почему |
|---|---|---|
| Нужно просто попробовать модель, подключить её к приложению, агенту для кода или внутреннему инструменту | Начать с provider/API | CloudPrice показывает 3 провайдера для Kimi K2.6, так что самостоятельный запуск не единственный вход.[ |
| Нужен приватный деплой, внутренняя сеть или свой serving-стек | Делать PoC по материалам Hugging Face и vLLM Recipes | Есть страница модели, файл deploy guidance и страница vLLM Recipes.[ |
| Хочется использовать потребительские GPU, например 4090 | Сначала арендовать или одолжить среду для проверки, не обещать production заранее | В доступных материалах нет официального минимума по потребительским GPU/VRAM, а примеры указывают скорее на multi-GPU-подход.[ |
| Планируется H100-класс | Рассматривать 4×H100 как возможную точку для теста, а не как гарантию | Утверждение про минимум 4×H100 идёт из стороннего self-hosting guide, не из официальной минимальной спецификации.[ |
| Нужен длинный context или высокая параллельная нагрузка | Тестировать ровно ту же версию модели, context length, квантование и concurrency | vLLM Recipes указывает 256K context, а сторонний пример K2.6 INT4 задаёт |
Чек-лист перед self-hosting PoC
1. Зафиксируйте версию модели
Не смешивайте moonshotai/Kimi-K2.6, moonshotai/Kimi-K2.6-INT4 и moonshotai/Kimi-K2-Instruct в одну задачу. Страница K2.6 на Hugging Face, сторонний пример для K2.6 INT4 и vLLM usage guide для K2-Instruct относятся к разным моделям или вариантам, поэтому требования к памяти и производительности нельзя переносить напрямую.[4][
9][
13]
2. Зафиксируйте длину контекста
vLLM Recipes помечает Kimi K2.6 как модель с 256K context, а пример AllThingsHow для K2.6 INT4 выставляет --max-model-len 1310725][
9] Если вы тестируете 131K context, это не доказывает, что при 256K будут те же VRAM, задержка и throughput.
3. Зафиксируйте квантование и KV cache
В примере vLLM для Kimi K2-Instruct используются FP8 quantization и FP8 KV cache, тогда как сторонний пример K2.6 указывает INT4-вариант модели.[13][
9] Смена квантования, dtype для KV cache, batch size или числа параллельных запросов может радикально поменять требования к железу.
4. Зафиксируйте parallelism
В vLLM-примере для K2-Instruct есть tensor parallel и pipeline parallel; в стороннем примере для K2.6 INT4 используется --tensor-parallel-size 413][
9] В отчёте по PoC нужно явно писать число узлов, число GPU на узел, tensor parallel, pipeline parallel и параметры сервера. Иначе результаты будет почти невозможно сравнить с чужими тестами или повторить у себя.
5. Сначала аренда, потом покупка
Если речь идёт о H100, H200, RTX 4090 или другом дорогом GPU-парке, безопаснее сначала провести PoC на целевой версии модели, целевом context length, целевой параллельной нагрузке и выбранном serving-фреймворке. Текущих проверяемых данных недостаточно, чтобы честно обещать: «вот эти несколько карт точно потянут production».[4][
1][
6][
9]
Практический итог
Для большинства команд стартовая стратегия проста: если нет жёсткого требования к приватному развёртыванию, начните с API или managed-провайдера. Это быстрее, дешевле для проверки гипотез и не требует немедленно решать задачу закупки GPU.[15]
Если self-hosting всё же нужен, относитесь к Kimi K2.6 как к серверному multi-GPU проекту. Берите Hugging Face и vLLM Recipes как отправные точки, но не превращайте сторонние примеры в официальные минимальные требования.[1][
5][
6]
Самый осторожный ответ на вопрос «сколько GPU нужно для Kimi K2.6» сейчас такой: публично подтверждённого минимума нет; считайте развёртывание задачей для много-GPU PoC и проверяйте именно ваш сценарий — ту же модель, то же квантование, тот же context length и ту же нагрузку. До появления официальных цифр не стоит обещать ни одиночную карту, ни потребительские GPU, ни фиксированное число H100 как гарантированно достаточное решение.[4][
1][
9][
13]
