Self-host Kimi K3 в день 0: путь vLLM против мифа про Ollama на ноутбуке

Хаб Kimi K3: Specs, цена, API id → /kimi-k3. Timeline → /kimi-k3-status. Реальность Ollama/VRAM → /blog/34-kimi-k3-vram-ollama-local-requirements. Календарь open weights → /blog/31-kimi-k3-open-weights-july-27.

Лента орёт: open weights Kimi K3 — 27 июля. Кто-то кидает скрин с Mac Mini. Кто-то — загадочный GGUF «one-click Ollama». А вам нужно ответить на более простую работу: сможет ли команда self-host’ить это, или это просто хайп?

Коротко: self-host — это задача кластера / vLLM, а не чат-приложения на ноутбуке. Продукт и API уже живые. Полные публичные веса — календарное событие, которое надо перепроверить на Hugging Face, а не гарантия, что ollama pull заработает сегодня вечером.

Сайт независим от Moonshot. Specs и даты ниже — по публичным докам и партнёрским блогам на 27 июля 2026; перед покупкой железа или доверием случайному репо перепроверьте блог Kimi K3, platform docs и vLLM K3 preview.

Короткий ответ (читай в первую очередь)

1. Две разные задачи.
   • «Хочу качество K3 уже сегодня» → kimi.com, Kimi Code или API id kimi-k3 на platform.kimi.ai.
   • «Хочу веса в своём VPC» → ждите официальный HF-репо Moonshot с реальными файлами + day-0 serving-стек (vLLM — публичный путь, к которому готовятся Moonshot и партнёры).
2. На момент написания HF moonshotai/Kimi-K3 — всё ещё страница Upcoming release (countdown / notify), а не готовый download с safetensors. Посты в соцсетях «уже open» обычно читают обещание, а не вкладку Files.
3. Ollama на одной gaming-GPU — неверная mental model для полного K3 класса 2.8T. Официальный serving-язык указывает на supernode / multi-accelerator, а не на игрушку 24 ГБ.
4. Preview vLLM от 22 июля — лучшая публичная заметка «как индустрия будет это сервировать»: day-0 model path, KDA-aware prefix caching, Docker-рецепты, NVIDIA + начальный AMD — не consumer one-liner.
5. Уже скачиваемые open-линии Kimi (например K2.6 / K2.7 Code на Hugging Face) — то, что можно self-host’ить сегодня, если нужны offline-веса, пока файлы K3 ещё pending.

Одной фразой: API или продукт — за intelligence на этой неделе; vLLM + реальные веса — за self-host, когда вкладка Files станет настоящей. Не путайте эти две двери.

Источник: официальный messaging запуска K3 / техблог Kimi K3, Moonshot AI, 16 июля 2026.

Кому этот гайд (и кому нет)

Если вы искали только «kimi k3 ollama», заодно читайте наш пост про VRAM и Ollama — там честная проверка локального железа. Эта страница — про self-host / serving-путь.

Что на самом деле значит «open weights day 0»

Публичная история Moonshot (см. анонс K3):

• Сначала продукт + API (живые с ~16 июля 2026): chat, Work, Code, API kimi-k3.
• Полные веса модели к 27 июля 2026 — обязательство выкатить файлы, а не магия «уже на всех зеркалах».
• Архитектура, которая меняет serving: Kimi Delta Attention (KDA), Attention Residuals, sparse MoE (официальный framing: 16 из 896 экспертов активны на токен), ~2.8T total params, 1M context, native vision.
• Явная заметка: они вложили KDA-related prefix-cache работу в community vLLM, релиз вместе с моделью — потому что KDA не ведёт себя как классический full-attention KV cache.

Так что «day 0» для self-host’еров — это по сути два дропа:

1. Веса + LICENSE + model card (обычно Hugging Face под moonshotai/…).
2. Serving-код, который понимает K3 (vLLM preview указывает на model path, parsers, kernels, Docker, recipes).

Одно без другого — полуоткрытая дверь.

Путь A — Продукт и API (что большинству открывать сегодня)

Self-host не нужен, чтобы пощупать frontier-качество K3:

Если цель — «зашить фичу в этом спринте», выигрывают API + продукт. Self-host — для data residency, air-gap, custom fine-tune или unit economics на огромном объёме, а не для FOMO.

Источник: официальные медиа запуска K3 / блог Kimi K3, 16 июля 2026.

Путь B — Self-host через vLLM (серьёзный day-0 путь)

Что vLLM публично обещал (22 июля 2026)

Preview команды vLLM — самый ясный пост про «готовность экосистемы» до полного open-source day. Простыми словами, они готовят:

• Day-0 open-source serving к релизу весов: model implementation, Docker images, deployment recipes, production validation
• KDA-aware prefix caching (классические paged KV-трюки недостаточны для recurrent KDA state)
• Kernel / performance-работа по KDA prefill & decode, Attention Residuals, MoE (MXFP4-путь в их framing релиза), multimodal-куски
• Рецепты NVIDIA на финальной настройке + начальный AMD-путь

Это язык инфры. Это не «вставьте это в Ollama на Windows и чатьтесь».

Как думать про day-0 serving (checklist, не замороженный CLI)

Когда веса появятся, нормальный self-host runbook выглядит так — всегда предпочитайте официальную model card и доки vLLM любому блогу, включая этот:

1. Проверьте репо
   • Org должен быть moonshotai (или другой источник, на который ссылается Moonshot из официального блога).
   • Реальные Files (shards), а не только маркетинг «Upcoming release».
   • LICENSE прочитан целиком (предыдущие open-линии Kimi часто шли с Modified MIT-style; не предполагайте то же для K3, пока файл не вышел).
2. Закрепите serving-build, который заявляет поддержку K3 / KDA
   • Следуйте посту vLLM и версии, которую они пометили для day-0 — ветки nightly/main двигаются.
   • Ожидайте tool-call / reasoning parsers и multimodal-флаги, специфичные для Kimi, похожие на более ранние рецепты семейства K2.
3. Планируйте параллелизм как у MoE-гиганта
   • Sparse MoE класса 2.8T — про expert parallelism + bandwidth, а не один эксперимент tensor-parallel-size 1.
   • Официальные product docs указывали на serving в стиле supernode с multi-accelerator для конкурентного throughput — читайте это как формат дата-центра.
4. Скромнее с 1M context
   • Cloud API «1M flat» — это не то же самое, что «я выставил --max-model-len 1048576 в день один и всё летает».
   • Начните с более короткого max length, измерьте prefill/decode, потом растягивайте.
5. Разведите «веса на диске» и «production SLO»
   • Day-0 часто значит оно бутнулось. Production — мониторинг, PD disaggregation, cache hit rates, failure domains; пост vLLM явно говорит про эти жёсткие части.

Мы не вставляем copy-paste строку vllm serve … с фейковыми флагами, будто она «освящена». Неверные флаги протухают за часы; model card + release notes vLLM — source of truth в день, когда файлы приземлятся.

Реальность железа (без выдуманной таблицы ГБ)

Люди хотят: «K3 Q4 = XX ГБ на 4090».

Мы не будем выдумывать эту таблицу.

За что можно держаться:

• Общий масштаб (~2.8T) и sparse activation (framing 16/896) ≠ «ноутбук вмещает total params». Вы всё равно храните огромный footprint весов; активируете только subset на токен.
• Community-оценки размера download часто попадают в коридор сотни ГБ до ~1+ ТБ в зависимости от quant-story (MXFP4 vs более высокая точность) — любой номер считайте неофициальным, пока model card не перечислит размеры файлов.
• Собственный язык Moonshot про 64+ accelerator / supernode — это форма serving, а не хобби-сноска.
• Если вы уже не крутите multi-node GPU-кластеры (и не покупаете managed inference), API или managed host для большинства команд победят героический weekend-build.

Про таймлайны Ollama/GGUF и «можно ли уже локально» — оставайтесь на гайде по VRAM.

Источник: официальные медиа запуска K3 / блог Kimi K3, 16 июля 2026.

Путь C — Миф про Ollama / «Mac Mini» (вежливо прибить)

Спрос на поиск ollama, gguf, local, self host реален. Ошибка — склеить это в одну фантазию:

Здоровый локальный путь, пока ждёте: self-host K2.6 / K2.7 Code (уже на HF) для offline coding-агентов; K3 через API — на тяжёлые задачи. Hybrid-стеки бьют конкурсы «чистоты».

Checklist дня (когда ячейка календаря «срабатывает»)

Используйте, когда что-то реально появилось — не когда репост орёт «dropping».

Веса

• Официальный блог/X или страница HF сдвинулись с Upcoming на скачиваемые Files
• Репо под moonshotai (или явно слинковано с kimi.com/blog/kimi-k3)
• LICENSE + model card + перечисленные размеры shard’ов
• Нет зависимости от случайного third-party «Kimi-K3-abliterated» как единственной копии

Serving

• vLLM (или другой engine, который назовёт Moonshot) — версия / image, где задокументирован K3
• Tool-call / reasoning parsers совпадают с card
• План параллелизма просмотрен кем-то, кто уже крутил large MoE
• Smoke test: health endpoint, короткий prompt, один tool call, один long-context prefill

Бизнес

• Decision tree: API по умолчанию vs self-host pilot vs managed host
• Security: контроль доступа к весам, eval на hallucination / tool safety — не «open = в prod той же ночью»

Что делать на этой неделе (decision tree)

Если нужно качество K3 до обеда
→ Продукт или API. Не блокируйтесь на весах.

Если строите self-host pilot
→ Читайте vLLM K3 preview; резервируйте cluster capacity; набросайте checklist выше; потренируйтесь на весах K2.6 / K2.7 Code, чтобы pipeline был скучным, когда прилетят файлы K3.

Если у вас только gaming-ноутбук
→ Наслаждайтесь K3 в cloud product/API. Локально — меньшие open-модели. Игнорируйте thumbnails «full K3 on 24GB».

Если compliance-команде нужны open weights
→ Закладка HF moonshotai/Kimi-K3 и официальный блог; никакого production design, пока LICENSE + файлы не реальны.

Watch-outs (фильтр шума)

1. Дата-обещание ≠ вкладка Files. 27 июля — публичный target Moonshot; проверяйте артефакты.
2. Треды про hallucination / независимые бенчмарки в соцсетях гуляют — не вставляйте чужие % в runbook как «официальные».
3. Архитектурные keywords (KDA, AttnRes, MXFP4) — реальная инженерия; они не доказывают, что consumer-runtime’ы существуют в день один.
4. Этот сайт — не support Moonshot. При сомнении побеждают официальные доки.

Куда дальше

• Status hub: /kimi-k3-status · product hub: /kimi-k3
• Календарь open weights: /blog/31-kimi-k3-open-weights-july-27
• Честность local / Ollama: /blog/34-kimi-k3-vram-ollama-local-requirements
• Free-двери: /blog/33-kimi-k3-free-how-to · как пользоваться: /blog/36-how-to-use-kimi-k3
• Контроль счёта: /blog/37-kimi-k3-api-pricing-cost-control
• Официально: блог Kimi K3 · vLLM K3 preview · HF moonshotai

Итог: self-host Kimi K3 — это серьёзный serving-проект (vLLM + multi-accelerator реальность), а не трюк party-Ollama. Пользуйтесь cloud-дверями, пока Upcoming ещё Upcoming — и когда вкладка Files станет настоящей, проверьте org, license и стек, прежде чем доверять любому download.