摘要GPT-5.6 把“模型选谁”进一步变成了“模型选谁、让它推理到什么程度”的二维调度问题。Sol、Terra、Luna 都支持 none、low、medium、high、xhigh、max 六档 reasoning.effort。如果所有请求都固定 high简单任务会为无效推理付出延迟和成本。如果所有请求都固定 low复杂编码、架构审查和高风险任务又可能丢失质量。本文不做参数介绍而是直接写一个可运行的 Python 动态推理路由器并配套 benchmark 脚本让同一批任务跑完六档 reasoning.effort再用质量、延迟和成本决定生产策略。整套示例重点解决 LLM Gateway 中最实际的一个问题什么时候应该让模型“多想”什么时候根本没必要。关键词GPT-5.6、reasoning.effort、Responses API、LLM Gateway、模型路由、成本优化、Python、Eval1. GPT-5.6 最容易被低估的变化是 reasoning.effort 变成了生产参数GPT-5.6 系列现在分为 Sol、Terra 和 Luna 三个能力层级。Sol 面向复杂专业工作、编码和长链路任务。Terra 更适合在质量与成本之间寻找平衡。Luna 面向高吞吐和成本敏感场景。这三个模型都支持六档 reasoning.effort。none low medium high xhigh max这使模型路由从一个简单的 model_id 选择变成了至少二维的资源调度问题。route model_tier × reasoning_effort 例如 gpt-5.6-luna none gpt-5.6-luna low gpt-5.6-terra medium gpt-5.6-terra high gpt-5.6-sol high gpt-5.6-sol xhigh gpt-5.6-sol max如果再把 text.verbosity、reasoning.context、Prompt Cache 和工具调用加进来实际配置空间会继续扩大。所以生产系统已经不能再靠“默认用某个模型”解决问题。真正要做的是根据任务形态动态分配推理预算。2. 为什么“全部 high”通常不是一个好默认值很多团队第一次接入推理模型时会把 reasoning.effort 固定成 high。逻辑很直观。既然模型可以多想就让它多想一点。但这忽略了真实业务请求的长尾分布。生产流量里大量任务并不需要复杂推理。日志字段提取、JSON 转换、文本分类、标题改写、简单摘要本质上都是决策空间较小的任务。它们最重要的指标通常是稳定、便宜、快。而数据库迁移评审、复杂 Debug、架构设计、事故根因分析则完全不同。这些任务更需要模型在多个假设之间进行验证和权衡。任务核心指标合理起点字段提取吞吐、结构稳定Luna none / low普通技术分析完整度、成本Terra medium复杂 Debug定位率、遗漏率Terra high高风险评审准确率、风险覆盖Sol high / xhigh同一个 high 参数同时服务这四类任务实际上等于没有路由。3. 先跑通 Responses APIreasoning 和 verbosity 要分开控制GPT-5.6 的 reasoning、工具调用和多轮工作流更适合通过 Responses API 管理。from openai import OpenAI client OpenAI() response client.responses.create( modelgpt-5.6-terra, input审查这个数据库迁移方案找出锁表和回滚风险。, reasoning{{ effort: medium, context: current_turn, }}, text{{ verbosity: medium, }}, ) print(response.output_text)这里最容易混淆的是 reasoning.effort 和 text.verbosity。reasoning.effort 决定模型为任务投入多少推理工作。text.verbosity 决定最终答案展开到什么程度。它们应该分别控制。例如高风险审查可以 high reasoning但最终只返回一个短风险表。反过来一篇长文可能需要 high verbosity却不一定需要 xhigh reasoning。4. 第一步把自然语言请求转换成 TaskProfile路由器最怕直接从 prompt 跳到 model。因为这样所有规则都会逐渐堆成 if-else。更稳妥的做法是先建立一层 TaskProfile。from dataclasses import dataclass dataclass class TaskProfile: task_type: str risk: int complexity: int latency_sensitive: bool quality_first: boolcomplexity 用于描述任务需要多少推理。risk 描述回答错误后的业务损失。latency_sensitive 表示用户是否更在意响应速度。quality_first 表示当前任务是否允许用更多成本换取质量。这几个变量比“prompt 有多少字”更接近真实路由需求。4.1 一个可运行的规则版 Profilerclass TaskProfiler: COMPLEX {{ 架构, 重构, 并发, 竞态, 死锁, 事务, 证明, 推导, 根因, 迁移, 安全, 审计, 故障, 性能, 多步骤, }} SIMPLE {{ 改写, 翻译, 摘要, 提取, 分类, 格式化, 标题, 转json, }} HIGH_RISK {{ 生产库, 数据库迁移, 支付, 权限, 安全漏洞, 线上故障, 删除数据, 财务, 合规, }} def profile(self, prompt: str) - TaskProfile: text prompt.strip() complex_hits sum( w in text for w in self.COMPLEX ) simple_hits sum( w in text for w in self.SIMPLE ) risk_hits sum( w in text for w in self.HIGH_RISK ) complexity 1 min( complex_hits, 3, ) if len(text) 600: complexity 1 if len(text) 1800: complexity 1 if ( simple_hits 2 and complex_hits 0 ): complexity max( 1, complexity - 1, ) complexity min( 5, complexity, ) risk min( 5, 1 risk_hits, ) latency_sensitive any( k in text for k in ( 实时, 低延迟, 批量, 尽快, ) ) quality_first ( risk 3 or 上线 in text or 最终版 in text or 严格审查 in text ) if complexity 2: task_type routine elif complexity 3: task_type analysis else: task_type deep_reasoning return TaskProfile( task_typetask_type, riskrisk, complexitycomplexity, latency_sensitivelatency_sensitive, quality_firstquality_first, )这个分类器并不追求“聪明”。它追求可解释、可调试和足够便宜。真正上线以后可以用历史数据训练轻量分类器也可以直接让业务接口显式传 task_type 和 risk。最不建议的方案是再用一个昂贵推理模型判断“应该使用哪个推理模型”。5. 第二步模型和 reasoning.effort 必须一起返回dataclass class RouteDecision: model: str effort: str verbosity: str reason: str下面这套路由逻辑故意比较保守。简单任务不会碰 Sol。复杂任务也不会默认 max。class AdaptiveRouter: def route(self, p: TaskProfile) - RouteDecision: if p.task_type routine: if p.latency_sensitive: return RouteDecision( modelgpt-5.6-luna, effortnone, verbositylow, reason低复杂度且延迟敏感, ) return RouteDecision( modelgpt-5.6-luna, effortlow, verbositylow, reason常规任务避免无效深推理, ) if p.task_type analysis: if p.quality_first: return RouteDecision( modelgpt-5.6-sol, efforthigh, verbositymedium, reason中等复杂但质量优先, ) return RouteDecision( modelgpt-5.6-terra, effortmedium, verbositymedium, reason成本与质量平衡, ) if p.risk 4: return RouteDecision( modelgpt-5.6-sol, effortxhigh, verbosityhigh, reason高风险复杂任务, ) if p.quality_first: return RouteDecision( modelgpt-5.6-sol, efforthigh, verbosityhigh, reason复杂且质量优先, ) return RouteDecision( modelgpt-5.6-terra, efforthigh, verbositymedium, reason复杂但非高风险, )为什么不自动返回 max。因为 max 的存在不意味着它应该成为默认生产值。只有当固定评测集证明 max 相比 xhigh 有稳定、可测量且值得成本的质量提升时才应该启用。6. 第三步把路由器接进真实 APIclass GPT56Service: def __init__(self): self.client OpenAI() self.profiler TaskProfiler() self.router AdaptiveRouter() def run(self, prompt: str): profile self.profiler.profile(prompt) decision self.router.route( profile ) response self.client.responses.create( modeldecision.model, inputprompt, reasoning{{ effort: decision.effort, context: current_turn, }}, text{{ verbosity: decision.verbosity, }}, ) return ( response.output_text, profile, decision, response.usage, )到这里一个最小 LLM Router 已经成立。但真正的生产价值还没有出现。因为我们还不知道这个决策到底省没省钱也不知道质量有没有下降。7. 第四步把价格、Token 和缓存放进同一条指标当前 GPT-5.6 Sol、Terra、Luna 的标准文本价格不同。因此只统计 token 数没有意义。PRICE {{ gpt-5.6-sol: {{ input: 5.00, cached_input: 0.50, output: 30.00, }}, gpt-5.6-terra: {{ input: 2.50, cached_input: 0.25, output: 15.00, }}, gpt-5.6-luna: {{ input: 1.00, cached_input: 0.10, output: 6.00, }}, }}def estimate_cost( model: str, input_tokens: int, output_tokens: int, cached_tokens: int, ) - float: p PRICE[model] uncached max( 0, input_tokens - cached_tokens, ) cost ( uncached * p[input] cached_tokens * p[cached_input] output_tokens * p[output] ) / 1_000_000 return round( cost, 8, )这段代码只适合 Demo。生产系统应该把价格表放入配置中心并给价格版本加生效时间。否则价格变化以后历史任务账单无法正确回放。8. 第五步每次请求都记录路由理由和 Metricsstarted time.perf_counter() response client.responses.create( modeldecision.model, inputprompt, reasoning{{ effort: decision.effort, context: current_turn, }}, text{{ verbosity: decision.verbosity, }}, ) latency_ms int( ( time.perf_counter() - started ) * 1000 ) usage response.usage metrics {{ model: decision.model, effort: decision.effort, latency_ms: latency_ms, input_tokens: usage.input_tokens, output_tokens: usage.output_tokens, }}真正进入日志系统时建议再追加 task_type、risk、route_reason、quality_score、accepted 和 retry_count。{ request_id: req_8d21, task_type: analysis, risk: 2, model: gpt-5.6-terra, effort: medium, route_reason: 成本与质量平衡, latency_ms: 4210, input_tokens: 1830, output_tokens: 742, cached_tokens: 1200, estimated_cost_usd: 0.0123, quality_score: 0.91, accepted: true }没有这一层观测数据动态路由很容易沦为“看起来很聪明的 if-else”。9. 第六步用固定 Eval 集跑六档 effort而不是靠感觉这是整套方案里最重要的一步。官方迁移建议也明确强调应该在代表性任务上比较相同 reasoning 档位以及更低档位的表现。换句话说不要假设更多推理一定更好。要测。EFFORTS [ none, low, medium, high, xhigh, max, ] for case in cases: for effort in EFFORTS: result run_case( clientclient, casecase, modelgpt-5.6-terra, efforteffort, ) rows.append(result)测试集必须固定。同一个 Case 要同时跑六个档位。否则不同档位之间没有可比性。{id:extract,prompt:从日志中提取 error_code、trace_id 和失败模块。,required_keywords:[DB_TIMEOUT,trace_id]} {id:review,prompt:审查数据库迁移方案重点检查锁表和回滚失败。,required_keywords:[锁,回滚]} {id:architecture,prompt:设计日处理 300 万事件的异步任务平台。,required_keywords:[幂等,死信,可观测]}Demo 使用 required_keywords 做最简单的自动评分。真正工程项目应该针对不同任务使用不同 Grader。9.1 不同任务应该使用不同评测器任务类型建议 Grader结构化提取JSON Schema 字段准确率代码生成单元测试 / 静态检查SQL执行结果 安全规则技术审查人工标注 LLM Judge摘要事实覆盖率 幻觉检测高质量的路由系统本质上一定依赖 Eval。没有 Eval就无法证明 high 比 medium 值得多花的钱。10. 不要只按最高质量选档位要优化 Utility如果业务只追求最高分最终结果通常会收敛到更贵的模型和更高 effort。但线上系统真正优化的是综合收益。utility ( 1.00 * quality_score - 0.20 * normalized_cost - 0.15 * normalized_latency - 0.10 * retry_rate )在线客服可以提高 latency 权重。批量内容处理可以提高 cost 权重。生产数据库变更审查则应该明显提高 quality 权重。所以不存在一个适合所有请求的“最佳 reasoning 档位”。它必须是 task_type 的函数。11. 更进一步失败以后可以做 Reasoning Escalation动态路由不一定一次就选到最终档位。对于非高风险任务可以先从较低档位尝试。如果自动验收失败再升级 reasoning。ESCALATION { none: low, low: medium, medium: high, high: xhigh, xhigh: max, } def next_effort(current: str) - str | None: return ESCALATION.get(current)例如 JSON 提取先走 Luna none。Schema 校验失败以后升级 Luna low。仍失败再切 Terra medium。这种逐级升级比一开始所有请求都 high 更容易控制成本。12. reasoning.context 也是路由参数不要永久 all_turnsGPT-5.6 支持 persisted reasoning。这使多轮任务可以继续利用之前的推理状态。response client.responses.create( modelgpt-5.6-sol, input继续检查上一轮方案中的回滚路径。, previous_response_idprevious_id, reasoning{ effort: high, context: all_turns, }, )如果任务目标和假设在多轮中保持稳定all_turns 很有价值。如果用户已经切换到一个独立任务current_turn 更合适。否则旧推理不仅增加上下文负担还可能让模型继续沿用已经失效的假设。13. Prompt Cache 也应该进入成本模型GPT-5.6 支持 Prompt Caching。缓存读取的价格明显低于普通输入。但缓存写入本身也不是免费的。因此最适合缓存的不是随机用户输入而是稳定前缀。稳定 System Prompt 固定业务规则 固定 Tool Schema 固定输出约束 ------------------ 动态用户问题 动态检索结果一个成熟的路由器最终不应该只输出 model 和 effort。RouteDecision( modelgpt-5.6-terra, effortmedium, reasoning_contextcurrent_turn, verbositymedium, cache_policyreuse_stable_prefix, timeout_ms15000, max_cost_usd0.03, )这已经很接近一个真正的 LLM Gateway 配置对象。14. 多模型平台真正难的不是“接模型”而是调度在单模型 Demo 里把 model 写死还勉强可以工作。但在创源AIGC这类同时处理文本、图片、视频、音频、PPT、AI漫剧和画布任务的平台里这种做法很快失效。同一个项目里脚本摘要、角色设定、分镜分析、视频提示词整理和最终审核的任务复杂度完全不同。平台后端真正需要维护的是统一的 Task Profile、Capability Route、Cost Metric 和 Quality Gate。用户看到的是同一个创作入口。系统内部实际在持续回答四个问题。这个任务应该交给哪个模型。这个任务值得让模型推理到什么程度。如果第一次失败应该升级模型还是升级 effort。为了得到一个合格结果最多允许花多少成本。这比单纯把模型列表做长更接近真正的平台技术壁垒。15. 七个常见工程坑ROUTE-101ALL_HIGH所有任务固定 high简单任务承担没有业务收益的额外推理成本。ROUTE-202MODEL_ONLY只切换 Sol、Terra、Luna不管理 reasoning.effort。EVAL-303NO_FIXED_CASES不同档位测试使用不同问题最后得出的性能结论没有统计意义。COST-404TOKEN_ONLY只记录 Token不记录具体模型价格、缓存命中和重试。CTX-505ALL_TURNS_FOREVER所有对话永久继承旧推理即使当前任务已经完全变化。CACHE-606WRITE_EVERYTHING低重复内容也频繁进入缓存忽略缓存写入本身的成本。MAX-707HIGHEST_EQUALS_BEST没有 Eval 证明就默认 max把“存在的最高档”误认为“线上最佳档”。16. 如何运行本文完整代码安装依赖。pip install -r requirements.txt配置环境变量。# Linux / macOS export OPENAI_API_KEYyour_key # Windows PowerShell $env:OPENAI_API_KEYyour_key先使用 dry-run 看任务会被路由到哪里。python router.py 把这 100 条日志分类并输出 JSON --dry-run复杂任务可以直接实际调用。python router.py 审查数据库迁移方案重点检查锁表、数据丢失和回滚风险。然后跑六档 reasoning.effort 的横向测试。python benchmark.py --cases tasks.jsonl --model gpt-5.6-terra --output benchmark.csv最终 benchmark.csv 会同时记录 effort、延迟、输入 Token、输出 Token、缓存 Token、估算成本和基础质量得分。这份 CSV 才是决定线上默认档位的起点。17. 最后reasoning.effort 本质上是“推理预算调度”GPT-5.6 的推理档位不应该只被当作界面上的“思考时间选项”。对后端系统来说它意味着推理预算终于可以显式参与路由。简单任务使用便宜模型和低 effort。复杂任务根据质量门禁逐级升级。高风险任务直接使用更强模型和更高 reasoning。max 只服务于已经通过评测证明值得的场景。模型、effort、context、cache、latency、cost、quality 最终都应该进入同一套 LLM Gateway 指标体系。当“让模型想多久”也能被工程化调度以后LLM 成本优化才真正从选模型进入了资源管理阶段。资料说明本文关于 GPT-5.6 Sol、Terra、Luna、六档 reasoning.effort、Responses API、persisted reasoning、Prompt Caching 和价格的信息均依据 OpenAI 2026 年 8 月公开开发者文档整理。文中的 TaskProfiler 与 Route Policy 是工程示例不代表所有业务都应该采用相同阈值。生产环境应该基于自己的固定 Eval 集重新确定路由策略。