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来源：云知声）
