Token压缩

调研范围：LLMLingua 系列（v1 / LongLLMLingua / LLMLingua-2）项目背景、技术演进、性能数据、横向对比、工程落地 主要文献：arXiv:2310.05736（EMNLP 2023）、arXiv:2310.06839（ACL 2024）、arXiv:2403.12968（ACL Findings 2024） 一、项目背景与核心原理 1.1 动机：Prompt 膨胀是 LLM 落地的成本瓶颈 CoT、ICL、RAG 等技术的普及使 prompt 长度从几百 token 迅速膨胀到数万 token。按 GPT-4 计费标准，一次请求仅 prompt 成本就可能达 $0.3–$1+。企业级应用中，80% 的 token 开销往往集中在冗余的上下文内容里。 技术范式 对 Prompt 的影响 In-Context Learning (ICL) 注入多个 few-shot 示例，每个示例 300–600 token Chain-of-Thought (CoT) 完整推理链进一步增大示例体积 RAG（检索增强生成） 每次请求注入若干检索文档段落 Agent / 工具调用 System prompt + 对话历史 + 工具描述累积 三类影响： 成本：Token 按量计费，压缩 20× 可节省约 95% 的 input token 费用 延迟：prefill 阶段与输入长度正相关，长 prompt 直接拉高首 token 延迟（TTFT） 准确率：超长上下文有 “lost-in-the-middle” 问题——LLM 对中间位置的信息关注度显著低于首尾 1.2 核心洞察：用小模型 PPL 代理信息量 LLMLingua 的根本思路是：用廉价的小语言模型（GPT-2/LLaMA-7B）计算 token 的困惑度（Perplexity），以此作为信息重要性的代理。 ...

最近看到一个叫 Headroom 的项目，Netflix 高级工程师 Tejas Chopra 个人开源的，号称能帮你把发给 LLM 的 token 减少 30-70%，而且不丢信息。 我把源码读了一遍，发现里面有几个设计很有意思，记下来。 项目地址：https://github.com/chopratejas/headroom 本文分析的主要源文件： headroom/transforms/content_router.py — 内容识别与路由 headroom/transforms/content_detector.py — 内容类型检测 crates/headroom-core/src/transforms/smart_crusher/ — SmartCrusher Rust 实现 crates/headroom-core/src/transforms/log_compressor.rs — 日志压缩 Rust 实现 headroom/transforms/cache_aligner.py — CacheAligner headroom/ccr/tool_injection.py — CCR 工具注入 它解决的是什么问题 你在用 Claude 或 GPT 做 agent 的时候，工具调用（tool call）的返回结果会吃掉大量 token。 比如你让 agent 查数据库，返回了 500 条记录，每条有 15 个字段。但其中 12 个字段在所有记录里都是完全相同的值，真正有用的只有 3 个字段。你把 500 × 15 的数据全塞给 LLM，它实际只需要 500 × 3。 这就是浪费。Headroom 做的事，就是在你把数据发给 LLM 之前，先把这些废话压掉。 ...