|
|
@@ -1,87 +0,0 @@
|
|
|
-确认完毕,给你结论和可执行方案。
|
|
|
-
|
|
|
-## 关键事实
|
|
|
-
|
|
|
-1. **llama.cpp 已原生支持 `paddleocr_vl` 架构**(build b8110,2026-02 合入)。你现在能跑 1.5-GGUF 就证明你的 llama.cpp 已支持。
|
|
|
-2. **1.6 与 1.5 架构「完全兼容」**(官方原话 "zero-cost plug-and-play migration")。这意味着 GGUF 转换/推理路径对 1.6 完全适用——没有任何适配成本。
|
|
|
-3. 1.6 的 HF model tree 已显示 "Quantizations 2 models",社区量化正在跟进(`noctrex` 这类作者对 1.5 更新很快)。
|
|
|
-
|
|
|
-所以你**不用等官方**,有两条高效路径。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 方案 A(最省事):直接找/等社区 GGUF
|
|
|
-
|
|
|
-因为架构完全兼容,社区转 1.6 是零成本的。优先去这两个地方蹲:
|
|
|
-
|
|
|
-- [`noctrex/PaddleOCR-VL-1.5-GGUF`](https://huggingface.co/noctrex/PaddleOCR-VL-1.5-GGUF)(看是否出 1.6 仓库)
|
|
|
-- 1.6 官方页的 [Quantizations 链接](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.6)(已挂 2 个量化)
|
|
|
-
|
|
|
-找到后,**你现有的 daemon 脚本几乎不用改**,只改 3 个变量(路径 + 别名)即可。
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-## 方案 B(最可控,推荐):自己转换 1.6 → GGUF
|
|
|
-
|
|
|
-模型只有 0.9B,M4 Pro 48G 转换+量化几分钟搞定。步骤:
|
|
|
-
|
|
|
-```bash
|
|
|
-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` 里这几行指向新文件就行:
|
|
|
-
|
|
|
-```bash
|
|
|
-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` 加上:
|
|
|
-
|
|
|
-```bash
|
|
|
---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 指南](https://insiderllm.com/guides/paddleocr-vl-local-document-ocr/)、[1.6 官方页](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.6)、[1.5-GGUF 用法](https://huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5-GGUF)。
|