Qwen-Compress：RTX 3090 上的 Qwen KV Cache 壓縮實驗 | Allen 知識庫 | Allen 知識庫LLM / Inference Optimization
Qwen-Compress：RTX 3090 上的 Qwen KV Cache 壓縮實驗
Qwen-Compress 是 Gavin-chen 發布在 Hugging Face 的 MIT 授權實驗專案，透過每 4 層插入 HiddenStateCompressor，以 learned weighted pooling 將部分 hidden states 4 合 1，目標是降低 Qwen 架構 KV cache prefill 成本；IFEval 幾乎不掉，但 GSM8K 推理明顯衰退，適合視為研究原型而非 production-ready 壓縮方案。
2026年7月15日3 分鐘閱讀👁 5
LLM Inference / KV Cache Compression
Qwen-Compress：把 DeepSeek 式壓縮注意力概念移植到 Qwen 的研究原型
這則 Threads 介紹的是 Gavin-chen/Qwen-Compress：一個 Hugging Face 上的 MIT 授權實驗專案，嘗試在 Qwen 架構中插入輕量 compressor，降低 prefill KV cache 成本。貼文亮點是：開發者在 GPUtw.ai 的 RTX 3090 節點上完成實驗，而不是租用 H200 叢集。
Kate 判斷：這篇值得收進 KB，但要降溫看待。它不是「無損 4 倍壓縮」；README 的實測顯示 IFEval 幾乎不掉，但 GSM8K 數學推理掉 16–33%。更精準的定位是：KV cache 壓縮研究原型 + OpenAI-compatible FastAPI demo，可用來評估長上下文 / 指令型任務的壓縮 trade-off。
來源訊號
- Threads 作者：林澈 Luke Lin（GPUtw.ai 相關貼文）。
- 主張：Gavin 只靠 GPUtw.ai 平台上的 RTX 3090，開發出 Qwen 架構上最高 4 倍 KV Cache 壓縮的 Qwen-Compress。
- 作者補充連結：Hugging Face：Gavin-chen/Qwen-Compress，並提到自帶 OpenAI 相容 API server。
- 高訊號留言：訓練仍至少需要兩張 3090；另一則留言引用 README 指出 GSM8K 成績下降，提醒壓縮對推理一定有影響。
專案實查
| 項目 | 結果 |
|---|
| 平台 | Hugging Face model repo：Gavin-chen/Qwen-Compress |
| License | MIT（model card / metadata 標示 license: mit） |
| 主要檔案 | README.md、README.zh.md、server.py、compressor checkpoint、LM_Eval.txt |
| 框架 | Transformers + PyTorch + FastAPI + bitsandbytes；server 提供 OpenAI-compatible API |
| 模型設定 | README 說測試於 Qwen3.6-27B NF4；server.py 也含 Qwen3.5-2B / 27B patch 路徑 |
| 成熟度 | 研究 / demo 原型；Hugging Face API 查詢時 downloads / likes 仍為 0，表示非常新 |
技術做法：HiddenStateCompressor
Qwen-Compress 的核心不是量化，也不是單純 prompt trick，而是在特定 Transformer layer 的 attention QKV projection 前，先壓縮 hidden states。
- 每隔 4 層插入一個
HiddenStateCompressor（layer_idx % 4 == 3）。
- compressor 對連續 4 個 hidden states 做 learned weighted pooling：用一個線性層計算每個 token 的重要性分數，再 softmax 後加權求和，將 4 個 token 壓成 1 個。
- 最後
window_size=128 個 token 不壓縮，保留 tail retention，避免近期上下文受損太大。
- 壓縮後仍追蹤 token 位置，用正確 RoPE index 避免位置錯配。
- decode 階段用 uncompressed buffer，當 buffer 達
window_size + ratio = 132 時，再把最舊 4 tokens 壓成 1 個併回 persistent KV cache。
效能與 trade-off
README 的 benchmark 是這篇最重要的部分，因為它同時支持與修正了 Threads 的行銷敘事。
| Benchmark | Baseline | Compressed | 變化 | 解讀 |
|---|
| GSM8K flexible-extract | 0.8749 | 0.7331 | −16.2% | 數學推理有明顯衰退 |
| GSM8K strict-match | 0.8658 | 0.5785 | −33.2% | 嚴格格式 / 多步驟推理更受傷 |
| IFEval inst loose | 0.8849 | 0.8897 | +0.5% | 指令遵循幾乎不受影響 |
| IFEval inst strict | 0.8525 | 0.8513 | −0.1% | 基本持平 |
| IFEval prompt strict | 0.7856 | 0.7856 | ±0.0% | 格式控制保留良好 |
壓縮率 caveat：README 英文版寫「prefill KV size up to ~1.75×」；繁中版與貼文提到最高約 4 倍。實際 README 範例是 301 tokens → 約 172 KV entries（約 1.75×），並補充非常長 prompt 才會接近 4×。所以商務/技術評估時應寫「有效壓縮率依 prompt 長度而變，長上下文更接近理論 4×」。
OpenAI-compatible API 形態
專案提供 server.py，會載入 Qwen、patch compressor，並用 FastAPI 暴露 /v1/chat/completions。README 給出的使用方式：
pip install torch transformers accelerate bitsandbytes
python server.py
curl http://localhost:8001/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "qwen-compress", "messages": [{"role": "user", "content": "1+1="}]}'
對 Allen / BigIntTech 的實用判斷
- 適合測：長上下文摘要、格式化輸出、分類、資訊抽取、客服 RAG 中「指令遵循比推理更重要」的場景。
- 不適合直接用：數學、程式推理、複雜規劃、agent 決策鏈，因 GSM8K 已顯示推理掉點。
- 可借鏡：如果 BigIntTech 做地端語音 / RAG agent，KV cache 壓縮可降低長上下文成本，但要按任務建立 eval，不可只看 IFEval。
- 部署注意：server.py 是研究實作，含本機 checkpoint path、CORS 全開、簡化併發控制；production 前需清理安全、模型路徑、監控、batching、vLLM/Transformers 相容性。
採用前 checklist
- 用自己的任務集跑 baseline vs compressed，至少含：指令遵循、長上下文 recall、推理、RAG factuality。
- 量測真正的 VRAM saving / latency / throughput，不只看 token 壓縮率。
- 分短 prompt 與長 prompt 測，因短 prompt 壓縮收益有限。
- 確認 base model 授權、checkpoint 授權與 Hugging Face repo MIT 標示是否滿足商用需求。
- 若要在 3090 上重現，保守預期訓練至少需要 2 張 3090；推理/serve 則另依模型量化與 batch 決定。
來源
快速動作