GPT-5.6 推理档位实战：别再全量 high，用 Python 做一个动态 reasoning.effort 路由器

摘要：

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、Eval

1. 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、架构设计、事故根因分析则完全不同。

这些任务更需要模型在多个假设之间进行验证和权衡。

同一个 high 参数同时服务这四类任务，实际上等于没有路由。

3. 先跑通 Responses API：reasoning 和 verbosity 要分开控制

GPT-5.6 的 reasoning、工具调用和多轮工作流更适合通过 Responses API 管理。

from openai import OpenAI client = OpenAI() response = client.responses.create( model="gpt-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: bool

complexity 用于描述任务需要多少推理。

risk 描述回答错误后的业务损失。

latency_sensitive 表示用户是否更在意响应速度。

quality_first 表示当前任务是否允许用更多成本换取质量。

这几个变量比“prompt 有多少字”更接近真实路由需求。

4.1 一个可运行的规则版 Profiler

class 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_type=task_type, risk=risk, complexity=complexity, latency_sensitive=latency_sensitive, quality_first=quality_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( model="gpt-5.6-luna", effort="none", verbosity="low", reason="低复杂度且延迟敏感", ) return RouteDecision( model="gpt-5.6-luna", effort="low", verbosity="low", reason="常规任务避免无效深推理", ) if p.task_type == "analysis": if p.quality_first: return RouteDecision( model="gpt-5.6-sol", effort="high", verbosity="medium", reason="中等复杂但质量优先", ) return RouteDecision( model="gpt-5.6-terra", effort="medium", verbosity="medium", reason="成本与质量平衡", ) if p.risk >= 4: return RouteDecision( model="gpt-5.6-sol", effort="xhigh", verbosity="high", reason="高风险复杂任务", ) if p.quality_first: return RouteDecision( model="gpt-5.6-sol", effort="high", verbosity="high", reason="复杂且质量优先", ) return RouteDecision( model="gpt-5.6-terra", effort="high", verbosity="medium", reason="复杂但非高风险", )

为什么不自动返回 max。

因为 max 的存在不意味着它应该成为默认生产值。

只有当固定评测集证明 max 相比 xhigh 有稳定、可测量且值得成本的质量提升时，才应该启用。

6. 第三步：把路由器接进真实 API

class 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( model=decision.model, input=prompt, 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. 第五步：每次请求都记录路由理由和 Metrics

started = time.perf_counter() response = client.responses.create( model=decision.model, input=prompt, 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( client=client, case=case, model="gpt-5.6-terra", effort=effort, ) 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 不同任务应该使用不同评测器

高质量的路由系统，本质上一定依赖 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_turns

GPT-5.6 支持 persisted reasoning。

这使多轮任务可以继续利用之前的推理状态。

response = client.responses.create( model="gpt-5.6-sol", input="继续检查上一轮方案中的回滚路径。", previous_response_id=previous_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( model="gpt-5.6-terra", effort="medium", reasoning_context="current_turn", verbosity="medium", cache_policy="reuse_stable_prefix", timeout_ms=15000, max_cost_usd=0.03, )

这已经很接近一个真正的 LLM Gateway 配置对象。

14. 多模型平台真正难的不是“接模型”，而是调度

在单模型 Demo 里，把 model 写死还勉强可以工作。

但在创源AIGC这类同时处理文本、图片、视频、音频、PPT、AI漫剧和画布任务的平台里，这种做法很快失效。

同一个项目里，脚本摘要、角色设定、分镜分析、视频提示词整理和最终审核的任务复杂度完全不同。

平台后端真正需要维护的，是统一的 Task Profile、Capability Route、Cost Metric 和 Quality Gate。

用户看到的是同一个创作入口。

系统内部实际在持续回答四个问题。

这个任务应该交给哪个模型。

这个任务值得让模型推理到什么程度。

如果第一次失败，应该升级模型还是升级 effort。

为了得到一个合格结果，最多允许花多少成本。

这比单纯把模型列表做长更接近真正的平台技术壁垒。

15. 七个常见工程坑

ROUTE-101：ALL_HIGH

所有任务固定 high，简单任务承担没有业务收益的额外推理成本。

ROUTE-202：MODEL_ONLY

只切换 Sol、Terra、Luna，不管理 reasoning.effort。

EVAL-303：NO_FIXED_CASES

不同档位测试使用不同问题，最后得出的性能结论没有统计意义。

COST-404：TOKEN_ONLY

只记录 Token，不记录具体模型价格、缓存命中和重试。

CTX-505：ALL_TURNS_FOREVER

所有对话永久继承旧推理，即使当前任务已经完全变化。

CACHE-606：WRITE_EVERYTHING

低重复内容也频繁进入缓存，忽略缓存写入本身的成本。

MAX-707：HIGHEST_EQUALS_BEST

没有 Eval 证明就默认 max，把“存在的最高档”误认为“线上最佳档”。

16. 如何运行本文完整代码

安装依赖。

pip install -r requirements.txt

配置环境变量。

# Linux / macOS export OPENAI_API_KEY="your_key" # Windows PowerShell $env:OPENAI_API_KEY="your_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 集重新确定路由策略。