傳統的 token 擴展方式已經走到了算力成本的天花板。與其硬扛百萬級 token 的計算壓力，不如讓 AI "看"文字，而不是"讀"文字。

不知道是否是巧合，DeepSeek與智譜都想到了這一個思路，并同時對外發布，DeepSeek發布了DeepSeek-OCR，而智譜發布了一個名為 Glyph 的框架，直接工程化的實現了這一思路。

不過，大家可能被deepseek吸引了注意力，而沒有注意到它，筆者今天介紹介紹。

核心思想

傳統方法要么擴展位置編碼，要么修改注意力機制，但計算和內存開銷仍然隨 token 數量線性增長。檢索方法能減少輸入，但可能遺漏關鍵信息，還會增加延遲。

Glyph 換了個角度：改變數據表示方式。把文本轉成圖片，讓已經具備 OCR、布局理解和推理能力的視覺-語言模型來處理。這樣每個視覺 token 能編碼更多字符，固定的 token 預算能覆蓋更多原始內容。它將傳統的序列建模問題轉化為多模態問題，在保持語義信息的同時大幅降低計算成本。

如圖，240K tokens 的《簡·愛》文本，通過 LLM 壓縮到 80K tokens，然后轉換成圖像讓 VLM 處理。整個過程實現了 3 倍壓縮。

訓練流程

Glyph 的訓練分三個階段：

持續預訓練：讓視覺-語言模型接觸大量不同排版風格的渲染長文本。目標是對齊視覺和文本表示，將長文本理解能力從文本 token 轉移到視覺 token。

LLM 驅動的渲染搜索：這是個有趣的設計。用大語言模型驅動的遺傳算法來優化渲染參數，包括頁面大小、DPI、字體、字號、行高、對齊方式、縮進和間距。在驗證集上評估候選配置，同時優化準確性和壓縮比。

后訓練：使用監督微調和強化學習（Group Relative Policy Optimization），外加一個輔助的 OCR 對齊任務。OCR 損失改善了小字體和緊密間距下的字符保真度。

實際效果

在 LongBench 和 MRCR 基準上，Glyph 實現了平均 3.3 倍的壓縮比，某些任務接近 5 倍。MRCR 上平均 3 倍。這個收益隨輸入長度增加而擴大，因為每個視覺 token 承載的字符更多。

速度提升也很明顯：在 128K 輸入上，預填充速度提升約 4.8 倍，解碼速度提升約 4.4 倍，監督微調吞吐量提升約 2 倍。

Ruler 基準證實，推理時使用更高的 DPI 能改善分數，因為更清晰的字形有助于 OCR 和布局解析。研究團隊報告了不同 DPI 下的壓縮比：

• DPI 72：平均壓縮 4.0 倍，最高 7.7 倍
• DPI 96：平均壓縮 2.2 倍，最高 4.4 倍
• DPI 120：平均壓縮 1.2 倍，最高 2.8 倍

一些限制

Glyph 在多模態文檔理解上表現不錯。在渲染頁面上的訓練改善了 MMLongBench Doc 的性能，說明渲染目標對包含圖表和布局的真實文檔任務有用。

但也有明顯的限制：

排版敏感性：過小的字體和過緊的間距會降低字符準確性，特別是對罕見的字母數字串。研究團隊在 Ruler 上排除了 UUID 子任務。

OCR 挑戰：識別細粒度或罕見的字母數字字符串仍然困難，超長輸入時可能出現字符錯誤分類。

泛化限制：主要針對長文本理解訓練，在更廣泛任務上的能力還待研究。

小結

與DeepSeek-OCR一樣，智譜的方案進一步證明了"視覺化文本處理"將會是一個新的熱門方向。把長文本建模重新定義為多模態問題，在保持語義的同時減少token。從方案調性看，DeepSeek是概念方向驗證，而Glyph來自于產品工程實踐，更具體實用。對這個方向感興趣，又不知道具體如何做，Glyph就是一個很好的學習樣板。

代碼：https://github.com/thu-coai/Glyph 

模型：https://huggingface.co/zai-org/Glyph

論文：???https://arxiv.org/abs/2510.17800  ??

本文轉載自??AI工程化??，作者：ully