让子弹再飞一会，国模的下半场才刚开始丨知乎 AI 观察

这个夏天，国产模型密集更新。

7 月中旬，月之暗面放出 Kimi K3；8 月 14 日，智谱发布 GLM-5.3；8 月 28 日，腾讯混元推出 Hy4 preview。一个半月，三家先后出手。

密集的发布节奏只是表象。把知乎上对应的这三轮讨论放在一起看，答主们的认可与抱怨其实指向了同一个问题：都这时候了，模型到底能不能把一件事从头做到尾？

时间回到几个月前。在 2026 年 5 月的腾讯股东大会上，马化腾打过一个后来被反复引用的比方：

原来一年前我们以为上了船，后来发现那个船漏水了，又开始换一艘船。现在感觉站上去了，还坐不下去，还是希望船速能快一点。

同一场会上，他还表示：

最近几个月比之前信心大增，Hy3 preview 用比较短的时间证明我们的方法论和基础设施重建是奏效的，先证明效果比什么都重要。

「船」是什么？又为什么「漏水」？这要追溯到 2025 年。DeepSeek 出现之后，腾讯造了艘自家的「船」——混元，一度以为自己已经登上了船，很快又发现情况不对。从那时到今天，中间补上的究竟是什么？这正是我们想详细讨论的问题。

先来看看这三个模型的基本情况：

追上来的

是「把事做完」

知乎答主@AI维克兹 在测试中感慨：

过去提起国产编程模型，几乎想不到混元。这些年它虽一直在更新，能力却并不突出；而这一次（节点为 Hy4 preview 发布），腾讯混元是真的追上来了。

按照腾讯自己公布的节奏，团队 2 月重建了基础设施，4 月推出 Hy3 preview，7 月发布 Hy3 正式版；到 Hy4 preview，主干总参数达到 770B，每个 Token 激活 49B，上下文长度做到 1M。

参数表固然是漂亮的，但要真正改变外界的看法，终究要靠实际任务去检验。

知乎答主@欧巴聊AI 让 Hy4 preview 写了一个跑酷游戏，跳跃、滑铲、变道一应俱全，沿途设置障碍，还配了磁铁、护盾之类的道具，他自己试玩了几轮，表示操作跟手；再换到网页桌面场景中：模型从开机、登录一路做到桌面，成功放入了 20 个可以真正运行的应用。

Hy4 preview 生成的跑酷游戏，画面中能看到三条跑道、障碍和道具状态 图源知乎答主@欧巴聊AI

在网页里复刻的桌面与应用窗口 图源知乎答主@欧巴聊AI

但让他真正给 Hy4 preview 打好评的另有缘由——他把一个全栈项目交给模型修复 Bug，修完之后，模型自行把项目预设的本地 CI 自动化检查全部跑完了：

之前很多模型都会忘记跑完全部的 CI 门禁，Hy4 preview 干活儿还是很靠谱的。

答主展示的项目修复结果与验证摘要 图源知乎答主@欧巴聊AI

他认可的，是 Hy4 preview 把「收尾」也当作了工程的一部分。

知乎答主@toyama nao 设计的则是一项「先调查、再动手」的测试，与知乎答主@欧巴聊AI 不同，他认可的并非结尾，而是「过程」：混元旧版本只草草检索少量材料就开工，新版本把将近一半的时间都花在调查上，产出也更扎实了。

同时，他还注意到了一个更隐蔽的变化：对同一道题反复进行测试，新版本即便偶尔发挥失常，也很少直接交白卷。

一次做对，赢得的是惊喜；次次靠谱，才能赢得下一次托付。

GLM-5.3 被认可的角度和前者又不太一样。知乎答主@MNACSTMSYSD 用它做了个四冲程柴油机仿真，并在提示词中特意要求零件结构、运动相位和交互信息需要彼此匹配；展示完生成结果后，他又接连做了城市沙盘、古风建筑等一系列的测试。他对最终成品的评价不低，但也没有替模型遮掩不足：一个池核场景做到一半时额度耗尽，只能先放出早期预览。但他给出的依旧是好评，主要在于整体的使用体感：

这个体感是综合能力包含速度、准确性、harness、模型自身能力共同作用的。

GLM-5.3 生成的柴油机仿真界面 图源知乎答主@MNACSTMSYSD

额度耗尽前留下的池核场景预览 图源知乎答主@MNACSTMSYSD

把过程拆开细看会发现，GLM-5.3 被认可的主要落点是「效率」。在另一组编程对比中，知乎答主@toyama nao 发现它倾向于并发调用工具、很少自测，完成一个任务所用的步数也更少；在他的测试条件下，同一个任务的成本大约只有 Kimi K3 或 Qwen 3.8 的三分之一到一半。

Kimi K3 被认可的关键词则是「耐力」。知乎答主@老狼 对照经典游戏《赤色要塞》的反汇编，让模型把游戏逻辑逐步重写为能在 UEFI Shell 中运行的程序。

他先拆解任务，为模型配齐截图和模拟按键工具。验收时模型发现吉普车位置不对，就对照画面、日志和汇编逐一排查；他试玩后向模型指出小兵倒着走的问题，模型随即就修正动画朝向。人负责试玩和提供反馈，模型负责检查与返工，两天半之后，整条游戏流程便跑通了。

在 UEFI 环境中运行的《赤色要塞》游戏画面 图源知乎答主@老狼

收尾、过程、效率、耐力，看似四个角度，其实是同一件事：模型能不能在几十步，乃至几百步之后，仍然把事情做对并完美结尾。

混元官方的 Hy4 preview 说明提到过一组内部盲测：腾讯组织了 163 名内部专家、用 203 个工程任务让三者同台竞技。结果是满分 4.00 的情况下，Hy4 preview 均分 2.99、Kimi K3 2.94、GLM-5.3 2.92。

引用这组数字前，有两点需要说明：一是它由腾讯自己组织，并非第三方评测；二是满分 4 分只拿到 2.9x，说明盲测任务本身偏难，不能理解为模型能力不够。

但数据仍能说明一些问题：三者分数极为接近，相差仅 0.07 分，而且都还没到 3 分。

如此看来，「国模第一梯队没有固定座位」不无道理——在长任务这个赛道，谁都还没能坐稳。

三个厂商

补的是同一件事

这种把长任务从头做到尾的能力从何而来？GLM-5.3 是一个现成的切口。智谱官方在发布介绍中强调：

与 GLM-5.2 相比，基座模型没变，但通过极致的后训练 Scaling 大大提高了模型的智能上界。

按照这份介绍，团队扩充了长程任务的环境与种类，同时也拉长了训练时间。有些任务的工作量已接近一名工程师连续工作数日的：模型需要调用计算集群、查阅内部文档和代码库，分析实验结果，再动手进行改进。

这里训练的对象是一长串前后相扣的动作，以及每一步之后随之而来的反馈，不再是简单的一问一答。

混元此前的迭代方向与此相同。Hy3 正式版的发布说明曾把进步归于两处：一是后训练算力规模加码，一是数据质量与多样性同步提升。Hy3 的官方模型说明把改进讲得更细些，包括细粒度的数据清洗和一道道的训练约束。官方也披露：在基于真实场景的内部评测中，模型幻觉率从 12.5% 降到了 5.4%；多轮对话中的指代、省略和约束继承也被专门进行了优化。这些数字自然有其内部评测的适用边界，但后训练在打磨什么，好像也已经能看出个大概了。

Kimi K3 则是架构探索、大规模预训练与后训练三条线同时推进。谈到它时，知乎答主@003 看重的，是团队把整套研发流程都独立地走了下来：

K3 标志 Kimi 自主完成了前期实验探索，大规模预训练与后训练的全部流程。

Kimi K3 在编程体验与通用工具使用任务中的训练曲线 图源知乎答主@想飞的石头

三家厂商路径不同，打磨的却是同一件事——让模型具备完成长任务的能力。而这种能力主要靠后训练，后训练要喂的正是大量长任务；长任务跑得动的前提，则是底层系统先承受得住。

任务一拉长，首先遇到的是同步等待。知乎答主@欠阿贝尔两块钱 在解读 GLM-5.3 时，点出了分组同步训练的一个老问题：同一批提示词，必须等一组内所有任务都跑完，才能用于更新模型。短问答耗时相近，问题尚不明显；Agent 任务却常常是一条早已结束，另一条仍在持续调用工具，整组算力就这样被慢任务占用。

而 GLM 的解法是 SAO（Single-Rollout Asynchronous Optimization，单条轨迹异步优化），即每条任务轨迹生成完毕后直接送入训练缓冲区，实现推理采样与模型训练完全解耦。

但 SAO 并非没有代价。知乎答主@欠阿贝尔两块钱 指出了两个必须同步解决的难题：一是单条轨迹更新缺少组内对照，单步优劣判断的波动变大，需引入价值网络来估计优势；二是采样与训练异步运行会导致模型版本错位、产生离策略偏差，需用 Token 级的重要性采样把偏差控制在信任域内。减少等待与保持训练稳定，必须同时做到。

任务拉长后的第二个问题是上下文越堆越长。分析 Hy4 preview 时，知乎答主@恋猫 注意到 Gated DSA 与 IndexCache 的配合：模型先筛出与当前查询相关的位置，再把主要的注意力计算集中到这些地方；部分层直接复用上一层选好的索引，省去了重复筛选。

这套机制并非腾讯自研。追根溯源，IndexCache 的原始论文出自清华与智谱的研究者，依据的是一个朴素现象：相邻层往往会选中相似的内容。一家厂商发表的论文，就此成了另一家厂商长上下文系统中的一部分。在底层技术上，厂商之间的边界，并没有发布会上看起来那么分明。

Kimi 同样在为长任务改造底层。Kimi官方介绍，MoonEP 负责专家并行中的通信，FlashKDA 专攻注意力计算优化，AgentEnv 为海量 Agent 任务提供隔离环境，快照、恢复和分叉都能快速完成。模型要同时尝试多条路径，系统就得让这些尝试跑得快、且互不干扰。

在这份介绍中，架构、数据与训练配方共同作用，最终被概括为一个数字：

规模化效率提升了 2.5 倍（即在算力最优意义下，单位算力产出智能约等于原来的 2.5 倍）。

Kimi K2 与 Kimi K3 的拟合缩放曲线，2.5× 对应训练计算量与验证损失的关系 图源知乎答主@想飞的石头

这个数字常被解读为「训练快了 2.5 倍」，但官方的含义并非如此，它衡量的是训练侧的规模化效率。同理，IndexCache 论文中的加速有其特定模型与上下文条件，也不能当作 Hy4 的端到端实测速度。

因此，回头看三家厂商在 Infra 上做的事：SAO 解决同步等待，IndexCache 解决上下文膨胀，AgentEnv 解决长任务的隔离与恢复。三者要解决的也是同一个问题：长任务太贵，需要为它省下钱和时间。

数据这一层遵循着同样的逻辑。知乎答主@想飞的石头 梳理了 Kimi 的技术报告后写道，自然长文档先要清除重复内容、截断文件和无效日志；足够长又连贯的材料本就稀缺，还要提高它们的采样比例。

文档再长，模型也可能只利用答案附近的局部信息，因此训练任务还要要求它把相隔很远的信息结合起来使用。到了监督微调阶段，模型自己生成的任务过程还要再经过一道筛选：

使用来自先前 Kimi 系列的领域专属模型合成数据轨迹，随后进行多阶段验证和人在回路标注。

Kimi 的一条训练任务合成流程，从知识概念采样、检索材料，再生成任务 图源知乎答主@想飞的石头

模型可以一次生成更多候选过程，但这些过程值不值得学，要靠验证和标注去判断。前面提到的 GLM-5.3 技术解读也指出，构造训练任务时要用独立的验证程序去检查结果，避免答案或奖励信息提前泄漏。

其实，人们对合成数据的信心本身也走过弯路。2024 年，知乎答主@李rumor 写道，自己起初更信任人工标注，直到模型能力逐步提升，才重新评估合成数据的潜力：

模型可以进行 self-play，不断判别->训练，用左脚踩右脚的方式提升效果。

但「判别必须准确」的这个前提始终不能放松。模型一旦把错误的过程当成正向经验，再据此批量生成相似过程，那么数据越多，偏离得反而越远。

至此，后训练、Infra 与数据这三层各自的角色已经明晰：后训练决定「练什么」，把长任务拆成前后相扣的动作反复打磨；Infra 决定「跑不跑得动」，用 SAO、IndexCache、AgentEnv 分别压低同步等待、上下文膨胀和隔离恢复的成本；数据决定「拿什么练」，靠清洗长文档、筛选合成轨迹，再用验证程序和人工标注把关。三者共同支撑模型学会把长任务做完。

长任务很贵

这就是那道坎

长任务时代的第一个问题，是成本。

先来看一个直观的对照。Hy4 preview 的公开定价为输入 6 元、输出 18 元、缓存命中 0.3 元（每百万 tokens）；Kimi K3 为缓存命中 2 元、未命中 20 元、输出 100 元。同样是输出，K3 的价格达到了 Hy4 preview 的 5.6 倍。

两个模型的参数规模、上下文长度和部署方式都不同，不能简单相比，但尚可作为一种体感参照。

讨论 Kimi K3 时，知乎答主@恋猫 先肯定了能力的提升，随即说出自己的顾虑：

能力是起来了，但是价格也起来了，实际上没办法完全转化成我的日常生产力。

知乎答主@老狼 那份赤色要塞记录也强调了开销：两个 199 元的套餐的周额度都耗尽，中途还要再升一档才能继续。而他自己估算，如果完全从零手写：

没有一两个月下不来，还未必能做到这个保真度。两天半、几百块钱，值。

老狼在 K3 游戏开发记录中展示的套餐用量，截图时本周用量已达 45% 图源知乎答主@老狼

「值」与「用不起」并不矛盾：两人要做的事不同，能够承受的消耗也不同，但可以窥见的是：成本随任务长度一同上升。

时间这一侧的成本同样在上升。前面那位肯定过 Hy4 Preview 射击游戏成品的知乎答主@Kitt在进化，同时写下了一大段对等待时间的不满：

770B 的参数量不算小，腾讯的推理资源明显感觉还没完全准备好。我排队排了好久才好不容易在 CodeBuddy 里用上。而且它的雷霆大思考太严重了。思维链比 DS、GLM 这些国模还要长。再加上推理资源的问题，就导致用起来真的太慢了……就一个小任务跑一个多小时，消耗我 400 多积分。

这里需要补充一个背景：Hy4 preview 首发时，WorkBuddy／CodeBuddy 同步开展了为期两周的限免活动。排队未必只是资源准备不足，限免带来的流量冲击也是原因之一。

排队时长、单步生成速度、思考链长度、工具调用次数，这每一项都在拉长任务最终的完成时间。Hy4 的官方说明也明确承认：模型在复杂任务中存在长思考、过度自我验证的倾向。

那么，自测这一步能不能省？知乎答主@toyama nao 的观察是分场景的：前端任务中，第一版代码质量已经不错，再跑自检往往只修到一些边角问题，让模型省去这一步，耗时可以减少约三分之一；而一旦换成非前端任务，他的观察正好相反：

对非前端任务，禁用自测带来的效率改善并不大，反而质量下降的风险更高，得不偿失。

省去一道工序，省下了时间，但可能丢掉了保障。游戏开发中多检查一遍车辆位置，在知乎答主@老狼 看来是值得的；但一个小任务如果耗时一个多小时仍未结束，用户的耐心将会被磨光。

等不起的时间、用不起的 token、供不起的部署，是同一件事的三个侧面，都会随任务变长而放大。

怎么把长任务变便宜

如何把长任务变便宜？知乎上的讨论可以归纳出三条路径：

一条是省。自测要不要做，本质上是基于「多做一步值不值」的判断。知乎答主@toyama nao 的分场景结论已经给出答案：该省的省，不该省的不省。当然，这不应该由用户自行试错，而应由模型学会判断——什么时候值得多查一遍，什么时候又应当停止。

一条是借。知乎答主@bestwang 看到第三方陆续开放 API 后，他的注意力转向另一种可能：开放模型与外部算力合作。即便对自建部署的顾虑并未完全消散，但能够下场提供服务的角色明显多了起来。

还有一条是续。即让中断的长任务能够断点续跑。知乎答主@Kitt在进化 在 OpenClaw 2.0 的讨论中更看重存储、网页控制面板和会话同步这些改造，在他看来，这轮更新让产品成熟了不少。这些环节都在模型能力之外，却直接关系到成本：任务要长时间运行，记录能否存下、中断后能否接续，既决定用户是否愿意继续使用，也决定一次中断之后是否要从头重跑、把此前消耗的 token 白白浪费掉。

结语

庆幸的是，国模这一波密集且重磅的发布，让人看清楚了追赶如何是真实发生的，也对未来有了更强的信心。

掌声给的是「做得完」，抱怨给的是「等不起」。马化腾希望「船速能快一点」——放到今天，「船速」似乎有了更具体的含义：长任务的完成效率，以及它背后的成本。

而随着 GPT-6 Astra 的上线引发众多讨论，我们相信，下半场游戏，才刚刚开始。

阅读更多