128K 上下文是真是假：三种可复现的核对方法

上下文长度是最容易被夸大的参数。宣称 128K 的服务，实际可用长度可能只有 32K；问题不在模型，而在中转的请求体上限、网关缓冲或计费策略。

第一种核对方法是长度探针。构造一段由编号句子组成的长文本，要求模型只回答最后一句的编号。逐步加长输入，记录第一次回答错误的长度。这个长度就是实际可用的下限，比宣称值更有参考意义。

第二种是计费反推。请求返回的 usage 里通常带有 prompt_tokens。把你的文本长度与 prompt_tokens 对比，如果两者差距很大，说明中间被截断或做了摘要。连续几次都出现明显缺口，基本可以判定存在静默截断。

第三种是 needle 验证的简化版：在长文本中埋入一个不常见的字符串（例如一串随机字母），要求模型原样复述。埋点位置从前往后移动，观察从哪个位置开始复述失败。上下文被裁剪时，通常表现为尾部或中部内容先丢失。

三种方法都做完，可以得到一张四列的表：声明长度、首次失败长度、计费可见长度、稳定可用长度。对外只应引用稳定可用长度，因为它才是业务能依赖的数字。

还要注意上下文与价格的关系。多数站点按输入 token 计费，长上下文请求的成本是线性增长的。把 100K 的文档整段塞进去，往往比先做检索再拼接贵一个数量级，这也是工程上更常见的优化方向。

工程上还有一个折中做法：把长文档先做分段摘要，再把摘要与关键段落一起送入，输入量可能只有原来的三分之一，回答质量却更稳定。上下文够长不等于应该用满，多数业务在 8K 到 32K 之间就能跑得很顺，把预算留给重试与并行，比追求极限长度更划算。