跳到主要内容

文档 OCR 模型

Surya OCR 2 本地部署:650M 参数吃不满一张 24GB 卡,难的是把 vLLM 后端喂饱

Surya 从 v0.20.0 起被 Datalab 推倒重做,OCR、版面分析、表格识别合并进同一个 650M 参数的 VLM。权重小得离谱,部署复杂度却全搬到了推理后端上。

先把最容易搜错的一件事说清楚:Surya 的显存问题不是「模型放不放得下」。datalab-to/surya-ocr-2 的 model.safetensors 是 bf16、1.37GB,GGUF 版本 surya-2.gguf 也才 1.27GB 外加一个 205MB 的 mmproj 投影层。真正决定你要租多大卡的是 vLLM 的 KV cache 与并发度——surya 的默认设置里 VLLM_GPU_MEMORY_UTILIZATION 是 0.85,VLLM_MAX_MODEL_LEN 是 18000,也就是说不管你的卡是 16GB 还是 80GB,它上来就把 85% 划走当缓存池。

Surya 2 是一次彻底的架构切换。v1 时代那套 FoundationPredictor 加一堆独立模型没了,现在 layout、recognition、table_rec 共用一个 Qwen3.5 风格的视觉语言模型,由 SuryaInferenceManager 统一调度;NVIDIA 卡走 vllm,CPU 与 Apple Silicon 走 llama.cpp。唯一还留在纯 PyTorch 里的是文本行检测模型(一个改过的 EfficientViT segformer),它不依赖任何推理后端,没有 GPU 也能跑——这条支线在选卡时非常有用。

能力上,Surya OCR 2 在 olmOCR-bench 上拿到 83.3%,是 3B 参数以下的最好成绩;91 种语言的内部基准平均通过率 87.2%,其中 38 种语言在 90% 以上。它的强项是版式规整的现代文档(Base 99.7%、TinyText 93.7%、ArXiv 88.3%、Tables 86.6%),弱项是老扫描件(OldScans 只有 41.8%)。项目代码是 Apache 2.0,但权重走的是改版 AI Pubs OpenRAIL-M——融资或收入 5,000,000 美元以下免费,越线要向 Datalab 买商业授权。这条线在你把它塞进生产之前就该看清楚。

01 —

现在到底有哪几个 Surya 模型

pip 包叫 surya-ocr,v0.22.x 是当前线;下面这些权重是它实际会拉下来的东西。

版本参数量显存上下文说明
datalab-to/surya-ocr-2650M(Qwen3.5 风格 VLM)bf16 权重 1.37GB;vLLM 默认按 0.85 占满整卡VLLM_MAX_MODEL_LEN 18000;全页 OCR 上限 12,288 token主力模型。OCR、版面、表格三件事共用它一个,olmOCR-bench 83.3%。
datalab-to/surya-ocr-2-gguf650Msurya-2.gguf 1.27GB(F16)+ surya-2-mmproj.gguf 205MB同上,由 llama.cpp 侧的上下文参数控制llama.cpp 后端用的版本。官方只发了 F16,没有 Q4_K_M/Q8_0 的官方量化。
文本行检测模型(s3://text_detection/2025_05_07)改版 EfficientViT segformer,小模型量级1GB 以内,纯 CPU 也能跑96 DPI 页图输入唯一不需要 vLLM/llama.cpp 的组件。surya_detect 单独跑,做切版、切行、预筛页非常划算。
datalab-to/surya_layout2(Fast Layout)紧凑目标检测器显存开销可忽略,CPU/GPU 都行96 DPI 页图输入v0.21.0 加进来的,是 VLM 版面分析的 drop-in 替代。能省掉一次 VLM 调用,吞吐差别很明显。
datalab-to/chandra-ocr-2(同厂上位模型)4B 级bf16 需要 A100 80GB / H100 80GB 这一档官方未公开olmOCR-bench 85.9%,数学、表格、复杂版面更强。代价是 6 倍参数量,且授权门槛更严(200 万美元)。

02 —

在 NexGPU 上该租哪张卡

关键约束不是权重大小,是 vLLM 要求算力 7.5 以上,以及 bf16 要 Ampere 起步。

  • 单卡跑通 detect + layout + 全页 OCR 全流程,做效果评估

    RTX 3090 24GB$0.193/卡·时

    Ampere 原生支持 bf16,24GB 在 0.85 占用下留给 KV cache 的空间足够撑起几十路并发,是能跑 vLLM 后端里最便宜的一档。

  • 对齐官方基准的生产吞吐,128 并发批量处理

    RTX 5090 32GB$0.723/卡·时

    Datalab 公布的 5.35 页/秒、12,884 token/秒 就是在 RTX 5090 加 vllm 上测的,租这张卡你能直接对上人家的数字。

  • 低并发常驻服务,或者预算优先的长尾队列

    Tesla T4 16GB$0.298/卡·时

    Turing 算力 7.5 刚好够 vLLM 的门槛,但不支持 bf16,起服务时要显式加 --dtype float16,否则直接报错退出。

  • 只跑文本行检测/Fast Layout,或走 llama.cpp GGUF 路线

    Tesla P40 24GB$0.214/卡·时

    P40 算力 6.1、V100 是 7.0,都低于 vLLM 要求的 7.5,vLLM 根本起不来;但检测模型是纯 torch,GGUF 走 llama.cpp,这两条路在老卡上完全可用。

03 —

从空机器到跑出第一页 HTML

四步。第二步故意放在起后端之前,因为它能在你和 Docker 搏斗之前就验证一半流水线。

  1. 01

    开实例,装包,确认 NVIDIA Container Toolkit 在位

    surya 会自己 docker pull vllm/vllm-openai:v0.20.1 来起后端,所以宿主机必须已经把 nvidia runtime 注册进 Docker。issue 里最常见的报错就是 unknown or invalid runtime name: nvidia——NexGPU 的 PyTorch 与 vLLM 预置镜像已经配好了,省掉这一步。顺带一提,目前还不支持 Podman。

    pip install surya-ocr
  2. 02

    先跑检测,验证不依赖后端的那一半

    文本行检测是独立的 torch 模型,不需要 vLLM 也不需要 llama.cpp。先让它把 bbox 画出来,你就能判断扫描质量够不够。识别效果差的时候,调 DETECTOR_TEXT_THRESHOLD(默认 0.6)和 DETECTOR_BLANK_THRESHOLD(默认 0.35)比换模型有用;分辨率则建议往上加,但页宽不要超过 2048px。

    surya_detect ./scans --images --output_dir ./out
  3. 03

    起 vLLM 后端,跑全页 OCR

    SURYA_INFERENCE_KEEP_ALIVE 默认是 false,意味着每批任务结束就把容器拆掉,下一批重新加载权重。批量作业务必设成 true。SURYA_INFERENCE_PARALLEL 控制客户端并发,24GB 卡上往 64 推通常还有余量。输出结构注意:v2 里 text_lines 已经变成带 HTML 的 blocks。

    SURYA_INFERENCE_KEEP_ALIVE=true SURYA_INFERENCE_PARALLEL=64 surya_ocr ./scans --output_dir ./out
  4. 04

    自己托管 vLLM,让 surya 指过来

    多机、共享卡、或者你不想让 surya 碰 Docker 的时候,自己起一个 OpenAI 兼容服务,然后 export SURYA_INFERENCE_URL=http://127.0.0.1:8000/v1 即可。安全提醒:surya 自己拉起的容器是用 -p {port}:8000 发布的,会绑到所有网卡上,公网 IP 的机器请自己上防火墙或改走这条自托管路线。

    vllm serve datalab-to/surya-ocr-2 --max-model-len 18000 --gpu-memory-utilization 0.85 --port 8000

十万页扫描件要花多少钱

拿官方公布的基准直接算:Surya OCR 2 在 RTX 5090 上用 vllm 后端、128 并发时跑到 5.35 页/秒,也就是 5.35 × 3600 = 19,260 页/小时。NexGPU 的 RTX 5090 32GB 是 $0.723/卡·时,100,000 ÷ 19,260 ≈ 5.19 小时,5.19 × $0.723 ≈ $3.75。摊到单页约 $0.0000375,每万页约 $0.375。换成 RTX 3090 24GB($0.193/卡·时)单价再降一半多,并发上不去而已,按秒计费所以慢一点也不亏。真正会让账单跑偏的从来不是模型:SURYA_INFERENCE_KEEP_ALIVE 保持默认的 false 时,每一批任务都要重新拉起 vLLM 容器、重新加载权重,那几十秒的空转一样在计费——常驻服务把它设成 true 就行。跑完 stop 实例,计算立刻停止;1.4GB 权重和镜像缓存留在盘上按 $0.414/GB·月(中位价)继续算,结果导出按 $0.0081/GB(中位价)走出口流量,不想付就把实例销毁掉。

04 —

常见问题

Surya OCR 本地部署到底需要多大显存?24GB 够不够?

权重本身只要 1.37GB,24GB 绰绰有余。但要注意 surya 起 vLLM 时用的是 VLLM_GPU_MEMORY_UTILIZATION=0.85,它会把整张卡的 85% 划成 KV cache 池——所以「占用多少」和「需要多少」是两回事。你真正该按并发来选:评估阶段 16GB 就能跑,几十路并发的生产服务上 24GB 起步。NexGPU 的 RTX 3090 24GB 是 $0.193/卡·时,按秒计费,跑一小时试出你的并发上限比任何估算都准。

Tesla V100 或 P40 这种老卡能跑 Surya 吗?

vLLM 要求算力 7.5 以上,V100 是 7.0、P40 是 6.1,都进不去,vLLM 后端起不来。但这不代表卡废了:文本行检测是纯 PyTorch 模型,Fast Layout 也是普通目标检测器,两者在老卡上跑得很好;完整 OCR 则可以走 datalab-to/surya-ocr-2-gguf 加 llama.cpp。NexGPU 上 Tesla V100 32GB 是 $0.188/卡·时、Tesla P40 24GB 是 $0.214/卡·时,做检测和预处理流水线是全站最划算的两张卡。

从 Surya 1 升到 Surya 2,代码要改哪些地方?

改动不小。FoundationPredictor 换成了 SuryaInferenceManager,并且由 layout、recognition、table_rec 共享;输出里 text_lines 变成了带 HTML 的 blocks;版面结果去掉了 top_k;表格识别的 cell 不再带 colspan 和 rowspan。另外 v2 多了一个硬依赖——你必须准备 vllm 或 llama.cpp 后端。想在不动老环境的前提下验证迁移,在 NexGPU 上开一台干净实例跑一遍最省事,验完 stop 就不再计算费用。

Surya 可以商用吗?授权是怎么算的?

代码库是 Apache 2.0,随便用;模型权重是改版 AI Pubs OpenRAIL-M,研究、个人使用,以及融资或收入在 500 万美元以下的创业公司免费,超过这个门槛需要联系 Datalab 购买商业授权(顺带一提,上位模型 Chandra OCR 2 的门槛更低,是 200 万美元,且禁止拿来跟他们的 API 竞争)。这条限制是关于权重的,跟你在谁家机器上跑无关——所以在 NexGPU 上自建推理服务不改变你的授权状态。

docker 报 unknown or invalid runtime name: nvidia 怎么办?

这是 surya 自建 vLLM 容器时最高频的失败,原因是宿主机装了驱动但没把 NVIDIA Container Toolkit 注册进 Docker。自己修就是跑一次 nvidia-ctk runtime configure 再重启 Docker;懒得折腾就绕过去——用 SURYA_INFERENCE_URL 指向一个已经在跑的 vLLM 服务。NexGPU 的 2,000+ 预置镜像里 PyTorch 和 vLLM 环境都已经配好容器运行时,开机就能 pip install surya-ocr 直接跑。

Surya 和 Chandra,或者更大的 OCR 模型该怎么选?

看你的文档。规整的现代 PDF、论文、票据、表格,Surya OCR 2 的 83.3% 已经很够用,而且只有 0.65B,吞吐量是 4B 级模型的数倍。但如果你手上大量是老扫描件(Surya 在 OldScans 上只有 41.8%)或者密集数学公式,Chandra OCR 2 的 85.9% 值得那 6 倍参数。NexGPU 上两条路都开着:Surya 一张 RTX 3090 24GB($0.193/卡·时)够了,Chandra 上 A100 PCIE 80GB($0.824/卡·时)或 H100 SXM 80GB($3.582/卡·时),同一个控制台里切换,都按秒计费。

开始使用 NexGPU

无论你是企业研发团队还是独立开发者,都可以在几分钟内跑起第一个任务。

注册即可浏览全网实时价格,无需绑定支付方式。