Как запустить Kimi K3 локально: расчеты и требования

Что требуется для самостоятельного размещения Kimi K3

Самостоятельно разместить Kimi K3 означает найти место для 2.8 триллиона параметров. Moonshot опубликовала открытые weights в формате MXFP4. Это примерно половина byte на weight, поэтому только weights занимают около 1.4 TB ещё до выделения памяти хотя бы под один token cache. Ни один доступный сегодня accelerator не вмещает такой объём самостоятельно. Для одного GPU ответ отрицательный. Для одного сервера ответ положительный в двух вариантах. Первый — узел с 8 GPU, каждый объёмом 288 GB, что соответствует самым небольшим опубликованным рецептам serving для нескольких пользователей. Второй — одна машина примерно с 1.6 TB совокупной RAM и VRAM, на которой запускается lossless Q8 GGUF от Unsloth в llama.cpp, с GPU или без него, для обслуживания одного пользователя за раз.

Таков вывод. Ниже приведены расчёты, лежащие в его основе, поскольку именно эти расчёты можно повторно использовать для следующего релиза. В течение нескольких недель после объявления 16 July 2026 несколько поставщиков инфраструктуры опубликовали руководства по развёртыванию K3, и в каждом предполагалось, что кластер у вас уже есть. Эта страница рассматривает вопрос с другой стороны: сколько это стоит, что можно запустить вместо этого и как определить, к какому из двух вариантов вы относитесь.

Общее количество параметров и количество активных параметров не совпадают

K3 — это модель типа Mixture of Experts (MoE). Архитектура MoE разделяет нейросеть на множество подсетей и использует маршрутизатор для выбора нескольких из них для каждого токена. В карточке модели указано 2.8T общих параметров и 104B активных параметров на токен; модель состоит из 896 маршрутизируемых экспертов, из которых 16 активируются для каждого токена, распределенных по 93 слоям.

Эти два показателя отвечают на разные вопросы, и их путаница — самая частая ошибка в любых обсуждениях на тему «потянет ли мое оборудование эту модель».

Активные параметры определяют вычислительную стоимость. Токен проходит умножение примерно через 104B параметров, поэтому ожидаемая пропускная способность соответствует плотной модели на 104B, а не на 2.8T. В этом и заключается основная цель создания MoE.

Общие параметры определяют требования к памяти. Маршрутизатор может выбрать любого эксперта для любого токена, поэтому все эксперты должны быть загружены в быстрое хранилище до начала обработки первого запроса. Существуют методы хранения только «горячих» экспертов в VRAM с подгрузкой остальных по требованию: например, --moe-cache-mib в llama.cpp поддерживает GPU-кэш для экспертов, которые в остальное время находятся в системной оперативной памяти, и загружает недостающих по мере выбора маршрутизатором. Однако это не уменьшает общий объем. Остальные эксперты всё равно должны находиться в оперативной памяти, а шина PCIe передает данные со скоростью десятки гигабайт в секунду против терабайт в секунду у HBM, поэтому каждый промах кэша (cache miss) требует времени. Потоковая передача экспертов с NVMe в случае, если модель не помещается даже в оперативную память, работает еще медленнее, и руководство по K3 от Unsloth предупреждает, что выгрузка на диск (disk offloading) значительно снижает производительность.

Таким образом, модель дешева в вычислениях, но дорога в хранении. Рассчитывайте аппаратное обеспечение исходя из 2.8T. Рассчитывайте ожидания по скорости исходя из 104B.

Количество байт на один вес и откуда берутся терабайты

Количество параметров, умноженное на количество байт на один вес. Для весов это вся формула.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 обучалась с учётом квантования и выпущена с весами MXFP4 и активациями MXFP8, поэтому строка для 4-битного формата является фактической. Строки выше приведены для масштаба: в формате bf16 той же модели потребовалось бы 5.6 TB. MXFP4 также хранит общий 8-битный коэффициент масштабирования для каждого блока из 32 весов. Это добавляет около 6 процентов. Кроме того, конфигурация Moonshot исключает attention, shared experts и vision tower из 4-битного формата. Поэтому полный checkpoint занимает около 1.56 TB по подсчётам Unsloth, а не ровно 1.4 TB.

Это сужает, но не закрывает обычный путь к уменьшению размера. Выпущенный checkpoint уже имеет 4-битный формат, поэтому простое уменьшение размера уже выполнено. Однако дальнейшее снижение разрядности всё ещё уменьшает объём. По состоянию на 27 October 2026 измеренные Unsloth динамические квантования GGUF для K3 занимают от 861.3 GB для 2-битного UD-Q2_K_XL до 594 GB для 1-битного UD-IQ1_S. Unsloth публикует и цену такого уменьшения: совпадение токенов top-1 с полной моделью составляет 90.390 процента для UD-Q2_K_XL, 84.127 процента для UD-IQ2_XXS размером 711.1 GB и 78.875 процента для UD-IQ1_S. В репозитории Hugging Face также есть меньшие 1-битные файлы, вплоть до 466 GB для UD-Q1_0, но рядом с ними показатель совпадения не опубликован. Это измеримое снижение точности. При этом даже самый маленький файл примерно в 1.6 раза больше самой большой отдельной карты.

Сколько GPU требуется Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Считайте это нижней границей, а не целевым значением. Здесь учитываются только веса: без KV cache, буферов активаций, фрагментации allocator и запаса для второго параллельного запроса. Разбиение не обязано быть равномерным: pipeline parallelism в vLLM разделяет модель по слоям и поддерживает неравномерные разбиения, а рецепты prefill для K3 в SGLang запускают 8 и 16 pipeline stages для 93 слоёв.

Опубликованные рекомендации выше этой нижней границы. В рекомендациях Moonshot при запуске предлагался supernode как минимум с 64 ускорителями. По состоянию на 27 October 2026 cookbook SGLang содержит конфигурацию H100 из четырёх узлов по 8 GPU, всего 32 GPU и 2,560 GB суммарной памяти, при нижней границе в 18 карт. В нём также приведены рецепты для одного узла: одного 8-GPU узла B300 и одного 8-GPU узла MI350X или MI355X, с 2,304 GB при 288 GB на карту. Разница с нижней границей не означает избыточность. Это место для KV cache, памяти активаций и запаса, который позволяет серверу одновременно обрабатывать много запросов. Наиболее удобный вариант, 5 карт класса GB300, на практике округляется ровно до такого 8-GPU узла. Это самая маленькая конфигурация, для которой кто-либо публикует рецепт обслуживания K3 для нескольких пользователей.

KV-кэш — это то, что удивляет пользователей

Веса модели — это фиксированные затраты. KV-кэш (key-value cache) — нет: он растет вместе с длиной контекста и увеличивается с каждым одновременным пользователем. Для обычного механизма внимания формула выглядит как bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, после чего результат умножается на длину контекста и количество одновременных запросов.

Приведем пример расчета, который является лишь иллюстрацией: 64 слоя, 8 KV-голов, размерность головы 128, формат fp8. Это дает 2 64 8 128 1 = 131 072 байта, то есть 128 KiB на токен.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Один пользователь с контекстом 128k требует 16 GiB. Один пользователь с полным миллионом токенов требует 128 GiB, что составляет почти половину памяти карты на 288 GB для одного диалога, еще до загрузки весов модели.

K3 не использует обычное внимание, и последнее число объясняет почему. Из 93 слоев 69 являются слоями KDA (Kimi Delta Attention), а 24 — слоями Gated MLA (multi-head latent attention). KDA поддерживает рекуррентное состояние фиксированного размера вместо кэша, растущего с каждым токеном, а MLA сжимает ключи и значения в один латентный вектор низкого ранга, поэтому реальные затраты на токен значительно ниже, чем в приведенном примере. Опубликованный файл config.json от Moonshot указывает размер этого латентного вектора: kv_lora_rank размером 512 плюс роторный ключ шириной 64 (qk_rope_head_dim), итого 576 значений на токен для каждого слоя MLA. Для 24 слоев по 2 байта каждое это составляет 27 648 байт, около 27 KiB на токен, или примерно 27 GiB для полного диалога на 1 048 576 токенов, плюс фиксированное состояние KDA. Рассматривайте это как оценку, а не как точное измерение: движки по-своему распределяют и выравнивают кэш, а 8-битный кэш примерно вдвое уменьшает этот объем.

Чтобы увидеть, что занимает память в вашем развертывании, не стоит мониторить nvidia-smi при увеличении --max-model-len. vLLM заранее выделяет пул KV-кэша, размер которого определяется параметром --gpu-memory-utilization (по умолчанию 0.92 в текущей документации) или явным бюджетом кэша на GPU, поэтому общий объем используемой памяти GPU показывает размер пула, а не одного диалога. Вместо этого изучите лог запуска, где vLLM сообщает размер KV-кэша в токенах и максимальную одновременную нагрузку при вашей длине контекста.

Структура рассуждений сохранится в следующем релизе. Если модель заявляет контекст в миллион токенов и ничего не говорит о своей архитектуре внимания, считайте кэш основным ограничивающим фактором, пока не доказано обратное.

Уровень 1: аренда кластера с почасовой оплатой

На этом уровне K3 обслуживает многих пользователей одновременно в точности, с которой поставляется. Одна машина с достаточным объёмом RAM также может разместить K3 в выпущенной точности через Q8 GGUF от Unsloth, которую Unsloth обозначает как full precision lossless, но этот вариант обслуживает только одного пользователя за раз и рассматривается на уровне 2. Здесь оборудование не покупают. Его арендуют на нужное количество часов, а затем останавливают.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

Тариф является допущением, а не официальным предложением. Почасовые тарифы сильно различаются у разных провайдеров и для разных поколений GPU. Ускорители на 288 GB, которые нужны для рецептов на одном узле, стоят в час дороже, чем H100, а зарезервированная ёмкость дешевле. Возьмите фактическое значение у своего провайдера и заново выполните расчёт: количество GPU × количество часов × тариф. Диаграмма показывает соотношение. Запуск узла с 8 GPU на 4 часа в день стоит 2,400 USD в месяц, а постоянно работающая конфигурация с 32 GPU H100, рассчитанная для SGLang, стоит 57,600 USD.

Оба распространённых сервера публикуют команду запуска на карточке модели.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Ни одну из этих команд в исходном виде не запускают в реальном кластере. Добавьте флаги параллелизма, соответствующие вашему оборудованию: в SGLang для tensor parallel используется --tp-size, для pipeline parallel — --pp-size, а для expert parallel — --ep-size. Произведение tensor parallel и pipeline parallel должно быть равно фактическому количеству GPU. Expert parallel разделяет экспертов внутри этой группы, поэтому в рецепте для 32 GPU H100 заданы и --tp-size 32, и --ep-size 32.

Проверьте, что сервер запустился, прежде чем отправлять реальный трафик:

curl http://127.0.0.1:30000/v1/models

Рабочий сервер отвечает JSON-объектом со списком идентификаторов моделей. Connection refused означает, что процесс всё ещё загружает веса или уже завершился, поэтому перед повторной попыткой прочитайте журнал сервера.

В первые недели распространённой проблемой была версия runtime старше модели. K3 поставлялся с KDA и новым слоем MoE, которых не было в стабильных выпусках vLLM и SGLang на момент запуска. Симптом — сервер завершается во время запуска со строкой вида Model architectures [...] are not supported for now. Изменение конфигурации это не исправит, поскольку в вашей сборке нет кода для выполнения этих слоёв. С тех пор ситуация изменилась: по состоянию на 27 October 2026 SGLang поддерживает K3 в своих выпусках начиная с v0.5.17, а последней версией является v0.5.22. В примечаниях к выпускам vLLM от v0.28.0 до v0.32.0 также указаны работы, связанные с K3. Установите текущий выпуск. В некоторых инструкциях для конкретного оборудования по-прежнему указывается специальный image, например в сборках SGLang NVFP4 для Blackwell, поэтому проверьте рецепт для своей карты.

Есть ещё одна особенность расходов, о которой часто забывают. Отсчёт начинается при запуске инстанса, а не после готовности модели. Загрузка объёма 1.56 TB со скоростью 1 GB/s занимает около 26 минут кластерного времени до получения первого token. Разместите веса на томе, который сохраняется после остановки инстанса, чтобы при втором запуске ожидание занимало минуты.

Уровень 2: запустите меньшую модель на одном ускорителе

На этом уровне K3 не запускается. Сразу зафиксируйте это, потому что большинство обсуждений на тему «запустить K3 локально» заканчиваются именно здесь, хотя авторы этого не признают.

Правило соответствия то же, но в уменьшенном масштабе: количество параметров, умноженное на число байтов на вес, плюс KV-кэш и примерно 2 GB служебных накладных расходов должны помещаться в доступный VRAM. При 4-bit это примерно полбайта на параметр, поэтому подходят следующие конфигурации:

• карта на 16 GB: модель 7B в формате 4-bit с запасом для длинного контекста
• карта на 24 GB: модель 14B в формате 4-bit
• карта на 48 GB: модель 32B в формате 4-bit
• карта на 80 GB: модель 70B в формате 4-bit или MoE класса 30B в формате 8-bit

Каждая конфигурация выше рассчитана на один запрос за раз. Как только второй пользователь отправляет запрос, каждому параллельному слоту требуется собственный KV-кэш. Именно это является компромиссом, который параметры Ollama NUM_PARALLEL и MAX_QUEUE задают между параллельными слотами, запросами в очереди и оставшимся VRAM.

Есть один способ запустить сам K3 на одной большой машине. Он находится между этим уровнем и последним. Unsloth документирует сборки GGUF для K3 в llama.cpp — от квантования 1-bit и 2-bit до UD-Q8_K_XL, которое он называет сжатием без потери точности. В качестве оборудования, способного запускать такие сборки, Unsloth указывает NVIDIA DGX Station. Практическое правило Unsloth: объём RAM плюс VRAM должен примерно соответствовать размеру квантования — от примерно 610 GB для сборки 1-bit UD-IQ1_S до примерно 1.6 TB для Q8. При меньшем объёме модель начинает использовать диск, и скорость резко падает. GPU необязателен: инструкции Unsloth отключают CUDA, если «у вас нет GPU или вы просто хотите выполнять инференс на CPU». Сборки 1-bit и 2-bit — это сильно квантованные варианты K3, поэтому они теряют часть точности. Сборка Q8 — это K3 с точностью, с которой модель была выпущена, обслуживающая одного пользователя со скоростью RAM. Ни один из этих вариантов не является меньшей моделью.

Ollama — самый короткий путь к рабочему серверу на VPS с подключённым GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run загружает модель при первом использовании, после чего открывает приглашение для ввода запросов. Если указанный тег не существует, возвращается Error: model "..." not found. Поэтому копируйте теги со страницы библиотеки, а не набирайте их по памяти. Полное руководство, включая systemd unit и удалённый доступ, приведено в разделе запуск Ollama на VPS.

llama.cpp предоставляет больше контроля над квантованием и выгрузкой слоёв:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 запрашивает размещение каждого слоя на GPU. Проверьте log загрузки: в нём указано, сколько слоёв было выгружено. Слои, которые не помещаются и переходят в системную RAM, работают с пропускной способностью RAM, а не HBM. Поэтому скорость генерации падает на порядок, как только модель перестаёт помещаться. Компромиссы между этими двумя инструментами рассмотрены в разделе Ollama и llama.cpp: сравнение.

Уровень 3: размещённый API, оркестрация на собственных серверах

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Endpoint совместим с OpenAI, поэтому существующий клиент заработает после изменения базового URL.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Рабочий ключ возвращает JSON-объект с массивом choices. Ошибка 401 означает, что аутентификация не пройдена: проверьте правильность ключа, срок его действия и отсутствие блокировки, а также убедитесь, что заголовок имеет вид Authorization: Bearer, после которого указан ключ. Ошибка о ненайденной модели обычно означает, что идентификатор изменился: провайдеры выводят идентификаторы из обращения между контрольными точками.

Теперь рассчитаем точку безубыточности, используя указанную выше стоимость аренды. Постоянно работающий узел с 8 GPU стоит 14,400 USD в месяц. При цене 15.00 USD за миллион выходных токенов за те же деньги через API можно получить около 960 миллионов выходных токенов. Чтобы выиграть по стоимости, нужно генерировать почти миллиард выходных токенов в месяц, то есть примерно 30 миллионов в день, и постоянно загружать кластер. Неактивные GPU тарифицируются по той же ставке, что и загруженные. Для агентских нагрузок с большим объёмом prompt эта граница смещается ещё дальше: повторно передаваемый контекст тарифицируется по ставке 0.30 USD за миллион при попадании в кэш, а не по ставке 3.00 USD при промахе кэша.

На этом уровне вы размещаете на собственных серверах всё, что окружает модель: gateway, который хранит API-ключ и не передаёт его клиенту, логи запросов и ответов, повторы запросов, ограничения частоты и бюджеты отдельных пользователей. Для этого достаточно небольшого VPS без GPU. То же разделение применяется к закрытым весам: самостоятельное размещение Claude на уровне модели невозможно, поэтому вы управляете только оркестрацией.

Какие serving stack соответствуют каждому уровню

Серверы класса vLLM и SGLang относятся к уровню 1. Они предназначены для одновременной обработки большого числа запросов, непрерывного batching и paged KV cache, а также для распределения tensor и expert parallelism между несколькими узлами. Они рассчитаны на ускорители в дата-центрах и быструю interconnect-связь между ними. На одной потребительской видеокарте их сложнее устанавливать, а заметных преимуществ они почти не дают.

llama.cpp и Ollama относятся к уровню 2. Они рассчитаны на одну машину, GGUF quantisation, выгрузку вычислений на CPU, если модель не помещается, и низкую concurrency. llama.cpp загружает огромную MoE-модель, размещая веса экспертов в системной RAM (--cpu-moe или --n-cpu-moe), а с --moe-cache-mib кэширует используемых экспертов на GPU. Именно так сборки K3 GGUF от Unsloth работают на одной машине. Скорость при этом зависит от пропускной способности RAM и от того, как часто router не находит данные в кэше. Если файл больше, чем объём RAM плюс VRAM, модель начинает использовать диск. Это рабочая конфигурация для одного пользователя. Это не сервис для одновременной работы многих пользователей. Полное сравнение приведено в Ollama и vLLM, и выбор не зависит от модели: всегда нужно определить, обслуживаете ли вы многих пользователей на общем оборудовании или одного пользователя на собственной машине.

Четыре показателя, которые сохраняют значение после этой контрольной точки

1. Общее количество параметров, умноженное на количество байт на вес, определяет минимальный объём памяти. При указанной в поставке точности ниже этого значения модель не запустится, а квантование ниже 4-bit позволяет сэкономить до примерно 70 процентов ценой снижения точности, но не на порядок.
2. Количество активных параметров определяет класс производительности. MoE-модель 2.8T со 104B активных параметров выполняет вычисления как модель 104B.
3. Объём KV cache на один token, умноженный на длину контекста и количество одновременных запросов, — это затраты, которые продолжают расти после того, как вы уже учли стоимость весов.
4. Количество tokens per second на доллар — единственный показатель, который определяет аппаратный уровень. Всё перечисленное выше служит входными данными для его расчёта.

Примените эти четыре показателя к любому выпуску, и вы получите правильный ответ ещё до того, как откроете руководство поставщика. Следующий выпуск уже анонсирован: 23 October 2026 Moonshot выпустила K3.1 Pro на базе K3 с дополнительным post-training в Kimi Code, а в её API quickstart указано, что полные веса будут выпущены к 4 November. После этого указывайте дату для каждого записанного показателя. Цены и списки поддерживаемых архитектур изменились в течение двух недель после запуска K3. Показатели запуска на этой странице опубликованы в July 2026, а serving-рецепты, выпуски runtime и значения квантования повторно проверены 27 October 2026.

FAQ

Можно ли запустить Kimi K3 на одном GPU?

Нет. Веса занимают около 1.4 TB при точности MXFP4, с которой Moonshot выпускает модель, а даже самая малая опубликованная квантованная версия K3 — файл Unsloth UD-Q1_0 размером 466 GB — примерно в 1.6 раза больше 288 GB, доступных в крупнейших широко распространённых ускорителях. llama.cpp может хранить experts в системной RAM и кэшировать активные experts на GPU, но для этого всё равно требуется примерно объём квантованной версии в RAM плюс VRAM. При меньшем объёме модель выгружается на диск и работает значительно медленнее. Самые малые опубликованные конфигурации для serving используют один узел с 8 картами B300 или MI350X/MI355X, а в конфигурации с H100 используются 32 карты.

Сколько VRAM требуется Kimi K3?

Начните с 1.4 TB только для весов. Это 18 карт H100 80GB или 5 карт класса GB300. Затем добавьте KV cache и память для activation. В рекомендациях Moonshot при запуске рекомендовалось использовать 64 или более ускорителей. По состоянию на 27 October 2026 в SGLang cookbook опубликованы конфигурации для одного узла с 8 картами B300 или 8 картами MI350X/MI355X, с общим объёмом 2,304 GB, а также конфигурация с 32 GPU H100 и общим объёмом 2,560 GB. Поэтому считайте объём весов нижней границей, а не требованием.

Позволяет ли quantisation разместить Kimi K3 на одном узле?

Поставляемый checkpoint с 4-bit уже помещается на одном узле, если в нём установлены 8 карт по 288 GB. Именно такую конфигурацию используют рецепты SGLang для B300 и MI355X. Кроме того, модель помещается на одной машине примерно с 1.6 TB RAM плюс VRAM через lossless Q8 GGUF от Unsloth. Более низкая разрядность подходит для менее мощных машин: измеренные Unsloth сборки dynamic GGUF занимают от 861.3 GB при 2-bit до 594 GB при 1-bit, а в репозитории перечислены 1-bit файлы размером вплоть до 466 GB. Для сравнения, lossless-версия занимает около 1.56 TB. Потеря точности измерена: top-1 agreement с полной моделью снижается до 90.390 percent для UD-Q2_K_XL и до 78.875 percent для UD-IQ1_S. Ни одна из этих версий не помещается на одной карте.

Аренда GPU дешевле API Kimi K3?

Только при большом и стабильном объёме. Если принять стоимость 2.50 USD за час работы GPU, постоянно работающий узел с 8 GPU обходится в 14,400 USD в месяц. За те же деньги можно получить около 960 million output tokens по опубликованному тарифу 15.00 USD за million. Кроме того, нужно оплачивать простои, загрузку весов и работу специалиста, который поддерживает кластер в рабочем состоянии. Для кратковременных нагрузок арендуйте GPU почасово и сравнивайте стоимость с фактически измеренным объёмом tokens, а не с предположением.

Что означает 104B active parameters с точки зрения скорости?

Это означает, что на каждый token выполняется объём вычислений, характерный для модели 104B. Поэтому пропускная способность соответствует этому классу, а не классу 2.8T. Это ничего не говорит об объёме памяти: все 2.8T параметров остаются в памяти, поскольку router может вызвать любой expert для любого token. Используйте число active parameters для оценки tokens per second, а общее число параметров — для расчёта требуемого объёма VRAM.