大模型推理引擎

先建立一个分类框架

推理工具可以按两个维度来区分:

维度 1:抽象层次(从低到高)

  • 推理引擎(Inference Engine):直接执行模型 forward pass,管显存、KV cache、算子调度
  • 推理服务器(Inference Server):包装引擎 + 提供 HTTP API、批处理、多请求并发
  • 应用层封装(User App):包装服务器 + GUI、模型管理、用户体验

维度 2:目标平台

  • NVIDIA GPU 为主(数据中心、服务器)
  • Apple Silicon 为主(Mac 本地)
  • 跨平台(CPU / 多种 GPU)

主流工具对比

我把常见工具按这两个维度画个表:

工具 抽象层次 主要平台 语言/后端 适用场景
HuggingFace Transformers 引擎(偏研究) 全平台 PyTorch 研究、实验、微调
vLLM 推理服务器 NVIDIA GPU PyTorch + CUDA 高并发生产部署
SGLang 推理服务器 NVIDIA GPU PyTorch + CUDA 高并发 + 结构化输出
TensorRT-LLM 推理引擎 NVIDIA GPU CUDA 深度优化 极致性能的企业部署
llama.cpp 推理引擎 全平台(CPU/多GPU) C++ 跨平台本地推理的基础
Ollama 应用层封装 全平台 Go(基于 llama.cpp) 个人/小团队本地使用
LM Studio 应用层封装(GUI) 全平台 基于 llama.cpp 非开发者用户
MLX 框架(类似 PyTorch) Apple Silicon C++/Python Apple 官方推理框架
MLX-LM 引擎 + 命令行 Apple Silicon 基于 MLX Mac 上跑 LLM
MLX-VLM 引擎 + 命令行 Apple Silicon 基于 MLX Mac 上跑视觉语言模型
TGI(Text Generation Inference) 推理服务器 NVIDIA GPU Rust + PyTorch HuggingFace 官方生产方案

按"家族"来理解会更清晰

这些工具其实可以分成几个"家族",每个家族内部有传承关系,跨家族才是真正的不同路线。

家族 1:PyTorch 生态(研究 → 生产)

HuggingFace Transformers(研究/原型)
    ↓
vLLM / SGLang / TGI / TensorRT-LLM(生产服务)
  • 共同点:都基于 PyTorch,模型权重都是 .safetensors 格式,主要跑 NVIDIA GPU
  • Transformers:灵活、代码可读、方便 debug 和改模型结构,但推理效率低、不适合高并发
  • vLLM:发明了 PagedAttention(借鉴操作系统的虚拟内存思想管理 KV cache),大幅提升吞吐量。目前开源推理服务的事实标准
  • SGLang:在 vLLM 基础上加强了结构化输出(JSON schema 约束)、RadixAttention(共享前缀缓存),适合 agent 场景
  • TensorRT-LLM:NVIDIA 官方出品,把模型编译成 CUDA kernel,极致性能但灵活性差
  • TGI:HuggingFace 出的生产服务器,和 vLLM 定位类似,和 HF 生态集成紧

典型用法:

# Transformers(研究)
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("...")
output = model.generate(...)

# vLLM(生产)
vllm serve zai-org/GLM-OCR --port 8080
# 然后 curl http://localhost:8080/v1/chat/completions

家族 2:llama.cpp 生态(跨平台本地)

llama.cpp(C++ 引擎,核心)
    ↓
Ollama(命令行 + API)
LM Studio(GUI app)
Jan / Msty / Open WebUI(各种前端)
  • 共同点:模型格式是 GGUF(量化友好、跨平台)、引擎是 llama.cpp(C++ 写的,编译到各平台)
  • llama.cpp 本身:就是一个可执行文件,命令行用。支持 CPU、CUDA、Metal、Vulkan、ROCm 等后端
  • Ollama:在 llama.cpp 上包了一层 Modelfile 机制(封装 prompt 模板、参数)和 API 服务,加上模型注册表,做到"开箱即用"
  • LM Studio:和 Ollama 类似定位,但是 GUI 优先,非程序员也能用
  • Open WebUI:纯前端,连接 Ollama 提供类似 ChatGPT 的网页界面

特点:

  • 量化支持好(4-bit / 5-bit / 8-bit 都常见)
  • 跨平台,Mac/Windows/Linux 一致体验
  • 性能不如 vLLM 等,但对单用户本地使用完全够

家族 3:Apple Silicon 专属(MLX)

MLX(Apple 官方 ML 框架)
    ↓
MLX-LM(LLM 推理)
MLX-VLM(VLM 推理)
LM Studio(也支持 MLX 后端)
  • MLX 是 Apple 2023 年底推出的、专门为 Apple Silicon 统一内存架构设计的 ML 框架。API 像 PyTorch,但底层直接用 Metal + 统一内存,省掉了 CPU↔GPU 拷贝
  • MLX-LM / MLX-VLM 是社区项目,把 Transformers 的模型移植到 MLX 上
  • 模型权重通常在 HuggingFace 的 mlx-community 命名空间下(比如 mlx-community/GLM-OCR-bf16)

特点:

  • 理论上是 Mac 上最快的方案(直接用 Apple 硬件)
  • 但生态不如 llama.cpp 成熟,新模型支持有延迟、偶尔有 bug(你踩的坑)
  • 适合愿意折腾、追求极致性能的 Mac 用户

家族 4:其他

  • TensorRT-LLM:NVIDIA 专属,追求最快
  • DeepSpeed-Inference / FasterTransformer:早期的优化框架,现在很多功能被 vLLM 吸收
  • MLC-LLM:基于 Apache TVM,号称"任何平台都能跑",但实际使用的人不多
  • Candle:Rust 写的推理框架,HuggingFace 官方,还在成长

关键维度横向对比

按"吞吐 vs 易用性"排序

吞吐高,部署复杂     ←→     吞吐低,一键启动
vLLM / SGLang / TRT-LLM  >  TGI  >  Transformers  >  Ollama  >  LM Studio

按"适合的硬件"

NVIDIA 数据中心:    vLLM, SGLang, TRT-LLM, TGI
NVIDIA 消费级:      vLLM, Ollama, LM Studio
Apple Silicon:      Ollama, LM Studio, MLX-LM, MLX-VLM  
纯 CPU:             llama.cpp, Ollama, LM Studio
边缘设备(嵌入式):  llama.cpp, MLC-LLM

按"模型格式"

.safetensors (PyTorch 原生) → Transformers, vLLM, SGLang, TGI, TRT-LLM
GGUF(量化)                 → llama.cpp, Ollama, LM Studio
MLX 格式                    → MLX-LM, MLX-VLM
特定编译格式                → TRT-LLM, MLC-LLM

不同格式之间需要转换——这就是为什么你会看到 mlx-community/xxx-bf16、TheBloke/xxx-GGUF、原厂的 .safetensors 这几种同一模型的变体。

怎么选?给你的建议

场景 A:研究、微调、改模型结构
→ Transformers(无可替代,最灵活)

场景 B:生产环境,高并发服务
→ vLLM(事实标准)或 SGLang(需要结构化输出时)
→ 预算充足且追求极致性能 → TensorRT-LLM

场景 C:本地 Mac 上自己用
→ 首选 Ollama(稳定、生态好、跨模型统一)
→ 追求最快性能、愿意折腾 → MLX-LM / MLX-VLM
→ 需要 GUI → LM Studio

场景 D:本地 Windows/Linux 自己用
→ Ollama 或 LM Studio

场景 E:学习内部原理
→ 读 llama.cpp 和 vLLM 源码(一个偏 C++ 系统,一个偏 Python 框架)

对应到 OCR 模型

  • GLM-OCR:官方支持 vLLM、SGLang、Ollama、mlx-vlm 四种部署方式,对应不同家族
  • DeepSeek-OCR:类似,主要通过 Transformers 和 vLLM 用
  • PaddleOCR:不在这个体系里——它是传统 CV 模型(CNN 两阶段 pipeline),用 Paddle 框架自己的推理引擎,跑不了在 llama.cpp 或 vLLM 上
  • MinerU:上层应用,内部可以选任意后端(甚至包含多个模型)

所以 PaddleOCR 的"特殊感"其实是因为它根本不是 LLM 时代的产物,是上一代 CV 技术。

心智模型总结

一句话概括这个生态:

"推理引擎" 是算力的使用方式,"服务器" 是接口的标准化方式,"应用" 是体验的打磨方式。选工具就是选你要在哪个抽象层次做事。

如果你只是想跑模型做产品,优先从高抽象层次选(Ollama、LM Studio),不要一上来就折腾 vLLM、mlx-vlm 这些底层工具——除非你有明确的性能或定制需求。踩的坑基本都是因为选了更底层的工具(mlx-vlm)但又想用高层的便利(GLM-OCR SDK 一键调用),两者之间的适配还没磨合好。

Ollama 这条路对 Mac 本地 OCR 场景来说,几乎是最甜蜜的选择。

问题 1:模型能不能跨工具复用?

基本不能直接复用,每个工具要用自己格式的模型。原因是三大生态用的模型格式完全不同:

工具 模型格式 存储位置
Transformers .safetensors / .bin ~/.cache/huggingface/hub/
MLX-VLM MLX 格式(也是 .safetensors 但结构不同) ~/.cache/huggingface/hub/
Ollama GGUF ~/.ollama/models/
vLLM / SGLang .safetensors(和 Transformers 共用) ~/.cache/huggingface/hub/

所以:

  • Transformers ↔ vLLM / SGLang:可以复用(都是 .safetensors,都放在 HuggingFace cache 里)。你在 Transformers 里下载过的模型,vLLM 启动时会直接用上。
  • MLX-VLM 下载的模型:只能被 MLX 生态用,Ollama 和 vLLM 都用不了
  • Ollama 下载的模型(GGUF):只能被 llama.cpp 生态用(Ollama / LM Studio / llama.cpp 本体),Transformers 和 MLX 都读不了

为什么格式不能互通?

不只是文件格式不同,连模型权重的布局都不一样:

  • .safetensors:PyTorch 张量的标准序列化格式,保留完整 fp16 / bf16 精度
  • MLX 格式:虽然也叫 .safetensors,但张量是按 MLX 的布局重排过的(MLX 的算子期待特定的内存布局)
  • GGUF:包含量化后的权重(通常 4-bit 或 8-bit,比原始小 2-4 倍)、tokenizer、聊天模板、各种 metadata,是一个自包含的单文件

能不能手动转换?

理论上可以,实际上很麻烦:

  • .safetensors → GGUF:用 llama.cpp 的 convert_hf_to_gguf.py 脚本,但不是所有模型架构都支持。新模型架构要等 llama.cpp 代码里加了对应实现才能转
  • .safetensors → MLX:用 mlx_vlm.convert 或 mlx_lm.convert,但和上面一样,需要 MLX 代码里支持该模型架构

这就是为什么你看到 HuggingFace 上同一个模型有三种变体,由不同社区维护:

  • zai-org/GLM-OCR — 原版,PyTorch .safetensors,官方
  • mlx-community/GLM-OCR-bf16 — MLX 社区转换
  • ollama.com/library/glm-ocr 背后的 GGUF — 要么官方转的,要么 llama.cpp 社区转的

所以之前下载过的模型

  • 通过 Transformers / HuggingFace 下载的 zai-org/GLM-OCR → vLLM、SGLang 可以直接用,但 Ollama 用不了
  • 通过 mlx-vlm 下载的 mlx-community/GLM-OCR-bf16 → 只有 MLX 生态能用
  • Ollama 必须单独下载它自己的 GGUF 版本

硬盘会不会吃不消?

会。vision 模型还好(GLM-OCR 只有 0.9B,每个版本 2GB 左右),但大语言模型同时存三种格式就很占空间了。实用建议:

  • 看你最常用哪个工具,就保留对应格式
  • 其他格式用完清掉:rm -rf ~/.cache/huggingface/hub/models--mlx-community--xxx
  • Ollama 不用的模型:ollama rm model-name

问题 2:PaddleOCR-VL 在 Ollama 上的情况

现状:没有官方 Ollama 版本

PaddlePaddle 官方到目前为止没有在 Ollama library 发布 PaddleOCR-VL。

但 PaddlePaddle 官方确实发布了 GGUF 版本

官方在 HuggingFace 上发布了 GGUF 格式的模型,叫 PaddlePaddle/PaddleOCR-VL-1.5-GGUF。
所以 GGUF 文件是可信的、官方出品的,只是 PaddlePaddle 团队没有把它打包成 Ollama 的 Modelfile 发布到 Ollama library 而已。

为什么 VLM 在 Ollama 上这么麻烦?

GGUF 格式的 VLM 其实是两个文件:

  1. 主模型文件(.gguf):LLM 的权重
  2. mmproj 文件(*-mmproj.gguf):视觉编码器(图像 → embedding 的投影层)

PaddleOCR 官方文档的 llama.cpp 命令就很清楚 :

llama-cli -m PaddleOCR-VL-1.5.gguf --mmproj PaddleOCR-VL-1.5-mmproj.gguf -p 'OCR:' --image 'test_image.jpg'

要同时加载两个文件,才是完整的 VLM。

还有个更深层的问题:完整 PaddleOCR-VL pipeline 不止这一个模型

关键的一点:PaddleOCR-VL 实际上是两个模型的 pipeline,跟 GLM-OCR 一样:

一个是 0.9B 的 VLM(用来识别元素),另一个是版面分析模型 PP-DocLayoutV2(用 PaddlePaddle 实现)。PaddlePaddle 团队更熟悉 paddlepaddle 生态,不熟悉 pytorch 生态工具链。

所以就算把 PaddleOCR-VL 的 VLM 部分跑在 Ollama 上,还需要另一个 PaddlePaddle 框架的版面检测模型才能做完整的文档解析。这也是为什么 PaddleOCR 官方推荐的用法是 paddleocr doc_parser ... --vl_rec_backend llama-cpp-server——用 PaddleOCR 的 Python 客户端做版面检测,然后把裁剪出来的区域发给 llama-server 做 VLM 识别。和 GLM-OCR SDK + mlx-vlm server 的架构一模一样。

建议

方案 1(推荐):走 PaddleOCR 官方文档的 llama.cpp 路径

不走 Ollama,直接用 llama.cpp:

# 1. 装 llama.cpp(Mac 上用 Homebrew 最方便)
brew install llama.cpp

# 2. 从 HuggingFace 下载官方 GGUF
# 去 https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5-GGUF 下载两个文件

# 3. 启动 llama-server
llama-server \
  -m /path/to/PaddleOCR-VL-1.5.gguf \
  --mmproj /path/to/PaddleOCR-VL-1.5-mmproj.gguf \
  --port 8080 \
  --temp 0

# 4. 用 PaddleOCR 客户端调用
pip install paddleocr
paddleocr doc_parser -i your_image.png \
  --vl_rec_backend llama-cpp-server \
  --vl_rec_server_url http://127.0.0.1:8080/v1

这是官方背书的完整方案,可信度最高。

方案 2:自己把官方 GGUF 打包成 Ollama 模型

如果你执意要用 Ollama(比如想用 Ollama GUI),理论上可以自己写 Modelfile:

cat > Modelfile <<EOF
FROM /path/to/PaddleOCR-VL-1.5.gguf
# 需要 mmproj
# 但 Ollama 对多文件 VLM 的支持不像 llama.cpp 原生那么直接
EOF

ollama create paddle-ocr-vl -f Modelfile

但这有个麻烦:Ollama 对 VLM(需要独立 mmproj 文件的视觉模型)的打包机制比较 tricky,不是所有情况都能正确识别 mmproj。需要查 Ollama 文档看当前怎么处理。

方案 3:跳过 Ollama,直接用 PaddleOCR 官方 Python 库

如果不坚持本地 VLM 推理:

pip install paddleocr paddlepaddle

PaddleOCR 有它自己的推理方式(不走 llama.cpp / Ollama 这些),直接跑就行。缺点是 PaddlePaddle 在 Apple Silicon 上的支持一直不如 PyTorch 生态完善。

关于"Ollama 没有官方版 PaddleOCR-VL"这件事

其实这反映了一个生态现象:

  • Ollama library 里出现某模型,有几种可能性:

    1. Ollama 团队主动转换和收录(主流热门模型)
    2. 模型原厂主动上传(需要原厂熟悉 Ollama 工具链)
    3. 第三方个人/组织上传(质量不保证)

  • PaddleOCR-VL 属于情况 2 没发生的情况:PaddlePaddle 团队主要用 PaddlePaddle 框架,他们专注的是让模型在 llama.cpp(上游)工作,而把发布到 Ollama 这一步留给社区或以后。Ollama 官方也有 issue 请求支持 PaddleOCR-VL,但目前还 Open 状态,没人做。

posted @ 2026-04-20 18:09  RolandHe  阅读(172)  评论(0)    收藏  举报