先把「多长」变成能感知的量

上下文窗口写着 128K、256K、1M，这些数字对多数人是没有体感的。 换算一下就清楚了：几万 token 大约相当于一本小册子的篇幅，十几万 token 能装下一部长篇小说的主要章节。 问题从来不是「装不装得下」，而是「装进去值不值这个钱、模型还能不能找准重点」。

换算规则很粗糙但够用：中文大致一个字一个 token 上下，英文平均三到四个字符一个 token， 代码因为符号密集，token 密度介于两者之间。真实数字取决于各家分词器， 需要更贴近的估算就把文本粘进 token 计算器。

窗口大小怎么选

选型时把窗口当成安全余量，而不是使用目标。理由有两个。

一是钱。上下文里的每个 token 都要按输入价计费，而且很多厂商按上下文长度分档， 超过某个阈值单价直接跳一档。把三十页文档整份塞进去问一句话，成本可能是检索出三段再问的十几倍。

二是效果。超长上下文里，关键信息被埋在中间时，模型的召回准确率通常不如短上下文稳定。 这不是某一家的问题，是长上下文的共性挑战。与其赌模型能从十万 token 里精准捞出那一句， 不如自己先把范围缩小到几千 token。

超长了怎么办

最省事的是裁剪历史：只保留最近几轮完整对话，更早的部分压成一段摘要。 摘要可以用便宜的小模型生成，成本几乎可以忽略。

其次是换成检索：把长文档切片建索引，每次只把相关的几片送进上下文。 这一步还顺带解决了「文档超过窗口上限根本塞不下」的硬约束。

最后是用提示缓存复用固定前缀：如果每次请求前半截都一样， 缓存命中后这部分按很低的折扣价计费，长 system prompt 的项目收益最明显。 三种手段可以叠加，顺序建议是先裁剪、再检索、最后缓存。

把结果接到预算上

这一页算的是单次调用成本。把它乘以日调用量再乘三十，就是月成本； 也可以直接去 月成本估算器按输入输出分别填， 那边会把各模型按月成本排好序。想先比单价，去价格对比表。