作者丨 Joab Jackson

譯者丨明知山

策劃丨 Tina

正如 Uber 和微軟 COO 最近所領教的那樣，鼓勵公司工程師積極使用 AI 可能會帶來巨額賬單，甚至可能抵消裁員帶來的所有收益。

不過 Netflix 的 AI 賬單或許不會那么觸目驚心，這要歸功于公司的高級工程師 Tejas Chopra，他開發了一款軟件，可以在指令到達大語言模型之前，以詞元為單位對智能體指令進行精簡。

Chopra 估計，高達 90% 的詞元對于你所選擇的模型來說都是冗余的。

盡管這并非 Netflix 的正式項目，但公司內部已有多個團隊在使用 Headroom（https://github.com/chopratejas/headroom），不少外部項目也依賴它。

在近期的開源峰會上，Chopra 表示，Headroom 已為用戶節省了約 70 萬美元，這些用戶可以將節省的 2000 億詞元用在其他地方。

對于一個今年 1 月份才發布的開源應用來說，這樣的成績已經相當不錯了。Headroom 目前仍處于較為初級的 v0.22 版本，已在 GitHub 上收獲 2000 個星標，被復刻超過 120 次。

“我們的很多用戶都是那些真正被詞元成本灼傷過的人，”Chopra 在演講中說道。

無損上下文壓縮

一筆來自 Claude Sonnet 的 287 美元賬單讓 Chopra 第一次留意到詞元成本優化的問題。

這筆賬單是典型的個人項目開銷：一些調試、一些重構、MCP 工具查詢數據庫。當時，Claude Sonnet 按詞元計價的收費標準看似十分劃算：每百萬輸入詞元收費 3 美元，如果超出上下文窗口的 20 萬詞元限制，每百萬收費 6 美元。即便資費單價不高，最終費用還是一路累積到了 287 美元。

仔細檢查后，Chopra 發現傳輸給大模型的數據里存在大量冗余內容。整體來看，他手動編寫的指令并非開銷偏高的元兇，真正的問題在于附帶的各類樣板代碼與機器元數據：冗余繁瑣的 JSON 結構、API 返回內容里層層嵌套的模板、大量重復的數據庫字段。

“這并非散文創作，也不是創意寫作，而是偽裝成文本的可壓縮數據，”Chopra 在一篇介紹這款軟件的博客文章中寫道。2025 年，一組研究人員發現，讀取用戶輸入約占所有詞元消耗的 76%。

模型廠商也提出了自己的詞元成本優化工具。但迄今為止，這些工具的設置對終端用戶來說有些晦澀難懂。默認情況下，Claude 的前綴緩存設置僅為 5 分鐘，閑置 5 分鐘不活動，整個上下文窗口都需要刷新，即使大模型需要的數據是完全一樣的。接口文檔里還標注了一小時的生存時間（TTL）配置，但這里暗藏陷阱。“你的寫入成本要翻倍才能換來讀取時 90% 的節省，”Chopra 告訴聽眾。找到最佳平衡點只能靠你自己了。

市面上也出現了不少新的商用“詞元精簡工具”，比如獲得 Y Combinator 投資的 Token Company（https://thetokencompany.com/），提供詞元壓縮即服務。開源領域則有 RTK（Rust Token Killer，https://www.rtk-ai.app/），它修剪冗長命令的輸出，比如對代碼倉庫的調用。另一個開源項目 LeanCTX（https://leanctx.com/） 是 RTK 的一個變體。

Chopra 承認這些工具都有用，但他設計 Headroom 的初衷是讓操作內嵌在開發者的工作流中，而且它具備其他應用和服務都無法提供的功能：可逆壓縮。

Headroom 會壓縮所有輸入用戶上下文窗口的源材料——不僅包括對話歷史，還包括日志、工具輸出、文件、RAG 檢索出的文檔片段——在它們到達大模型之前。

上下文窗口是單用戶會話的固定存放空間。當下頂尖的模型正迅速將上下文窗口擴展至 200 萬詞元以上，同時容納輸入和輸出。

正如 Pope Leo 所言，這種慷慨是一把雙刃劍。作為計量單位，單個詞元大致相當于一個人類詞匯。在按量計費模式下，塞入上下文窗口的內容越多，產生的費用也就越高。

像吃豆人一樣吃掉詞元

Headroom 基于 Python 和 Node，作為代理形式（端口 8787）在工程師的設備上運行。用戶在命令行界面對大語言模型進行包裝（例如headroom wrap codex），工具便會自動解析輸入內容。

雖然 Headroom 確實會壓縮部分代碼和人工指令，但它最擅長的是精簡服務器日志（其中 90% 可以丟棄）、MCP 工具輸出（70% 是冗余 JSON）、數據庫輸出和文件樹（大量重復的元數據）。

Headroom 的第一步是一個叫作 CacheAligner 的過程，它只在已輸入的內容中尋找發生變化的信息，只向大模型發送新增的內容，省去替換 KV 緩存內絕大部分未變動全文的操作。KV 緩存是 AI 供應商存儲用戶上下文窗口的緩存。

“如果系統提示詞里帶有日期字段或是每輪會話都會自動變化的 UUID，每次調用都會出現緩存未命中的情況，”他向聽眾說道，“進而造成成本大幅飆升。”

隨后會經過路由處理識別數據類型，再發給對應的壓縮器。抽象語法樹（AST）壓縮器負責壓縮程序代碼，JSON 壓縮器、文檔對象模型（DOM）壓縮器則分別剔除冗余 JSON 與網頁模板代碼。

Headroom 還提供了一些精簡處理器，它們讀取文本或 JSON 輸入，基于統計分析篩選有效內容。這些工具依靠反饋循環迭代優化壓縮程度，根據模型調取原始未壓縮提示詞的頻次來判斷壓縮是否過量或壓縮不足。

最后一步為 CCR（壓縮緩存與讀取），讓大模型能夠調取原始未壓縮數據。這個過程會在數據壓縮處打上標記，倘若大模型需要原始上下文，可通過 Headroom MCP 從用戶本地設備拉取對應內容，原始數據統一存放在 Redis 或 SQLite 數據庫中。

Chopra 坦言這個工具棧仍有待完善，特別是在測試準確性方面。這個難度應該不會很高，因為 CCR 存儲了原始提示詞，后續還可針對金融數據等特殊數據類型開發專屬壓縮器。

音頻、圖像和視頻同樣需要做壓縮處理（已有用戶復刻項目用于視頻解析）。Chopra 透露，相關項目 Headlight 即將開源。Headlight 將追蹤每個詞元的來源，這對于確保多模型工作的準確性來說可能特別有用。

省一個詞元就是賺了一個詞元

相關研究顯示，合理管控詞元用量既能節省開支，也有助于提升模型輸出效果。

智能體推送的上下文超出模型實際所需，不僅會大幅增加用戶開銷，還會導致大模型的生成效果變差。

和人類一樣，大模型在面對過多信息時也會出現判斷混亂。斯坦福大學的一些學者發現，大模型更關注上下文窗口的開頭和結尾，容易忽略中間部分。

同樣，來自數據集成商 Chroma 的一組研究人員推斷，在參與測評的 18 款大模型里，“輸入文本越長，模型輸出穩定性就越差”。

他們將這種現象稱為“上下文腐爛”（Context Rot）。

精簡提示詞還能降低響應延遲。Chopra 在演講中提到 Headroom 的一位用戶復刻了該軟件用于語音交互應用。對于語音來說，即使是沉默也會產生詞元。用戶期望應用能夠在 200 毫秒內做出響應，這樣服務聽起來才自然，因此這家公司正在使用 Headroom 最大限度地縮短延遲窗口。

對于擔憂數據中心能耗加劇全球變暖的人群來說，Headroom 算得上是一個好消息。更少的詞元意味著更小的上下文窗口，也就是更少的能源消耗——當然前提是杰文斯悖論尚未生效，不然人們總會想出更耗能的辦法去生成各類動畫貓咪短片。

https://www.theregister.com/ai-ml/2026/05/31/netflix-wiz-creates-app-to-slash-ai-bills-then-open-sources-it/5248702

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。