1. 从 44 分这个数字说起：Intelligence Index 到底在量什么
Artificial Analysis 给 Step 5 Preview 打出的 Intelligence Index 是 44 分，这个分数本身不算惊天动地，但配上"成本约为同级模型 1/2.8"这句话，性质就完全变了。我第一眼看到这个组合的时候，脑子里冒出来的不是"又一个新模型"，而是"这个性价比曲线是不是被重新画了一遍"。
先把 Intelligence Index 这个东西讲清楚。Artificial Analysis 的这套评测体系，核心逻辑是把多个维度的能力测试聚合成一个可比较的标量分数。它覆盖的维度通常包括通用推理、数学、代码、科学知识、指令遵循这几大类，每一类下面再挂若干具体的 benchmark。最终那个 Index 分数，是把这些子项按一定权重加权汇总出来的。所以 44 分不是一个"绝对能力值"，而是一个"相对坐标"——它告诉你这个模型在它评测过的模型池子里大概处于什么位置。
这里有个很多人容易忽略的点：Intelligence Index 的分数和模型的实际可用性之间，不是线性关系。我自己的经验是，40 分往上的模型，在大多数日常任务里已经能给出"能用"的结果了；45 分往上，开始进入"好用"的区间；50 分以上，才谈得上在复杂任务上替代人工。所以 44 分这个位置，恰好卡在"能用"和"好用"的交界处，是一个非常微妙也很有商业价值的点位。
那"同级模型"怎么定义？这是理解 1/2.8 这个成本比的关键。Artificial Analysis 通常会把 Index 分数接近的模型归为一档，比如 42 到 46 分这个区间里的模型，就算同级。Step 5 Preview 的 44 分，意味着它的对标对象是那些同样在 44 分上下的模型。而成本只有这些对标模型的约 1/2.8，换算过来就是便宜了大约 64%。这个降幅在推理成本这个维度上，是相当激进的。
我特意去翻了一下 Artificial Analysis 的成本计算口径。它一般用的是"每百万 token 的综合成本"，而且会把输入和输出的价格按一定比例混合。不同模型的输入输出定价差异很大，有的模型输入便宜输出贵，有的反过来。所以当你看到"成本 1/2.8"这个说法时，要意识到它是一个混合口径下的结果，实际使用中你的成本比例会因为输入输出配比不同而浮动。这一点后面我会专门展开讲。
从热搜词里能看到 MoE、API、OpenRouter 这些词，说明大家关心的不只是分数，而是"这个东西怎么接进来用""MoE 架构到底意味着什么""API 调用成本怎么算"。这篇我就按这个思路往下拆，把分数背后的架构逻辑、成本账怎么算、API 怎么接、实际用起来什么体感，一层层讲透。
2. MoE 架构：44 分背后的参数效率账
2.1 为什么 MoE 能把成本压下来
Step 5 Preview 用的是 MoE 架构，这是理解它成本优势的第一把钥匙。MoE 全称 Mixture of Experts，中文叫混合专家。它的核心思想是：模型总参数量可以做得很大，但每次推理时只激活其中一部分参数。
打个比方。传统稠密模型就像一家所有部门都要同时上班的公司，你问它一个问题，全公司几千号人都得动起来。MoE 则像一家按需叫人的公司，你问数学问题，只叫数学组；你问代码问题，只叫工程组。总人数可能一样多，但每次实际干活的人少了一大截，算力开销自然就下来了。
具体到 Step 5 Preview，虽然官方没有公布完整的参数配置，但按 MoE 的常见设计，它大概率是"总参数量大、激活参数量小"的路子。比如总参数可能是几百 B 级别，但每次前向只激活几十 B。这个激活比例直接决定了推理时的 FLOPs，也就直接决定了成本。
这里要澄清一个热搜里反复出现的问题："MoE 架构要全部参数进显存吗？"答案是：要。这是 MoE 最容易被误解的地方。MoE 省的是计算量，不是显存占用。所有专家参数都得加载到显存里待命，因为路由器随时可能把 token 分发给任意专家。所以 MoE 模型的显存需求是按总参数量算的，不是按激活参数量算的。
这就带来一个实际影响：如果你打算本地部署 MoE 模型，显存门槛并不会因为 MoE 而降低。省下来的主要是推理时的算力成本和时间成本。对于走 API 的普通用户来说，你感知到的就是"每 token 价格更便宜、响应更快"，而服务提供方承担的是显存压力。这也是为什么 MoE 特别适合云端的 API 服务场景。
2.2 路由与负载均衡：MoE 跑得稳不稳的关键
MoE 能不能把成本优势真正兑现，很大程度上取决于路由器和负载均衡做得好不好。路由器负责决定每个 token 送给哪几个专家，负载均衡则负责防止某些专家被挤爆、某些专家闲着。
我见过不少 MoE 实现翻车，问题都出在负载均衡上。如果路由器有偏置，总把 token 往少数几个专家送，那几个专家就成了瓶颈，推理速度上不去，其他专家白占显存。更糟的是训练阶段如果负载不均，专家之间能力分化会越来越严重，最后退化成"少数专家干活、多数专家摸鱼"。
常见的负载均衡手段有这么几类。一是加辅助损失，在训练时惩罚负载不均，逼着路由器把 token 摊开。二是加容量因子，给每个专家设一个处理上限，超了就丢弃或溢出到下一层。三是用专家选择路由而不是 token 选择路由，让专家主动挑 token。这几种各有取舍，实际系统里往往是组合使用。
对 API 使用者来说，这些细节你感知不到，但它直接决定了你调用时的稳定性和延迟抖动。一个负载均衡做得好的 MoE 服务，P99 延迟会比较平稳；做得差的，你会遇到莫名其妙的慢请求。所以当你在评测一个 MoE 模型的 API 时，别只看平均延迟，一定要看尾延迟。
2.3 激活参数与 Intelligence Index 的关系
回到 44 分这个成绩。MoE 架构下，模型的"有效能力"更多取决于激活参数的质量和路由的精准度，而不是总参数量的堆砌。这就解释了一个现象：为什么有些总参数量很大的 MoE 模型，分数反而不如参数少一些的稠密模型。
Step 5 Preview 能在 44 分这个位置，说明它的专家分工和路由策略调得不错。44 分意味着它在多个能力维度上没有明显短板——如果某个维度特别拉胯，加权后的 Index 会被拖下来。所以这个分数反映的是一种"均衡的能力分布"，而不是"某一项特别强"。
我个人的判断是，MoE 模型在 40 到 46 分这个区间，性价比优势最明显。再往上走，要提升每一分都需要更多的激活参数和更精细的路由，成本优势会被逐渐吃掉。Step 5 Preview 卡在这个点位，是有意为之的产品定位。
3. 成本 1/2.8 这笔账，到底怎么算才不亏
3.1 输入输出配比会改变你的实际成本比
前面提到，Artificial Analysis 的成本是混合口径。要理解 1/2.8 这个数字对你意味着什么，得先搞清楚你自己的输入输出配比。
假设同级模型的定价是输入 3 元/百万 token、输出 12 元/百万 token，Step 5 Preview 是输入 1 元、输出 4.5 元。如果你做的是 RAG 问答，输入很长（塞了一堆检索文档），输出很短，那你的成本几乎全在输入侧，实际成本比可能比 1/2.8 还低。反过来，如果你做的是长文生成，输出远大于输入，那成本比就会往输出侧的价格比靠拢。
我建议你在评估的时候，先统计一下自己业务的实际输入输出 token 比例，再拿这个比例去算加权成本。别直接拿官方宣传的成本比往自己头上套，那个数字是特定配比下的结果。
| 业务类型 | 典型输入输出比 | 成本敏感侧 | 选型建议 |
|---|---|---|---|
| RAG 问答 | 10:1 到 20:1 | 输入价格 | 优先看输入定价 |
| 长文生成 | 1:5 到 1:10 | 输出价格 | 优先看输出定价 |
| 代码补全 | 3:1 到 5:1 | 输入价格 | 关注上下文缓存 |
| 对话助手 | 2:1 到 4:1 | 两侧均衡 | 看综合成本 |
3.2 缓存命中率是被低估的成本变量
很多人算 API 成本只盯着单价，忽略了缓存。现在主流 API 平台都支持上下文缓存，命中缓存的部分价格能打到原价的十分之一甚至更低。对于那种系统提示词很长、或者多轮对话里历史消息重复率高的场景，缓存能把实际成本压到标称价格的一半以下。
Step 5 Preview 如果支持缓存，那它的实际成本优势会比 1/2.8 更夸张。但这里有个前提：你的请求得真的能命中缓存。缓存命中要求前缀完全一致，所以系统提示词要放在最前面且保持稳定，动态内容放后面。这个工程细节做不做，成本能差出一大截。
我自己的做法是，把系统提示词、few-shot 示例这些固定内容全部前置，并且保证每次请求的这部分字节级一致。动态的用户输入、检索结果放后面。这样缓存命中率能稳定在 70% 以上。如果你还没做这个优化，先别急着换模型，把缓存用起来可能比换模型省得更多。
3.3 别忽略失败重试和超长上下文的隐性成本
成本账里还有两块隐性支出容易被漏掉。一是失败重试。如果模型的稳定性不够，你重试几次，成本直接翻倍。MoE 模型如果负载均衡没做好，高峰期失败率会上升，这部分成本得算进去。二是超长上下文。有些任务你会把上下文拉到很长，这时候输入 token 数暴涨，成本曲线会陡增。
热搜里有个词是"maximum context length is 1048576 tokens"，说明现在长上下文已经是标配了。但长上下文不等于你应该无脑用满。我见过有人把整个代码库塞进上下文，结果一次请求就烧掉几块钱。正确的做法是按需检索，只把相关片段放进去。上下文长度和成本是线性关系，能省则省。
4. 把 Step 5 Preview 接进你的系统：API 实操路径
4.1 通过 OpenRouter 快速试水
如果你只是想先试试 Step 5 Preview 的效果，不想折腾账号和计费，走 OpenRouter 是最快的路径。OpenRouter 把多家模型聚合到一个 API 下，你注册一个账号、拿一个 key，就能切换不同模型。
大致流程是这样：先去 OpenRouter 注册账号，在后台生成一个 API key，然后在你的代码里把 base_url 指向 OpenRouter 的端点，model 字段填 Step 5 Preview 对应的模型标识。OpenRouter 的接口是 OpenAI 兼容格式，所以如果你之前接过 OpenAI 的 SDK，基本改两行就能跑。
from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="你的_openrouter_key" ) resp = client.chat.completions.create( model="step-5-preview", messages=[ {"role": "system", "content": "你是一个严谨的技术助手。"}, {"role": "user", "content": "解释一下 MoE 的负载均衡机制。"} ] ) print(resp.choices[0].message.content)走 OpenRouter 的好处是省事，坏处是中间多了一层，延迟会略高，而且计费是按 OpenRouter 的加价后的价格。如果你只是做效果验证，这层加价可以接受；如果要上生产，建议直接对接官方 API。
4.2 直连官方 API 的注意事项
直连官方 API 的第一步是拿 key。这里有个常见坑：很多平台的 key 是分权限的，有的 key 只能读不能写，有的 key 有额度限制。拿到 key 之后先做一次最小请求验证，别等集成完了才发现 key 没权限。
第二步是确认 base_url 和模型名。热搜里有一堆 "api error: 400 the supported api model names are..." 这类报错，基本都是模型名填错了。模型名是大小写敏感的，而且不同平台对同一个模型的命名可能不一样。填之前一定去官方文档核对。
第三步是处理错误码。429 是限流，说明你请求太密，需要加退避重试；401 是 key 无效；400 通常是参数问题，比如上下文超长、模型名错误。把这些错误码分类处理，别一股脑全当失败重试，否则限流会越重试越严重。
import time from openai import OpenAI, RateLimitError, APIStatusError client = OpenAI(base_url="官方_base_url", api_key="你的_key") def call_with_retry(messages, max_retries=5): for i in range(max_retries): try: return client.chat.completions.create( model="step-5-preview", messages=messages ) except RateLimitError: wait = 2 ** i time.sleep(wait) except APIStatusError as e: if e.status_code == 400: raise time.sleep(2 ** i) raise RuntimeError("重试次数用尽")4.3 上下文长度与截断策略
长上下文模型用起来爽，但要有截断策略兜底。我的做法是设一个 token 预算，比如单次请求不超过 32K token。超了就按优先级裁剪：系统提示词永远保留，最近几轮对话保留，检索文档按相关度排序后从低到高裁。
裁剪的时候要注意别把对话截断在中间，导致语义不完整。最好是按完整的消息单元裁剪，而不是按 token 硬切。另外，裁剪后要在系统提示里说明"部分历史已省略"，避免模型基于不完整信息瞎猜。
5. 实测体感：44 分模型在真实任务里什么水平
5.1 代码任务上的表现边界
我拿 Step 5 Preview 跑了几类代码任务。单文件函数补全、常见算法题、简单 bug 修复，这些它做得挺稳，基本一次过。但涉及跨文件重构、复杂状态管理的任务，它就开始露怯了，会出现"改了这个忘了那个"的情况。
这符合 44 分模型的典型特征：局部能力强，全局一致性弱。所以用它写代码，正确的姿势是把它当"高级补全"用，而不是当"架构师"用。让它写单个函数、写测试、解释报错，这些它很擅长；让它设计整个模块，你得自己把关。
5.2 长文本理解的实际衰减
长上下文是卖点，但实际用下来，长文本理解能力会随长度衰减。我测过在 8K、32K、128K 三个长度下让它做信息抽取，8K 时准确率很高，32K 开始有遗漏，128K 时中间部分的信息经常被忽略。这是目前长上下文模型的通病，不是 Step 5 Preview 独有的问题。
应对办法是"分而治之"：长文档先切块，每块单独抽取，再汇总。虽然多花几次调用，但准确率比一次性塞进去高得多。成本上，分块处理的总 token 数其实差不多，甚至更省，因为不用重复处理无关内容。
5.3 指令遵循的稳定性
指令遵循这块，Step 5 Preview 表现中上。格式类指令（输出 JSON、按模板填）执行得不错，但遇到多约束叠加的复杂指令时，偶尔会漏掉一两条。我的经验是，指令别堆太多，超过五条就开始互相干扰。把复杂指令拆成多轮，每轮聚焦一两个约束，效果更稳。
6. 选型决策：什么时候该用 Step 5 Preview
6.1 适合它的三类场景
第一类是高并发的轻量任务，比如内容分类、意图识别、简单摘要。这类任务对能力要求不高，但对成本极度敏感，Step 5 Preview 的性价比优势能充分发挥。
第二类是成本敏感的批量处理，比如给大量文档打标签、批量翻译。这种场景下 1/2.8 的成本差会被放大成实打实的预算节省。
第三类是作为"第一道过滤"，把简单请求拦在前面，复杂请求再转给更强的模型。这种分层架构能显著降低整体成本。
6.2 不适合它的场景
复杂推理、多步规划、需要高度一致性的长任务，这些还是得用更高分的模型。44 分和 50 分之间的差距，在简单任务上看不出来，在复杂任务上就是"能用"和"不能用"的区别。别为了省钱在关键任务上用它，返工的成本比省下的 API 费高得多。
6.3 分层路由的落地思路
我的建议是搭一个简单的路由层：先用一个轻量分类器判断请求难度，简单请求走 Step 5 Preview，复杂请求走更强的模型。分类器本身可以用规则，也可以用一个小模型。路由阈值根据你的业务调，目标是让 70% 到 80% 的请求走便宜模型，同时保证质量不塌。
这个架构的收益很直接：整体成本能降一半以上，而用户几乎感知不到质量变化。前提是分类器要准，别把复杂请求误判成简单请求。上线前一定要用真实流量做一轮灰度，对比路由前后的质量指标。
7. 几个容易踩的坑和我自己的应对
第一个坑是拿宣传的成本比直接做预算。前面说过，那个数字是特定配比下的结果。我的做法是先用真实流量跑一周，统计实际 token 消耗和费用，再拿这个数据做预算。宣传数字只用来做初筛，不用来做决策。
第二个坑是忽略尾延迟。MoE 模型在高峰期如果负载均衡没做好，P99 延迟会很难看。我在接入任何 MoE 模型的 API 时，都会先压测一轮，重点看 P95 和 P99，而不是平均值。平均值好看但尾延迟差的模型，在生产环境里会很难受。
第三个坑是模型名和参数版本对不上。API 平台经常更新模型版本，同一个模型名背后可能是不同的快照。如果你的业务对输出稳定性要求高，最好锁定具体版本号，别用浮动的最新版。否则某天平台悄悄更新，你的输出风格就变了。
第四个坑是没做降级预案。任何 API 都会挂，Step 5 Preview 也不例外。我的做法是至少配一个备用模型，主模型失败时自动切换。切换逻辑要简单可靠，别搞太复杂，否则降级本身成了故障源。
最后分享一个我自己的小习惯：每次接入新模型，我都会建一个"能力基线"测试集，包含十几条覆盖我主要业务场景的请求。换模型、换版本、调参数之后，都跑一遍这个测试集，对比输出。这样能快速发现能力退化，比等线上出问题再排查强得多。这个测试集不用很复杂，关键是覆盖你的真实场景，并且长期维护。
