Flash 正在从旗舰模型的效率版本，变成高频真实任务里的主力模型。

作者｜周悦

编辑｜栗子

9 月 10 日，DeepSeek 发布 V4.1-Flash。

和过去 " 更快、更便宜，但能力让位于旗舰 " 的 Flash 不同，这一次，DeepSeek 首先强调的是能力。

V4.1-Flash 是一个 552B 参数的 MoE 模型，输入阶段只激活 8B 参数、输出阶段激活 16B。经过新的预训练方式和更大规模的强化学习后训练，DeepSeek 称其能力已经超过 V4 Pro。

更直接的是，从 9 月 14 日中午开始，所有对 V4 Pro API 的请求，都被直接路由到 V4.1-Flash，并按 Flash 价格计费，直到下一代 Pro 上线。

Google 也在做类似的事。9 月初发布的 Gemini 3.8 Flash，被 Google 直接称为 "most intelligent workhorse model（最智能的主力工作模型）"，重点提升的也不只是速度，而是软件工程、Agent 任务和多步推理。

「甲子光年」认为，Flash 正在从效率版本，变成主力模型。成为主力，首先意味着能力足够承担复杂任务；在此基础上，速度、成本和稳定性，决定它能不能被真正用进大量生产任务。

9 月 15 日，云知声发布 U2-Flash。U2-Flash 沿用了 U2 的模型基座，主要通过后训练继续提升 Coding、Agent 等复杂任务中的推理和自主执行能力。与此同时，云知声称，相比 U2，U2-Flash 完成同一任务所需的 Token、交互轮数和执行步骤都有下降。

云知声还把这套后训练闭环放进了一个更大的命题里：递归自我改进（RSI）。模型开始参与生成训练数据、分析自己的执行轨迹，甚至巡检和修复训练系统。云知声将其定义为 RSI 的第一步。

U2-Flash 想做的，不是一个更轻的 U2，而是在复杂任务能力继续提高的同时，把任务做得更稳、路径更短。

1. 被压缩的是任务路径

U2-Flash 并不是最近这轮 Flash 热潮起来之后才临时启动的。

「甲子光年」了解到，5 月底云知声团队就已经开始规划 Flash 版本。当时最想解决的是在同一个基座下，把 Coding、Agent 这些长链路任务做得更稳。

目前披露的评测里，变化最明显的也是这两类任务。

按云知声提供的数据，在代表软件工程能力的 DeepSWE v1.1 上，U2-Flash 得到 64.6 分，相比 U2 的 32 分接近翻倍，也高于 DeepSeek-V4-Pro-0813 的 62.7 分和 GLM-5.3-Flash 的 63.4 分；SWE-Bench Pro 则从 U2 的 50.1 分提高到 61.6 分。

长链路 Agent 任务的提升更明显。在 TerminalBench 3.0 上，U2-Flash 从 U2 的 2.7 分提高到 24.3 分，高于 DeepSeek-V4-Pro-0813 的 11.8 分和 Kimi K3 的 17.4 分，不过仍低于 GLM-5.3 的 28.3 分和 DeepSeek-V4.1-Flash 的 30 分。

在更接近企业日常工作的 WorkBuddy-Bench Office 上，U2-Flash 得到 81 分，相比 U2 的 72 分提高 9 分，也高于 DeepSeek-V4-Flash 和 V4-Pro。

和上一代相比，U2-Flash 的提升主要集中在 Coding、长链路 Agent 和办公任务这些更接近实际生产的能力上。在部分评测中，它也已经能与 DeepSeek、GLM 等头部模型直接比较。

U2-Flash Benchmark 表现，图片来源：云知声

把模型放进几个具体任务里，更容易看清 U2-Flash 到底能做什么。

 【Demo 1】3D 空间建模

面对输入的纯结构化 2D 办公室平面描述，U2-Flash 自主编写脚本调用 Blender 渲染管线，主动捕捉布尔运算失败、法线翻转以及光照死角等视觉缺陷，最终交付 3D 办公室场景。

 【Demo 2】Bug 自主诊断与修复  

很多真实工程中的 Bug，单看静态代码逻辑极为隐蔽，只有在接入真实运行时并触发边界条件时才会暴露。U2-Flash 能够在沙箱环境中自主拉起测试、捕获堆栈回溯。像资深工程师一样，自主推演执行流、设计最小可复现案例并针对偶发疑难问题完成就地修补与回归校验，实现代码生成的 " 无缝自愈 "。

 【Demo 3】前沿论文复现

围绕智能体架构前沿工作 RSI ( Recursive Harness Self-Improvement ) ，U2-Flash 完成了端到端的工程闭环复现：在无人工预置策略的条件下，模型从零策略的极简弱种子出发，自主构建出包含执行循环、上下文管理与校验拦截的完整运行基底；在后续多轮演进中，模型完全基于下游执行轨迹与报错反馈进行自省归因，定向修补跨模块依赖并抑制性能回退，完整复现了论文中 " 以执行反馈驱动执行系统自我进化 " 的核心实验链路，SWE-bench Pro 由 60.9% 提升至 62.6%

U2-Flash 和 U2 用的还是同一个基座。如果只看私有化部署所需要的算力，它和 U2 并没有明显差异，变化主要发生在任务执行过程中。

云知声相关负责人告诉「甲子光年」，相比 U2，U2-Flash 完成同一个任务所需要的 Token、交互轮数和执行步骤都有下降，内部统计显示，任务迭代步数平均减少约 20% — 30%。此外，U2-Flash 的 Agent 任务执行周期相比 U2 缩短约 35%，复杂任务 Token 消耗减少约 20% — 30%。

这里的 " 快 "，不是把模型做小以后换来的。Coding、Agent 这些任务上的分数提高之后，完成任务的过程反而变短了。

对于 Agent 来说，一个任务可能要连续做几十次判断：理解问题、选择工具、读取结果、执行下一步；如果中途走错，还要决定继续尝试、换一种工具，还是重新规划。

最后都能完成，并不意味着过程一样。多一次错误调用、多一轮无效尝试，都会变成额外的 Token、时间和成本。

云知声内部目前已经将 U2-Flash 用于 HR 数据处理、英文材料润色、周报、会议纪要、方案分析、代码仓库阅读和前端页面生成等场景。

这些任务未必需要模型解决最难的问题，却更接近企业里每天都会发生的工作。调用次数一多，中间那些不起眼的试错和返工也就被放大了。

过去谈模型效率，最直观的指标是首 Token 延迟、生成速度，或者每百万 Token 的价格。到了 Agent 阶段，还得评估它到底要执行多少步，才能把事情做完。

2. 后训练，寻找模型的能力边界

U2-Flash 没有换基座，主要改的是后训练。

云知声相关负责人告诉「甲子光年」，他们团队在做 Coding、Agent 任务时逐渐发现，模型的瓶颈很多时候已经不是 " 还缺多少知识 "，而是能不能把事情做对。

同样一个任务，有的路径会不断试错，有的则能更快定位问题、调用正确工具并完成验证。后训练能够改变的，是这种任务轨迹。

U2-Flash 没有简单堆叠更多训练样本，而是做了一套 " 自主闭环演进 "。

它首先要解决的是：模型下一步该练什么？

模型会先自己生成 Query，再去执行。哪些任务已经会了、哪些总是失败、哪些最后虽然能完成却绕了太多路，都会影响下一轮数据怎么生成。

在云知声团队看来，模型是在不断寻找自己的 " 能力边界 "。

如果一类任务已经稳定会做，再增加大量相似样本，增益会越来越有限。更有训练价值的，反而是那些 " 差一点 " 的任务：能做到一半，却总在某个环节出错；或者最后能完成，但要经历很多试错。

于是，失败本身也变成了数据。U2-Flash 会保留任务执行失败产生的信号，再去寻找薄弱环节，并围绕这些问题生成新的训练数据。

前述负责人提到，重点不是让模型 " 永远不失败 "，而是失败以后能知道哪里出了问题，下一步该怎么调整。

不过，找到失败还不够。Agent 任务往往有几十步，最后代码没有跑通，问题可能早在十几步之前就已经出现。只给最终 " 成功 " 或 " 失败 " 的信号，很难知道中间到底是哪一步出了问题，监督信号太稀疏。

这也是多教师蒸馏的作用。云知声分别训练了 Coding、数学、医疗、工业等领域的 Teacher。代码教师去检查代码执行轨迹，数学教师判断推理过程，医疗教师处理专业判断，再把这些专项能力蒸馏回同一个通用模型。

云知声称，相比单纯依靠 RL 从零训练，这套方法达到同等能力水平所需要的训练步数减少了约 55%。

云知声团队想验证：不继续扩大模型，能不能把不同领域的专家能力重新汇聚进同一套权重。

长链路任务还有另一个问题：训练本身很慢。

Agent 一次执行可能持续几十步甚至上百步，中间夹杂工具调用、代码运行和环境等待。如果所有 Rollout 同步执行，一条轨迹卡住，就可能拖慢整批训练。

U2-Flash 采用异步 Agent RL，让多个 Rollout 同时在不同环境中运行。一条轨迹还在等待时，其他任务可以继续；同时通过强化学习鼓励模型探索不同的解决路径，而不是只学习一条固定的 " 标准答案 "。

按照云知声披露的数据，相比同步训练模式，这套异步架构让单位时间内产出的有效训练轨迹数提升了约 60%。

把这三步连在一起，自主任务生成负责找下一步练什么，多教师蒸馏判断错在哪里，异步 Agent RL 则把这些长链路任务练起来。

这也是云知声把这套训练闭环放进 RSI 框架下理解的原因。这里的 " 自我改进 " 还不是模型自主改写架构或者训练配方，而是它开始进入自己的训练过程：生成任务和轨迹、根据表现调整下一轮任务难度，并参与训练系统的巡检和异常修复。

技术报告披露，U2-Flash 已经能够自主巡检训练机器、定位并修复异常，将训练故障的平均恢复时间压缩到人工介入模式的约三分之一。云知声把当前阶段称为 " 有界 " 的自我改进——任务仍运行在人工设定的沙盒、验证标准和授权范围内，每次调整都要求可验证、可追溯。

类似的后训练思路，也出现在 DeepSeek 和智谱近期公开的模型中。

DeepSeek V4.1-Flash 没有改变 SFT — RL — on-policy distillation 的基本配方，主要变化反而集中在数据管线：自动合成 Agent 任务和环境，并继续扩大 data、tasks 和 rollouts。

智谱则在 GLM-5.3 中明确写道，它和 GLM-5.2 使用同一个 base model，能力增益来自 post-training；公开评测中，Terminal Bench 3.0 从 4.6 分提高到 28.3 分，DeepSWE v1.1 从 46.2 分提高到 66.9 分。

U2-Flash 披露的自主任务生成、Agent RL 和蒸馏，也与头部模型近期的 Agent 后训练方向趋同，并且他们都指向同一个问题——怎么持续得到高质量、可验证，又刚好落在模型能力边界附近的任务和轨迹。

云知声团队提到，对于 Coding、Agent 这样的复杂任务，他们想验证高质量的执行轨迹，比单纯增加训练样本更重要。

这延续了云知声此前 " 高智能密度 " 的思路：不换基座，而是继续把同一套权重里的能力释放出来，并让它更有效地作用在真实任务上。

3. 主力模型，要算一笔任务账

云知声最早解释 " 高智能密度 " 时，算的主要还是模型内部的一笔账。

今年 6 月发布 U2 时，云知声更多从模型本身解释它：有限的激活参数和 Token，能承载多少有效智能。

U2-Flash 延续了这条路线。总参数约 266B，单次推理激活约 10B，不到总参数的 4%。

但当模型真正开始承担复杂任务，" 高智能密度 " 还要算另一笔账：把事情做完，需要付出多少资源？

对 Agent 来说，单个 Token 便宜，并不意味着完成任务就便宜。模型如果不断试错、重复调用工具，即使单价更低，最后花掉的 Token、时间和调用次数也可能更多。

企业最终购买的不是 Token 本身，而是这些 Token 最后完成了多少工作。

Google 最新的 Flash 模型提供了一个很有意思的例子。

Gemini 3.8 Flash 在 Coding 和 Agent 能力上继续提高，Google 也指出，在复杂任务上，模型可能会 "work harder"：增加推理步骤和工具调用，高 effort 模式下有时会消耗更多 Token。对于更看重计算效率的场景，Google 仍然保留 3.7 Flash。

模型更强，并不天然意味着完成一项任务就更省。

DeepSeek 则从另一个方向压低成本。V4.1-Flash 通过 8B/16B 激活的非对称结构降低推理计算，同时把 KV Cache 对 HBM 的需求压缩到上一代的 1/4、SSD 需求压缩到 1/8。DeepSeek 特别提到，在 Agent 场景里，缓存本身就是一笔不小的成本。

U2-Flash 解决的是另一部分：模型已经开始执行任务以后，能不能少走几步，减少无效尝试和不必要的 Token。

架构、缓存和任务路径，是三种不同的降本方式。最后算的却是同一笔账：一个 Agent 把事情做完，到底需要多少资源。

过去衡量模型，首先看参数规模和 Benchmark；到了真实业务里，企业还要看另一组指标：任务能不能完成、需要多久、花多少 Token，中间要不要人工接管。

云知声相关负责人告诉「甲子光年」，他们对 " 主力模型 " 的理解，并不是单项能力最高，而是在大量真实任务里，把效果、速度、成本和稳定性放到一起看。

企业内部大量发生的任务，往往也不是极限数学推理或者前沿科研，而是文档、数据、代码，以及越来越多需要连续执行多步的 Agent 任务。

这些任务调用频率高，一次多走几步并不起眼，放到成千上万次调用里，就会直接变成成本。

云知声目前已经把 U2-Flash 用于文档分析与润色、表格和数据处理、会议纪要、方案生成与调研、代码理解和修改等场景。按照其内部判断，随着模型能力继续提高，未来这类模型可能覆盖 90% 以上的企业真实任务。

如果大部分日常任务都能由同一个主力模型接住，企业的模型路由方式也会随之变化。

按照云知声团队的设想，U2-Flash 可以先承接大多数任务；只有当任务需要特殊能力，或者执行过程中触碰到当前模型的能力边界时，再切换到其他模型。

模型路由的依据不再只是 " 大模型还是小模型 "，而会更多取决于任务本身，以及执行过程中是否已经超出当前模型的能力范围。

能力上限仍然重要，但真正成为主力模型，还得看这份能力能不能被稳定、低成本地反复调用。

（封面图来源：AI 生成，文中视频、图片、Demo 来源：云知声）

END.