Kimi K3 на 4 ГБ: правда о 2.8 триллионах параметров

Может ли Kimi K3 работать на GPU с 4 ГБ? Нет в обычном смысле слова «запуститься локально». Нативные веса MXFP4 модели Kimi K3 требуют примерно 1.4 ТБ до учёта метаданных и overhead исполнения. GPU с 4 ГБ может выступать лишь промежуточным хранилищем, если программное обеспечение передаёт крошечные фрагменты модели с диска или оперативной памяти хоста. Это технически интересно, но это не то же самое, что загрузить Kimi K3 в 4 ГБ VRAM, и ни один действующий рецепт Kimi K3 не делает это практичным решением.^[1][2]

Различие важно, потому что три верных факта часто объединяют в одно ложное заключение: Kimi K3 является разреженной моделью, только 104B параметров активны на токен, а инструменты layer offloading уже запускали модели на 70B меньшего размера на GPUs с 4 ГБ. Ни один из этих фактов не делает checkpoint из 2.8T параметров таким, чтобы он вместился в 4 ГБ. В этом руководстве мы разберём математику памяти, объясним, что действительно меняется при offloading, проверим текущую поддержку софта и покажем практичный маршрут, который работает сегодня.

TL;DR

• Kimi K3 действительно содержит 2.8T параметров всего. Это разреженная модель Mixture-of-Experts с 104B активных параметров на токен, 93 слоями, 896 экспертами и окном контекста из 1M токенов.^[1]
• MXFP4 её не делает маленькой. Четыре бита на параметр дают нижний предел в 1.4 ТБ десятичных, или 1.27 ТиБ, до учёта масштабов, метаданных, тензоров других precision и runtime state.
• 104B активных параметров — это показатель вычислений, не хранилища. Маршрутизатор может выбрать разные эксперты на следующем токене, поэтому все эксперты должны оставаться доступными где-то.
• GPU в 4 ГБ может быть только буферной зоной. Offloading на диск или CPU перемещает фрагменты модели через VRAM; оно не избавляет от необходимости хранить полную модель.
• AirLLM в настоящее время не документирует поддержку Kimi K3. Его опубликованный пример для 4 ГБ ориентирован на Llama 3 70B, в то время как Kimi K3 использует новую кастомную multimodal MoE архитектуру.^[4]
• Практичный способ — использовать API. Недорогой ноутбук может обращаться к Kimi K3 через OpenAI-совместимый endpoint, пока модель работает на удалённой инфраструктуре.

Реалии железа Kimi K3 в двух словах

Moonshot описывает Kimi K3 как open-weight, native multimodal agentic модель, построенную на основе Kimi Delta Attention, Attention Residuals и Stable LatentMoE. Она активирует 16 из 896 маршрутизируемых экспертов для каждого токена и включает vision encoder MoonViT-V2.^[1][2]

Эти архитектурные решения снижают вычислительные затраты и стоимость длинного контекста. Они не превращают checkpoint в триллион параметров в модель для потребительского GPU.

Почему 2.8 триллионов MXFP4 параметров требуют 1.4 ТБ

Первый расчёт простой:

2.8 триллиона параметров × 4 бита
= 11.2 триллиона бит
= 1.4 триллиона байт
= примерно 1.27 ТиБ

Это нижний предел, а не полная оценка развёртывания. Реальные checkpoints также содержат масштабы квантизации, индексы, конфигурацию, embeddings, тензоры других precision и 401M-параметровый vision encoder. Runtime добавляет activations, рабочую память выбранных экспертов, attention state, CUDA или NPU ядра, а также KV или recurrent-state бюджет, растущий с параллелизмом и настройками контекста.^[1]

Официальный checkpoint Hugging Face разбит на много больших safetensor шардов; индивидуальные перечисленные шарды измеряются в десятках гигабайт. Один шард может превысить всю ёмкость GPU на 4 ГБ, прежде чем движок вывода выделит хотя бы один буфер активации.^[3]

Для сравнения, GPU в 4 ГБ теоретически может вместить около 8 миллиардов обычных 4-битных параметров, если бы каждый байт был доступен для весов. На практике может вместить меньше, потому что runtime также нуждается в памяти. Kimi K3 примерно в 350 раз больше по общему количеству параметров.

Почему «104B активных параметров» не означает модель в 52 ГБ

Разреженность MoE снижает арифметику, а не checkpoint, который нужно держать доступным. Kimi K3 маршрутизирует каждый токен через малый подмножество его 896 экспертов, поэтому только 104B из 2.8T параметров участвуют в forward pass этого токена. На четыре бита каждый, 104B параметров представляют примерно 52 ГБ данных весов до runtime overhead.

Даже эта оценка 52 ГБ не должна приниматься за статичный мини-checkpoint. Следующий токен может выбрать другой набор экспертов. Если только рабочая нагрузка не зафиксирует выбор экспертов—что изменило бы поведение модели—runtime нужен доступ ко всему пулу экспертов на последовательности.

Здесь три отдельных числа:

• 2.8T параметров всего определяют полное хранилище checkpoint.
• 104B активных параметров приблизительно соответствуют вычислениям и доступу данных на токен.
• 4 ГБ VRAM — это только объём, который может находиться на GPU в один момент.

Разреженная активация делает Kimi K3 эффективнее плотной модели в 2.8T. Но она не делает полную модель загрузкой в 104B, и 104B всё ещё намного больше, чем 4 ГБ GPU.

Как layer-by-layer offloading может использовать GPU в 4 ГБ

Layer offloading меняет где ждут веса, а не сколько весов существует. Базовый offload-цикл выглядит так:

1. Храни большинство весов модели на SSD или в системной памяти.
2. Загрузи следующий необходимый слой или шард эксперта в GPU память.
3. Выполни эту часть forward pass.
4. Выгрузи шард и загрузи следующий.
5. Повтори последовательность для каждого слоя и каждого сгенерированного токена.

Так может работать модель, которая больше чем VRAM. AirLLM популяризировал этот паттерн демонстрацией Llama 3 70B на GPU в 4 ГБ, разложив модель на layer-wise шарды и перекрывая загрузку с вычислениями.^[4]

Kimi K3 делает паттерн намного сложнее. Она имеет 93 слоя, сотни возможных экспертов, кастомный KDA/Gated-MLA attention стек, native multimodality и более одного терабайта квантизованных весов. Полный MoE слой сам может быть больше 4 ГБ, поэтому совместимый движок нужен sub-layer или expert-level streaming—не просто обычный layer offload.

Узким местом производительности становится перемещение данных. Генерация одного токена может вызвать много случайных или полу-случайных чтений экспертов по десяткам слоёв. Даже быстрый NVMe SSD на много порядков медленнее памяти акселератора, и тот же процесс повторяется для следующего токена. Offloading может запустить эксперимент; он не делает его интерактивным.

Можешь ли ты запустить Kimi K3 на GPU в 4 ГБ с AirLLM сегодня?

Нет, согласно его опубликованной поддержке и примерам на 1 августа 2026 года. AirLLM документирует Llama, Mixtral, Qwen, ChatGLM, Baichuan, Mistral, InternLM и связанные семейства моделей. Его результат в 4 ГБ — Llama 3 70B, а не Kimi K3.^[4]

Это отсутствие важно. Kimi K3 — это не больший Llama checkpoint, который существующий загрузчик может автоматически идентифицировать. Рабочая реализация должна понимать:

• кастомную конфигурацию Kimi K3 и имена тензоров;
• Stable LatentMoE маршрутизацию через 896 экспертов;
• нативные MXFP4 веса и MXFP8 активации;
• KDA и периодические Gated MLA attention слои;
• сохранённый reasoning output и multimodal vision tower;
• expert-aware разбиение, достаточно маленькое для доступной VRAM.

Moonshot в настоящее время рекомендует vLLM, SGLang и TokenSpeed для развёртывания Kimi K3. AirLLM не указан как поддерживаемый движок.^[1]

Это не доказывает, что community port на 4 ГБ невозможен. Это означает, что скопированный AirLLM Llama пример — это не воспроизводимое руководство Kimi K3 сегодня. Достоверное утверждение должно предоставить публичную ветвь, точный commit, детали хранилища и памяти, prompt, output, tokens per second и доказательство того, что использованы полные официальные веса.

Как выглядит валидированное развёртывание Kimi K3

Production-рецепты Kimi K3 работают в масштабе кластера. Одно текущее руководство vLLM-Ascend валидирует 131K-контекст развёртывание на четырёх узлах Atlas 800 A3, каждый с шестнадцатью 64-гигабайтными NPUs. Его конфигурация 1M-контекста требует минимум восемь таких узлов.^[5]

Это не универсальный минимум—разные акселераторы, движки, параллелизм и лимиты контекста меняют требование—но это полезная проверка реальности. Валидированная конфигурация измеряет агрегированную память акселератора в терабайтах, а не гигабайтах.

Правильный ответ по железу зависит от того, является ли цель доказательством исполнения, интерактивным использованием, multi-user serving или production throughput. Фраза «работает на 4 ГБ» бессмысленна без этой цели.

Чек-лист для оценки любого утверждения о Kimi K3 на 4 ГБ

Перед тем, как следовать руководству, ищи доказательства, ответящие на эти вопросы:

1. Это официальный checkpoint в 2.8T? Дистилляция, прокси или меньшая модель с названием Kimi — это не Kimi K3.
2. Где хранятся полные веса? Ответ должен учитывать более одного терабайта локального или сетевого хранилища.
3. Сколько системной памяти требуется? «GPU в 4 ГБ» ничего не говорит о 512 ГБ или 1 ТБ памяти хоста рядом с ним.
4. Какой commit движка вывода поддерживает K3? Генерик pip install команда недостаточна для новой архитектуры.
5. Поддерживается ли vision или только язык? Пропуск 401M vision encoder меняет тестируемую поверхность модели.
6. Какая длина контекста использована? 64-токен демо и 1M-токен сессия имеют радикально разные потребности runtime.
7. Какова измеренная пропускная способность? Требуй tokens per second—или per minute—плюс time to first token.
8. Был ли ответ верифицирован? Успешно запущенный процесс — это не доказательство того, что он загрузил правильные веса или сгенерировал когерентный K3 output.

Если пост сообщает только VRAM, он пропустил ресурсы, которые делают трюк возможным.

Практичный способ использовать Kimi K3 с компьютера с GPU в 4 ГБ

Маршрут, который работает сегодня — держать inference удалённо и использовать low-end компьютер как клиент. Локальный GPU неуместен; всё, что нужно — это сетевое соединение и API ключ.

reAPI предоставляет Kimi K3 через OpenAI-совместимый Chat Completions endpoint:

curl https://api.reapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $REAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Explain how expert routing changes memory access in a sparse MoE model."
      }
    ],
    "reasoning_effort": "high",
    "stream": true
  }'

Это не локальный вывод, и его не следует маркетировать как таковой. Это практичный ответ для разработчиков, которые хотят Kimi K3 возможность без приобретения и управления multi-node акселератор кластером. Полный контракт запроса находится в документации Kimi K3 API, с живыми тарифами на странице модели.^[6]

Если ты всё ещё хочешь экспериментировать с локальным offloading

Рассматривай это как systems research, а не как one-command установку. Реалистичный preflight список:

• минимум 1.5–2 ТБ быстрого свободного хранилища для checkpoint, кешей и conversion артефактов;
• достаточно bandwidth и терпения для загрузки много больших шардов;
• ветвь движка вывода, которая явно поддерживает архитектуру Kimi K3 и MXFP4 формат;
• план для host RAM, memory mapping, page cache и SSD endurance;
• язык-only режим если experimental runtime не реализовал vision;
• короткий контекст и крошечные outputs для первой валидации;
• instrumentation для disk reads, GPU utilization, time to first token и output correctness.

Не придумывай рабочую команду заменой Llama model ID на moonshotai/Kimi-K3. Пока offloading движок явно не поддерживает K3, наиболее вероятный результат — unsupported конфигурация, tensor mismatch или out-of-memory отказ во время конвертации.

FAQ

Может ли Kimi K3 действительно работать на GPU в 4 ГБ?

Нет как self-contained, практичная локальная модель. Будущее специализированное runtime может использовать 4 ГБ VRAM как staging буфер пока потоковые веса из намного большего хранилища или памяти, но полная модель не вмещается и текущие mainstream 4 ГБ рецепты не документируют поддержку Kimi K3.

Насколько велики веса Kimi K3?

Теоретический пол для 2.8T параметров на четыре бита каждый — примерно 1.4 ТБ десятичных или 1.27 ТиБ. Реальный checkpoint и runtime требуют больше из-за quantization масштабов, non-4-bit тензоров, vision encoder и execution state.

Почему Kimi K3 говорит что только 104B параметров активны?

Kimi K3 — разреженная MoE модель. Каждый токен использует подмножество экспертов, снижая compute, но будущие токены могут выбрать других экспертов. Полный пул 2.8T экспертов всё ещё должен оставаться доступным.

Означает ли MXFP4 что любой GPU с 4 ГБ может его запустить?

Нет. MXFP4 означает что основные веса используют примерно четыре бита на значение. Четыре бита на 2.8 триллиона — это всё ещё примерно 1.4 ТБ до overhead.

Может ли AirLLM запустить Kimi K3?

AirLLM в настоящее время не перечисляет Kimi K3 среди своих документированных семейств моделей и не предоставляет Kimi K3 рецепт. Его пример в 4 ГБ для Llama 3 70B. Поддержка может быть добавлена позже, но она не должна предполагаться из generic model loader.

Какой самый дешёвый практичный способ использовать Kimi K3?

Для случайного или development использования используй hosted pay-per-token API. Self-hosting становится разумным только когда контроль, sustained volume или data-location потребности оправдывают multi-node hardware и operations работу.

Могу ли я запустить меньшую версию Kimi K3 локально?

Community дистилляции могут появиться, но они — это отдельные модели с разными весами и возможностями. Если требование — 4 ГБ локальный помощник, выбери модель разработанную для того бюджета памяти и обозначь её правильно.

Честный смысл запуска Kimi K3 на GPU в 4 ГБ

Запуск Kimi K3 на единственном GPU в 4 ГБ верится только под узким определением: GPU держит маленький кусок пока остаток примерно 1.4 ТБ checkpoint живёт в другом месте и потоком через него. Это может стать ценной research демонстрацией, но это не практичное локальное развёртывание сегодня.

Заголовок невероятен потому что он пропускает машину вокруг GPU: SSD, system RAM, custom runtime, transfer время и часто удалённую инфраструктуру. Считай все те ресурсы перед судом о утверждении. Если цель использовать Kimi K3 а не изучать extreme offloading, API — это маршрут который работает на 4 ГБ ноутбуке сейчас.

Раскрытие: reAPI публикует эту статью и предлагает hosted Kimi K3 API доступ. Архитектура и quantization факты происходят из официального хранилища Moonshot и технического отчёта. Оценка 4 ГБ выведена из тех спецификаций, документации текущего движка и базовой арифметики хранилища; это не утверждение что reAPI воспроизвела полную Kimi K3 генерацию на GPU в 4 ГБ.

References

1. Moonshot AI. Kimi K3 official repository — architecture, model summary, native MXFP4, and recommended inference engines. Retrieved August 1, 2026. github.com/MoonshotAI/Kimi-K3
2. Kimi Team. Kimi K3: Open Frontier Intelligence. Published July 2026. arxiv.org/abs/2607.24653
3. Moonshot AI. Kimi K3 official weights and model card. Retrieved August 1, 2026. huggingface.co/moonshotai/Kimi-K3
4. AirLLM. Supported model families and 4GB Llama 3 70B layer-offloading example. Retrieved August 1, 2026. github.com/lyogavin/airllm
5. vLLM Ascend. Validated Kimi K3 multi-node deployment guide. Retrieved August 1, 2026. docs.vllm.ai/projects/ascend/tutorials/models/Kimi-K3
6. reAPI. Kimi K3 API reference and current model page. Retrieved August 1, 2026. reapi.ai/docs/kimi-k3 and reapi.ai/models/kimi-k3

Further reading

• reAPI. Kimi K3: The Complete Guide to Moonshot's 2.8T Flagship. reapi.ai/blog/kimi-k3-complete-guide
• reAPI. Best Open-Source AI Video Models for Local GPUs. reapi.ai/blog/best-open-source-ai-video-models-local-gpu-2026
• Moonshot AI. Kimi K3 official repository. github.com/MoonshotAI/Kimi-K3