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

自行托管 Kimi K3 的要求

自行托管 Kimi K3，意味着需要为 2.8 trillion 个参数准备存储空间。Moonshot 以 MXFP4 格式发布了开放权重。该格式平均每个权重约占 half a byte，因此仅权重就约为 1.4 TB，还未为任何一个 token 分配缓存空间。目前在售的任何单个加速器都无法独立容纳这些数据。K3 是多节点模型，因此单台服务器无法运行。

结论就是这样。下面给出计算过程，因为这些计算方法也适用于下一次发布的模型。2026 年 17 July 公布 K3 后的几周内，多家基础设施供应商发布了 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 位这一行才是实际情况。上面的行用于对比：如果使用 bf16，同一个模型的权重将需要 5.6 TB。MXFP4 还会为每个包含 32 个权重的块存储一个共享的 8 位缩放值，这会额外增加约 6%，因此公开发布的仓库占用量更接近 1.5 TB，而不是整齐的 1.4 TB。

这排除了通常的应对办法。“直接量化”在这里没有帮助，因为发布的检查点已经是 4 位。降到 2 位后，权重将占用 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 个或更多加速器的 supernode；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。单个用户使用完整的 million 上下文时，需要 128 GiB。对于一个会话，这一容量已经超过任何单张显卡的容量。

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

这种推理方式在下一个版本中仍然成立。如果某个模型宣称支持 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 数量 × 小时数 × 费率。图表的重点是比例。每天让一个 8 GPU 节点突发运行 4 小时，每月成本为 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.5 TB 数据，即使速度达到 1 GB/s，也需要约 25 分钟的集群运行时间，之后才能生成第一个 token。请将权重预置在生命周期长于实例的卷上，这样第二次运行只需几分钟即可启动。

第 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 设置会在并行槽位、排队请求和剩余显存之间为您进行取舍。

在附加 GPU 的 VPS 上，Ollama 是最快搭建可用服务器的方式：

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 上。请查看加载日志，其中会显示已卸载到 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，因此只需修改基础 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 按相同费率计费。对于提示词占比较高的代理工作负载，成本平衡点还会进一步提高：重复上下文按每百万 0.30 USD 的缓存命中费率计费，而不是按每百万 3.00 USD 的缓存未命中费率计费。

在这一层自托管的，是模型周边的全部组件：保存 API 密钥且确保密钥不会发送到客户端的网关、请求和响应日志、重试机制、速率限制以及按用户设置的预算。这些组件可运行在完全不配备 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、总计 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；相同费用按公开价格计算，大约可购买 960 million 个输出 token，单价为每 million 个 token 15.00 USD。此外，还要支付空闲时段、权重下载，以及维护集群正常运行的人员成本。突发负载应按小时租用 GPU，并根据实际测得的 token 用量进行比较，不要依赖估算值。

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

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