paddleocr_vl 1.6->GGUF.md 3.9 KB
确认完毕，给你结论和可执行方案。
关键事实
- llama.cpp 已原生支持
paddleocr_vl架构（build b8110，2026-02 合入）。你现在能跑 1.5-GGUF 就证明你的 llama.cpp 已支持。 - 1.6 与 1.5 架构「完全兼容」（官方原话 "zero-cost plug-and-play migration"）。这意味着 GGUF 转换/推理路径对 1.6 完全适用——没有任何适配成本。
- 1.6 的 HF model tree 已显示 "Quantizations 2 models"，社区量化正在跟进（
noctrex这类作者对 1.5 更新很快）。
所以你不用等官方，有两条高效路径。
方案 A（最省事）：直接找/等社区 GGUF
因为架构完全兼容，社区转 1.6 是零成本的。优先去这两个地方蹲：
noctrex/PaddleOCR-VL-1.5-GGUF（看是否出 1.6 仓库）- 1.6 官方页的 Quantizations 链接（已挂 2 个量化）
找到后，你现有的 daemon 脚本几乎不用改，只改 3 个变量（路径 + 别名）即可。
方案 B（最可控，推荐）：自己转换 1.6 → GGUF
模型只有 0.9B，M4 Pro 48G 转换+量化几分钟搞定。步骤：
conda activate mineru
# 1. 拿最新 llama.cpp（确保 convert 脚本支持 paddleocr_vl）
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
pip install -r requirements.txt # 转换脚本依赖
cmake -B build -DGGML_METAL=ON && cmake --build build -j
# 2. 下载 1.6 原始权重（safetensors）
conda activate mineru
hf download PaddlePaddle/PaddleOCR-VL-1.6 --local-dir ~/models/PaddleOCR-VL-1.6
# 3. 转语言模型主体（M4 48G 内存充足，直接 f16 不量化质量最好）
python convert_hf_to_gguf.py ~/models/PaddleOCR-VL-1.6 \
--outfile ~/models/paddleocr_vl/PaddleOCR-VL-1.6.gguf \
--outtype f16
# 4. 转视觉投影器 mmproj（OCR 质量主要看这个，建议 f16/f32）
python convert_hf_to_gguf.py ~/models/PaddleOCR-VL-1.6 \
--mmproj \
--outfile ~/models/paddleocr_vl/PaddleOCR-VL-1.6-mmproj.gguf \
--outtype f16
模型总共才 ~1.5GB，48G 内存下不建议量化主模型（Q4 会掉 OCR 精度），直接 f16 即可；mmproj 用 f16 或 f32 质量最佳。
转完后，把你 paddle_local_daemon.sh 里这几行指向新文件就行：
HF_CACHE="$HOME/models/paddleocr_vl"
MODEL_PATH="$HF_CACHE/PaddleOCR-VL-1.6.gguf"
MMPROJ_PATH="$HF_CACHE/PaddleOCR-VL-1.6-mmproj.gguf"
MODEL_NAME="PaddleOCR-VL-1.6"
一个重要的坑：chat template
社区/自转的 GGUF 如果不带模板，调用时会因为缺少图像占位符 token（<|IMAGE_START|><|IMAGE_PLACEHOLDER|><|IMAGE_END|>）而崩溃。你当前脚本能跑 1.5 官方 GGUF 是因为模板已内嵌。如果换 1.6 后启动报错或输出异常，给 llama-server 加上：
--jinja --chat-template-file /path/to/chat_template.jinja
chat_template.jinja 从 GGUF 仓库下载，或从 1.6 的 tokenizer_config.json 里的 chat_template 字段提取。
不推荐的路径
- transformers + MPS：Mac 上 MPS 跑视觉模型慢，且官方明确说 transformers 路径只支持 element-level（单元素识别），不支持整页解析，会破坏你现在的流水线。
- vLLM：官方加速方案依赖 CUDA/Docker GPU，Mac 上没有可用 GPU 后端。
建议：先按方案 B 自转一份 f16，跑通后对比 1.5 看精度提升是否值得切换；同时关注社区 1.6 GGUF，出了直接换方案 A。需要的话我可以（切到 Agent 模式后）帮你把脚本改造成支持 --jinja 并参数化版本号，方便 1.5/1.6 一键切换。
Citation: InsiderLLM 指南、1.6 官方页、1.5-GGUF 用法。