Headroom深度解析：AI Agent上下文压缩层的架构革命——Token成本暴降95%与可逆压缩的完整实战指南

当Claude Code、Cursor、Codex成为日常开发标配，一个被忽视的成本黑洞正在膨胀——上下文窗口中堆积的工具输出、日志、RAG片段和对话历史。Headroom用六大压缩算法+可逆存储机制，为这个2026年最棘手的工程问题交出了一份务实的答卷。

一、问题：你的AI Agent在「吃」Token，你在「烧」钱

2026年，AI编码助手已从「尝鲜玩具」变成「生产力基础设施」。Claude Code、Cursor、GitHub Copilot、Codex——每个开发者桌面上至少跑着两三个AI Agent。但一个尴尬的现实是：你付给LLM的钱，大量花在了它「读废话」上。

1.1 一个典型的SRE故障排查场景

想象一个SRE工程师让AI Agent排查Kubernetes集群故障：

# Agent执行的命令及典型输出量
kubectl get pods -A          # ~2000 tokens
kubectl describe pod xxx     # ~3000 tokens  
docker logs xxx --tail 500   # ~8000 tokens
git log --oneline -50        # ~1500 tokens

一个简单的故障排查流程，Agent产生的工具输出轻松突破20,000 tokens。再加上RAG检索返回的代码搜索结果（100条结果 × 每条约150 tokens = 15,000 tokens），以及不断累积的多轮对话历史，一次会话的上下文窗口可能被撑到50,000-100,000 tokens。

根据Gartner 2026年3月的预测，虽然万亿参数LLM的推理成本到2030年将下降90%，但眼下，一个每天重度使用AI Agent的开发者，月Token开销轻松突破500-1000美元。

1.2 更隐蔽的问题：KV Cache失效

Token成本只是冰山一角。更隐蔽的问题是KV Cache命中率暴跌。

Anthropic和OpenAI的推理优化依赖于稳定的前缀缓存（Prompt Caching）：如果请求的前缀和之前一样，就不需要重新计算KV矩阵，推理延迟和成本都会大幅降低。

但问题在于：

• 工具输出中包含时间戳（2026-07-05T13:09:17.796Z）
• 日志中有进程ID（PID: 28457）
• 搜索结果包含随机哈希（commit SHA: a3f8b2c）
• 每次请求的前缀都在变化，Cache命中率极低

这意味着你不仅在为「废话」付费，还在为「无法缓存」重复付费。

1.3 传统方案的局限

面对这个问题，业界的主流方案各有短板：

没有一个方案能同时解决「压缩率」「信息保留」「LLM可理解性」三个问题。

Headroom的出现，正是为了填补这个空白。

二、Headroom是什么？

Headroom是一个本地运行的上下文压缩中间层，在数据到达LLM之前进行智能压缩。它的核心理念是：

不改变Agent的行为，只压缩它「看到」的内容。

Agent → [Headroom 压缩层] → LLM Provider
              ↓
    原文存入本地 CCR 仓库（可逆）

这个设计哲学非常关键——Headroom不需要你修改Agent的代码、改变工作流程，甚至不需要知道你在用哪个Agent。它只是一个透明的「中间人」，在数据流经时进行压缩。

2.1 四种接入方式

Headroom提供了从零侵入到深度集成的四种接入模式：

# 方式一：Library模式（Python/TS应用内联调用）
from headroom import compress
messages = [{"role": "user", "content": "分析这段代码..."}]
compressed = compress(messages, model="claude-sonnet-4-20250514")
# compressed.messages 就是压缩后的消息，直接发给LLM

# 方式二：Proxy模式（零代码，所有请求经过本地代理）
headroom proxy --port 8787
# 之后所有LLM请求改为 localhost:8787 即可

# 方式三：Agent Wrap模式（一行命令，推荐）
headroom wrap claude    # 自动配置Claude Code
headroom wrap cursor    # 自动配置Cursor
headroom stats          # 查看节省了多少Token

// 方式四：MCP Server模式（标准MCP协议）
// 在MCP客户端配置中添加：
{
  "mcpServers": {
    "headroom": {
      "command": "headroom",
      "args": ["mcp", "serve"]
    }
  }
}

对于大多数开发者，Wrap模式是最佳选择——一行命令搞定，零配置，立即生效。

三、架构拆解：六大压缩算法 + 核心机制

Headroom的压缩管线是一个10阶段生命周期：

Setup → Pre-Start → Post-Start → Input Received → Input Cached
→ Input Routed → Input Compressed → Input Remembered
→ Pre-Send → Post-Send → Response Received

其中最核心的是六大压缩算法和两个配套机制。逐一拆解：

3.1 ContentRouter — 智能内容路由器

ContentRouter是整个压缩管线的「调度中心」。它不执行压缩，而是检测输入内容的类型，将不同数据分发到最适合的压缩器：

# ContentRouter的路由逻辑（伪代码）
class ContentRouter:
    def route(self, content: str) -> Compressor:
        if self.is_json(content):
            return SmartCrusher()        # JSON数据 → SmartCrusher
        elif self.is_code(content):
            return CodeCompressor()      # 代码文件 → CodeCompressor
        elif self.is_image(content):
            return ImageCompressor()     # 图片 → ImageCompressor
        else:
            return KompressBase()        # 自然语言 → Kompress-base

这种按内容类型选择压缩策略的设计，比「一刀切」的通用压缩效果好得多。你不会用压缩JSON的方式去压缩Python代码，也不会用压缩代码的方式去压缩自然语言对话——每种内容类型都有最适合的压缩器。

3.2 SmartCrusher — JSON专用压缩器

AI Agent的工具输出大量是JSON格式：API响应、代码搜索结果、数据库查询结果、配置文件dump……SmartCrusher专门处理这类数据。

它的压缩策略包括三个层面：

结构扁平化：将深层嵌套JSON压平为更紧凑的表示：

// 原始JSON（嵌套3层，120 tokens）
{
  "data": {
    "results": [
      {
        "file": {
          "path": "/src/main.py",
          "metadata": {
            "size": 4523,
            "modified": "2026-07-05T10:30:00Z",
            "author": "dev@example.com"
          }
        },
        "match": {
          "line": 42,
          "content": "def process_request(req):"
        }
      }
    ]
  }
}

// SmartCrusher压缩后（扁平化，约45 tokens）
[
  {"f": "/src/main.py", "l": 42, "c": "def process_request(req):", "s": 4523}
]

冗余消除：对重复的键值模式进行去重。比如100条搜索结果中，"type": "file"出现100次——SmartCrusher会在数组级别消除这种冗余。

类型感知裁剪：根据值类型选择最优编码。布尔值true/false比字符串"true"/"false"更省token；数字比等价的字符串描述更紧凑。

实测数据：100条代码搜索结果从17,765 tokens压缩到1,408 tokens，节省92%。

3.3 CodeCompressor — AST感知代码压缩

这是Headroom最精巧的设计之一。它不是简单地截断代码，而是基于AST（抽象语法树）进行结构感知压缩，支持Python、JavaScript、Go、Rust、Java、C++六种语言。

# 原始代码（约80 tokens）
def calculate_metrics(data: pd.DataFrame, 
                      window: int = 30,
                      threshold: float = 0.95) -> dict:
    """
    Calculate rolling metrics with anomaly detection.
    Returns dict with keys: mean, std, anomalies, trend.
    """
    rolling_mean = data.rolling(window=window).mean()
    rolling_std = data.rolling(window=window).std()
    anomalies = data[abs(data - rolling_mean) > threshold * rolling_std]
    trend = "up" if rolling_mean.iloc[-1] > rolling_mean.iloc[-window] else "down"
    return {"mean": rolling_mean, "std": rolling_std, 
            "anomalies": anomalies, "trend": trend}

# AST压缩后（保留骨架，约25 tokens）
def calculate_metrics(data: DataFrame, window=30, threshold=0.95) -> dict:
    # → rolling mean/std, anomaly detection, trend analysis
    ...

AST感知压缩的核心思路是：保留代码的结构骨架（函数签名、类定义、导入关系、类型注解），对实现细节进行压缩（函数体替换为一行摘要）。

这使得LLM仍然能「理解」代码的整体架构——知道有哪些函数、参数类型是什么、返回什么——而不需要逐行阅读每个实现细节。当LLM确实需要看完整实现时，可以通过CCR机制按需检索原文。

3.4 Kompress-base — 专为Agent场景训练的压缩模型

这是Headroom团队在HuggingFace上发布的专用压缩模型，在Agent交互轨迹数据上训练（"trained on agentic traces"）。

与通用文本压缩不同，Kompress-base针对Agent的对话模式进行了专门优化：

• 工具调用模式：识别function_call/tool_use等结构，压缩中间参数但保留函数名和关键参数
• 推理链路：压缩冗长的CoT推理过程，保留关键决策节点
• 错误信息：压缩堆栈跟踪，保留错误类型和关键行号
• 多轮对话：识别重复的确认/反馈模式，压缩为状态标记

# 原始Agent对话（约200 tokens）
"""
User: 帮我修复这个bug
Assistant: 我来分析一下。首先让我查看错误日志。
[Tool Call: read_file("error.log")]
[Tool Output: ERROR 2026-07-05 10:30:15.123 [pool-3-thread-7] 
com.example.service.UserService - NullPointerException at line 142
at com.example.service.UserService.getUser(UserService.java:142)
at com.example.controller.UserController.handleRequest(UserController.java:87)
... (stack trace continues for 30 lines)]
Assistant: 我看到了，是一个NullPointerException。让我查看UserService.java的第142行。
[Tool Call: read_file("UserService.java", lines="135-150")]
[Tool Output: ... (16 lines of code)]
Assistant: 找到了！问题在于getUser方法没有做null检查...
"""

# Kompress-base压缩后（约60 tokens）
"""
[Task: fix bug]
[Error: NPE @UserService.java:142 in getUser()]
[Code: getUser()缺少null检查]
[Fix: 添加null检查并返回Optional]
"""

3.5 Image Compressor — 图片压缩

在多模态Agent场景中，图片（截图、UI截图、架构图）是重要的上下文来源，但也是Token消耗大户。Image Compressor通过训练好的ML路由器选择最优压缩策略：

• UI截图：保留关键UI元素和布局，降低分辨率和色彩深度
• 代码截图：高对比度保留文字可读性
• 架构图：保留线条和形状，压缩背景和装饰元素

实测可实现40-90%的体积缩减，同时保持LLM对图片内容的理解能力。

3.6 IntelligentContext — 基于重要性评分的上下文拟合

IntelligentContext不是一个独立的压缩器，而是一个全局调度器。当上下文窗口空间不足时，它会根据每条信息的学习到的重要性分数来决定保留哪些内容：

class IntelligentContext:
    def fit_to_window(self, messages, max_tokens):
        scored_messages = []
        for msg in messages:
            score = self.importance_model.score(
                content=msg.content,
                recency=msg.timestamp,
                role=msg.role,
                tool_relevance=msg.tool_call_id,
                conversation_flow=self.flow_analysis(msg)
            )
            scored_messages.append((score, msg))
        
        # 按重要性排序，贪心填充窗口
        scored_messages.sort(reverse=True)
        result = []
        current_tokens = 0
        for score, msg in scored_messages:
            if current_tokens + msg.token_count <= max_tokens:
                result.append(msg)
                current_tokens += msg.token_count
            else:
                # 低重要性消息存入CCR，LLM可按需检索
                self.ccr_store.save(msg)
        return result

关键设计：被裁剪的消息不是被丢弃，而是存入CCR仓库。LLM如果后续需要这些信息，可以通过headroom_retrieve工具按需检索。这实现了「什么都不丢」的承诺。

3.7 CacheAligner — KV Cache命中率优化

这是一个被很多人忽视但极其重要的组件。

class CacheAligner:
    def stabilize_prefix(self, messages):
        """将动态值替换为固定占位符，稳定化请求前缀"""
        stabilized = []
        for msg in messages:
            content = msg.content
            # 替换时间戳
            content = re.sub(
                r'\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}[\.\d]*Z?',
                '<TIMESTAMP>', content
            )
            # 替换UUID
            content = re.sub(
                r'[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}',
                '<UUID>', content
            )
            # 替换进程ID
            content = re.sub(r'PID:\s*\d+', 'PID:<NUM>', content)
            # 替换commit SHA
            content = re.sub(r'[0-9a-f]{7,40}', '<HASH>', content)
            stabilized.append({"role": msg.role, "content": content})
        return stabilized

CacheAligner的做法是稳定化前缀：将动态值（时间戳、UUID、哈希、进程ID等）替换为固定占位符，让相同的请求结构产生相同的前缀，从而大幅提升KV Cache命中率。

在高频调用场景下，这不仅节省Token（缓存的前缀计算成本更低），还显著降低推理延迟（省去了重复的前缀计算）。

3.8 CCR — 可逆压缩（Context Compression with Retrieval）

这是Headroom区别于所有竞品的核心特性。

传统压缩是有损的、不可逆的——信息一旦压缩就丢失了。CCR的做法是：

原始数据 → Headroom压缩 → 压缩后数据 → 发送给LLM
    ↓
本地CCR仓库（原始数据完整保留）

当LLM需要原始信息时：

LLM: "我需要看第42条搜索结果的完整代码"
  → 调用 headroom_retrieve(id=42)
  → Headroom从CCR仓库返回原始内容
  → LLM获得完整信息

这相当于给LLM一个**「放大镜」**——平时看摘要，需要时看原文。

# CCR的工作原理（简化版）
class CCRStore:
    def __init__(self, db_path=".headroom/ccr.db"):
        self.db = sqlite3.connect(db_path)
        self._init_tables()
    
    def save(self, content_id, original_content, compressed_summary):
        """保存原始内容和压缩摘要的映射"""
        self.db.execute(
            "INSERT INTO ccr_entries (id, original, summary, created_at) "
            "VALUES (?, ?, ?, ?)",
            (content_id, original_content, compressed_summary, 
             datetime.utcnow().isoformat())
        )
        self.db.commit()
    
    def retrieve(self, content_id):
        """按ID检索原始内容"""
        cursor = self.db.execute(
            "SELECT original FROM ccr_entries WHERE id = ?",
            (content_id,)
        )
        row = cursor.fetchone()
        return row[0] if row else None

CCR仓库存储在本地（~/.headroom/ccr.db），数据永远不会离开你的机器。这对安全性敏感的企业环境尤其重要。

3.9 跨Agent记忆共享

Headroom还有一个杀手级特性：跨Agent记忆共享。

当你同时使用Claude Code、Cursor、Codex等多个Agent时，每个Agent都有独立的上下文——它们不知道彼此做了什么。Headroom的跨Agent记忆机制打破了这个壁垒：

# Claude Code在一个会话中发现了一个bug
headroom remember "发现UserService.java:142的NPE问题，原因是缺少null检查"

# 切换到Cursor继续工作
headroom recall "UserService"
# → 返回：发现UserService.java:142的NPE问题，原因是缺少null检查

这在以下场景中尤其有价值：

• 多Agent协作：不同Agent负责不同模块，需要共享上下文
• 会话切换：新会话需要知道之前会话做了什么
• 团队协作：团队成员的Agent可以共享知识（需要额外配置）

四、基准测试：压缩率与精度的平衡

Headroom的基准测试覆盖四个维度，数据来自官方仓库：

几个值得注意的发现：

数学推理完全不降：GSM8K上精度与未压缩基线持平，说明Headroom的压缩不会损害LLM的逻辑推理能力。

事实准确性反而提升：TruthfulQA上压缩后精度提高了3个百分点。这可能是因为压缩去除了干扰信息（冗余的工具输出、重复的确认对话），让模型更专注于关键事实。

工具调用几乎无损：BFCL（Berkeley Function Calling Leaderboard）上保留了97%的精度，这对Agent场景至关重要——工具调用是Agent的核心能力，压缩不能损害这个能力。

Token节省显著：在SQuAD v2上实现81%的Token节省，在BFCL上实现68%的Token节省。

五、竞品对比：Headroom的差异化在哪？

值得注意的是，Headroom并不排斥竞品——它内置了RTK作为CLI输出的预处理器，并支持lean-ctx作为替代上下文工具。这种**「组合优于替代」**的思路很务实。

六、实战：从零到生产的完整部署

6.1 安装

# 方式一：pip安装（推荐）
pip install "headroom-ai[all]"

# 方式二：uv安装（更快）
uv pip install "headroom-ai[all]"

# 方式三：从源码安装
git clone https://github.com/chopratejas/headroom.git
cd headroom
pip install -e ".[all]"

6.2 配置Claude Code（Wrap模式）

# 一行命令，自动配置
headroom wrap claude

# 验证配置
headroom stats
# 输出示例：
# ╭──────────────────────────────────╮
# │ Headroom Stats                   │
# ├──────────────────────────────────┤
# │ Sessions: 47                     │
# │ Tokens Saved: 2,847,321         │
# │ Compression Ratio: 73.2%        │
# │ Avg Precision: 96.8%            │
# │ CCR Entries: 1,247              │
# ╰──────────────────────────────────╯

6.3 配置Proxy模式（适合团队共享）

# 启动代理
headroom proxy --port 8787 --cache-dir ~/.headroom/shared

# 在Agent配置中设置API endpoint为本地代理
# 例如Claude Code的环境变量：
export ANTHROPIC_BASE_URL=http://localhost:8787

# 团队成员共享同一个代理实例
headroom proxy --port 8787 --bind 0.0.0.0 --auth-token team-secret

6.4 Python代码集成

from headroom import compress, CCRStore

# 初始化CCR仓库
ccr = CCRStore(db_path=".headroom/ccr.db")

# 压缩消息
messages = [
    {"role": "system", "content": "你是一个代码助手..."},
    {"role": "user", "content": "帮我分析这段代码的问题"},
    {"role": "assistant", "content": "我来分析..."},
    {"role": "tool", "content": very_long_tool_output},  # 大段工具输出
]

compressed = compress(
    messages, 
    model="claude-sonnet-4-20250514",
    ccr_store=ccr,
    target_ratio=0.3,  # 目标压缩到30%
)

print(f"原始tokens: {compressed.original_tokens}")
print(f"压缩后tokens: {compressed.compressed_tokens}")
print(f"压缩率: {compressed.ratio:.1%}")

# 发送压缩后的消息给LLM
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=compressed.messages
)

# 如果LLM需要原始信息，通过CCR检索
if response.stop_reason == "tool_use":
    tool_call = response.content[-1]
    if tool_call.name == "headroom_retrieve":
        original = ccr.retrieve(tool_call.input["id"])
        # 将原始信息返回给LLM

6.5 headroom learn：从失败中学习

这是Headroom最具「Agent味」的功能：

# 分析最近的失败会话，提取教训
headroom learn --session-id claude-20260705

# 自动写入CLAUDE.md
headroom learn --output CLAUDE.md

headroom learn会：

1. 分析Agent的失败会话（比如代码修改后测试失败、方案被否定）
2. 提取失败原因和修正方案
3. 自动写入CLAUDE.md / AGENTS.md / GEMINI.md

# 自动写入的教训（示例）

## 2026-07-05: UserService NPE修复
- **问题**: getUser()方法没有做null检查
- **教训**: 所有从外部数据源获取的方法，返回值都应该做null检查
- **建议**: 使用Optional<T>包装可能为null的返回值

这相当于给Agent一个**「错题本」**——下次遇到类似问题，它会自动参考之前的教训。

七、与Context Engineering的关系

Headroom不是一个孤立的工具，它是Context Engineering这个新兴工程学科的重要组成部分。

7.1 什么是Context Engineering？

Context Engineering是2026年兴起的一个工程学科，专注于优化LLM的上下文窗口使用。它的核心思想是：上下文窗口是一种稀缺资源，需要像管理内存一样精心管理。

Token预算分配（类比内存管理）：
┌─────────────────────────────────────────┐
│ 指令与边界（System Prompt）    ~10%     │
├─────────────────────────────────────────┤
│ 历史与记忆（对话历史）         ~30%     │
├─────────────────────────────────────────┤
│ 检索块（RAG结果）             ~25%     │
├─────────────────────────────────────────┤
│ 工具返回（Tool Output）       ~25%     │
├─────────────────────────────────────────┤
│ 预留输出空间                   ~10%     │
└─────────────────────────────────────────┘

Headroom在这个框架中的定位是：优化「工具返回」和「历史与记忆」两个池子的使用效率。

7.2 学术前沿

2025-2026年，上下文压缩领域有几个重要研究方向：

ACON框架（微软研究院，ICML 2026）：提出Agent Context Optimization，在自然语言空间中迭代优化压缩策略。在AppWorld、OfficeBench和Multi-objective QA上实现了26-54%的峰值Token削减，同时提升任务成功率。蒸馏到小模型后，小模型作为长周期Agent的性能最高提升46%。

SWE-Pruner（2026.01）：针对编码Agent的自适应上下文裁剪框架，基于0.6B参数的Qwen3-Reranker骨干，使用CRF层进行行级保留决策。在SWE-Bench Verified上实现最高54% Token减少，交互轮次减少最高26%。

ContextPilot（MLSys 2026）：引入上下文复用机制，通过最大化前缀复用和去重来加速LLM预填充阶段，将推理延迟降低最高3倍。

Headroom的CCR（可逆压缩）和跨Agent记忆设计，恰好处于这些研究方向的交汇点。它不是一个简单的「Token削减器」，而是一个上下文管理系统——这让它的上限比单纯的压缩工具高得多。

八、适用场景与最佳实践

8.1 最适合的场景

重度AI编码用户：每天使用Claude Code/Cursor超过4小时，月Token开销超过200美元。Headroom可以将这个数字降低60-80%。

多Agent工作流：同时使用Claude Code、Cursor、Codex等多个Agent，需要跨Agent共享上下文。Headroom的跨Agent记忆是目前唯一的开源方案。

RAG应用开发者：RAG检索结果是Token消耗大户，SmartCrusher对JSON格式的搜索结果压缩效果尤其出色（92%压缩率）。

SRE/运维场景：大量命令输出、日志、配置文件需要LLM分析，这些内容的压缩率通常在80-95%。

8.2 不太适合的场景

轻度使用：每天只用AI Agent聊几句话，Token开销不敏感。Headroom的收益不足以覆盖配置成本。

纯Provider原生压缩：只用OpenAI的Compaction，且够用。但要注意OpenAI Compaction只压缩对话历史，不管工具输出。

沙箱环境：无法运行本地进程的环境（如某些CI/CD管道）。Headroom需要本地运行来维护CCR仓库。

8.3 性能调优建议

# 调整压缩目标（默认0.3，即压缩到30%）
headroom config set target_ratio 0.4  # 更保守，保留更多信息

# 调整CCR仓库大小限制
headroom config set ccr_max_size 10GB  # 默认5GB

# 启用/禁用特定压缩器
headroom config set compressors.enabled code true
headroom config set compressors.enabled image false  # 禁用图片压缩

# 查看详细统计
headroom stats --detailed --since 7d

九、技术展望：上下文压缩的下一步

9.1 从压缩到智能调度

当前的上下文压缩主要关注「如何压缩」，但未来的方向是「如何调度」。想象一个智能调度器：

• 根据任务类型自动调整压缩策略（编码任务保留更多代码上下文，对话任务保留更多历史）
• 预测LLM接下来需要什么信息，提前预加载到上下文窗口
• 根据LLM的反馈动态调整压缩率（如果LLM频繁检索原始信息，说明压缩过度了）

9.2 压缩模型的进化

Kompress-base是第一个专门为Agent场景训练的压缩模型，但它只是开始。未来的压缩模型可能会：

• 支持更多语言和框架（目前只支持6种语言的AST感知）
• 实现跨模态压缩（将图片、音频、视频统一压缩）
• 支持增量压缩（只压缩新增的内容，不重复压缩已有内容）

9.3 与LLM推理的深度集成

当前Headroom是在LLM外部进行压缩。未来可能会看到：

• LLM原生支持压缩上下文（在注意力机制层面优化）
• 推理引擎内置压缩能力（vLLM、SGLang等推理框架集成压缩层）
• 压缩感知的推理优化（根据压缩后的内容结构优化KV Cache策略）

十、总结

Headroom的核心价值可以浓缩为一句话：让AI Agent在更少的Token里看到同样多的信息。

它的六大压缩算法覆盖了Agent日常遇到的所有内容类型（JSON、代码、自然语言、图片），CCR可逆机制解决了「压缩后信息丢失」的行业痛点，CacheAligner从KV Cache层面进一步优化成本，跨Agent记忆则为多Agent协作场景提供了基础设施。

在Token成本仍是AI Agent规模化瓶颈的2026年，Headroom提供了一个务实且工程化的解决方案。它不会让Token变得免费，但它能让你的每一分钱都花在刀刃上。

项目信息：

• 仓库：https://github.com/chopratejas/headroom
• 文档：https://headroom-docs.vercel.app/docs
• 压缩模型：https://huggingface.co/chopratejas/kompress-base
• 许可证：Apache 2.0