智谱开源Glyph视觉Token方案：与DeepSeek-OCR竞逐长上下文处理新境界

真是巧合，智谱与DeepSeek再次在同一技术领域碰面。

竞争日益激烈，DeepSeek-OCR发布尚未满24小时，智谱便紧随其后开源了其视觉Token方案——Glyph。

既然是同台竞技，自然要邀请近日频频称赞DeepSeek的卡帕西来点评一番：

或许你也会对我们的工作感兴趣。

发布论文就发布论文，怎么还上演了一场争宠戏码。（doge）

网友戏称：AI界也有属于自己的霸道总裁爱情故事。

智谱也进军视觉压缩领域

没错，与DeepSeek-OCR相似，智谱这篇论文的目标同样是通过视觉方法，解决当前LLM上下文过长的问题。

急速增长的上下文需求

随着LLM性能的飞速提升，用户和厂商对长上下文的需求也日益迫切。

毕竟，无论是长文档分析、代码审查，还是多轮对话，模型不能像金鱼一样记忆短暂。要确保它们可靠执行任务，必须拥有稳定的「工作记忆」。

但扩展上下文是一项艰巨且回报有限的工作。

举例来说：若将上下文从50K扩展到100K，计算资源消耗大约会增至原来的四倍。

原因在于，更多的Token意味着模型需要存储更多的激活值、缓存和注意力权重，这些在训练和推理阶段都依赖大量资金投入。

如果性能能实质提升，多投入些资源也值得。

但最令人沮丧的是，投入巨资扩展上下文，模型未必变得更智能。

IBM的研究表明，仅靠“增加Token数量”并不能保证模型表现线性提升。

相反，当输入过长、信息过杂时，模型可能受到噪声干扰和信息过载，导致理解能力下降。

针对此类问题，目前主要有三种主流解决方案：

第一类，扩展位置编码。

在Transformer架构中，模型无法识别输入的顺序，因此需为每个Token添加“位置编码”，以告知其先后关系。

扩展位置编码的方法，是将原有位置编码区间直接向外延展。

例如，将0～32K的位置区间“插值”到0～100K，这样模型就能在处理时接受更长输入，无需重新训练。

然而，这并未解决推理成本问题，模型在推理阶段仍需遍历所有上下文。

而且，模型虽能继续读取，但由于训练中从未接触如此长的上下文，强制读取必然影响表现。

第二类，改进注意力机制。

既然上下文变长，那就让模型「读取」加速，例如采用稀疏注意力、线性注意力等技术，提升每个Token的处理效率。

但效率再高，基本问题未变，Token总量未减少，若上下文达几十万，再高效的机制也难以承受。

第三类，检索增强RAG路径。

它通过外部检索筛选重点，再输入模型，从而缩短输入、加速推理。

但众所周知，RAG的输出结果通常不如模型基于训练数据的回答，且额外检索步骤会拖慢整体响应速度。

寻觅良久，上下文问题依旧棘手。

以「图」为载体进行理解

为解决这一难题，研究团队提出新范式——Glyph。

原理简单：既然纯文本信息密度不足，就将其转换为图像。

普通LLM处理文本时，将句子拆分为独立Token依次输入，效率较低。

例如，若一句话可分成1000个Token，模型就需计算1000个向量，并进行注意力计算。

相比之下，Glyph不逐字阅读，而是先将整段文字排版为图像式视觉Token，再将这张「截图」交由VLM处理。

这样做是因为图像承载的信息密度远高于纯文本，仅需一个视觉Token就能容纳原先多个文本Token的内容。

通过这种方式，即使是上下文窗口固定的VLM，无需依赖稀疏注意力或RAG等工具，也能轻松处理足以让LLM“过载”的超长文本。

举例：小说《简·爱》约有240K文本Token，对于上下文窗口仅128K的传统LLM，只能输入一半内容。

在此情况下，若询问涉及故事跨度较大的问题，传统模型很可能无法回答。

例如：女主角离开桑菲尔德后，谁在她困难时提供了帮助？

但若使用Glyph，将整本书渲染为紧凑图像，仅需约80K视觉Token。

如此一来，同样128K上下文的VLM就能轻松阅读完整《简·爱》，把握故事脉络，并从更全局的角度回答问题。

如此显著的效果，是如何实现的？

Glyph的训练流程主要分为三个阶段：

第一阶段：持续预训练（Continual Pre-training）

此阶段目标，是将模型的长上下文理解能力从文本领域迁移到视觉领域。

具体而言，研究团队首先将海量长文本渲染为多种风格的图像，让VLM在各种排版、字体和布局中“读图识文”，以训练出更强泛化能力。

在此过程中，模型不断学习如何将图像中的文字信息与原始文本语义对齐。

第二阶段：LLM驱动的渲染搜索（LLM-driven Rendering Search）

尽管多样化渲染方式能提升模型泛化能力，但在实际应用中需兼顾效率与精度。

文字转为图像的方式，决定了压缩率与可读性之间的微妙平衡。

字体过大、排版过松固然不佳，这会降低信息密度，违背视觉Token的初衷。

然而，过度追求信息密度也不理想。

字体过小、布局过紧，虽压缩率高，却可能导致模型“看不清”，理解出现偏差。

为此，研究团队引入由LLM驱动的遗传搜索算法，让模型自动探索最优渲染参数——如字体大小、页面布局、图像分辨率等——力求在最大化压缩的同时保留语义。

第三阶段：后训练（Post-training）

找到最优渲染方案后，研究团队进一步执行两项任务：有监督微调和强化学习，旨在让模型在“看图读文”上更智能、更稳定。

此外，他们在SFT和RL阶段均加入辅助OCR对齐任务，教导模型从图像中准确还原文字细节，实现视觉与文本能力的深度融合。

最终，Glyph练就两大能力：

1、理解长文，推理精准高效。

2、识别细节，读图不费脑力。

凭借这套组合策略，Glyph在高压缩视觉上下文任务中游刃有余。

大幅削减75%上下文

理解原理后，接下来查看Glyph的实际表现。

事实证明，Glyph确实能显著减少Token数量。

实验结果显示，Glyph在多项长上下文基准测试中实现3–4倍的Token压缩率，同时保持与主流模型（如Qwen3-8B）相当的准确度。

这种压缩不仅减轻了计算负担，还带来约4倍的prefill与解码速度提升，以及约2倍的SFT训练加速。

更令人惊喜的是，在极端压缩情况下，一个上下文窗口仅128K的VLM，仍能应对相当于百万Token级的文本任务，且表现毫不逊色。

此外，尽管Glyph的训练数据主要来自渲染后的文本图像，它在多模态任务上同样表现优异，证明了其强大泛化潜力。

综上所述，这篇论文提出了名为Glyph的长上下文建模框架。

核心思路是将长文本“绘制”成图像，再让VLM看图读文，实现一目十行，从而高效扩展上下文。

论文作者

如此卓越的成果，由谁完成？

论文第一作者是Jiale Cheng，清华大学博士生，主要研究方向包括自然语言生成、对话系统及相关人工智能交互技术。

目前，Jiale已发表多篇论文，在谷歌学术上具有不错的影响力。

此外，论文还有三位主要贡献者：Yusen Liu、Xinyu Zhang、Yulin Fei。

遗憾的是，他们公开资料较少。

本文通讯作者为黄民烈教授。

黄教授本科与博士均毕业于清华大学，现任清华大学计算机科学与技术系长聘教授，兼任智能技术与系统实验室副主任、清华大学基础模型中心副主任。

此外，他还是北京聆心智能科技有限公司创始人兼首席科学家。

黄教授的研究方向主要集中在人工智能、深度学习、强化学习及自然语言处理等领域。

像素或成为终极Token

继MoE兴起后，DeepSeek-OCR的出现再次在AI领域引发技术变革。

截至10月22日，Hugging Face上最受欢迎的四个模型均支持OCR。

一方面，这源于视觉Token自身的巨大潜力。

在上下文建模方面，视觉Token表现惊人——

DeepSeek-OCR仅用100个视觉Token，就能在原本需要800个文本Token的文档上达到97.3%的准确率。

这种效率提升，意味着AI门槛正快速降低。

据DeepSeek介绍，引入OCR技术后，单张NVIDIA A100-40G GPU每天可处理超过20万页文档。

按此速度估算，仅需一百多张显卡，就能完成一次完整模型预训练。

降本增效一直是开源阵营的优势，但此次讨论焦点已超越此范围——

视觉Token的出现，可能正从底层重构LLM的信息处理方式。

未来，像素或许会取代文本，成为下一代AI的基本信息单元。

卡帕西指出，像素天生比文本更适合作为LLM输入，主要原因有二：

1、信息压缩率更高→ 更短的上下文窗口，更高的效率。

2、信息流更广泛→ 不仅能表示文字，还能包含粗体、颜色及任意图像。

马斯克的观点更为激进：

从长远来看，人工智能模型的输入和输出中 99% 以上都将是光子。

此外，OCR的爆火也引人重新思考AI与脑科学之间的紧密联系。

使用图像而非文本作为输入，初看似乎反直觉，但细想却发现，这更贴近人脑的信息处理模式。

人类获取新信息时，最先感知的总是图像。

即使是阅读，我们大脑最初接收的也只是由像素按特定规律排列的图形，经过层层视觉处理，这些像素才被翻译为“文字”概念。

由此观之，OCR的表现虽惊艳，却也不足为奇。

毕竟，视觉是人类数万年来感知世界的一手途径。

相比之下，语言只是我们基于视觉与其他感官体验提炼的高度浓缩抽象层。它标准化、成本低，但本质仍是视觉的降维产物。

即便影子再清晰，也注定会丢失不少细节。

有趣的是，当AI在各指标上不断逼近人类、引发广泛焦虑的同时，每当技术发展遇到瓶颈，我们总能从那个被质疑“不够智能”的人脑中重新找到灵感。

神经网络、注意力机制、MoE……皆是这一规律的体现。

而这一次，深不可测的「人类智能」，在视觉Token上再次获得验证。

论文

https://arxiv.org/pdf/2510.17800

GitHub

https://github.com/thu-coai/Glyph

参考链接

[1]https://x.com/ShawLiu12/status/1980485737507352760