摘要：

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

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

任务	核心指标	合理起点
字段提取	吞吐、结构稳定	Luna + none / low
普通技术分析	完整度、成本	Terra + medium
复杂 Debug	定位率、遗漏率	Terra + high
高风险评审	准确率、风险覆盖	Sol + high / xhigh

同一个 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 不同任务应该使用不同评测器

任务类型	建议 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_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 集重新确定路由策略。