Fable 5被網友薅出省錢神招！最高減70%！

henry 發自 凹非寺
量子位 | 公眾號 QbitAI

沒想到，人類當年靠微縮打印做小抄的土辦法，在大模型身上也照樣管用。

這兩天，有位機智的老哥發現，只要把Fable 5的上下文轉換成一張張密密麻麻寫滿文字的圖片，再讓模型通過OCR讀回來，token輸入成本最多能省下70%。

更離譜的是，不只是普通對話，系統提示、工具文檔、歷史記錄，全都能一股腦塞進圖里。

空說無憑，老哥還真給了一個例子：

大約4.8萬字符的系統提示詞和工具文檔，如果直接按文本輸入，大約需要2.5萬token；

但把它們渲染成一張上面1573×1248的圖片后，只需要約2700個image token。

按Fable 5現在的價格計算，實測端到端賬單下降了59%到70%。

這一圖勝過千言萬語，還真有以前考試微縮、寫小字的味兒了。

真·壓縮即智能。

網友看完直接表示：這招可千萬別讓Dario知道了。

（你也不想你的Fable 5限制上傳圖片吧）

把上下文做成小抄，賬單直接砍七成

開頭提到的這個邪修Fable 5的方法，名叫pxpipe，目前在GitHub已經收獲3000+ STAR。

在說明里，作者也是直抒胸臆的表示：

這玩意就是把Fable 5的文本上下文，渲染成圖片，以降低的token用量。

之所以能這么“邪修”，關鍵在于一個計價差異：

圖片的token成本，主要由像素尺寸決定，而不是由圖片里塞了多少文字決定。

也就是說，只要模型還能讀清圖片里的字，那么同樣一段內容，壓成一張密密麻麻的PNG，可能就比直接作為文本輸入更便宜。

尤其是代碼、JSON、工具輸出、系統提示詞、工具文檔這類內容，本身就非常token密集。

按照pxpipe作者的測算，在真實Claude Code流量中，這類內容如果作為圖片輸入，大約可以做到每個image token容納3.1個字符；

但如果作為文本輸入，約等于每個text token只能容納1個字符。

而這，就給了pxpipe操作空間。

pxpipe本質上是一個本地代理：攔截Claude Code發出的請求，在請求離開本機之前，先把其中比較臃腫、適合壓縮的上下文，重新排版成一張張緊湊的PNG圖片，再塞回請求里發給模型。

模型讀這些圖片，走的則是同一個視覺通道——也就是Anthropic的computer use功能讀取屏幕截圖時依賴的那條通道。

換句話說，pxpipe并不是讓模型“真正OCR”文本，而是利用模型本來就具備的看圖能力，把大段上下文偽裝成截圖喂進去。

說白了，就是一個自動的微縮“打印機”。

后面，為了證明這招不是純腦洞，作者也放了一個對比demo。

同樣一組任務，原始文本版本跑到最后，賬單是42.21美元，上下文窗口已經占滿96%；而pxpipe版本只花了6.06美元，上下文還只用了73.5k/1M

也就在省錢的同時，任務也照樣完成了，Fable 5依然能從圖片化上下文中讀出關鍵信息，完成計數和多步賬本運算。

不過，這也不是一招鮮吃遍天。作者用Opus 4.8跑了同樣的實驗，普通文本needle沒問題，但一到圖片化內容里的詞頻統計，Opus就讀不出來了。

與此同時，這也意味著，這是一種有損壓縮，非常吃模型的視覺讀取能力。

密集圖片里的精確字符串，Fable 5還能勉強讀，Opus就很容易翻車；更危險的是，錯了也未必報錯，而是自信編出一個看似合理的結果。

（注：這組benchmark證明：在Fable 5上，把高密度上下文渲染成圖片，基本不影響語義理解和狀態追蹤，還能顯著省token；但一旦涉及逐字讀取精確字符串，就會暴露有損壓縮的風險）

所以pxpipe也沒有把所有內容都圖片化，而是保留ID、哈希、密鑰、精確數字和最近幾輪對話，只壓縮系統提示詞、工具文檔、較早歷史記錄、大型工具輸出這些“又長又密”的內容。

最后，如果想自己試一下也很簡單，作者給的啟動方式只有兩行：

npxpxpipe-proxy# proxy on 127.0.0.1:47821ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude# point Claude Code at it

啟動后，本地還有一個dashboard：

http://127.0.0.1:47821/

里面可以看到節省了多少token、每一次文本轉圖片的前后對比、kill switch，以及當前啟用的模型標簽。

需要注意的是，pxpipe只壓縮請求，不壓縮模型輸出。也就是說，響應還是正常流式返回；它動的只是輸入側那些大塊上下文。

谷歌2022年老論文早已證明

這項目一經發出后，也是一石激起千層浪，誰叫fable 5這么貴。

有網友表示，這招我早就在用了。

還有學者翻出了谷歌2022年的老論文，CLIPPO。

簡單來說，跟pxpipe的做的差不多，CLIPPO的核心思想就是把文字也當成圖片處理

傳統CLIP通常是兩套編碼器：一套看圖，一套讀文本。

CLIPPO則直接把文本渲染成RGB圖片，讓同一個Vision Transformer同時處理真實圖片和文字圖片，連圖片 + 問題也可以拼成一張圖一起喂進去。

這樣一來，模型不再需要tokenizer、文本tower和word embedding，但在圖像分類、圖文檢索上依然接近CLIP風格模型，只差1-2個點。

也就是說，文字不一定非得以token的形式進入模型，也可以先變成像素。

此外，評論區里，還有不少網友提到了DeepSeek-OCR。

在DeepSeek OCR中，主打的就是把長上下文做成視覺壓縮。pxpipe文檔里也專門拿它解釋這條路線，低于10x壓縮時能有約97%解碼精度，接近20x時降到約60%。

所以，這次pxpipe的熱鬧可能不只是一個“省錢小工具”引發的。

它更像是把過去幾年幾條線突然接上了：CLIPPO證明，文字可以當圖看；DeepSeek-OCR證明，上下文可以做光學壓縮；

而Fable 5這代模型，則讓普通用戶第一次在真實生產工具里，摸到了這個套利空間。

話說，用圖像作文本輸入，有沒有搞頭？

[1]https://github.com/teamchong/pxpipe

[2]https://arxiv.org/pdf/2212.08045