跳转到主要内容
Last verified: 2026-10-14
Kimi K3 是 Moonshot AI 的前沿模型：2.8 万亿总参数，每 token 104 亿级活跃参数，通过 Stable LatentMoE 路由（16 个活跃 + 2 个共享专家，共 896 个），通过 MoonViT-V2 支持原生视觉输入，以及 1 百万 token 上下文窗口。K3 由 Moonshot 推出，17 日（2026 年），面向长周期编码、知识工作和推理任务，可下载权重随后于 27-28 日（2026 年）在 HuggingFace 上发布（1.1M+ 下载）。 权重、模型卡和许可证均已公开。您可以在足够大的集群上自托管 K3 并将其连接到 Tokios。
Kimi K3 权重可在 HuggingFace 上获取（1.1M+ 下载）。您可以使用 vLLM 在 K3 上自托管，需要 64+ 个加速器的集群并将其连接到 Tokios。

​
有哪些可用路径？

来源：Kimi K3 发布公告和 Kimi K3 API 指南。

​
Kimi K3 概览

Moonshot 随权重发布一同公布了技术报告、检查点文件和模型卡。请阅读模型卡获取完整规格和许可条款。

​
能在本地运行 Kimi K3 吗？

可以——如果您有足够大的集群。权重已在 HuggingFace 上发布，但 K3 约 1.4 TB 的权重下限（4 位精度下）排除了所有消费级和专业级方案。Moonshot 自己的建议是配备 64 个或更多加速器的超级节点。八个 DGX Spark 汇聚 1 TB 统一内存仍然差 376 GB。完整计算请参阅 DGX Spark 内存计算。 vLLM 是官方支持的服务后端。您也可以使用 Docker Model Runner 或配合 trust_remote_code 的 Transformers。
K3 需要 64+ 个加速器。请参阅 Kimi K3 的替代方案，为您的具体硬件找到最佳编码和通用模型，从 Strix Halo 到 4-Spark 集群。

​
Kimi K3 硬件需求

没有任何消费级或专业级方案能承载 K3。按每参数恰好 4 位计算，2.8T 参数仅权重就需要约 1.4 TB——还不包括微缩放元数据、运行时缓冲区、激活值和上下文状态。作为参考：八个 DGX Spark 汇聚 1 TB 统一内存，仍比原始权重下限差至少 376 GB，NVIDIA 目前仅记录到四节点的 Spark 集群，而 Moonshot 建议在服务 K3 时配备 64 个或更多加速器的超级节点。 完整计算、集群表格和网络约束请参阅 DGX Spark 内存计算。

​
在本地服务 K3

官方支持的服务路径是 vLLM。Docker Model Runner 和 HuggingFace Transformers（配合 trust_remote_code）也可使用。
K3 需要支持 KDA 的内核和缓存语义。仅能加载权重的运行时并不自动兼容 K3。请使用支持 KDA 的 vLLM 或其他经过验证的后端。

​
为何架构对自托管至关重要

K3 并非只是更大的 K2 检查点。五项变化对计划服务它的用户尤为重要：
  • Kimi Delta Attention（KDA）——一种混合线性注意力设计，使百万 token 提示的预填充成本更低。它需要匹配的内核和缓存语义：Moonshot 指出常规前缀缓存无法直接映射到 KDA，其 vLLM 预填充缓存贡献随权重一同发布。仅能加载权重的运行时并不自动兼容 K3。
  • Attention Residuals（AttnRes）——各层有选择地从较早深度检索有用表示，而非以固定权重累加每层的输出。Moonshot 的 AttnRes 论文报告了更深模型中更稳定的信息流。
  • Stable LatentMoE——16 个活跃 + 2 个共享专家按 token 路由，共 896 个专家。稀疏激活降低了每 token 计算量，但并不会缩小存储的检查点：每个专家都必须驻留在服务集群中，这使得高速互连成为首要需求。
  • MoonViT-V2——一个 401M 参数的视觉编码器，原生处理文本、图像和视频输入。
  • 原生 MXFP4——量化感知训练从监督微调阶段起运行，目标为 MXFP4 权重和 MXFP8 激活。这是预期的服务格式，不是社区量化——因此上文的 4 位数值是下限，不是折中。

​
需保留的 K3 API 行为

如果您通过 Moonshot 的 API 测试 K3，或验证自托管运行时，这些协议细节很重要：
  • K3 始终进行推理。使用顶层 reasoning_effort: "max"；不要发送 K2.x 的 thinking 参数。
  • 流式响应将推理内容分离到 reasoning_content，最终答案分离到 content。
  • 对于多轮对话和工具循环，重放完整的助手消息，包括保留的推理内容和工具调用字段。仅返回 content 可能导致后续轮次不稳定。
  • max_completion_tokens 默认为 131,072，最高可设为 1,048,576。
  • 发布 API 固定了采样值。Moonshot 建议您省略 temperature、top_p、n 和惩罚参数，而非覆盖它们。
  • 不接受公开图片 URL。请发送 base64 数据或 ms://<file-id> 引用。
当前请求模式请参阅 K3 官方 API 指南。

​
将 K3 与 Tokios 连接

Tokios 位于本地运行时之后。它不下载模型也不替代 vLLM。在支持的集群上服务 K3 并连接到 Tokios：
1

验证官方制品

确认仓库为 moonshotai/Kimi-K3。阅读模型卡、许可证、检查点清单、支持的加速器列表和推荐的并行设置。
2

在支持的集群上服务 K3

运行 vllm serve "moonshotai/Kimi-K3" 或按照 Docker Model Runner / Transformers 说明操作。确认本地服务器可以完成流式请求、保留 reasoning_content 并在其自己的 /v1 API 上执行多轮工具循环。
3

配对 Tokios 连接器

在能访问服务端点的节点上安装连接器。在 dashboard 中打开 Setup，选择 Start pairing，使用一次性 TKS-XXXX-XXXX 配对码。
Windows
macOS
Linux
然后approve该设备（在 Setup 或 Connectors 标签页上）。
4

注册部署

将连接器指向集群的 OpenAI 兼容 /v1 基础 URL。在公共部署名称（如 kimi-k3-tunnel）下注册上游模型 ID。
5

创建 API 密钥

在 Keys 标签页中，点击 Create key。立即复制 sk-tok-… 密钥——它仅显示一次。
6

共享端点前进行测试

通过 https://api.tokios.com 测试流式传输、长轮次、视觉、结构化输出和工具调用。使用专用的 sk-tok-… API 密钥，并在验证内存使用时保持初始上下文简短。

​
从任意位置调用

验证该路径后，客户端调用您的部署名称而非上游模型 ID：

​
发布注意事项

  • K3 基准测试结果由 Moonshot 报告。独立复现需要评估环境。
  • Moonshot 警告，丢失保留的推理历史记录或将其他模型的现有会话切换到 K3 可能导致输出不稳定。
  • K3 针对长时间、高难度任务训练，在指令模糊时可能表现过于主动。在系统提示或 AGENTS.md 中设定明确边界。
  • 1M token 限制是上限，不是目标。长上下文会增加预填充时间、缓存存储和推理成本。
  • Kimi K3 许可证是定制的——在生产环境部署前请阅读模型卡了解条款。

​
常见问题

在原生 MXFP4 精度（每参数 4 位）下，K3 的 2.8T 参数仅权重就需要约 1.4 TB——还不包括块缩放、运行时缓冲区、激活值和 KV 缓存。这大约需要 11 个 DGX Spark（每个 128 GB），仅用于原始权重下限。实际上，您至少需要 14-16 个 Spark 才能支撑假设的分布式服务栈，而 NVIDIA 仅记录到 4 节点的 Spark 集群。
实际不可行。八个 DGX Spark 提供 1 TB 统一内存——比权重下限差 376 GB。NVIDIA 记录的 Spark 拓扑最多 4 个节点（512 GB），而 Moonshot 将 K3 定位于配备 64 个或更多加速器的超级节点。对于 Spark 规模的模型，请参阅 DGX Spark 模型兼容性。
权重在 HuggingFace 上可用，采用定制 “Kimi K3 License”——非 MIT 或 Apache。部署前请阅读模型卡了解完整许可条款。Kimi K2.6 和 K2.7-Code 也是开放权重——请参阅 Kimi 模型系列。
在配备 64+ 个加速器的受支持集群上服务检查点。官方支持的路径是 vllm serve "moonshotai/Kimi-K3"。Docker Model Runner 和配合 trust_remote_code 的 Transformers 也可使用。Tokios 可以为该本地端点提供作用域 API 密钥——参见上文 将 K3 与 Tokios 连接。您也可以使用模型 id kimi-k3 调用 Moonshot 的托管 API。
1,048,576 tokens（1M）。max_completion_tokens 参数默认为 131,072，最高可设为完整上下文窗口。长上下文会增加预填充时间、缓存存储和推理成本——1M 是上限，不是目标。
K3 是一个混合专家模型，93 层（69 KDA + 24 Gated MLA），隐藏维度 7168，96 个注意力头，具有 4 项关键创新：Stable LatentMoE（每 token 16 个活跃 + 2 个共享专家，共 896 个，104B 活跃），Kimi Delta Attention（高效百万 token 预填充的混合线性注意力），Attention Residuals（深度方向信息路由），MoonViT-V2（401M 参数视觉编码器，支持文本 + 图像 + 视频），以及原生 MXFP4（从 SFT 阶段起的量化感知训练）。这些与标准 transformer 服务不直接兼容——特别是 KDA 需要匹配的内核和缓存语义。

DGX Spark 上的 Kimi K3

完整的内存计算、集群约束和发布证据表。

Kimi 模型

将 K3 与可下载的 K2.6 和 K2.7-Code 对比，立即自托管 Kimi。

K3 的替代方案

适合您硬件的最佳编码和通用模型，从 Strix Halo 到 4-Spark 集群。

模型服务与扩展

在规划前沿规模集群前，先了解张量并行、流水线并行和专家并行。

快速入门

配对连接器并注册一个当前可用的本地模型。