Datawhale干货
分享：吴鑫，阶跃星辰算法专家
前天，距离阶跃星辰发布开源基座模型 Step 3.5 Flash 仅过去两天，Datawhale 联合阶跃星辰团队带来了全网第一手深度揭秘。
这是一场关于“如何打造真正为 Agent 而生的极速模型”的技术分享，由阶跃星辰算法专家、Coding Agent 基座研发团队的吴鑫主讲。
当行业还在卷参数规模时，Step 3.5 Flash 选择了一条“高智能密度+极速推理”的非典型路径。
Step 3.5 Flash 已全面开源：
1. GitHub：https://github.com/stepfun-ai/Step-3.5-Flash/tree/main
2. OpenRouter：https://openrouter.ai/stepfun/Step-3.5-Flash:free
3. 魔搭社区：https://modelscope.cn/models/stepfun-ai/Step-3.5-Flash
以下内容基于 24000 字的直播原文整理，在不改变原意的情况下进行了结构化梳理。
一、最重要的升级点：为什么要做 Flash？
“在Agent时代，推理速度就是生产力。”
Step 3.5 Flash 的参数配置乍看之下充满矛盾：总参数量高达 196B，但激活参数却仅有 11B。这是一个极致稀疏的 MoE 架构，稀疏度达到了 20:1。
为什么要在这个时间点，发布这样一个“大得不像Flash，快得不像196B”的模型？
吴鑫：我们的 CTO 在知乎上也分享过，Chatbot 时代，模型只要“够读”就行。但在 Agent 时代，Agent 的生产力直接挂钩于它的迭代速度。
Step 3.5 Flash 的核心定位非常明确：面向实时 Agent 工作流的开源基座。
大家看我们的 Model Page，Step 3.5 Flash 处于坐标轴的右上角，这意味着它的 智能密度（Intelligence Density） 非常高。
参数策略： 总参 196B，激活 11B，稀疏度 20:1。
性能指标： 推理速度高达 350 TPS（Tokens Per Second），混合上下文支持 256K。
我们在做技术决策时基于一个核心假设：Agent 场景下的 Intelligence，不仅仅在于模型参数量的 Scale，更在于智能密度的 Scale。
我们发现，模型在编程或 Agent 场景的能力，与 LiveBench、Verified、Terminal-bench 这些学术榜单的分数是强相关的。所以我们选择了 Flash 这个型号，把智能密度做高，同时把成本打到最低，让开发者在构建 Agent 时真的“用得起、等得起”。
二、 技术团队背后的思考：Midi-train 与架构取舍
“模型不再单一扩展参数量，更需要原子能力作为智能基石。”
在训练策略上，Step 3.5 Flash 引入了一个被称为 Midi-train 的中间阶段。这不同于传统的预训练（Pre-train）或后训练（Post-train）。这是阶跃星辰团队为了解决 Coding Agent “懂代码但不懂框架”这一痛点所做的针对性优化。
吴鑫：这一代模型相比前两代，最大的技术变量就是 Midi-train。
在这个阶段，我们给模型灌输了大量的 原子能力（Atomic Capabilities） 数据。 比如在 Coding 场景，我们不会只教它写 Python，我们会针对前端场景，把 Three.js 的语法、GPU 进行科学计算的能力、甚至页面渲染的“美观度”都拆解成原子能力喂给模型。
我们非常意外地发现，有了这些原子能力垫底，Post-train 阶段变得异常顺利。模型在面对复杂任务时，展现出了一种 近乎直觉的组合能力。它不需要我们去灌输大量的任务模板，就能自己把这些原子能力串联起来。
关于架构设计的两个关键点：
MTP (Multi-Token Prediction) 的双刃剑：我们要快，所以上了 MTP。这不仅仅是为了刷 TPS 数据，而是为了让 Agent 的交互体验不卡顿。 但这也带来了一些意想不到的工程挑战。比如上线第一天我们发现，因为生成速度太快（一个 Delta 里包含了多个 Token），导致下游传统的 Stream Parser 逻辑直接崩了。 “我们其实是昨天才解决的一个 bug。” 这种生成速度过快导致传统逻辑跪掉的问题，反向倒逼了我们工程链路的升级。
注意力机制的混合（SWA vs Full Attention）：我们在 Sliding Window Attention (SWA) 和 Full Attention 之间做了一个 3:1 的混合比例。 为什么不用全 SWA？因为 Agent 需要 State（状态）存储。在长 Context 下，SWA 会有信息损失，而全 Attention 又太慢。我们目前的配比是为了在保留 因果关系（Causal Dependency） 和推理速度之间寻找最优解。
Test-Time Scaling（测试时扩展）：因为 Flash 推理速度非常快，所以 Parallel Scaling（并行推理） 技术特别适合它。 我们让模型同时生成多个候选答案，然后通过一个 Controller 去总结和反思。更神奇的是，即使 Candidates 里面没有正确答案，经过 Controller 的反思后，模型也可能最终推理出正确答案。 这是我们意想不到的结果，也是只有在推理成本足够低时才能玩得起的技术。
三、 真实场景：当 Agent 开始写 Agent
“它不需要我教，自己去看了文档，把代码跑通了。”
吴鑫在现场没有跑分，而是直接演示了几个“高压”场景。其中最引人注目的是用 Step 3.5 Flash 去探索和编写 Deep Research 的 Wrapper。这不仅是写代码，而是模型在理解业务逻辑。
吴鑫：我想展示一个 Agentic Coding 的 Case。
我们让模型去探索 Deep Research 的 Wrapper。大家注意看视频里的速度（虽然稍微加速了），但模型输入了 10K tokens，几乎是瞬间就开始输出。
Markdown 解析： 它的文档还没读到一半，4个章节已经写出来了。
格式化： 信息提取非常准确，Markdown 表格、标题、Emoji 的使用完全符合人类开发者的习惯。
还有一个 Step GUI 的例子，这是我们主推的“端云结合”路线。Step 3.5 Flash 在云端作为“大脑”，规划任务；Step GUI 模型在端侧作为“手”，执行操作。
这个 Case 是让 Step 3.5 Flash 相对于 GUI 还是算一个稍大一点的模型，所以它作为大脑去规划和指挥 GUI 模型去干具体的活。比如搜到一个 arXiv 上的文章，把摘要总结出来，然后再发出去。这种功能对于平常没有时间去读非常多论文，但又在了解学术的小伙伴，应该是非常有用的。
另一个 Case 是比价：让 GUI 去比对不同电商平台里面 MacBook 的价格。可以看到端侧模型还是更快的，大脑也非常快。
端云协同，大模型做规划，小模型做执行，这是阶跃星辰在探索的一条差异化路线。
四、 接入与实操：兼容与“翻车”现场
“目前 OpenRouter 可能会报 Rate Limit，因为它太快了。”
作为一个刚发布两天的模型，Step 3.5 Flash 对开发者生态的适配做得非常激进。它不仅支持标准的 OpenAI 格式，还深度适配了 Claude Code 的 MCP (Model Context Protocol) 协议。
吴鑫： 大家现在就可以上手玩。我们在 OpenRouter 上提供了限免额度（Step 3.5 Flash-free）。
关于接入 MCP Tools 和 适配 Skills： 我们非常看重 Skills。现场演示里，我把一个 AI Daily News 的 Skill 扔给了 Claude Code 框架下的 Step 3.5 Flash。 大家可以看到，它自己去 GitHub 拉取了最新的 Skill 代码，安装依赖，然后开始搜索今天的新闻。
关于“翻车”： 刚才有个报错，Rate Limit Exceeded。这不是模型挂了，是因为它生成速度太快，两个请求之间的时间间隔太短，触发了 OpenRouter 的 RPM（每分钟请求数）限制。 另外，大家可能会发现 Step 3.5 Flash 有时候 思维链（CoT）特别长。这是我们已知的一个 Issue。现在的 Token Efficiency（效率）还不够高，虽然生成得快，但我们希望它能更精简。这是下一版优化的首要目标——在缩短 CoT 的同时，保持住智能水平。
五、 主创团队核心 QA 实录
Q1：为了追求 350 TPS 的速度，是否牺牲了工具调用的成功率？
吴鑫：从原理上讲，速度快并不会降低成功率。但在工程细节上，确实会有影响。 刚才提到的 MTP 技术，因为推得太快，导致很多下游的解析器（Parser）跟不上。比如我们把 output 分为 thinking content 和 tool call，流式传输时如果切分太快，传统的解析逻辑会出错。这些 Bug 我们基本上都在上线后 24 小时内修复了。 但反过来看，我们的目标是，利用高 TPS 带来的时间冗余，让 Agent 有机会进行 Self-Correction（自修正）。错了没关系，因为它快，它有时间再试一次。
Q2：对于不同编程语言的支持有差异吗？
吴鑫：这是一个犀利的问题。 坦白讲，我们在 Python 上花了很多功夫。内部指标显示，Python 的支持是最好的，因为我们在 Midi-train 阶段对脚本式语言做了更充分的训练和压缩。 对于 C# 或者 C++，虽然也支持，但目前确实存在一些 Noise，我们正在持续补强多语言的原子能力。
Q3：关于 Test-time Scaling（测试时计算扩展）？
吴鑫：我们的 Parallel Scaling（并行推理）技术是和 Flash 模型绝配的。 即使 Candidate 里没有正确答案，经过并行推理 + Controller 的反思，模型也可能最终推理出正确答案。 因为 Flash 足够快、成本足够低，我们才敢在 Test-time 耗费更多的 Token 去换取更高的智能上限。
Q4：对于复杂的业务系统开发，如何与 Step 3.5 Flash 协作？
吴鑫：我们把能力分为“0 到 1”和“1 到 100”。你可以先描述需求，补充技术栈，让 Step 3.5 Flash 生成一个初版框架（0 到 1），然后在此基础上通过不断的 Prompt 指令进行细节更新（1 到 100）。你描述得越详细，它生成得越好。
在复杂任务中，如果你想让模型不只是编程，还要像数字员工一样操作办公软件，可以给它配置 MCP 工具（比如操作聊天软件、Excel 的工具）。模型理解了这些工具后，就能在长程任务中去编排和使用它们。
Q5：Step 3.5 Flash 是否支持多模态输入？
吴鑫：目前的 Flash 版本是一个纯文本模型 。如果涉及到多模态输入，系统会自动路由到我们之前的多模态模型。 我们专注于把 Text-to-Action 做到极致，而视觉理解则通过 MCP 工具（如 Step Search 或外挂视觉工具）来解决。
最后：目前 Step 3.5 Flash 已上线官网及 OpenRouter 限免。相关的 Technical Report 和黑客松活动（如汤泉 Hackathon）也将陆续推出。同时，也欢迎大家加入我们阶跃星辰。
这只是 Step 系列的一个开始，后续一定会有 3.6、4.0，甚至更强的版本。但在此刻，这就是我们能拿出的，最适合 Agent 开发者的基座模型。
写在最后
整场直播下来，最大的感受就是：Step 3.5 Flash 真的很快。
快到还没有介绍完，它就已经写完了。快到触发了 API 的 Rate Limit，快到可以支撑 Multi-Agent 并行协作。
但更重要的是，这个“快”不是牺牲智能换来的。从榜单分数到实际 Case，Step 3.5 Flash 在保持高智能密度的同时，做到了极致的推理速度。
在 Agent 时代，推理速度就是生产力。
如果你也想体验这种“眼睛跟不上”的速度，可以去 OpenRouter 上免费试用 Step 3.5 Flash。如果你想深入了解技术细节，可以关注阶跃星辰即将发布的 Tech Report 和后续的 AMA 活动。
开源是一种表态，工程是一种信仰。但速度，才是 Agent 时代的入场券。
一起“点赞”三连↓
