很多人看到 GPT-6 Luna 输入 0.10 美元每百万 token 就以为捡到了地板价，但 OpenAI API 页脚有一行小字：这个标准价只适用于上下文长度低于 27.2 万 token 的请求。一旦你的对话或文档超过这个阈值，单价会上浮。对做长文档、长会话产品的团队，这 27.2 万就是一个看不见的计费悬崖。本文给一个可直接落地的路由加压缩方案，把悬崖变成缓坡。
27.2 万 token 这条计费悬崖到底在哪？
假设你把一份 50 万 token 的文档喂给 Luna。前 27.2 万 token 按 0.10 美元，后面的部分按上浮价算。问题是你在请求发出前，并不知道总价会飘到哪。更糟的是，长会话里你每轮都把历史全发一遍，token 是累积的——第 20 轮时，光历史就可能突破阈值，整单悄悄变贵。
对策分两层：入口路由，和超限压缩。
怎么在发请求前就预判价格？
在你的调用层包一个函数，发请求前先估算当次的 prompt_tokens（用 tiktoken 按模型编码数一遍即可）。逻辑很简单：
- 如果累计上下文预计低于 25 万 token（留一点余量），直接走 Luna 标准价档。
- 如果预计在 25 万到 27.2 万之间，先触发一次压缩再发。
- 如果明显超过 27.2 万，不要硬塞长上下文，改成分段检索：只把相关片段塞进上下文，而不是全文。
关键是那个 25 万的预警线，要比 27.2 万的计费线提前一点，给压缩留余量。
超阈值该截断还是该摘要？
最忌讳的做法是直接砍掉最早的对话历史——重要信息可能正好被切掉。正确做法是让模型先把前半段历史压成一份摘要：把第 1 到 N 轮历史发给一个便宜模型，要求输出「用户目标、已确认结论、待办事项」三段式摘要，然后用摘要替换原文历史，再和最近几轮原文拼在一起发出去。
这样上下文长度从 50 万压到几万，既守住了 27.2 万的低价线，又没丢关键信息。压缩本身只做一次，成本可以忽略。
上线后该养成什么校验习惯？
压缩之后，抽样人工看十份摘要，确认关键结论没被摘要抹掉。长上下文产品最大的风险不是贵，而是悄悄丢信息还不自知。设一个监控：当某日触发压缩的请求占比超过 20%，说明你的产品上下文设计有问题，该重构检索而不是继续压。
27.2 万这条线，本质是 OpenAI 在告诉你：长上下文是要加钱的。聪明的团队不在超阈值后硬扛，而在到线之前就把上下文管起来。