在一把 key 上按提示词长度分流：短请求和长请求分别该派给谁

为什么要先量 token 再发请求

很多人调用 LLM API 的习惯是：先选模型，再把提示词扔过去。问题在于，模型的上下文窗口是硬约束，而不少 API 在提示词超长时并不会明确报错，而是静默截断——只保留前 N 个 token，后面的内容直接丢掉，返回结果看起来「正常」，但你的关键指令或文档后半段根本没被读到。

这类问题最难排查，因为它不抛异常。输出质量下降，你以为是模型不行、提示词不行，实际是输入被切掉了一截。

所以更稳的顺序是：先量 token，再决定发给谁。

量 token 的几个要点

• token 不等于字符。中英文差异很大，同一个长度感觉的两段文本，token 数可能差出数倍。
• 不同模型的 tokenizer 不同，同一段文本在两家模型上的 token 数会有偏差。做分流判断时，用目标模型对应的 tokenizer 估算最准；做不到就用一个偏保守的估算，宁可高估。
• 估算需要把系统提示词、对话历史、用户输入、预留给输出的空间全部算进去，而不是只数当前这一条消息。多轮对话里历史会不断累积，是最容易被忽略的部分。

按长度分流的基本策略

可以把请求粗略分成两档：

• 短请求：提示词加历史在较小窗口内，任务通常是分类、抽取、改写、简短问答。这类请求交给便宜、快的小模型就够，没必要上最贵的大模型。
• 长请求：携带长文档、长代码库、长对话历史，或需要模型在长上下文中做定位和推理。这类请求必须走大上下文窗口的后端，否则就会撞上截断。

分流的价值有两层：一是成本，短请求用小模型能省下大量额度；二是正确性，长请求发错后端会被无声截断，这是质量事故而不是省钱。

在聚合站上怎么落地

用一个 API key 调多个模型时，分流逻辑可以放在你自己的代码里，也可以借助聚合层的能力：

1. 发送前用 tokenizer 或估算函数算出总 token。
2. 设一个阈值，低于阈值走便宜后端，高于阈值走大上下文后端。
3. 对大上下文后端再设一道上限：超过它的窗口就主动报错或先做摘要/切分，绝不让它自己截。
4. 记录每次请求的实际 token 用量和后端选择，便于回头校准阈值。

聚合站的好处是切换后端只改模型名，不用换 key、不用改鉴权。把模型名做成配置项，分流规则就能独立调整。

常见坑

• 只数用户消息：忘了系统提示词和对话历史，多轮场景下严重低估。
• 忽略输出预留：上下文窗口是输入加输出共享的，给输出留太少会导致回答被截尾。
• 阈值一刀切：不同任务对上下文的需求不同，长文档问答和长历史闲聊不该用同一条线。
• 把截断当成功：对返回结果做基本校验，比如长文档任务里检查模型是否引用了文档后段的内容。
• tokenizer 与后端不一致：估算用 A 模型、实际发 B 模型，边界情况下会误判。

一个可执行的判断流程

1. 组装完整输入（系统提示词 + 历史 + 当前输入）。
2. 估算 token 总量，加上期望的输出长度。
3. 若总量小于便宜后端的窗口，走便宜后端。
4. 否则若总量小于大上下文后端窗口，走大上下文后端。
5. 两者都不满足，先对历史或文档做摘要、检索裁剪，再重走一遍。

这个流程不需要很复杂，关键是在发请求之前做判断，而不是等返回结果不对了再回头查。