开源AI能读整本书，但需要8块顶级显卡才行

月之暗面发布了Kimi K3，一个2.8万亿参数的混合专家模型（MoE）。它每个token激活16个专家（共896个），支持最多100万token的上下文窗口，并原生支持视觉输入。对于需要长文档分析的应用，比如法律合同审查、长篇小说辅助写作，这个能力让AI不再需要频繁分段或丢失上下文。

K3能做到这点，靠的是自家的注意力架构：Kimi Delta Attention（KDA）。它用一个固定大小的循环状态代替传统Transformer里不断增长的KV缓存，再与周期性的全注意力层交错。循环层保持低成本，全注意力层负责精确的全局召回。两者结合，1M上下文才变得实际。注意力残差（AttnRes）则把前几层的输出与softmax注意力混合，vLLM已经为它写好了融合CUDA内核，一次启动就能完成logits计算、softmax和聚合。

速度是另一个亮点。在vLLM服务框架下，不使用推测解码时，K3每用户每秒可输出118个token；启动DSpark推测解码算法后，速度提升到370 tok/s，提升约3.14倍。DSpark由Inferact开源，其draft模型使用MLA架构，与K3的注意力机制对齐。DSpark一次并行生成多个推测token，成本随块深度增长保持平稳。实际接受率因任务而异：编码等低熵任务每步约4.73个token，创意写作等高熵任务约2.61个token。编码这类任务用户几乎感觉不到等待，写故事时改善就没那么明显了。

但跑这个模型不便宜。部署K3至少需要8块NVIDIA B300（或GB300）显卡构成一个节点，大多数生产环境还需要多节点专家并行和数据并行，通过RDMA或NVLink连接。8块B300是起步价，个人开发者或小公司无法本地部署，只能通过大型云服务商使用。vLLM对K3的初始支持覆盖NVIDIA B200、B300、GB200、GB300和AMD ROCm（较早调优仍在路线图中）。vLLM还实现了prefill/decode分离部署，已验证拓扑为TEP8 prefill → DEP16 decode，KV/状态通过NIXL在阶段间移动。

既然普通用户无法本地运行，K3的实力如何体现？vLLM服务下的K3在基准测试中表现突出：数学推理GSM8K得分0.976，科学问答GPQA-Diamond得分0.939，视觉理解MMMU Pro Vision得分0.818，OCR识别OCRBench得分0.889。这些分数都很高，用户在教育、科研等领域可能获得更可靠的AI辅助。

K3还支持工具调用、推理输出和结构化输出，加上vLLM的Mooncake集成，可以让AI代理跨轮次和请求卸载、重用KV缓存。这样，重复提交的代码库、文档或智能体草稿不需要每次从头计算，特别适合长时间运行的多轮对话客服或自动编程助手。此外，K3的权重是量化感知训练的原生4-bit MXFP4格式，精度在训练时就定好了，不是事后转换的，这保证了部署时的效率。

vLLM为K3做了很多底层适配。K3没有常见的Jinja聊天模板，它的分词器通过Python程序渲染消息。vLLM在Python和Rust前端都实现了相同的渲染程序，确保工具调用、推理输出和结构化输出行为一致。MoE层使用专家并行，vLLM提供两种后端：TRT-LLM-Gen适用于张量并行（TP>1），MegaMoE适用于分离/专家并行（DEP），还有可选的专家并行负载均衡（EPLB）。混合KV缓存管理器统一管理全注意力层的分页KV块和KDA层的紧凑循环状态块，同时支持对循环状态的前缀缓存（但默认关闭，需通过--enable-prefix-caching启用）。

K3的模型权重、DSpark推理代码、部署配方和Docker镜像都已开源发布。目前还有几个关键问题没有明确：K3的API调用成本是多少？中文任务表现如何？除了vLLM，其他推理引擎何时支持K3？许可证是否允许商业使用？这些答案将决定K3能否真正进入主流应用场景。