henry 發(fā)自 凹非寺
量子位 | 公眾號(hào) QbitAI

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

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

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

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

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

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

按Fable 5現(xiàn)在的價(jià)格計(jì)算，實(shí)測(cè)端到端賬單下降了59%到70%。

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

真·壓縮即智能。

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

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

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

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

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

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

之所以能這么“邪修”，關(guān)鍵在于一個(gè)計(jì)價(jià)差異：

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

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

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

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

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

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

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

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

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

說白了，就是一個(gè)自動(dòng)的微縮“打印機(jī)”。

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

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

也就在省錢的同時(shí)，任務(wù)也照樣完成了，F(xiàn)able 5依然能從圖片化上下文中讀出關(guān)鍵信息，完成計(jì)數(shù)和多步賬本運(yùn)算。

不過，這也不是一招鮮吃遍天。作者用Opus 4.8跑了同樣的實(shí)驗(yàn)，普通文本needle沒問題，但一到圖片化內(nèi)容里的詞頻統(tǒng)計(jì)，Opus就讀不出來了。

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

密集圖片里的精確字符串，F(xiàn)able 5還能勉強(qiáng)讀，Opus就很容易翻車；更危險(xiǎn)的是，錯(cuò)了也未必報(bào)錯(cuò)，而是自信編出一個(gè)看似合理的結(jié)果。

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

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

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

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

啟動(dòng)后，本地還有一個(gè)dashboard：

http://127.0.0.1:47821/

里面可以看到節(jié)省了多少token、每一次文本轉(zhuǎn)圖片的前后對(duì)比、kill switch，以及當(dāng)前啟用的模型標(biāo)簽。

需要注意的是，pxpipe只壓縮請(qǐng)求，不壓縮模型輸出。也就是說，響應(yīng)還是正常流式返回；它動(dòng)的只是輸入側(cè)那些大塊上下文。

谷歌2022年老論文早已證明

這項(xiàng)目一經(jīng)發(fā)出后，也是一石激起千層浪，誰叫fable 5這么貴。

有網(wǎng)友表示，這招我早就在用了。

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

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

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

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

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

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

此外，評(píng)論區(qū)里，還有不少網(wǎng)友提到了DeepSeek-OCR。

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

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

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

而Fable 5這代模型，則讓普通用戶第一次在真實(shí)生產(chǎn)工具里，摸到了這個(gè)套利空間。

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

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

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