自行托管 Kimi K3 需要多少显存和服务器？

自行托管 Kimi K3 所需的条件

自行托管 Kimi K3 意味着要为 2.8 万亿个参数腾出空间。Moonshot 以 MXFP4 格式发布了开放权重，每个权重大约占半字节，因此仅权重就约为 1.4 TB，尚未为缓存分配任何 token。目前在售的单个加速器都无法独立容纳这些数据。单个 GPU 不行。单台服务器可以，主要有两种方式。第一种是使用一台配备 8 个 GPU、每个加速器为 288 GB 的节点，这也是已发布的多用户服务方案中使用的最小配置。第二种是使用一台总 RAM 和 VRAM 约为 1.6 TB 的机器，在 llama.cpp 中运行 Unsloth 的无损 Q8 GGUF；可以配备 GPU，也可以不配备，但一次只能服务一个用户。

结论就是这样。下面的内容是推导这一结论的计算过程，因为这些计算方法也可复用于下一次发布。2026 年 7 月 16 日发布后几周内，多家基础设施供应商发布了 K3 部署指南，但每份指南都假设您已经拥有集群。本页从另一个角度出发：需要多少成本、可以运行哪些替代方案，以及如何判断自己属于这两种情况中的哪一种。

总参数量与激活参数量不是同一个数字

K3 是混合专家模型。MoE（混合专家）将网络拆分为许多子网络，并让路由器为每个 token 选择其中一部分。模型卡列出了 2.8T 总参数量和每个 token 激活的 104B 参数。这些参数来自 896 个路由专家，其中每个 token 会激活 16 个专家，共分布在 93 层中。

这两个参数量回答的是不同问题。在所有“我能运行这个模型吗”的讨论中，把它们混淆是最常见的错误。

激活参数量决定计算成本。 每个 token 大约会经过 104B 个参数，因此预期吞吐量应接近 104B 的稠密模型，而不是 2.8T 的稠密模型。这正是构建 MoE 的全部原因。

总参数量决定内存成本。 路由器可能在任意 token 上选择任意专家，因此在第一个请求到达前，所有专家都必须存放在某个高速存储位置。只将高频专家保存在 VRAM 中、按需加载其余专家是可行的：llama.cpp 的 --moe-cache-mib 会在 GPU 中维护专家缓存，其余专家存放在系统 RAM 中，并在路由器选中未缓存的专家时将其上传到 GPU。不过，这不会减少总参数量。其余专家仍必须存放在 RAM 中；而 PCIe 每秒只能传输数十 GB，HBM 每秒可传输数 TB，因此每次缓存未命中都会产生延迟。如果模型连 RAM 都无法容纳，只能从 NVMe 流式加载专家，速度会进一步下降；Unsloth 的 K3 指南也警告称，从磁盘卸载的速度会慢很多。

因此，它的计算成本较低，但存储成本很高。请按 2.8T 评估硬件需求，按 104B 评估速度预期。

每个权重对应的字节数，以及 TB 的来源

参数量乘以每个权重对应的字节数。对于权重，公式就是这样。

[
  {
    "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-bit 这一行才是实际情况。上面的行用于对比：在 bf16 下，同一模型需要 5.6 TB。MXFP4 还会为每 32 个权重的每个块存储一个共享的 8-bit scale，这会额外增加约 6 percent；Moonshot 的配置还会将 attention、共享 experts 和 vision tower 排除在 4-bit 格式之外，因此按 Unsloth 的统计，完整 checkpoint 约为 1.56 TB，而不是整整 1.4 TB。

这缩小了通常的压缩空间，但并未完全消除。发布的 checkpoint 已经是 4-bit，因此容易获得的节省已经实现，但继续降低位数仍会改变这个数值。截至 27 October 2026，Unsloth 测量的 K3 动态 GGUF 量化版本从 2-bit 的 UD-Q2_K_XL（861.3 GB）到 1-bit 的 UD-IQ1_S（594 GB）不等，Unsloth 也公布了相应代价：与完整模型相比，UD-Q2_K_XL 的 top-1 token agreement 为 90.390 percent，711.1 GB 的 UD-IQ2_XXS 为 84.127 percent，UD-IQ1_S 为 78.875 percent。其 Hugging Face repo 还提供更小的 1-bit 文件，最小为 466 GB 的 UD-Q1_0，但文件旁未公布 agreement 数值。这是经过测量的准确率损失，而且即使是最小的文件，容量仍约为最大单卡容量的 1.6 倍。

Kimi K3 需要多少块 GPU

[
  {
    "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、激活缓冲区、分配器碎片，也没有为第二个并发请求预留空间。切分本身不要求均匀：vLLM 的 pipeline parallelism 沿层切分模型，并支持不均匀切分；SGLang 的 K3 prefill 配置则在 93 层上运行 8 和 16 个 pipeline stage。

已发布的指导配置高于这个下限。Moonshot 的发布指导建议使用包含 64 个或更多加速器的 supernode。截至 27 October 2026，SGLang cookbook 提供了一种 H100 配置，由 4 个 8-GPU 节点组成，共 32 个 GPU 和 2,560 GB 总内存；相比之下，权重所需下限为 18 张卡。该 cookbook 还列出了单节点配置：一个 8-GPU B300 节点，以及一个 8-GPU MI350X 或 MI355X 节点，后者总内存为 2,304 GB，即每张卡 288 GB。高于下限的部分并非浪费，而是用于 KV cache、激活内存，以及让服务器能够同时批处理多个请求的余量。最宽松的配置是 5 张 GB300 class 卡；实际部署时会向上取整为这种 8-GPU 节点。这也是公开发布的多用户 K3 serving 配置中最小的机器。

KV 缓存才是容易让人意外的部分

权重是固定成本。KV（键值）缓存不是：它会随上下文长度增长，也会随并发用户数再次增长。对于普通注意力，公式是 bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element，然后还要乘以上下文长度和并发数。

下面是一个计算示例，仅用于说明：64 层、8 个 KV 头、头维度为 128、fp8。计算结果为 2 64 8 128 1 = 131,072 字节，即每个 token 需要 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。完整 1 million 上下文下，单个用户需要 128 GiB。也就是说，在尚未加载任何权重之前，仅一个会话就几乎占用一张 288 GB 显卡的一半显存。

K3 不使用普通注意力，这正是原因所在。它的 93 层中，有 69 层是 KDA（Kimi Delta Attention）层，24 层是 Gated MLA（多头潜在注意力）层。KDA 使用固定大小的循环状态，而不是随每个 token 增长的缓存；MLA 则将键和值压缩到一个低秩潜在向量中。因此，实际每个 token 的成本会远低于上面的计算示例。Moonshot 发布的 config.json 给出了该潜在向量的大小：一个 kv_lora_rank，大小为 512，加上一个宽度为 64 的旋转键（qk_rope_head_dim），因此每个 MLA 层每个 token 包含 576 个值。24 层、每个值占 2 字节时，总计为 27,648 字节，即每个 token 约 27 KiB；完整的 1,048,576 token 会话约需 27 GiB，另加固定大小的 KDA 状态。请将此结果视为估算值，而不是测量值：不同引擎会采用各自的缓存填充和布局方式，使用 8 位缓存则大致可将占用减半。

若要查看自己的部署实际持有多少缓存，不要在提高 --max-model-len 时监控 nvidia-smi。vLLM 会预分配 KV 缓存池，其大小根据 --gpu-memory-utilization（当前文档中的默认值为 0.92）或显式设置的每 GPU 缓存预算确定，因此 GPU 总显存显示的是整个缓存池，而不是单个会话的占用。应改为查看启动日志，其中 vLLM 会报告 KV 缓存的 token 数量，以及在指定上下文长度下的最大并发数。

这种推理方式在下一个版本中仍然适用。如果某个模型声称支持 1 million token 上下文，却没有说明其注意力设计，应先假设缓存是限制因素，直到有人证明并非如此。

第 1 层：按小时租用集群

这一层以 K3 发布时的精度同时服务多个用户。配备足够 RAM 的单台机器也可以通过 Unsloth 的 Q8 GGUF，以其发布时的精度运行 K3；Unsloth 将其标记为全精度无损方案，但该方式一次只能服务一个用户，详见第 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 数量 × 小时数 × 费率。图表的重点是比例。每天运行 4 小时的 8 GPU 节点每月成本为 2,400 USD，而持续运行按 SGLang 规模配置的 32 GPU H100 配置每月成本为 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 使用 --tp-size 表示张量并行，使用 --pp-size 表示流水线并行，使用 --ep-size 表示专家并行。张量并行数乘以流水线并行数必须等于实际拥有的 GPU 数量；专家并行会在该并行组内拆分专家，因此 32 GPU H100 方案会同时设置 --tp-size 32 和 --ep-size 32。

发送实际流量前，请确认服务器已启动：

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

运行正常的服务器会返回一个列出模型 id 的 JSON 对象。Connection refused 表示进程仍在加载权重，或已经退出，因此重试前应先查看服务器日志。

最初几周的常见故障是运行时版本早于模型。K3 发布时包含 KDA 和新的 MoE 层，而稳定版 vLLM 和 SGLang 在发布时尚未包含这些组件；其表现为服务器在启动期间退出，并显示类似 Model architectures [...] are not supported for now 的日志行。修改配置无法解决该问题，因为您的构建中没有运行这些层所需的代码。此后情况已有变化：截至 2026 年 10 月 27 日，SGLang 自 v0.5.17 起已在其发行版中支持 K3，最新版本为 v0.5.22；vLLM 的 v0.28.0 至 v0.32.0 版本说明也都包含 K3 相关工作。请安装当前版本。某些特定硬件路径仍会列出专用镜像，例如 Blackwell 上的 SGLang NVFP4 构建，因此请根据您的显卡检查相应方案。

还有一个容易被忽略的成本问题。计费从实例启动时开始，而不是从模型就绪时开始。以 1 GB/s 的速度下载 1.56 TB 数据，在生成第一个 token 前就会占用集群约 26 分钟。请将权重存放在生命周期超过实例的卷上，这样第二次运行只需几分钟即可启动。

Tier 2：在一块加速卡上运行较小的模型

在这一层级中，您不会运行 K3。在开始之前先明确这一点，因为大多数“在本地运行 K3”的讨论最终都会停在这里，却不承认这一点。

适配规则相同，只是规模更小：参数量乘以每个权重占用的字节数，再加上 KV cache 和约 2 GB 的运行时开销，必须小于您的显存容量。4-bit 量化时，每个参数大约占用半个字节，因此可以采用以下较为宽裕的组合：

• 16 GB 显卡：使用 4-bit 量化的 7B 模型，并为较长上下文留出空间
• 24 GB 显卡：使用 4-bit 量化的 14B 模型
• 48 GB 显卡：使用 4-bit 量化的 32B 模型
• 80 GB 显卡：使用 4-bit 量化的 70B 模型，或使用 8-bit 量化的 30B 级 MoE 模型

以上每种组合都假设一次只处理一个请求。第二个人发送提示词后，每个并发槽位都需要独立的 KV cache。Ollama 的 NUM_PARALLEL 和 MAX_QUEUE 设置会在并行槽位、排队请求和剩余显存之间进行取舍。

在一台大型机器上运行 K3 本身有一种方法，其规模介于本层级和上一层级之间。Unsloth 记录了在 llama.cpp 中使用 GGUF 构建运行 K3 的方法，量化范围从 1-bit 和 2-bit 到 UD-Q8_K_XL；Unsloth 将后者标记为无损全精度，并以 NVIDIA DGX Station 作为可运行这些构建的硬件示例。其经验规则是：RAM 加 VRAM 大致应等于量化后的模型大小，从约 610 GB 的 1-bit UD-IQ1_S 构建到约 1.6 TB 的 Q8 构建；低于这一容量时，模型会回退到磁盘，速度会显著下降。GPU 不是必需的：Unsloth 的构建说明会在“没有 GPU 或只是希望使用 CPU 推理”时关闭 CUDA。1-bit 和 2-bit 构建对 K3 进行了高强度量化，代价是前文所述的准确率损失。Q8 构建使用 K3 发布时的精度，以 RAM 速度为一个用户提供服务。两者都不是较小的模型。

在附加 GPU 的 VPS 上运行 Ollama是获得可用服务器的最短路径：

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

ollama run会在首次使用时下载模型，然后显示提示符。不存在的标签会返回 Error: model "..." not found，因此请从 library 页面复制标签，不要凭记忆输入。完整操作说明（包括 systemd 单元和远程访问）见在 VPS 上运行 Ollama。

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。请查看负载日志，其中会显示已卸载的层数。溢出到系统 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"
  }
]

该端点兼容 OpenAI，因此只需修改 base 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."}]}'

正常工作的密钥会返回一个包含 choices 数组的 JSON 对象。出现 401 表示身份验证失败：检查密钥是否正确、是否已过期或被禁用，并确认请求头为 Authorization: Bearer 后跟密钥。出现模型未找到错误通常表示模型 id 已更改，因为服务提供商会在检查点之间停用旧 id。

现在根据上文假定的租用费率计算盈亏平衡点。一台始终运行的 8 GPU 节点每月成本为 14,400 USD；按每百万输出令牌 15.00 USD 计算，同样的费用约可从 API 购买 960 million 个输出令牌。要在成本上占优，每月需要生成接近 1 billion 个输出令牌，即每天约 30 million 个，并让集群始终保持繁忙，因为空闲 GPU 与繁忙 GPU 的计费费率相同。以 prompt 为主的代理工作负载会使这一临界点进一步推远：重复上下文按 0.30 USD 每百万令牌的缓存命中费率计费，而不是按 3.00 USD 的缓存未命中费率计费。

在这一层级中，自托管的是模型周边的全部组件：用于保存 API key、确保密钥不会到达客户端的网关，请求和响应日志、重试机制、速率限制以及按用户设置的预算。这些组件可运行在完全不配备 GPU 的小型 VPS 上。对于闭源权重，情况同样如此：在模型层面无法自托管 Claude，因此你拥有的只有编排部分。

哪类推理服务栈属于哪个层级

vLLM 和 SGLang 类服务器属于第 1 层。它们用于同时处理大量请求，支持连续批处理、分页 KV 缓存，以及跨多个节点的张量并行和专家并行。它们面向数据中心加速器，并假设加速器之间具备高速互连。在单张消费级显卡上，它们安装更复杂，而且能带来的可感知收益很少。

llama.cpp 和 Ollama 属于第 2 层。它们面向单台机器、GGUF 量化、模型无法装入显存时的 CPU 卸载，以及低并发场景。llama.cpp 可以将专家权重保留在系统 RAM 中（--cpu-moe 或 --n-cpu-moe），从而加载超大的 MoE；配合 --moe-cache-mib 后，它还可以将使用中的专家缓存到 GPU 上。这正是 Unsloth 的 K3 GGUF 构建在单台机器上的运行方式。此时速度取决于 RAM 带宽，以及路由器未命中缓存的频率；如果文件大于 RAM 和 VRAM 的总容量，数据就会落到磁盘上。这种配置适合单个用户使用，但不适合作为供许多用户使用的服务。完整对比请参见 Ollama 与 vLLM 的对比。模型不会改变这一结论：问题始终在于，你是在共享硬件上为许多用户提供服务，还是在自己的机器上为一个用户提供服务。

在这一检查点之后仍然适用的四个数字

1. 参数总量乘以每个权重所占的字节数，就是内存下限。按发布时的精度运行时，内存不会低于这个下限；将量化精度降到 4-bit 以下，最多可节省约 70 percent，但会损失精度，无法带来数量级的降低。
2. 活跃参数量决定吞吐量级别。拥有 2.8T 参数、其中 104B 为活跃参数的 MoE，计算量相当于一个 104B 模型。
3. 每个 token 的 KV cache 大小乘以上下文长度，再乘以并发数，就是支付权重内存成本后仍会持续增长的开销。
4. 每美元每秒生成的 token 数，是唯一能决定档位的数字。上面的所有数据都用于计算它。

将这四个数字应用于任何版本，你无需打开供应商指南就能得到正确答案。下一个版本已经宣布：Moonshot 于 2026 年 10 月 23 日在 Kimi Code 中推出 K3.1 Pro。该版本基于 K3，并进行了进一步的后训练；其 API 快速入门文档称，全量权重将在 11 月 4 日前发布。然后，为你记录的每个数字注明日期。K3 发布后的两周内，价格和支持的架构列表都发生了变化。本页的发布数据于 2026 年 7 月公布，服务部署方案、运行时版本和量化数据已于 2026 年 10 月 27 日重新核对。

FAQ

我可以在单个 GPU 上运行 Kimi K3 吗？

不可以。Moonshot 发布的 MXFP4 精度权重约为 1.4 TB，即使是已发布的 K3 最小量化版本——Unsloth 的 466 GB UD-Q1_0 文件——也约为最大广泛可用加速器 288 GB 显存的 1.6 倍。llama.cpp 可以将专家保留在系统 RAM 中，并将活跃专家缓存到 GPU，但这仍大约需要相当于量化文件大小的 RAM 加上 VRAM；低于这一容量时，模型会换出到磁盘，运行速度大幅下降。已发布的最小服务配置使用一个配备 B300 或 MI350X/MI355X 卡的 8-GPU 节点，而 H100 配置使用 32 个 GPU。

Kimi K3 需要多少 VRAM？

仅权重就需要从 1.4 TB 开始，相当于 18 张 H100 80GB 卡，或 5 张 GB300 级别的卡。还需额外为 KV cache 和激活值内存预留空间。Moonshot 的发布指南建议使用 64 个或更多加速器。截至 2026 年 10 月 27 日，SGLang cookbook 发布了单节点配置：8 张 B300 或 8 张 MI350X/MI355X 卡，总计 2,304 GB；以及 32 GPU 的 H100 配置，总计 2,560 GB。因此，应将权重容量视为最低值，而不是完整需求。

量化能让 Kimi K3 装入单个节点吗？

如果节点配备 8 张 288 GB 卡，已发布的 4-bit checkpoint 可以装入单个节点；SGLang 的 B300 和 MI355X 配置就是如此。通过 Unsloth 的无损 Q8 GGUF，在一台配备约 1.6 TB RAM 加 VRAM 的机器上也可以运行。进一步降低位数可以适配更小的机器：Unsloth 测得的动态 GGUF 构建版本从 2-bit 的 861.3 GB 到 1-bit 的 594 GB 不等，其仓库还列出了低至 466 GB 的 1-bit 文件，而无损版本约为 1.56 TB。精度损失已有测量结果：UD-Q2_K_XL 与完整模型的 top-1 一致率降至 90.390%，UD-IQ1_S 降至 78.875%。这些版本都无法装入单张卡。

租用 GPU 比使用 Kimi K3 API 便宜吗？

只有在规模较大且负载稳定时才可能便宜。按每个 GPU 小时 2.50 USD 计算，始终运行的 8 GPU 节点每月成本为 14,400 USD；按公开价格 15.00 USD/百万输出 token 计算，同样的费用约可购买 960 million 个输出 token。你还需要支付空闲时段、权重下载，以及维护集群运行的人员成本。突发负载按小时租用 GPU，并根据实际测得的 token 用量进行比较，不要依赖估算。

104B active parameters 对速度意味着什么？

这意味着每个 token 的计算量相当于 104B 模型，因此吞吐量属于这一档，而不是 2.8T 档。它不能说明内存需求：全部 2.8T 参数都会常驻内存，因为路由器可以针对任意 token 调用任意专家。使用 active count 预测每秒 token 数，使用 total count 规划 VRAM。