北京
周三下午，一个AI应用开发者在例行的API账单前呆住了——他那个还在打磨中的智能体单日就推送了超过50K token的上下文，其中夹带了大量系统模板、历史摘要和根本没有被用到的中间结果。这些冗余token每时每刻都在消耗昂贵的GPU周期，而类似的故事正在数以万计的项目中无声上演。开发者Arjun Shah不想再忍了，他花大量业余时间做了一个叫SuperCompress的提示压缩系统，核心数据很直接：在答案准确性不受影响的前提下，推理成本能省下65%。
正方逻辑建立在一条朴素观察上：绝大多数发送给大语言模型的token，其实从未被真正需要。Shah在调试LLM智能体时反复看到，每一个代理循环都会把海量上下文塞进GPU，10K token起步，50K甚至更多都很平常。但这些文本中，与当前任务高度相关的往往只集中在少数段落。传统的截断方法——只保留开头和尾部——成了最常被采用的妥协方案，但它有一个致命缺陷：关键信息常常恰好卡在中间，一旦被丢弃就追不回来。于是Shah提出一个完全不同的思路：能不能在文本进入GPU之前，先用一个运行在CPU上的轻量模型，对上下文里的每一行做相关性评分，然后只把高分行保留下来？这个设想如果成立，就能把昂贵的GPU计算精准“喂”给真正重要的内容，同时避开截断带来的信息丢失陷阱。
这套想法最终被锤炼成仅约5K参数的小型策略模型，单次推断耗时不超过60毫秒，可在CPU上高效运行。它逐行评估和用户提问的关联度，剔除低相关行，保留那些对最终答案生成起决定性作用的部分。经过多轮迭代，Shah拿到的实验数据甚至让设计者本人感到意外：在达到同等token压缩率的情况下，该策略实现了100%的“神谕召回”（oracle recall）——压缩过程从未丢弃过任何一行答案所依赖的上下文。也就是说，输出不仅短了，答案的准确度也完整保留了下来。这一结论有65个通过的测试用例支撑，结果公开发布，可供任何第三方复现。
反方视角的担忧大致集中在“压缩必然伴随损失”这一直觉上。毕竟，传统的头部-尾部截断已经反复证明，中间位置的文本一旦被裁掉，回答质量就会明显下滑。有人会问，一行一行打分的方式真的可靠吗？会不会某个看似无关的提示片段，恰好承载着模型正确推理所需的背景线索？Shah用100%神谕召回的回答是：策略训练的目标就是在不伤害答案线索的前提下实现压缩，而透明开源的设计允许任何人直接跑测试，亲手验证它会不会吃掉自己的关键信息。对于仍然抱有疑虑的开发者，项目还提供了浏览器端一键演示，上传自己的用例立即能看到压缩后的效果，结果是把判断权交还给用户。
把视角拉到行业规模，这组数字会让人感受到更现实的冲击。按Shah的保守估算，如果每天发生5000万次智能体调用，全行业一天就会产生1000亿个无效或冗余token，这对应着2.4万小时的GPU运算、1526吨的二氧化碳排放，以及650万升冷却水的消耗。而SuperCompress每处理100万次压缩，就能直接避免8亿token被送入GPU，从而节省29度电力、12公斤二氧化碳和52升冷却水。单次压缩的节约量微不足道，但当它被嵌进每天数十亿次推理体量时，能耗极差便会变成可观的成本与环境收益。
目前，SuperCompress已经从个人项目落地成可随时接入的产品：一个设有免费额度的托管API、可直接在浏览器中使用的压缩演示、Python客户端库，以及针对OpenAI、LangChain、LlamaIndex等主流框架的集成指南。整套代码采用MIT协议完全开源，托管在GitHub上，Shah正在寻找第一批真实用户、集成伙伴和开源贡献者。如果你也是大模型应用的开发者，不妨在下一次调用前走一遍压缩流程，看看答案是否还是你熟悉的样子。把反馈甩过去，或许这就是你今天能做出的成本与碳足迹兼顾的高效优化。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
