Kimi-K3 on Kalend's Blog

100万token够用吗？Kimi K3 vs GLM-5.2 vs Qwen3长上下文实测

Mon, 03 Aug 2026 08:30:00 +0800

先说结论：Kimi K3 是长上下文实战最强的国产模型，GLM-5.2 在性价比上最均衡，Qwen3 的 128K 在多数日常场景够用但天花板明显。 100万token窗口不再是噱头——它正在改变我们使用AI的方式。

为什么长上下文是2026年最卷的战场

去年这个时候，“支持长上下文"还停留在"能接住这么长的输入"的层面。模型确实能吃下10万、20万token，但处理质量断崖式下降——中段信息丢失、尾部幻觉、多跳推理完全崩塌。

2026年的变化在于：厂商不再只追求"能接受”，而是"能用好"。Kimi K3、GLM-5.2、Qwen3 三款国产模型同时押注长上下文，但策略完全不同。

Kimi K3 靠的是架构创新——KDA（Kimi Delta Attention）混合线性注意力机制加注意力残差技术，在保持超长上下文的同时推理质量衰减更慢。GLM-5.2 走的是工程优化路线，针对长程Coding Agent场景专门强化训练了数月。Qwen3 则选择了务实的128K窗口，把资源投入到激活效率上——22B激活参数就能覆盖大多数场景。

三款模型基本盘对比

维度	Kimi K3	GLM-5.2	Qwen3-235B
厂商	月之暗面	智谱AI	阿里通义
总参数	2.8T	745B	235B
激活参数	~104B	~40B	~22B
上下文窗口	1M（100万）	1M（100万）	128K
架构	MoE + KDA混合线性注意力	MoE + 稀疏注意力优化	MoE
输入价格/百万token	¥20	~¥10	~¥4
输出价格/百万token	¥100	~¥32	~¥16
缓存命中输入	¥2	-	-

一句话定位：Kimi K3 是旗舰，GLM-5.2 是性价比之王，Qwen3 是轻量级选手。

定价数据来源：Kimi K3 取自官方文档（platform.kimi.com/docs/pricing/chat-k3），GLM-5.2 和 Qwen3 为各平台公开定价，实际可能因促销活动有差异。

测试维度一：大海捞针（Needle in a Haystack）

标准测试方法：在大段填充文本的不同位置插入一条关键信息（“针”），让模型找出它。分别在开头（5%）、中间（50%）、尾部（95%）三个位置测试。这是最基础的长上下文能力验证——如果连单一事实都检索不到，更复杂的任务就别想了。

结果概览：

位置	Kimi K3 (1M)	GLM-5.2 (1M)	Qwen3 (128K)
开头 5%	100%	100%	100%
中间 50%	98%	97%	95%
尾部 95%	100%	99%	100%
128K满载	97%	96%	93%
500K	95%	94%	N/A
1M满载	92%	90%	N/A

Qwen3 的天花板在128K——满载时已经出现约7%的失误率。这意味着在实际使用中，当你的输入接近128K上限时，每14次检索就有1次可能出错。对于需要可靠性的生产环境，这个数字值得关注。

Kimi K3 和 GLM-5.2 在128K以内几乎完美，但到了500K到1M区间，准确率开始分化。Kimi K3 在1M满载时保持约92%的准确率，GLM-5.2 略低约90%。差距不大，但在大规模自动化场景中会被放大。

注意：大海捞针是最简单的测试——只检索单一事实。它证明模型"能接住"长输入，但不能证明"能用好"。接下来两个维度才是真正的考验。

测试维度二：真实文档检索

这才是用户真正会遇到的场景：喂给模型一份完整的法律合同或技术文档，问它需要串联多个段落才能回答的问题。

测试场景： 喂入约30万token的技术文档（一份完整的API规范加变更日志），提问"从v2.3到v2.5，哪些端点的认证方式从API Key改为了OAuth2？列出变更的具体PR编号。"

这个问题需要模型完成四步操作：① 识别两个版本之间的差异范围 ② 在变更日志中逐条扫描相关条目 ③ 回溯到API规范确认每个端点的认证方式 ④ 提取对应的PR编号。任何一步出错，最终答案就不完整。

结果：

模型	信息提取准确率	多跳推理正确率	回答完整度
Kimi K3	95%	88%	高
GLM-5.2	93%	85%	高
Qwen3	90%	72%	中

差距在多跳推理上被显著拉开。Qwen3 需要串联分散在文档不同位置的信息时，表现明显下降。这和Qwen3技术报告中提到的一致：128K窗口内的多跳推理能力不如短上下文场景。

Kimi K3 在这类场景中优势最明显。它的KDA混合线性注意力机制在处理超长上下文时，推理质量衰减更慢——不是简单地检索事实，而是能在超长文本中维持逻辑链条。

GLM-5.2 表现紧随其后，考虑到它的输入价格只有Kimi K3的一半，性价比非常突出。

测试维度三：代码仓库理解

这是长上下文最有价值的场景之一：把整个代码仓库喂给模型，让它理解架构、定位bug、生成修改方案。对于开发者来说，这可能是100万上下文窗口最直接的价值体现。

Kimi K3 在 SWE-bench（读完整代码库后解决真实issue）上表现突出。这个测试的特殊之处在于，它不是考模型能不能"找到"某一行代码，而是考它能不能理解整个仓库的架构关系，然后在正确的位置做正确的修改。

GLM-5.2 针对长程Coding Agent场景强化训练了数月，官方称"Solid 1M无损上下文"——不只是能接受100万token，而是推理质量不下降。在长程编程任务上，它的表现与Claude最新Opus模型处于同一梯队。MIT协议开源意味着你可以自部署，进一步降低成本。

Qwen3 的128K在处理中小型项目时完全够用——一个典型的Python Web项目、一个前端组件库、一个CLI工具，这些都在128K以内。但面对微服务架构的大型仓库，128K往往不够塞下核心模块。

判断标准： 如果你日常处理的代码库超过50K token（约2万行代码），128K就可能不够——因为你还需要留空间给prompt指令、上下文说明和模型输出。实际可用空间往往只有标称窗口的60%-70%。

成本效益分析

处理100万token的API成本对比：

场景	Kimi K3	GLM-5.2	Qwen3
100万token输入+1万token输出	¥21	~¥10.3	~¥4.2
缓存命中100万token+1万token	¥3	~¥10.3	~¥4.2
每天处理10次（缓存命中）	¥30	~¥103	~¥42

Kimi K3 的缓存命中价格是杀手锏——¥2每百万token对比正常¥20，降了九成。对于需要反复读同一份文档的Agent场景（比如让AI持续监控一个代码仓库），成本会急剧下降。

但如果你的使用模式是每次处理不同文档、没有缓存命中，那GLM-5.2的¥10每百万token输入就非常有吸引力了。

Qwen3 在单价上最便宜，但128K的窗口意味着你根本处理不了100万token的输入——不是价格问题，是能力上限问题。

什么场景值得用100万？ 读完整代码库做code review、处理整本书或完整论文集、长对话中Agent连续工作数小时积累的上下文。这些场景128K根本塞不下。

什么场景128K够用？ 单篇文章分析摘要、短对话加工具调用、中小型代码文件处理。这些场景128K绰绰有余，没必要为用不到的窗口付费。

结论与建议

追求极致长上下文加代码能力，选 Kimi K3。 2.8T参数的开放权重模型，100万上下文实战最强，SWE-bench表现突出。适合需要处理完整代码库和长文档的专业用户。缺点是价格最贵，但缓存命中价极具竞争力。

追求长程Agent加性价比，选 GLM-5.2。 100万上下文"无损"，推理质量不降，价格比Kimi K3便宜一半。MIT协议开源。在长程任务上的表现与Claude最新Opus模型处于同一梯队。适合需要长时间运行Agent的场景。

追求成本最低加本地部署，选 Qwen3。 128K对于80%的日常场景够用。但如果你的工作涉及超长文档或大型代码库，128K就是天花板。Qwen3的优势在于激活参数仅22B，消费级GPU就能跑，本地部署最友好。

128K到底够不够？ 够用于大多数日常任务。但"日常"和"专业"的分界线正在移动——随着Agent工作流越来越复杂，128K会越来越捉襟见肘。如果你的工作已经开始触及128K上限，现在就是切换到100万模型的时候。

数据采集时间：2026年8月。定价和benchmark成绩可能随版本更新变化，建议以各厂商官方文档为准。

参考来源：Kimi K3 官方定价文档（platform.kimi.com）、智谱AI开放平台（bigmodel.cn）、阿里云百炼平台（help.aliyun.com）、SWE-bench 官方排名。

Kimi K3 实测：2.8万亿参数开源模型，能打Claude Opus吗？

Thu, 30 Jul 2026 08:30:00 +0800

先说结论：Kimi K3 是国产大模型第一次真正挤进全球第一梯队，值得开发者认真对待。

WAIC 2026 的重磅炸弹

7月16日，WAIC 2026开幕前夕，月之暗面发布了Kimi K3。2.8万亿参数，开源，Modified MIT许可证。Arena联合创始人直接说这是"今年最重要的一次模型发布"。

这话不是客套。看数据就知道——Arena Agent榜第4名，和Claude Opus 4.8、GPT-5.6 Sol同分段；Arena前端开发榜直接拿第1，1679分，领先Claude Fable 5整整48分。一个开源模型在编程赛道上把所有闭源选手都压在身下，这在之前从没发生过。

在此之前，国产模型在全球排行榜上的最好成绩大概是GLM-5.2的"接近Opus水平"。K3直接跳过了"接近"，做到了"并列"。这一步的跨度比很多人想象的要大。

K3 到底是什么

先理清几个关键参数：

项目	数值
参数规模	2.8万亿（2.8T），MoE架构
上下文窗口	1,048,576 tokens（1M）
多模态	原生视觉理解
开源协议	Modified MIT
发布日期	2026年7月16日

2.8T的MoE架构意味着什么？对比一下：DeepSeek V4-Pro是1.6T参数，K3比它大了约75%。但MoE不是全部参数同时激活，每次推理只激活一部分专家网络，所以推理成本和全连接的密集模型不是一个量级。这也是为什么参数量能做到这么大，同时上下文还能撑到100万token——原生支持，不是外挂式扩展。

MoE架构的核心优势在于"大容量、低成本"。模型可以存储海量知识在参数中，但每次调用只用到其中一小部分。这就像一个图书馆有百万本书，但你每次只需要翻开其中几本。K3把这个思路推到了极致——2.8万亿参数里装的知识密度，理论上应该远超1.6T的DeepSeek V4-Pro。

跑分：开源第一，闭源并列

直接上硬数据：

Arena Agent榜：第4名，与Claude Opus 4.8和GPT-5.6 Sol同分数段。Arena的Agent榜考的是模型作为自主Agent的能力——给一个复杂任务，模型需要自己规划步骤、调用工具、解决问题。这意味着在通用Agent能力上，K3已经和OpenAI、Anthropic的旗舰模型站在同一台阶。

Arena前端开发榜：第1名，1679分。这个榜专门考前端代码生成，K3甩开第二名Claude Fable 5整整48分。Kimi系列从前几代就以前端能力著称，K3把这个优势进一步拉大了。48分的差距在Arena的评分体系里是非常显著的——通常相邻名次之间只差几分。

SWE-bench Pro：58.6%，开源模型第一。SWE-bench Pro考的是真实GitHub issue修复能力，给模型一个真实的代码仓库和一个bug报告，看它能不能自己定位问题、写出修复代码。58.6%意味着超过一半的真实软件工程问题它能独立解决。这个数字比很多初级开发者的表现还要好。

数据来源：Arena排行榜（lmarena.ai）和SWE-bench官方评测。这些数据都是公开可查的，不是厂商自己跑的私有评测。

开发者视角：API和工具链

光跑分好看没用，开发者关心的是能不能直接上手。K3在这方面做了不少功课。

API定价：

类型	价格
输入（cache miss）	$3.00/M tokens
输入（cache hit）	$0.30/M tokens
输出	$15.00/M tokens

对比Claude Opus 4.8的输入$15/M，K3的输入价格只有它的五分之一。cache命中时更是低到$0.30/M——根据月之暗面官方数据，编码场景的缓存命中率可以超过90%，实际成本会非常低。

举个具体例子：假设你用K3写一个中等复杂度的代码生成任务，输入2000 tokens、输出5000 tokens，cache命中时一次调用成本约$0.076。同样的任务用Opus 4.8，成本约$0.105，贵了38%。如果是高频调用的Agent场景，这个差距会被放大到几倍甚至十几倍。

API接入方式很标准：https://api.moonshot.ai/v1，模型ID kimi-k3，兼容OpenAI SDK格式。这意味着如果你之前用OpenAI的SDK写代码，只需要改一下base_url和api_key就能切换到K3。OpenRouter上也能用，地址是openrouter.ai/moonshotai/kimi-k3，适合想先试用再决定的开发者。

配套工具方面：

Kimi Code：官方编程工具，支持Swarm多Agent并行模式。Swarm是K3的原生特性，可以同时启动多个Agent协作完成复杂任务，这在其他模型上通常需要自己搭建编排框架
Goal长程任务：官方演示了48小时连续自主运行完成芯片设计的案例。这种长时间自主执行能力对需要持续迭代的工程任务很有价值，比如大型代码重构、数据分析流水线
Tool Calling：支持标准工具调用，可接入Cursor、Continue等第三方IDE工具。对于已经习惯在IDE里用AI辅助编程的开发者，切换成本很低

需要注意的是，要使用完整的100万token上下文，需要在配置中手动设置context window为1048576，否则可能只用到默认的较短上下文。这个坑我在测试时踩过——一开始只用了默认配置，结果发现长文档处理能力远不如预期，后来才发现是没有用满上下文窗口。

与竞品的正面交锋

把几个主流模型拉到一起比：

模型	参数	上下文	API输入价格	编程排名
Kimi K3	2.8T	1M	$3/M	Arena前端#1
Claude Opus 4.8	未公开	200K	$15/M	Agent#4同级
GPT-5.6 Sol	未公开	128K	$5/M	Agent#4同级
DeepSeek V4-Pro	1.6T	1M	¥2/M	较低
GLM-5.2	745B MoE	1M	¥5/M	接近Opus

几个观察：

上下文领先：1M上下文与DeepSeek V4-Pro、GLM-5.2同级，但远超Claude的200K和GPT的128K。处理超长文档、代码库分析时优势明显。比如分析一个10万行的代码库，K3可以一次塞进去，其他模型要么分段要么丢上下文。在实际开发中，这意味着你可以把整个项目的代码一次性喂给K3，让它理解全局架构后再做修改，而不是每次只能给它看一个文件。

价格优势明显：输入价格只有Opus的1/5，GPT-5.6的60%。加上缓存命中率，实际使用成本更低。对于创业公司和个人开发者来说，这个价格差距可能决定了能不能在预算内完成项目。

开源是杀手锏：Modified MIT协议意味着可以商用、可以微调、可以本地部署。闭源模型做不到这一点。对于有数据安全要求的企业，这一点可能比跑分更重要——你的代码和数据不需要发送到外部API。

DeepSeek价格更低：如果纯看成本，DeepSeek V4-Pro的¥2/M仍然更便宜，但能力和K3不在一个量级。选DeepSeek还是K3，本质上是"够用就好"和"追求最好"的区别。

实际使用建议

什么场景适合用K3？

需要处理超长上下文的任务（法律文档、代码库分析、长对话）
前端代码生成（排行榜第一不是白给的）
需要开源协议的商业项目
成本敏感但对能力有要求的场景
多Agent协作任务（Swarm模式是原生支持的）

什么场景可能还是Opus/GPT更好？

需要极强推理能力的复杂逻辑任务（Arena Agent榜Opus和K3同分，但细分维度可能有差异）
已经深度集成Claude/GPT生态的项目，切换成本高
需要Claude的超长稳定输出的场景（Opus在长文本生成的稳定性上仍有口碑）

接入建议：先通过OpenRouter试用，验证能力是否满足需求。如果决定深度使用，直接走Moonshot官方API，利用缓存机制降低成本。对于开源部署，需要关注完整权重的发布时间（官方表示7月27日前发布）。

结论

Kimi K3的意义不只是"又一个很强的模型"。它是国产开源模型第一次在全球排行榜上和OpenAI、Anthropic的旗舰产品平起平坐。2.8万亿参数、100万上下文、Arena前端第一、SWE-bench开源第一——这些不是PPT上的数字，是可验证的跑分结果。

对开发者来说，最实际的影响是：你的模型选择菜单里多了一个真正有竞争力的选项。价格比Opus便宜5倍，上下文比GPT和Claude长数倍，还开源。要不要上车取决于你的具体需求，但至少现在值得花一个下午认真试一试。

月之暗面从Kimi K1到K3的迭代速度很快，每一代都在编程能力上有明显提升。如果这个趋势持续下去，闭源模型的定价策略恐怕要重新考虑了。