StepFun Step 5 Preview 开放权重将智能体模型竞赛推向部署能力

StepFun 于 10 月 15 日以两种主要格式发布 Step 5 Preview 开放权重，将 API 预览版变成开发者可以检查和部署的模型。该公司在 Hugging Face 和 ModelScope 发布了 BF16 与 FP8 检查点，并同步提供代码和详细技术博客。

这一动作之所以重要，是因为 Step 5 Preview 并非面向本地运行的轻量级模型。它总参数量约为 6000 亿，每个 token 激活 270 亿参数，并支持长达 100 万 token 的上下文窗口。要以完整规模运行它，需要数据中心级硬件、分布式推理和审慎的内存管理。

因此，这次发布形成了一种颇有意义的张力。StepFun 让模型权重变得可获取，但实际控制权仍受基础设施限制。真正的竞赛不只是开放权重与封闭 API 的对抗，而是团队能否将可检查的权重转化为可靠、可负担且能完成长任务的智能体。

这给其他争夺同类智能体工作负载的开放权重开发者带来压力，包括 DeepSeek、Qwen 和 Kimi。同时，它也为 vLLM、SGLang、量化、上下文管理和多节点服务等基础设施团队提供了一项高要求的新测试。

StepFun Step 5 Preview 开放权重现已可部署

10 月的发布让 Step 5 Preview 从托管服务承诺，转变为具备条件的团队可在自主控制下运行的模型。

StepFun 最初将该模型定位为面向智能体工作的旗舰系统，并承诺会在 API 初步可用后发布开放权重。10 月 15 日，该公司兑现承诺，发布了模型文件和部署说明。

官方 FP8 检查点旨在降低部署如此大型模型的内存负担。FP8 以八位浮点精度存储大量模型数值，相较 BF16 可减少内存使用，同时保留比整数量化更宽的数值范围。

StepFun 还发布了独立的 BF16 检查点。BF16 使用 16 位浮点数值，通常为评估、适配和数值比较提供更保守的参考。

这些文件也通过 ModelScope 发布页面提供，为开发者增加了一条分发渠道。这对基础设施或下载流程已依赖 ModelScope 的团队尤其重要。

两种检查点之间的差异是运行层面的，而非表面差异。StepFun 警告称，设置 BF16 运行时选项并不会将 FP8 权重转换为 BF16。团队必须下载与其计划部署精度相匹配的检查点。

模型卡提供了 vLLM、SGLang 和独立 Transformers 实现的路径。vLLM 和 SGLang 都能通过兼容 OpenAI 的接口暴露模型，因此现有应用无需采用全新的请求格式即可连接。

部署仍需要大量工程投入。StepFun 的参考配置将 FP8 检查点部署在四张 Nvidia B300 GPU 或八张 H200 GPU 上。BF16 配置则使用八张 B300 GPU，或由 16 张 H200 GPU 构成的两个节点。

这些示例描述的是起始配置，并不保证适用于每一种工作负载的容量。一次 100 万 token 的请求还需要为键值缓存、运行时缓冲区和并发序列预留内存。权重只是系统资源占用的一部分。

BF16 文档还包含另一项重要说明。StepFun 表示，其完整的分片 BF16 转换与生成流程尚未经过完整的端到端验证。该公司已验证检查点形状、较小规模的转换测试，以及完整模型的流式权重推理。

这一说明让此次发布更具可信度，而非相反。开放部署会暴露托管 API 可能掩盖的工具链不完善和扩展限制，也让外部工程师能够复现故障并提出修复方案。

因此，此次发布意义重大，但并非毫无摩擦。开发者如今已获得模型工件、服务示例和架构说明，但仍需构建能够实际使用它们的运行环境。

StepFun 为何打造更窄、更深的智能体模型

StepFun 的核心押注是：在长时间、高工具调用频率的智能体会话中，深层内部计算比单纯增加活跃参数量更重要。

Step 5 Preview 使用稀疏混合专家架构。在这种设计中，网络包含许多专门化参数组，但路由器只会为每个 token 激活其中一部分。

该模型总参数量约为 6000 亿，每个 token 激活 270 亿参数。稀疏激活旨在保留广泛能力，而不必在每一步调用整个网络，但这并不能消除存储和通信完整模型的负担。

StepFun 将该模型描述为“窄而深”。它包含 92 个 transformer block，在输入与输出之间增加了更多顺序处理阶段。该公司认为，深度有助于在长提示处理过程中进行潜在的多步推理。

这一设计瞄准了软件智能体的一个棘手特征。编程智能体会反复读取文件、接收工具结果、编辑代码、运行测试，并更新计划。其大部分推理必须在处理累积上下文时完成，而不只是通过可见的推理文本。

更深的网络让表征能够经过更多层的发展。不过，深度也使优化更加困难。StepFun 报告称，模型扩展过程中出现了数值爆炸和梯度尖峰。

该公司的技术架构介绍了三项应对措施：以 FP32 保留隐藏状态及其梯度、以 FP32 存储归一化缩放系数，以及引入细粒度梯度裁剪。

据 StepFun 称，FP32 隐藏状态将极端激活峰值降低了近一个数量级。该公司表示，与传统 BF16 处理相比，这一改变仅增加了少量训练开销。

归一化调整针对接近负一的数值，因为此时 BF16 精度可能不足。StepFun 发现，部分通道会在完全受抑制与重新开启之间交替，导致输出行为不稳定。

其梯度裁剪每层仅针对 0.00004% 的梯度数值。StepFun 表示，这些罕见数值可能在中间层间被放大并形成尖峰，而裁剪它们据称能带来更平滑的收敛。

这些是公司报告的训练观察结果，并非独立复现。但它们的加入使这篇博客比单纯的基准测试公告更有参考价值。研究人员可以将这些技术与其他深层模型中观察到的行为进行比较。

注意力设计构成了架构论证的另一半。Step 5 Preview 将三层高效注意力层与一层稀疏全注意力层交错组合。高效层采用门控滑动窗口注意力，限制每个 token 所检查的近期区域。

全注意力路径采用 StepFun 所称的 Sparse GQA。分组查询注意力，即 GQA，可让多个查询头共享键和值表征。StepFun 增加了一套选择机制，用于检索相关历史块，而非读取完整序列。

其索引器将 token 合并为每块八个 token。模型选择 4,096 token 的预算，对应 512 个块。StepFun 表示，块合并将索引和 Top-K 选择成本降低了八倍。

这一机制解决了一个具体问题。随着序列变长，标准全注意力的成本会持续上升，因为 token 需要与不断扩展的历史进行比较。在 100 万 token 时，这一成本会变得难以承受。

稀疏选择减少了每次操作所检查的历史范围。然而，任何选择器都有可能遗漏后来证明重要的信息。StepFun 报告称，其所选配置的 token 覆盖率为 78.06%，而更精细的参考配置为 79.09%。

这一较小的报告差异支持该设计，但并不能决定应用质量。代码库结构、嘈杂的工具输出，以及相隔数十万 token 的细节，都可能暴露不同的检索失效问题。

这套架构最好被理解为一种带有取舍的效率机制。它让超长上下文更具可行性，同时也引入了一个其决策需要测试的新组件。

开放权重遇上真实智能体基础设施的成本

StepFun 降低了检查和修改模型的门槛，但硬件要求仍让常规自托管超出大多数个人开发者的能力范围。

开放权重提供了 API 不具备的能力。团队可以检查配置文件、控制服务日志、选择提示词的处理位置，并在不将专有数据外发的情况下测试模型行为。

研究人员可以在不同解码设置下评估同一检查点。基础设施工程师可以修改内核、尝试并行化，或构建新的量化方案。受监管组织则可以将推理置于受控环境内。

这些优势对智能体系统很重要，因为智能体会接触敏感材料。编程智能体可以读取私有代码库和部署配置；业务智能体可以处理合同、内部报告、客户记录和财务模型。

自托管可为这些工作流提供更强的运营控制，但并不会自动让它们变得安全。组织仍需要访问规则、审计轨迹、工具限制、提示注入防御，以及针对非预期操作的监控。

第一个限制是内存。StepFun 的参考路径将 FP8 推理分布在四张 B300 GPU 或八张 H200 GPU 上。BF16 则将要求扩展至八张 B300 GPU，或分布在两个节点上的 16 张 H200 GPU。

张量并行将模型计算分配到多个设备上；专家并行分发混合专家组件；数据并行可以支持更高的请求吞吐量，尽管它会复制或重新分配服务工作负载的不同部分。

每种方法都会引入通信成本。性能取决于互连带宽、集合操作、内核支持、批处理，以及被激活专家的确切模式。一条能够成功启动的命令并不保证高效的生产服务。

上下文窗口带来了另一项限制。StepFun 在服务示例中列出输入和输出合计 1,048,576 token 的上限。实际可用长度取决于为键值缓存预留的内存。

键值缓存会存储早期 token 的注意力信息，避免模型为每个新 token 重新计算整个序列。在极端长度下，该缓存会成为主要的内存消耗来源。

团队必须在上下文长度、并发量、延迟和输出容量之间进行选择。服务一个超长会话可能会挤占许多较小请求；更高的并发量则可能迫使系统缩短最大序列长度，或采用更激进的缓存压缩。

StepFun 表示，MTP-3 预测头可带来约 30% 的端到端速度提升。多 token 预测，即 MTP，使系统能够起草多个可能的未来 token，并同时验证它们。

该公司还称，在保持 BF16 质量的同时，原生 FP8 混合专家执行可带来约 20% 的额外性能提升。这些说法仍需在不同硬件、提示词、并发水平和智能体框架中由外部机构复现验证。

StepFun 还表示，协同专家并行、CPU 缓存卸载、压缩权重存储和 FP8 缓存训练可将有效缓存容量扩大八至十二倍。这一区间反映的是完整的系统栈，而非某一项简单的模型设置。

因此，实际的竞争对手并非某一家特定公司，而是权重可用性与可部署智能体基础设施之间的鸿沟。StepFun 开放了第一层，而将第二层的难题留给了采购方解决。

这一鸿沟也为托管服务提供商留下了竞争空间。封闭式 API 提供即时访问、可预测的集成和外包运维。开放权重系统则提供控制权、定制能力和本地数据处理，但需要投入更多资本和工程资源。

大型企业和推理服务提供商最有可能成为首批自行托管者。较小团队仍可使用托管端点，同时研究模型卡并等待社区推出压缩版本。

此次发布也为开发者提供了更清晰的采购框架。他们可以将模型质量与服务成本分开评估，再根据自身工作负载衡量两者。再高的基准测试分数，也无法弥补不可接受的延迟或基础设施成本。

基准测试主张仍需独立验证

Step 5 Preview 的发布使严肃评估成为可能，但由公司自行挑选的基准测试无法单独证明其在生产环境中的可靠性。

StepFun 将该模型定位于软件工程、长时程执行、专业知识工作和金融领域。这些类别与高价值智能体工作负载相契合，在这类场景中，一项任务的完成往往比对话流畅度更重要。

该公司表示，Step 5 Preview 在代码生成、漏洞修复、重构、文档编写和性能优化方面表现强劲。其模型概览还展示了旨在体现智能体持续行为能力的长时间运行示例。

开放检查点使这些主张得以验证。独立团队可以运行固定测试框架、保留完整记录、比较解码设置，并公布失败案例。这一过程比比较托管聊天界面的截图更具参考价值。

然而，基准测试的可复现性仍可能面临困难。智能体得分取决于围绕模型构建的脚手架，包括可用工具、提示模板、重试策略、时间限制和上下文压缩方式。

模型还可能受益于基准测试特定的数据或评估器弱点。StepFun 公开讨论了模型投机取巧问题，即智能体利用任务规范的漏洞，却没有真正解决预期问题。据称，其数据管道包含反投机取巧检查。

这一承认指出了正确的问题，但并不能证明这些检查已足够充分。外部评估者应检验成功运行是否产生了正确、可维护的输出，而不是仅仅通过范围狭窄的测试。

长时程评估还带来了额外问题。智能体或许能完成孤立的代码仓库任务，却可能在持续数小时的工作中逐渐偏离目标。它可能重复操作、覆盖正确修改、误读工具结果，或在上下文压缩后丢失原有假设。

StepFun 的强化学习系统聚焦于时长、深度和区分度。时长衡量持续工作的能力，深度涵盖累积的状态变化，区分度则衡量任务能否区分成功与失败的 rollout。

该公司称，其已在软件工程、科学推理、机器学习研究和专业工作领域构建了超过一百万个具有挑战性且可验证的环境。该数字描述的是构建出的环境，而非独特的生产部署。

StepFun 还称，端到端 rollout 的样本丢失率低于 1%。样本丢失很重要，因为基础设施故障往往会剔除耗时最长、难度最高的轨迹，从而悄然让训练偏向更容易的任务。

这些细节表明，StepFun 将智能体训练视为系统工程问题。然而，这些证据仍来自模型开发者。独立团队应在已声明的硬件、框架版本和评估预算条件下复现结果。

许可证同样值得仔细审查。Hugging Face 将该仓库许可证标记为“other”，而 StepFun 将其 Model License 1.0 描述为 Apache-2.0 风格。该许可证增加了针对模型使用、修改和分发的署名及商业条件。

因此，“开放权重”是准确的描述。但这并不意味着每种使用方式都享有标准开源软件许可证通常赋予的同等、不受限制的权限。

组织在分发衍生版本、提供商业服务或将模型嵌入客户产品前，应完整阅读许可证。权重访问权与法律许可彼此相关，但并不完全相同。

安全测试同样重要。一个长时间运行的智能体可以访问更多文件、发出更多工具调用，并累积更多出错机会。更强的持续能力会同时提高实用性和错误决策的潜在影响。

因此，应分阶段评估该模型。团队可以先从只读任务、受控代码仓库和合成记录开始，随后衡量权限违规、恢复行为、工具误用以及缺乏证据支持的改动。

开发者还应比较 FP8 和 BF16 的输出。StepFun 表示原生 FP8 可匹配 BF16 的质量，但微小差异可能会在长轨迹中不断累积。一次工具选择的改变，就可能重定向之后的每一步。

开放发布使这些实验成为可能，但并不会默认带来有利的答案。

接下来的三个信号将决定 Step 5 Preview 的影响力

只有在权重发布之后出现独立结果、更广泛的服务支持和持续的真实世界采用，这次发布才会真正产生重大影响。

第一个信号是可复现的智能体评估。独立研究者应针对代码编写、文档分析、金融和长上下文检索，对 Step 5 Preview 进行测试，并提供完整执行日志。

最有价值的比较将保持智能体脚手架不变。模型应获得相同的工具、预算、提示词和重试限制。评估者还应披露硬件、精度、框架版本和上下文设置。

强有力的独立结果将支持 StepFun 的核心主张：狭而深的架构有助于长时程工作。若模型在公司环境之外出现大幅下滑，这一论点将被削弱，关注点也会转向脚手架优势。

第二个信号是基础设施成熟度。StepFun 已为 vLLM、SGLang 和独立 Transformers 提供启动路径。下一项考验是，这些路径能否变得更易用、更快且更具可移植性。

团队应关注稳定的上游支持、更多 GPU 配置、优化内核和由独立社区维护的量化版本。他们还应关注 BF16 分片文件工作流是否获得完整验证。

成熟的部署栈将缩小可下载权重与可用服务之间的距离。持续的部署失败则会让该模型集中在少数专业运营者手中。

第三个信号是在真实智能体产品中的采用情况。仓库 star 数和模型下载量可以反映好奇心，但无法说明用户是否愿意将关键工作交给该模型。

有意义的采用将通过生产集成、重复使用、公开案例研究和可量化的任务完成情况体现出来。它还会带来关于延迟、故障恢复和基础设施利用率的详细报告。

这正是竞争对手面临最明确压力的地方。DeepSeek、Qwen、Kimi 和其他开放权重开发者，正在争夺那些希望保持控制权、又不愿牺牲前沿级智能体性能的开发者。

StepFun 的发布为这一群体提供了又一种值得严肃评估的架构。它也提高了人们对技术披露的期待。如今，如果没有服务说明、精度版本、架构细节和可复现评估指南，一个检查点看起来已不再完整。

封闭模型提供商则面临不同考验。他们仍可通过可靠性、安全系统、生态系统集成和托管基础设施保持领先。他们必须证明，API 的便利性为何能胜过开放权重所提供的控制能力和可检查性。

对开发者而言，眼下应采取的行动是有纪律的测试，而不是全面迁移。选择一个具有代表性的任务，保留其完整工作上下文，并比较成功率、延迟和人工干预频率。

长时间的智能体评估会产生大量日志、决策记录和源材料。可搜索的 AI 知识库可以帮助团队保留这些证据，而不是将结果简化为一个最终分数。

因此，StepFun Step 5 Preview 开放权重发布只是一个起点。这些文件解决的是该公司是否愿意提供访问权的问题，却无法回答该架构能否在独立条件下胜出。

未来几个月，请关注谁能复现这些结果、谁能高效运营该模型，以及谁会在初步测试后继续使用它。这些信号将揭示 Step 5 Preview 究竟会成为基础设施，还是仍只是一份令人印象深刻的检查点。