砍掉90%冗余詞元，省下70萬美元：Netflix開源工具狙擊AI賬單黑洞

正如 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

本文來自微信公眾號「AI前線」，作者：Joab Jackson；；譯者：明知山，36氪經授權發佈。