从 ViT 到 M-RoPE：TeleOCR 的 1.2B 架构里藏着哪些细节-北京尧图网络

从 ViT 到 M-RoPETeleOCR 的 1.2B 架构里藏着哪些细节【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR当 OmiDocBench 榜单上出现一个只有 1.2B 参数的模型以 96.87 的综合得分压过 235B 的 Qwen3-VL89.78和 GPT-5.286.52时绝大多数人的第一反应是这不科学。参数差了近两百倍凭什么能在文本识别、表格还原、公式转写这些硬指标上全面反超答案不在魔法里而在架构细节中。TeleOCR 并非从零发明了一套新范式而是站在 Qwen2.5-VL 的肩膀上把轻量二字做到了极致32 层窗口注意力 ViT 负责把像素吃干榨净28 层 GQA Decoder 用 M-RoPE 三维位置编码把版面几何关系编码进注意力再用 4 倍 token 压缩的 PatchMerger 把视觉特征廉价地喂给语言模型。这篇文章直接翻开仓库源码逐行拆解这份 1.2B 的参数预算到底花在了哪里。一张 config.json 看懂 1.2B 的参数分布TeleOCR 的完整配置都写在仓库根目录的 config.json 里。用hidden_size × 层数粗算一下参数体量模块关键配置参数规模ViT 视觉编码器depth32hidden_size1280intermediate_size342016 头≈ 6 亿Decoder 语言模型28 层hidden_size1024intermediate_size307216 头≈ 5 亿PatchMerger Embeddingout_hidden_size1024词表 151936tie_word_embeddingstrue≈ 1.5 亿共享后大幅压缩这份配置最扎眼的地方在于语言模型的 hidden_size1024刻意做得比视觉编码器1280小这不同于多数 VLM语言侧为主的惯例。文档解析的瓶颈在看懂版面而非生成文本把算力向视觉侧倾斜是 1.2B 能打 235B 的第一个信号。同时tie_word_embeddings: trueconfig.json 第 95 行让词表 embedding 与 LM Head 权重共享151936 词表的词嵌入只存一份为 Decoder 侧又省下近亿参数。32 层 ViT窗口注意力每隔 8 层一次的全局拥抱视觉编码器的实现在 modeling_naviocr.py 的Qwen2_5_VisionTransformerPretrainedModel第 307 行中。整条流水线是Conv3d Patch Embed → 32 层 Vision Block → PatchMerger。Patch Embed 是一个 3D 卷积。Qwen2_5_VisionPatchEmbed第 68 行用temporal_patch_size2, patch_size14的 Conv3d 直接把输入的 RGB 像素切成 14×14 的 patch每 2×14×14 的体素块映射成 1280 维向量。对单张文档图来说temporal 维取 2 是为了与 Qwen2.5-VL 的视频预训练结构对齐保持权重可继承。注意力是窗口全局的混合。32 层并非全部做全局注意力fullatt_block_indexes配置为[7, 15, 23, 31]config.json即每隔 7 层才做一次全局注意力其余 28 层全部限制在局部窗口内。窗口的计算逻辑在get_window_index第 366 行vit_merger_window_size self.window_size // self.spatial_merge_size // self.patch_size # 112 // 2 // 14 4即每个窗口覆盖 4×4 个合并后的 patch再结合 forward 循环中的分派逻辑第 448-452 行for layer_num, blk in enumerate(self.blocks): if layer_num in self.fullatt_block_indexes: cu_seqlens_now cu_seqlens # 全局注意力 else: cu_seqlens_now cu_window_seqlens # 4×4 窗口注意力这套设计对文档场景极其关键一个 1036×1036 的分辨率下ViT 会产生 5476 个 patch token全局注意力是 O(N²) 的平方开销而 4×4 窗口把每次注意力的视野锁死在相邻 16 个 token 内28 层窗口 4 层全局的组合让模型用约 1/8 的注意力预算拿到了局部纹理精细、全局结构在场的版面理解能力。文档 OCR 恰好是这种需求的完美匹配字符细节靠局部阅读顺序与表格行列结构靠全局。PatchMerger 是 4 倍 token 压缩器。视觉特征在进入语言模型前要经过Qwen2_5_VLPatchMerger第 108 行self.hidden_size context_dim * (spatial_merge_size**2) # 1280 * 4 5120 self.ln_q Qwen2RMSNorm(context_dim, eps1e-6) self.mlp nn.Sequential( nn.Linear(self.hidden_size, self.hidden_size), nn.GELU(), nn.Linear(self.hidden_size, dim), # 5120 → 1024 )spatial_merge_size2意味着每 2×2 相邻 patch 被打包成一个 5120 维的向量经 LN 两层 MLP 压缩回语言模型的 1024 维。token 数直接除以 4一张 1036×1036 的图从 5476 个视觉 token 降到 1369 个KV Cache 和自回归解码的长度压力同步缩减——这是 1.2B 模型能把 4096 个新 token 的生成控制在消费级显卡上的直接原因。28 层 DecoderGQA 省显存M-RoPE 管几何视觉特征压缩完毕后进入 28 层Qwen2_5_VLDecoderLayer。两个最值得展开的细节GQA 和 M-RoPE。GQAGrouped Query Attention16 个头共享 8 组 KV。在Qwen2_5_VLAttention第 615 行中配置明确num_attention_heads16, num_key_value_heads8self.num_key_value_groups self.num_heads // self.num_key_value_heads # 2 self.q_proj nn.Linear(self.hidden_size, self.num_heads * self.head_dim, biasFalse) self.k_proj nn.Linear(self.hidden_size, self.num_key_value_heads * self.head_dim, biasFalse) self.v_proj nn.Linear(self.hidden_size, self.num_key_value_heads * self.head_dim, biasFalse)KV 头数减半意味着每层 KV Cache 减半。文档解析的生成序列动辄数千 token公式、表格展开都很长KV 占用随序列线性增长GQA 在这里省下的不是几个百分点而是把长序列解码从显存爆炸拉回可部署的直接手段。另一处细节是q_norm/k_norm第 656-657 行query 和 key 在进入注意力前各自过一层 Qwen3RMSNormRMSNorm 应用到 head 维度这是 Qwen3 系模型训练稳定性增强的标配被完整继承了下来。M-RoPE三维位置编码让注意力知道版面长什么样。这是全文最核心的机制。先看位置编码的生成Qwen2_5_VLRotaryEmbedding.forward第 516 行把频率矩阵扩展成 3 份inv_freq_expanded self.inv_freq[None, None, :, None].float().expand(3, position_ids.shape[1], -1, 1)而apply_multimodal_rotary_pos_emb第 549 行按mrope_section把隐藏维度切成三段分别旋转mrope_section mrope_section * 2 # [16, 24, 24] → [32, 48, 48] cos torch.cat([m[i % 3] for i, m in enumerate(cos.split(mrope_section, dim-1))], dim-1)配置中的mrope_section: [16, 24, 24]config.json 第 23 行配合rope_theta: 1000000.0含义是128 维的 head 中前 16 维承载时序位置随后各 24 维分别承载高度、宽度方向的位置三者用不同频率的旋转角编码。文本 token 的三个位置索引相同退化为普通 1D RoPE而图像 token 的位置索引来自_get_vision_position_ids逻辑第 1064-1146 行position_ids torch.ones(3, input_ids.shape[0], input_ids.shape[1], ...) # 对每个图像 patch token 生成 (t_index, h_index, w_index) 三元组 llm_pos_ids_list.append(torch.stack([t_index, h_index, w_index]) text_len st_idx)最终传入 Decoder 的position_ids是(3, batch, seq)的张量视觉 token 的每个维度位置各不相同。这意味着注意力在做 Q·K 计算时旋转相位差里天然编码了这两个 patch 在纸面上相距多高、多宽。对弯折、透视变形的手机拍摄文档来说模型不需要显式的矫正模块位置编码本身就承载了扭曲的几何关系——这正是 README 里无需 dewarping 预处理的直接架构根源。顺带一提Decoder 的 MLP 用的是 SwiGLU 结构Qwen2MLP第 533 行gate/up/down 三投影 silu 门控FFN 比 Vision 侧多一组投影是标准 Qwen 系配方此处不赘述。动态分辨率适配与贪心解码精度与速度的平衡术分辨率不是固定死的。仓库的 preprocessor_config.json 给出了两个关键阈值min_pixels: 3136、max_pixels: 12845056。Qwen2VLImageProcessor 会根据输入图的长宽比在上下限之间把图缩放到像素数恰好达标的尺寸再切成 patch。1.2B 模型之所以能同时处理数字文档与手机实拍图正是因为这层动态缩放分辨率上限开到 1280 万像素约 3584×3584足够承载弯折文档中变形字符的细节下限 3136 又保证小图不会被过度上采样。README 的 Quick Start 中布局示例统一resize((1036, 1036))只是为了演示实际推理完全交给 processor 按像素预算动态决定。生成阶段直接用贪心解码。仓库 generation_config.json 里do_sample: true、temperature: 0.1、top_k: 1的参数组合本质上是极低温采样而 README 官方推理代码README.md 第 339-344 行更进一步output_ids model.generate( **inputs, use_cacheTrue, max_new_tokens4096, do_sampleFalse, # 贪心解码逐 token 取 argmax )do_sampleFalse意味着每个 token 都是当前条件下概率最大的那个输出完全确定、可复现。对 OCR 这类答案唯一的任务采样带来的随机性只会引入字符漂移而贪心配合repetition_penalty: 1.05抑制长公式、长表格序列中的复读在确定性之外把质量下限兜住。这也是社区实测中同一张图多次推理结果一致的直接原因——对生产流水线的后处理解析比如把 OTSL 转 HTML来说确定性输出意味着整条管线可以稳定复现。结构化的确定性不止体现在解码表格输出走 OTSL 中间格式README 中仅 6 个特殊 token 描述单元格与行列跨度由后处理函数convert_otsl_to_html确定性地转成 HTML绕开了让模型直接生成 HTML 的语法错误风险公式输出则由后处理统一包装成$$...$$块README 第 312-317 行。架构上省参数、解码上保确定两条线合起来才凑出了轻量高分的完整答案。1.2B 打 235B参数的乘法效应最后回到那个不科学的榜单。以 README.md 公布的 OmniDocBench v1.6 数据看模型参数量Overall ↑Table TEDS ↑Read Order Edit ↓TeleOCR1.2B96.8797.050.122Qwen3-VL-235B235B89.7883.070.166GPT-5.2—86.5282.950.193235B 的通用大模型在表格结构还原这一项上被 1.2B 的专用模型拉开 14 个点原因恰恰是本文拆出的这些细节窗口注意力让视觉侧在有限参数下看到了足够多的 patch 细节M-RoPE 把版面几何直接烙进位置编码GQA PatchMerger 贪心解码把算力和显存省下来投给更长的序列和更高的分辨率。同样的结论也出现在 Wild_OmniDocBench88.53第一、PureDocBenchClean 86.90第一和 ICDAR2026 Sci-ImageMiner加权 41.81第一上——弯折文档、退化文档这些脏活累活正是几何感知建模最占优势的战场。1.2B 的架构说明了一件事在文档解析这个垂直赛道上架构和数据的针对性比无脑堆参数量更接近正确答案。而这份答案的全部细节都摊开在仓库的 1754 行模型代码与 141 行配置里任何人随时可以翻开对照。【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

从 ViT 到 M-RoPE：TeleOCR 的 1.2B 架构里藏着哪些细节

相关推荐

XERJ语义搜索完全指南：semantic_text字段与neural嵌入模式怎么配才对？

MLP还是Attention？Qwen3.8-27B-singprobe两种探针结构（SingProbeMlpModel vs SingProbeAttnModel）深度对比

Python TCP断线重连实战：原理、策略与避坑指南

更多资讯

FTTH光猫超级密码获取与路由模式设置实战指南

MASM611在Windows 10/11下的DOSBox安装配置与运行指南

H5游戏强制横屏方案：CSS旋转与坐标换算实战

四连杆机构动力学Matlab仿真：从起落架建模到驱动力矩分析

iOS原生热更新合规实现：配置驱动与资源热替换

FacePoison+：用对抗扰动瘫痪DeepFake人脸检测的防御新思路

今日更新

Cephadm实战指南：Linux系统工程师的生产级Ceph集群部署与排障

不想再被 Token 额度卡脖子？把免费 API 接入 WorkBuddy 的完整教程

ITK中SpatialObject几何体系解析：坐标系、变换与管道集成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？