feat(新增PaddleOCR-VL 1.6到GGUF转换文档): 新增paddleocr_vl 1.6到GGUF的详细转换方案，提供两条高效路径，包含社区资源和自转步骤，提升用户在模型转换过程中的指导性与可操作性。

docs/ocr_tools/universal_doc_parser/paddleocr_vl 1.6->GGUF.md

@@ -0,0 +1,87 @@
+确认完毕，给你结论和可执行方案。
+
+## 关键事实
+
+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)。