阶跃星辰 Step Router 智能路由是什么：路由规则与计费口径
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
一句话说清：step-router-v1 不是一个模型，是阶跃星辰在 Step Plan 通道上放的一层调度器。你在 model 字段里填它，系统按这次请求的特征自动决定把活派给 deepseek-v4-pro 还是 step-3.7-flash——官方的说法是复杂推理与长链路决策交给前者，高频与结构化执行交给后者。它的价值不在于「更强」，而在于省掉你自己写分流逻辑那部分工程量。但代价也很实在：它只在 Step Plan 专用地址下存在，一旦被路由到 DeepSeek 引擎，请求字段的约束会跟你平时直调阶跃模型时不一样，而且这个「不一样」在 OpenAI 协议和 Anthropic 协议下还各自差一行。计费则是按实际命中的那个引擎算，再换算成 Step Plan 的额度消耗——也就是说，同一段代码这个月的花销取决于你的请求被判成了「复杂」还是「高频」，这件事你没法在请求里指定。
先搞清楚它路由的到底是什么
很多人第一眼把智能路由理解成「多模型集成」或者「自动选最便宜的」，都不太对。阶跃官方在产品页里把这两个引擎的分工写得很直白：deepseek-v4-pro 是决策引擎，面向复杂推理与长链路 Agent 决策；step-3.7-flash 是执行引擎，承载多数高频与结构化任务，并且是 step-router-v1 的默认执行模型。
注意「默认」这两个字。这意味着路由的基线是走 Flash，只有当请求被判定为复杂或高不确定性时才升级到 Pro。开发指南那边给的场景描述也是一致的口径：默认由 step-3.7-flash 承载多数请求以控制成本，复杂请求自动升级。所以你不该指望它「遇到难题就变强」——它的设计目标是在多数请求上省下来，在少数关键请求上不掉链子。
判定依据官方给了，但只给到类目这一层：按请求特征自动路由，参考消息轮数、输入量、工具数量。开发指南里还补了一句更具体的场景说明——多轮对话、含工具调用的请求，系统会在判定为复杂场景时调度 deepseek-v4-pro 以保障输出质量。
至于这三个特征各自的权重是多少、跨过哪条线才算复杂，官方文档里没有找到相关说明。这不是文档没写全的问题，更像是有意留白：路由策略本身是可以随时调整的，写死了反而绑住自己。对你的实际影响是，你没法通过「把消息数控制在某个数以内」来稳定地把成本压在 Flash 上。想要确定性，就别用路由，直接指定具体模型。
同样查不到的还有一条：能不能在请求里强制指定走某个引擎。官方只写了「无需在请求中额外指定」，没有给出任何反向的强制参数。按现有文档理解，路由决策权完全在服务端。
它只在 Step Plan 这条通道上存在
这是接入阶段第一个会栽的地方。产品页和开发指南都用 Note 框强调了同一件事：step-router-v1 仅在 Step Plan 通道可用，地址是 https://api.stepfun.com/step_plan/v1。
阶跃有两套 base URL，Step Plan 概览里专门提醒了要注意区别于普通 API 的 https://api.stepfun.com/v1。这两个地址长得太像，少了中间那一段 step_plan 你的请求不会静默降级，而是直接报错。阶跃自己在 Step Plan 常见问题里把「确认 Base URL 是否使用了专用地址」列为第三方工具接入报错的首要排查项，还特意标注了这是常见问题点；Claude Code 接入页在解释 model does not exist 这个报错时，也把「Base URL 指向错误接口」列为可能原因之一。同一个坑在两处文档里各写了一遍，说明踩的人确实不少。
还有一个 SDK 层面的细节，官方用 Warning 框单独拎出来过：Anthropic SDK 会自动在 base URL 后面拼 /v1/messages，所以用 Anthropic SDK 时 base URL 要写成 https://api.stepfun.com/step_plan，不带 /v1；用 OpenAI SDK 才是带 /v1 的完整形式。同一个通道，两个 SDK 写法不一样，复制粘贴时最容易串。
除此之外，切换到路由本身没有额外成本。官方在推理模型接入页里的原话是调用方式与直接调用完全一致，只把 model 字段换成 step-router-v1 就行。Chat Completion（OpenAI 协议）和 Messages（Anthropic 协议）两个端点都支持它。
命中 DeepSeek 引擎时，字段约束会变
这一节是全篇最值钱的部分，也是路由这个设计带来的真实副作用。
阶跃在 Chat Completion API 和 Messages API 两份文档里，各放了一节叫「Step Plan 通道：DeepSeek 引擎字段差异」。核心意思是：step-router-v1 的字段约束整体跟直调底层模型一致，但有几项例外。
OpenAI 协议那张表里列了四条。model 字段在这条通道下只接受 step-router-v1，填其他名称会返回 HTTP 400 加上 request_params_invalid。max_tokens 有独立的上限（具体数值以官方文档当前版本为准，官方写的是 250K）。messages 里的图像输入和文档输入不支持，用了会返回 unsupported_content_type。tools 里的 web_search 同样不支持，报的也是 unsupported_content_type。
Anthropic 协议那张表前四条基本对应，只是把「图像输入」的说法换成了 messages.content 中的图片块和文档块。但它比 OpenAI 协议那张表多了一行：output_config.effort 字段会被忽略。
这一行值得单独说。阶跃的推理模型是支持三档推理强度的，取值 low、medium、high，OpenAI 协议下走 reasoning_effort，Anthropic 协议下走 output_config.effort。也就是说，你在 Messages 协议里辛辛苦苦调的推理强度，到了路由这里是不生效的——这很合理，毕竟推理强度该多高本来就是路由要替你决定的事。
但对称的那个问题官方没有回答：OpenAI 协议下的 reasoning_effort 在 step-router-v1 上是什么行为？Chat Completion 那张差异表里没有这一行，官方文档里没有找到相关说明。两张表不对称到底是遗漏还是刻意，我判断不了，只能提醒你别默认它跟 Anthropic 协议一个行为。
另外有一条能力边界写在开发指南的 Note 框里，很容易被跳过：「本模型不支持图像识别」。这跟上面那两条内容类型限制是一回事——虽然 step-3.7-flash 本身原生支持图片与视频理解，但一旦你走的是路由，多模态输入这条路就是关的。有视觉需求的请求，别指望路由帮你转发。
工具调用这块倒是明确支持的。阶跃的工具调用文档在「支持工具调用的模型」里单独开了一档「仅 Step Plan 通道」，里面就是 step-router-v1。所以 Agent 场景可以用，只是别在 tools 里塞官方的 web_search。
计费口径：按实际命中的引擎算
三份文档（产品页、开发指南、推理模型接入页）用了几乎同样的措辞：按实际命中的引擎计费，命中 deepseek-v4-pro 就按 deepseek-v4-pro 计费，命中 step-3.7-flash 就按 step-3.7-flash 计费，最后统一换算为 Step Plan 的总额度消耗。
Step Plan 这套额度体系本身有几个机制要先理解，才知道路由的成本波动会落在哪：
- 它用 Credit 作为统一计费单位，调用任何模型都换算成 Credit 从当月额度里扣。Credit 与金额的换算比例、各档位发多少，都在官方定价页上，这里不列。
- Credit 按月一次性发放到「月池」，月内任意时段消耗，月末清零、不结转到下一周期。这条比价格重要得多——它意味着你的成本控制目标不是「省钱」，而是「把这个月的池子用得刚好」。
- 当月用完可以加购加油包补充，加油包有独立的到期周期，与套餐到期时间相互独立，具体周期长度见官方页面。
- 月池 Credit 和加油包 Credit 同时存在时，按到期时间先后消耗，优先扣减先到期的那一份。
- Step Plan 不适用开放平台那套按累计充值金额划分的阶梯限速，用量由所订阅档位的月度额度管理。
把这些串起来看，路由的真实成本风险就清楚了：你的月度消耗曲线取决于服务端的判定分布，而这个分布你既不能指定也无法预测。同样一个 Agent，需求换了个写法、上下文长了一截、工具从三个加到八个，都可能把更多请求推到决策引擎那一侧。
于是有个操作上的问题很关键：怎么知道某次请求命中了哪个引擎？Chat Completion 的响应体里确实有 model 字段，文档对它的说明只有「模型名称」四个字，没有明确写它会返回实际命中的引擎名还是你请求时填的 step-router-v1。这一点官方文档未说明，接之前建议先自己打日志把响应里的 model 存下来核对，别拿它当既定事实写进结算逻辑。
至于账单侧的归因，可以关注 usage 里的细分统计：completion_tokens_details.reasoning_tokens 记的是推理思考过程消耗的 token 数量，prompt_tokens_details.cached_tokens 记的是命中缓存的 token 数量。这两个字段是你判断请求「重不重」的现成依据。成本这条线怎么系统地盯，可以配合 API 成本怎么监控 那套做法，别等账单出来才发现结构变了。
缓存这一块要单独查一眼
这是我读文档时最意外的一处。阶跃的 Prompt 缓存最佳实践里列出了支持缓存的模型，写的是 step-3.7-flash、step-3.5-flash、step-3.5-flash-2603、step-1o-turbo-vision 等模型支持，然后紧跟一句「其他模型暂时不支持 Prompt 缓存」。
这份清单里没有 step-router-v1，也没有 deepseek-v4-pro。
按字面理解，走路由的请求拿不到 Prompt 缓存的价格优惠。这对长 system prompt 的 Agent 场景影响不小——你在直调 step-3.7-flash 时靠前缀缓存省下的那部分输入成本，换成路由之后可能就没了。缓存这件事在各家的计费口径差别很大，可以先看 提示缓存是怎么计费的 把通用机制理顺，再回来对照阶跃的清单。
我要诚实地补一句：官方没有在路由的文档里正面说「路由不支持缓存」，我这个结论是从缓存文档的支持清单和那句「其他模型暂时不支持」推出来的。清单随时可能更新，接入前请自己回官方缓存页确认一遍当前版本怎么写。
什么时候该用，什么时候别用
值得用的场景，官方给的三条我认为是靠谱的：一个 Agent 里同时有格式整理、信息抽取这类高频小活和架构规划、错误诊断这类关键决策；多轮加工具调用的长链路任务；以及成本敏感但不希望在关键决策上掉质量的场景。共同点是——你确实需要分流，但不想自己维护那套分流规则。
反过来，这几种情况我建议直接指定模型，别用路由：
需要视觉输入的，直接排除，官方写了不支持图像识别。需要成本可预测的（比如要给客户报价、要做单次调用的成本核算），路由这种服务端决定引擎的模式天然给不了确定性。重度依赖 Prompt 缓存压成本的，先确认清单再说。以及——需要在 Messages 协议下精细控制推理强度的，那个字段在路由下会被忽略。
最后是最容易栽的坑，按踩中概率排序：第一是 base URL 写成了普通 API 地址，报错信息还可能表现为「模型不存在」，让你误以为是权限问题；第二是 Anthropic SDK 那个 /v1 拼接规则，跟 OpenAI SDK 反着来；第三是把直调 step-3.7-flash 的现成代码原样切过来，结果里面带了图片输入或者 web_search 工具，报 unsupported_content_type 才发现字段约束变了。这三条本质上都是「换模型不只是换 model 字段」的老问题，切之前顺一遍 换一家大模型 API 的迁移自查清单 会省不少事。
上面涉及的字段上限、协议差异、缓存支持清单，都以阶跃星辰官方文档当前版本为准——这几张表是最容易随版本变动的部分，接入前值得再回源看一眼。