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

自托管 Kimi K3 需要什么条件

自托管 Kimi K3，意味着需要为 2.8 万亿个参数提供存储空间。Moonshot 以 MXFP4 格式发布了开放权重。该格式每个权重约占半个字节，因此仅权重就约为 1.4 TB，还没有为任何缓存 token 分配空间。目前在售的加速器没有任何一款能够单独容纳这些数据。K3 是多节点模型，因此单台服务器无法运行。

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

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

K3 是一个混合专家模型。MoE（混合专家）会将网络拆分为许多子网络，并让路由器为每个 token 选择其中少数几个。模型卡列出总参数量为 2.8T，每个 token 激活 104B 个参数；模型包含 93 层，每层有 896 个路由专家，其中任意一个 token 会触发 16 个专家。

这两个参数量回答的是不同问题。在每个“我能否运行它”的讨论中，把它们混用都是最常见的错误。

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

总参数量决定内存成本。 路由器可能为任意 token 选择任意专家，因此第一个请求到达前，所有专家都必须驻留在内存中。不能只将 104B 个参数放入 VRAM，再按需加载其余参数，因为加载必须在微秒级完成，而 PCIe 链路每秒只能传输几十 GB。确实有人会尝试这样做。但从 NVMe 流式加载专家，会将一个本应每秒生成几十个 token 的模型，变成每几秒生成一个 token 的模型。

因此，它的计算成本低，但存储成本高。请根据 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 缩放值，这会额外增加约 6%，因此已发布的仓库大小更接近 1.5 TB，而不是整齐的 1.4 TB。

这排除了通常的应对方式。“直接量化”在这里没有帮助，因为发布的检查点已经是 4-bit。降到 2-bit 可将权重压缩到 0.7 TB，但会导致精度损失，而且没有人测量过该检查点在这种设置下的精度。即使如此，所需容量仍远超任何单张显卡。

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、激活缓冲区、分配器碎片，也没有为第二个并发请求预留空间。此外，它们假设并行拆分可以均匀分配，但 93 层和 896 个专家并不总能满足这一条件。

已发布的建议配置明显高于这个下限。截至 2026 年 8 月，Moonshot 建议使用包含 64 个或更多加速器的超节点；SGLang cookbook 提供的 H100 配置则由 4 个 8-GPU 节点组成，共 32 块 GPU，总显存为 2,560 GB，而权重所需的下限是 18 块卡。这个差额不是浪费，而是用于 KV cache、激活内存，以及让服务器能够同时批处理大量请求的余量。即使是最有利的一行，5 GB300 级别的卡，也对应一台大多数服务提供商不会以单个 SKU 出租的机器。

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。这个容量超过任何单张卡的容量，而且只对应一个会话。

K3 不使用普通注意力机制，这正是上一数字如此之大的原因。它的 93 个层中，有 69 个 KDA（Kimi Delta Attention）层和 24 个 Gated MLA（多头潜在注意力）层。KDA 使用固定大小的循环状态，而不是随每个 token 增长的缓存；MLA 则将键和值压缩到一个低秩潜向量中。因此，实际的每 token 成本会远低于上面的计算示例。Moonshot 尚未公布潜向量的维度，因此我不会为 K3 本身给出每用户容量。请改为测量您的实际情况：使用较小的 --max-model-len 启动服务器，使用 nvidia-smi 监控内存，然后逐步提高限制，直到分配失败。

下一版本发布后，推理过程的基本规律仍然成立。如果某个模型宣称支持 1 million token 的上下文，却没有说明其注意力机制设计，那么在有人证明并非如此之前，应假设缓存是限制因素。

第 1 层：按小时租用集群

这是唯一实际运行 K3 本身的层级。您无需购买硬件，而是按需租用，在需要的时段运行，之后将其停止。

[
  {
    "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"
  }
]

这里的费率是估算值，不是报价。到 2026 年，数据中心加速器的按需价格大致为每 GPU 小时 2 到 5 USD，预留容量的价格更低。请使用供应商的实际费率重新计算：GPU 数量 × 小时数 × 费率。图表的重点是比例。每天运行 4 小时的 8 GPU 节点，每月成本为 2,400 USD；而持续运行按 SGLang 配置的 32 GPU 环境，每月成本为 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 设置张量并行，使用 --ep-size 设置专家并行，并且两者的乘积必须等于实际拥有的 GPU 数量。

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

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 的日志行。修改配置无法解决此问题，因为当前构建中没有运行这些层所需的代码。请安装模型卡片指定的 nightly 版本，或等待包含相关支持的正式版本发布。

还需要注意一个成本问题。计费从实例启动时开始，而不是从模型就绪时开始。以 1 GB/s 的速度下载 1.5 TB 数据，大约需要占用集群 25 分钟，之后才能生成第一个 token。请将权重预置在生命周期长于实例的卷上，这样第二次运行可在几分钟内启动。

Tier 2：在一台加速器上运行更小的模型

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

适配规则仍然使用同一个公式，只是规模更小：参数量乘以每个权重所占的字节数，再加上 KV cache 和约 2 GB 的运行时开销，必须低于 VRAM 容量。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 模型

Ollama 是在 已连接 GPU 的 VPS 上运行可用服务器的最短路径：

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

ollama run会在首次使用时下载模型，然后显示提示符。不存在的标签会返回 Error: model "..." not found，因此请从库页面复制标签，不要凭记忆输入。完整操作流程（包括 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，表示密钥错误，或缺少 Bearer 前缀。出现模型未找到错误通常表示 id 已更改，因为服务提供商会在检查点之间停用 id。

下面按上述假定的租用费率计算盈亏平衡点。一台始终运行的 8 GPU 节点每月成本为 14,400 USD。按每百万输出 token 15.00 USD 计算，同样的费用可从 API 获取约 960 million 个输出 token。要在成本上占优，每月需要生成接近 1 billion 个输出 token，即每天约 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 中来加载超大型 MoE；但对于 2.8T 模型，这种方式的速度通常是每个 token 需要数秒。它只能证明文件可以被解析，并不适合部署为供用户使用的服务。完整对比请参见 Ollama 与 vLLM 的对比。模型不会改变这个结论：关键始终在于，你是在共享硬件上为多个用户提供服务，还是在自己的设备上服务一个用户。

决定检查点后仍然有效的 4 个数字

1. 总参数量乘以每个权重占用的字节数，得到内存下限。任何运行都不能低于这个下限；当发布版本已经是 4-bit 时，量化技巧也无法明显降低它。
2. 激活参数量决定吞吐量级别。具有 2.8T 参数、其中 104B 为激活参数的 MoE，计算量相当于 104B 模型。
3. 每个 token 的 KV cache 大小，乘以上下文长度，再乘以并发数，就是加载权重后仍会持续增长的成本。
4. 每美元每秒生成的 token 数，是唯一能确定规格档位的数字。以上所有数据都是它的输入。

将这 4 个数字应用于任何发布版本，即使不查看厂商指南，也能先得出正确结论。然后为记录的每个数据标注日期。K3 发布后的两周内，价格和支持的架构列表都发生了变化；本页的所有数字均为 2026 年 7 月发布的数据。

FAQ

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

不可以。Moonshot 发布的 MXFP4 精度权重约为 1.4 TB，而目前在售的最大单块加速器只能容纳 288 GB。MoE 模型无法以可用速度从磁盘流式加载未激活的专家，因为路由器可能为任意 token 选择任意专家，而 PCIe 获取数据所需的时间远超 token 预算允许的时间。合理的 K3 最小部署规模是一个多 GPU 节点，已发布的部署方案使用了 32 个或更多加速器。

Kimi K3 需要多少 VRAM？

仅权重就需要至少 1.4 TB，也就是 18 张 H100 80GB 卡，或 5 张 GB300 级别的卡。随后还需要为 KV cache 和激活值内存预留空间。截至 August 2026，Moonshot 建议使用 64 个或更多加速器；SGLang cookbook 发布了一个使用 32 个 H100 GPU、总计 2,560 GB 的配置。因此，应将权重容量视为最低值，而不是完整的内存需求。

量化能让 Kimi K3 适配单个节点吗？

不能有效解决问题。发布的 checkpoint 已经采用 4-bit 量化和量化感知训练，因此容易获得的节省空间已经实现。再次降到 2-bit 后，权重大小为 0.7 TB，仍超过最大单卡容量的两倍；而且尚未测量 2-bit 对该模型准确率的影响。

租用 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。