TRAE-AI编程
Grok 推理强度四档取舍
推理强度（reasoning effort）是「让模型想多久」的旋钮，不是「让模型变聪明」的开关。最常见的误用是把 xhigh 当成「高质量档」无脑拉满，结果延迟翻倍、账单暴涨，答案质量却只线性甚至次线性提升。这一节把四档的取舍讲清，并给一个本书自定的相对代价模型——它只用来演示取舍逻辑，不引用任何第三方基准数字。
按 2026-11-04 官方 release-notes，grok-4.7 与 grok-4.6 支持 low / medium / high(默认) / xhigh 四档；grok-4.5 的发布说明只列 low / medium / high 三档（默认 high）。不同模型的档位数目以各自官方页为准。
这里要分清两个「默认」：high 是平台默认值（不传参时的初值），不等于「推荐值」；本书主线项目因简单请求占比高，把默认下探到 medium（见 4.4）。一个说平台初值，一个说按画像调优，两者不冲突。
一、问题不是「能不能拉满」，而是「值不值」
推理强度影响两件事：消耗的 token（想得越多，内部推理链越长）和延迟（想得越久，首 token 越晚）。它不保证答案质量按倍数提升——很多任务在 medium 就已经饱和，xhigh 只是更贵更慢。
下面用一个相对系数模型演示取舍。系数以 high 为 1.0 基准，纯粹是本书为讲清逻辑设定的相对量，不是官方值也不是任何第三方基准，真实倍数请以自己的实测为准。
二、最小可运行示例：相对代价模型
下面的脚本不联网、不需要真实密钥。它用自定相对系数估算每档的「相对输出量」与「相对延迟」。
"""推理强度四档的相对代价模型（本书自定系数，仅演示取舍，非官方/第三方基准）。"""
## 相对系数：以 high 为 1.0 基准。仅用于演示，不引用任何外部基准数字。
RELATIVE = {
"low": {"cost": 0.4, "latency": 0.5},
"medium": {"cost": 0.7, "latency": 0.8},
"high": {"cost": 1.0, "latency": 1.0},
"xhigh": {"cost": 1.8, "latency": 1.6},
}
VALID = set(RELATIVE)
def estimate(effort: str, base_output_tokens: int, base_latency_s: float) -> dict:
if effort not in VALID:
raise ValueError(f"未知档位：{effort}，可选 {sorted(VALID)}")
r = RELATIVE[effort]
return {
"effort": effort,
"est_output": int(base_output_tokens * r["cost"]),
"est_latency": round(base_latency_s * r["latency"], 2),
}
def offline_check() -> None:
base_out, base_lat = 1000, 10.0
for e in ("low", "medium", "high", "xhigh"):
print(e, "->", estimate(e, base_out, base_lat))
# xhigh 比 high 贵约 80%、慢约 60%，但答案质量未必线性提升
xh = estimate("xhigh", base_out, base_lat)
hi = estimate("high", base_out, base_lat)
assert xh["est_output"] == 1800 and hi["est_output"] == 1000
print("xhigh 相对 high：成本", xh["est_output"]/hi["est_output"], "倍")
if __name__ == "__main__":
offline_check()
真正上线时，把 RELATIVE 换成你自己的实测倍数是更负责任的做法；上面这组数字的唯一作用是让你看清「xhigh 明显更贵更慢」这个定性结论。
三、四档怎么选
| 档位 | 适合的任务 | 不适合的任务 | 代价特征 |
|---|---|---|---|
low |
简单抽取、分类、格式化 | 多步推理、长链条 | 最省最快，质量可能不够 |
medium |
多数常规问答、摘要 | 需要深推理的硬题 | 性价比基线 |
high（默认） |
默认兜底，质量与成本均衡 | 对延迟极度敏感 | 标准代价 |
xhigh |
难推理、难校验、值得多花 | 高并发、延迟敏感、简单题 | 明显更贵更慢 |
三件要强调的事：
xhigh不是「更好」，是「更慢更贵」。把它当质量开关是预算杀手。 多数任务在medium/high已经饱和，拉满只是把成本与延迟推上去。- 不同模型档位数目不同。
grok-4.7/4.6四档，grok-4.5三档；给xhigh前先确认你的模型支持，否则参数可能被静默忽略或报错（具体行为以官方页为准）。 - 系数要自己测。本节系数是演示用的相对量，绝不引用第三方基准；真实取舍应基于你自己的 A/B 实测，而非任何外部数字。
四、预期输出与异常分支
运行相对代价模型，预期输出：
low -> {'effort': 'low', 'est_output': 400, 'est_latency': 5.0}
medium -> {'effort': 'medium', 'est_output': 700, 'est_latency': 8.0}
high -> {'effort': 'high', 'est_output': 1000, 'est_latency': 10.0}
xhigh -> {'effort': 'xhigh', 'est_output': 1800, 'est_latency': 16.0}
xhigh 相对 high：成本 1.8 倍换成真实调用时，若出现异常，按下面顺序定位：
| 现象 | 优先怀疑 | 第一步动作 |
|---|---|---|
| 参数被忽略 | 模型不支持该档 | 核对模型档位数目 |
| 延迟不降反升 | 误设 xhigh |
打印实际 reasoning 值 |
| 成本异常 | 档位与请求量错配 | 先按任务分档再放量 |
| 未知档位报错 | 拼写或枚举错 | 对照 VALID 枚举 |
最后一行尤其重要：xhigh 成本 1.8 倍这个结论是基于自定系数演示的。真实世界里它提醒你「拉满前先算账」，而不是「拉满就是 1.8 倍」——把倍数换成你自己的实测才是负责任的做法。
五、判据卡
| 判断项 | 该这么做 | 不该这么做 |
|---|---|---|
| 选档位 | 按任务分档，简单题用 low/medium | 无脑拉满 xhigh |
| 看代价 | 用自己实测倍数算账 | 引用第三方基准数字 |
| 确认支持 | 先查模型档位数目 | 假设全部四档通用 |
| 高并发 | 用 high 兜底（平台默认），简单题下探 medium | 为「求稳」全量 xhigh |
| 出错排查 | 先打印实际 reasoning 值 | 先换模型或重发 |
这张卡的重点是先分档再放量。五类现象里「成本异常」和「延迟不降」常常同源：档位与请求量错配，表现一个是钱一个是时间，但修法都在「按任务分档」上。
六、来源与核验
- 官方 release-notes：
https://docs.x.ai/developers/release-notes（核验日期 2026-11-04）。grok-4.7/4.6四档、grok-4.5三档（默认 high）以该页为准（F31）。 - 本节的相对代价系数为本书演示用，非官方值、非第三方基准；真实倍数请以你的实测为准。
- 价格、额度与区域可用性以控制台当前页面为准。
七、动手试
- 把
RELATIVE换成你自己的实测倍数（例如用high与xhigh各跑 100 次同任务，记录平均输出 token 与延迟），重跑offline_check()，对比演示系数与你实测的差异。 - 给
estimate()加一个budget_cap参数：当某档预估成本超过上限时返回「不建议」，并给出降级到的档位。想一想：这个上限该怎么定，按单次还是按月？ - 设计一个分档策略：对内部文档问答这类任务，给出「简单检索用 low、复杂追问用 high、绝不默认 xhigh」的规则，并说明你依据的是任务类型还是用户等待容忍度。
更多建议：