推理长度失控治理｜token 账单砍半实录

推理模型的账单失控，往往不是模型变笨了，而是它变得话多了：该停不停、简单题长篇大论、候选样本一批一批地烧。

最近几项研究把"长度失控"拆成了三个可独立治理的层次：终止 token 层面的错配会让学生模型越长越长；实例层面不分难度的统一分配造成简单题过度思考；系统层面同样的候选预算，串行调度的能耗接近单批调度的 5 倍。我把这三层治理搬进了自己的推理网关，账单肉眼可见地降了下来。这篇把机制、配置和代码一次讲全。模型接入统一走 4sapi（https://4sapi.com），治理逻辑做在接入层。

一、开篇痛点

我的推理网关一度出现三个诡异现象：

• 同一任务换个模型跑，输出长度翻三倍，质量却没见涨；
• 简单分类任务也要"思考"两屏，Token 费比答案本身贵十倍；
• 为了提升准确率做多次采样，账单翻倍之外，响应延迟还长到不可用。

三个现象指向同一个盲区：我一直在调提示词，却从没治理过"模型决定何时停、想多深、采几次"这三个成本开关。

二、原理速览：长度失控的三层来源

第一层: 终止行为 (什么时候停)
    学生/教师把停止概率放在不同 EOS token 上
        -> 学生话痨化, 直到耗尽生成预算

第二层: 深度分配 (想多深)
    统一长度策略: 简单题过度思考, 难题思考不足
        -> 计算花在了不需要的地方

第三层: 调度方式 (怎么采)
    同样的候选预算, 串行调用 vs 单次大批量
        -> 能耗与延迟差出数倍

三层互相独立，治理手段也不同。逐层拆开讲。

三、第一层：EOS 错配与长度膨胀

蒸馏场景里的一个隐蔽问题：学生模型和教师模型可能把停止概率放在不同的 EOS token上——即使两者声明的停止集合完全一样。后果是学生的首选终止动作被压制，教师的替代方案又没被可靠传递，于是回复越长越长，直到撞上生成预算上限。

实测覆盖 Qwen3、Llama、Gemma 三个模型家族，结论有两个反直觉点：

给我的直接启示：换基座或换教师重新蒸馏之前，先审计终止行为——跑一批任务统计输出长度分布，如果中位数莫名上浮，先查 EOS 对齐，别急着改提示词。

四、第二层：难度感知的深度分配

推理模型的系统性低效是"简单题过度思考、难题思考不足"。统一长度惩罚是钝刀子——省了简单题的钱，赔了难题的准确率。

更好的做法是把高效推理当成按实例分配计算的问题：难度感知的控制机制利用预先算好的参考统计量（各难度档的典型准确率与 Token 用量）做奖励塑形，让模型学会"这题值多少思考"。

落到我自己的网关，等价物是双档路由：

请求进入
    |
    v
难度预估 (分类器/规则: 任务类型 + 历史统计)
    |
    +-- 简单档: 直答模型, 小 max_tokens, 禁长思考
    |
    +-- 困难档: 推理模型, 宽预算, 保留思考链
    |
    v
按档位计费与监控

简单档走直答，困难档才放开推理预算。这一层治理在账单上的效果立竿见影：多数日常任务被分流到简单档，推理模型的使用量降到真正需要的部分。

五、第三层：采样调度的能耗账

提升准确率常用多次采样。同样的候选预算 N=8，调度方式不同，系统成本天差地别。实测数据（A100，固定候选总数）：

同一模式在三个独立调度的 A100 节点上复现，短输出任务的 V100 实验同样成立。结论：候选数量相同的前提下，能一批出的就不要拆多次。串行小批调用烧的是双倍的钱和六倍的延迟，换来的准确率与单批无异。

六、接入教程：预算控制与批量采样代码

通过 4sapi（https://4sapi.com）接入后，我把三层治理做成了一个统一的调用入口：

from openai import OpenAI
import concurrent.futures as cf

client = OpenAI(
    api_key="4sapi-key",
    base_url="https://4sapi.com/v1",
)

PROFILES = {
    "easy":   {"model": "direct-model",   "max_tokens": 512},
    "hard":   {"model": "reasoning-model", "max_tokens": 8192},
}

def ask(task: str, profile: str = "easy") -> str:
    cfg = PROFILES[profile]
    resp = client.chat.completions.create(
        model=cfg["model"],
        messages=[{"role": "user", "content": task}],
        max_tokens=cfg["max_tokens"],
    )
    return resp.choices[0].message.content or ""

def batch_candidates(task: str, n: int = 8) -> list[str]:
    """单次调用批量出 N 个候选: 用一条大请求拿多答案,
    而不是 N 次串行小请求。"""
    resp = client.chat.completions.create(
        model=PROFILES["hard"]["model"],
        messages=[{"role": "user", "content":
                   f"给出 {n} 个独立候选答案，用编号分隔:\n{task}"}],
        max_tokens=PROFILES["hard"]["max_tokens"],
    )
    text = resp.choices[0].message.content or ""
    return [seg.strip() for seg in text.split("\n\n") if seg.strip()][:n]

配套的长度监控：每次调用记录"输入 Token、输出 Token、完成原因"，输出长度分布的滑窗中位数上浮超过阈值就告警——这是发现 EOS 类问题的第一信号。

七、成本核算：治理前后的账单结构

治理前后（月度口径）我的账单构成变化：

三层数字加起来，总账单的下降幅度接近一半——没有换模型，没有砍功能，只动了"何时停、想多深、怎么采"。

八、风险提示

• 难度预估会错：分类器把难题分到简单档是准确率事故，给简单档留一个"升级重试"通道；
• 单批采样的隔离性：多个候选在同一次生成里产生，可能互相趋同，独立性要求高的场景要核对多样性；
• EOS 审计的适用范围：终止错配主要影响蒸馏/微调模型，纯官方 API 场景优先查配置里的 stop 序列冲突；
• max_tokens 不是免费保险：撞顶截断的答案常常不可用，重试反而更贵，预算要按长度分布的 P95 设；
• 监控先行：没有按任务、按模型的长度分布看板，任何治理都是盲调。

九、检查清单：推理成本治理上线

1. 记录每次调用的输入/输出 Token 与完成原因；
2. 输出长度分布按模型分桶看板，中位数上浮告警；
3. 简单/困难双档路由就位，升级重试通道可用；
4. 采样任务默认单批出多候选，禁用串行小批；
5. 换基座/教师前跑终止行为审计；
6. stop 序列与模型自带终止机制的冲突定期排查。

总结

推理账单失控有三层来源，也对应三层解法：终止 token 层查 EOS 错配（对齐停止集不够，要按语义合并停止动作）、实例层做难度感知的深度分配（简单题直答、难题放开思考）、系统层坚持单批出多候选（串行小批的能耗接近 5 倍、延迟接近 6 倍）。我的经验是把治理做在接入层——通过 4sapi（https://4sapi.com）统一入口配预算、路由和长度监控，模型层不动，账单先降一半。欢迎在评论区聊聊推理成本失控的翻车现场和治理技巧。