docs/README.md

@@ -6,6 +6,7 @@
 
 ```
 docs/
+├── conda与uv包管理指南.md       # Conda 与 uv 环境/依赖管理策略
 ├── paddlex/                    # PaddleX 相关文档
 │   ├── README.md              # PaddleX 环境配置和使用说明
 │   ├── PaddleOCR-VL-说明.md   # PaddleOCR-VL 使用说明
@@ -36,6 +37,9 @@ docs/
 
 ## 快速导航
 
+### 环境与包管理
+- [Conda 与 uv 包管理指南](conda与uv包管理指南.md)
+
 ### PaddleX 文档
 - [环境配置和使用说明](paddlex/README.md)
 - [PaddleOCR-VL 使用说明](paddlex/PaddleOCR-VL-说明.md)

docs/conda与uv包管理指南.md

@@ -0,0 +1,213 @@
+# Conda 与 uv 包管理指南
+
+本文档说明 OCR Platform 及 MinerU 相关项目的 Python 环境管理策略：**conda 管环境隔离，uv 管依赖安装**。
+
+## 结论概览
+
+| 层级 | 推荐工具 | 作用 |
+|------|----------|------|
+| Python 版本 / 环境隔离 | **conda** | 固定 Python 3.10–3.13，多项目互不干扰 |
+| 依赖安装 | **uv** | 官方推荐，解析与安装速度显著快于 pip/conda |
+
+**不是二选一**：本项目约定使用 `conda activate mineru` 创建/激活环境后，用 `uv pip install` 安装包。
+
+MinerU 官方安装方式同样以 uv 为主（见 [MinerU README](https://github.com/opendatalab/MinerU/blob/master/README_zh-CN.md)），conda 在本项目中主要用于环境壳层，而非替代 pip 装包。
+
+---
+
+## 推荐工作流
+
+### 1. 创建并激活 conda 环境
+
+```bash
+conda create -n mineru python=3.12
+conda activate mineru
+```
+
+### 2. 用 uv 安装 MinerU
+
+```bash
+# 安装 uv（若尚未安装）
+pip install uv -i https://mirrors.aliyun.com/pypi/simple
+
+# PyPI 安装（用户）
+uv pip install -U "mineru[all]" -i https://mirrors.aliyun.com/pypi/simple
+
+# 源码开发安装（开发者）
+cd /path/to/MinerU
+uv pip install -U -e '.[all]' -i https://mirrors.aliyun.com/pypi/simple
+```
+
+### 3. 非交互式命令（脚本 / CI）
+
+```bash
+conda run -n mineru uv pip install -U "mineru[core]" -i https://mirrors.aliyun.com/pypi/simple
+conda run -n mineru python -c "import torch; print(torch.__version__)"
+```
+
+### 4. 验证环境
+
+```bash
+conda activate mineru
+python -c "import torch; print(f'PyTorch: {torch.__version__}, CUDA: {torch.cuda.is_available()}')"
+python -c "import mineru; print('mineru OK')"
+```
+
+---
+
+## 什么时候用 conda
+
+1. **固定 Python 版本**  
+   MinerU 要求 Python 3.10–3.13。Windows 上使用 vLLM 时，因 `ray` 限制暂不支持 3.13，建议使用 3.10–3.12。
+
+2. **CUDA / cuDNN 版本对齐困难时（Linux GPU）**  
+   pip 的 torch / vllm wheel 自带部分 CUDA runtime，但仍需与 NVIDIA 驱动、Compute Capability 匹配。conda-forge / nvidia channel 可一次性安装 `pytorch-cuda` + `cudnn`，减少版本矩阵踩坑。
+
+3. **需要编译的 C++ 扩展**  
+   例如 [DiT 布局检测](../ocr_tools/universal_doc_parser/dit_support/README.md) 依赖的 **detectron2**，从源码编译时常需匹配的 gcc/clang 与 torch ABI；conda-forge 预编译包有时更省事。
+
+4. **多项目环境隔离**  
+   OCR Platform 同时涉及 MinerU、PaddleX、DotsOCR 等，用 conda 区分环境可避免依赖冲突。
+
+---
+
+## 什么时候用 uv
+
+1. **MinerU 本体及绝大部分 PyPI 依赖**  
+   `mineru[all]` 中的 torch、transformers、vllm、onnxruntime、opencv-python、fastapi 等均有 PyPI wheel。
+
+2. **日常开发、CI、重装依赖**  
+   uv 解析与安装速度明显快于 conda SAT 求解。
+
+3. **纯 Python 工具链**  
+   mineru-vl-utils、gradio、项目内脚本依赖等。
+
+4. **子项目独立 venv（可选）**  
+   PaddleX 等可按 [paddlex/README.md](paddlex/README.md) 使用 `uv venv` 单独建环境，与 MinerU 环境分离。
+
+---
+
+## MinerU 核心依赖：uv/pip 能否安装
+
+以下依赖来自 MinerU `pyproject.toml`，**通常无需 conda 单独安装**：
+
+| 依赖 | uv/pip | 说明 |
+|------|--------|------|
+| torch / torchvision | ✅ | PyPI 提供 CPU/CUDA wheel；GPU 需选对 CUDA 版本 index |
+| vllm | ✅ | Linux 上 pip 安装；生产环境也可使用官方 Docker 镜像 |
+| onnxruntime | ✅ | wheel 自带推理后端 |
+| opencv-python | ✅ | wheel 自带 OpenCV；Linux 无头环境可能还需系统 libGL |
+| transformers / accelerate | ✅ | 纯 Python |
+| detectron2 | ⚠️ | 可从 git 源码编译；conda 预编译包有时更稳（见 DiT 模块） |
+| PaddlePaddle | — | **MinerU 核心不需要**；模型已转为 PyTorch，见 [mineru_处理流程.md](mineru/mineru_处理流程.md) |
+
+可选扩展（按后端选择安装）：
+
+| extra | 主要依赖 | 平台 |
+|-------|----------|------|
+| `pipeline` | torch, torchvision, onnxruntime | 全平台，支持纯 CPU |
+| `vlm` | torch, transformers | 全平台 |
+| `vllm` | vllm | Linux |
+| `mlx` | mlx-vlm | macOS (Apple Silicon) |
+| `lmdeploy` | lmdeploy | Windows |
+| `gradio` | gradio | 全平台 |
+
+---
+
+## 哪些情况 conda / 系统包仍不可少
+
+uv **不能替代**以下层级；缺了会在 import 或 GPU 初始化阶段失败：
+
+### 1. NVIDIA 驱动
+
+uv 不安装驱动。需本机 `nvidia-smi` 可用，且驱动版本满足所选 CUDA / torch wheel 要求。
+
+### 2. CUDA 版本矩阵
+
+torch + vllm + 驱动 + CUDA 必须对齐。uv 可以装 wheel，但**选错版本会导致 `CUDA available: False`**。裸机 Linux GPU 若反复踩坑，可改用：
+
+- conda 安装 `pytorch-cuda` + `cudnn`；或
+- MinerU 官方 Docker 镜像（已打包 torch + vllm + CUDA）。
+
+### 3. 系统级 C 库
+
+典型报错：`ImportError: libGL.so.1: cannot open shared object file`
+
+这是系统库缺失，需用系统包管理器安装，例如 WSL2 / Ubuntu：
+
+```bash
+sudo apt-get install libgl1-mesa-glx
+```
+
+conda 和 uv 均不能直接解决。
+
+### 4. 从源码编译的扩展
+
+detectron2 等需要本地编译器与 torch 版本匹配。uv 只能触发 pip 编译，不保证在所有平台一次成功。
+
+---
+
+## 能力边界示意
+
+```
+┌─────────────────────────────────────────────────────────┐
+│  uv / pip 能管                                           │
+│  PyPI Python 包：torch, vllm, opencv-python, mineru…    │
+└─────────────────────────────────────────────────────────┘
+                          ↓ 依赖
+┌─────────────────────────────────────────────────────────┐
+│  uv / pip 管不了（需 conda / apt / brew / 驱动安装）     │
+│  · NVIDIA 驱动                                          │
+│  · CUDA Toolkit / cuDNN 与驱动对齐                       │
+│  · libGL、libgomp 等系统 .so                             │
+│  · C++ 编译 toolchain（detectron2 等）                   │
+└─────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 按场景选择
+
+| 场景 | 建议 |
+|------|------|
+| **macOS 本地开发** | `conda create -n mineru python=3.12` + `uv pip install -e '.[all]'`；VLM 可用 MLX 或远程 vLLM 服务 |
+| **Linux GPU 生产** | 优先 **Docker 官方镜像**；裸机则用 conda 对齐 CUDA 栈 + uv 装 mineru |
+| **仅 MinerU CLI/API** | 可完全 `uv venv` + `uv pip install mineru[all]`，不必 conda |
+| **OCR Platform 全家桶**（PaddleX + DiT + MinerU） | conda 做环境隔离；各子项目用 uv 装包；Paddle 可单独 `uv venv` |
+| **CI / 脚本** | `conda run -n mineru ...` 避免 activate 未生效 |
+
+---
+
+## 与本仓库其他文档的关系
+
+| 文档 | 内容 |
+|------|------|
+| [mineru/README.md](mineru/README.md) | MinerU 环境变量、vLLM 服务、批量处理 |
+| [paddlex/README.md](paddlex/README.md) | PaddleX 独立 `uv venv` 与 paddlepaddle 安装 |
+| [ocr_tools/universal_doc_parser/dit_support/README.md](../ocr_tools/universal_doc_parser/dit_support/README.md) | detectron2 编译安装 |
+| 项目 `.cursor/rules/project-conventions.mdc` | 全局约定：`conda activate mineru` / `conda run -n mineru` |
+
+---
+
+## 常见问题
+
+### Q: 能否完全不用 conda，只用 uv？
+
+可以。MinerU 官方支持 `uv venv` + `uv pip install mineru[all]`。本项目因多工具并存、团队已有 `mineru` conda 环境，仍推荐 conda 做环境壳。
+
+### Q: 能否完全不用 uv，只用 conda install？
+
+不推荐。MinerU 未提供 conda 配方，conda 直接装 PyPI 包速度慢且易与 channel 冲突。应用 conda 管 Python，uv 管 PyPI 依赖。
+
+### Q: Windows 上 CUDA 不可用怎么办？
+
+参考 [MinerU Windows CUDA FAQ](https://opendatalab.github.io/MinerU/zh/faq/#windows-cuda-acceleration)。确认 Python 版本 ≤ 3.12，并安装与驱动匹配的 torch CUDA wheel。
+
+### Q: 当前环境装了哪些是通过 conda、哪些是通过 pip？
+
+典型 `mineru` 环境中，conda 仅提供 **Python + 基础系统库**（openssl、zlib 等），torch、vllm、onnxruntime、opencv、detectron2 等均为 pip/uv 安装。可用以下命令自查：
+
+```bash
+conda list -n mineru | head -30          # conda 层
+conda list -n mineru | rg "pypi_0"       # pip/uv 层
+```

docs/ocr_tools/universal_doc_parser/HF_safetensors->GGUF.md

@@ -64,6 +64,76 @@ MinerU2.5-Pro 是个视觉-语言文档解析模型（PDF→Markdown），整体
 所以三者是**串行协作、缺一不可**的：投影器和编码器决定 LLM「看到了什么」，LLM 决定「怎么把看到的说出来」。这也是 MinerU2.5-Pro、PaddleOCR-VL 转换时必须同时导出主体模型和 `mmproj` 两个 GGUF 的原因——少了 mmproj，模型就「瞎」了。
 
 ---
+### 进一步问题
+1. ViT把图片切成小块（patch）,是否会造成文字不论从横向还是纵向的不完整，向量维度和语义空间是否会对齐？
+2. 如果文字不完整，投影器又是如何将视觉patch编码映射到LLM的embedding空间？
+
+两个问题问到了 VLM 的核心机制。简短回答：**单个 patch 的"切割不完整"几乎不影响结果，因为真正的语义理解不发生在单个 patch 层面，而是发生在 ViT 的全局自注意力之后。** 下面拆开讲。
+
+## 1. 切 patch 确实会切断文字，但这不是问题
+
+你的直觉完全正确：ViT 把图片按固定网格（比如 14×14 或 16×16 像素一块）硬切，**一个汉字、一个字母确实经常会被横向或纵向切到两三个 patch 里**，笔画被拆开。
+
+但 ViT 不是「一个 patch 单独识别一个字」的结构。关键在于：
+
+### 自注意力（Self-Attention）让每个 patch 都能"看到"所有其他 patch
+
+ViT 的每一层 Transformer 里，**任意一个 patch 的向量都会和图中所有其他 patch 做注意力交互**。所以经过若干层之后：
+
+- 含「某字左半边」的 patch，会从相邻含「右半边」的 patch 那里聚合信息；
+- 最终这个 patch 的输出向量，**已经不只代表它那一小块像素，而是编码了它在整张图里的上下文**。
+
+加上 **位置编码（position embedding）** 记录了每个 patch 的二维坐标，模型知道「这块在那块的右边/下边」，于是被切断的笔画在特征空间里被重新「拼回」完整字符的语义。
+
+### 类比
+就像你把一张写满字的纸撕成小方块，单看一块碎片认不出字；但如果你能同时看到所有碎片、并且知道每块原来的位置，你的大脑就能拼出完整内容。自注意力 + 位置编码就是干这件事的。
+
+### 工程上还有额外保障
+- **小 patch + 高分辨率**：一个字往往横跨多个 patch，信息冗余度高，丢一点边角无所谓。
+- **Qwen2-VL 的动态分辨率**：它不强制把图缩成固定尺寸，而是按原图比例切，避免文字被压扁变形；并且会把相邻 2×2 的 patch 合并，兼顾细节和效率。
+- **端到端训练**：整个模型是拿海量「图→文字」样本训出来的，它在训练中早就"学会"了如何处理被切碎的字符——这是数据驱动的能力，不是靠人工对齐 patch 边界。
+
+## 2. 投影器如何映射"不完整"的 patch —— 其实它拿到的已经不是碎片了
+
+这是理解的关键点：**投影器（projector / mmproj）不是直接对接原始切碎的 patch，而是对接 ViT 全部自注意力层处理之后的输出。**
+
+数据流的精确顺序：
+
+```
+原始 patch（碎片，局部像素）
+   │
+   ▼
+[ViT 的 N 层自注意力]  ← 这里完成了跨 patch 的信息融合
+   │
+   ▼
+富含全局上下文的 patch 向量（每个向量已"懂"自己代表什么字/结构）
+   │
+   ▼
+[投影器 Projector]  ← 它处理的是上面这种"已理解"的向量
+   │
+   ▼
+LLM embedding 空间
+```
+
+所以回答你的疑问：**投影器面对的从来不是"半个字"，而是已经被 ViT 注意力机制重组、带有完整语义的特征向量。** 文字完不完整的问题，在到达投影器之前就已经被 ViT 内部解决了。
+
+### 投影器具体做两件事
+
+1. **维度对齐**：ViT 隐藏维度（比如 1152、1280）和 LLM 隐藏维度（比如 1536、3584）通常不一样。投影器（一般是 1～2 层 MLP）把视觉向量线性变换到 LLM 要求的维度。
+
+2. **语义空间对齐**：ViT 和 LLM 是两个独立训练出来的模型，各自的向量空间含义不通。投影器在训练中学到一个映射，让视觉特征"翻译"成 LLM 词向量空间里有意义的点——使 LLM 把这些图像 token 当成"能读懂的词"来处理。
+
+### 最后 LLM 还会再融合一次
+进入 LLM 后，这些图像 token 会和文本 token 一起，在 LLM 自己的注意力层里**再次跨 token 交互**。也就是说还有第二轮"全局拼合"。所以即使个别视觉 token 信息有损，LLM 也能借助语言先验和上下文（比如它知道"这是一段中文句子，根据前后文这里应该是某个字"）进一步纠错补全。
+
+## 一句话总结
+
+- 切碎不要紧：**ViT 的自注意力 + 位置编码**在投影器之前就把被切断的字符在特征层面重组完整了。
+- 投影器拿到的是"已理解的全局特征"而非"像素碎片"，它只负责**维度 + 语义空间的对齐翻译**。
+- LLM 端的注意力 + 语言先验再做一轮纠错，最终输出连贯的文字。
+
+整个能力是**端到端训练**赋予的——模型从数据里自己学会了「碎片化输入 → 完整文字」的鲁棒映射，而不是靠在 patch 边界上做精确切字。
+---
 
 ## 关键事实
 
@@ -130,7 +200,7 @@ cp ~/models/MinerU2.5-Pro-2604-1.2B/chat_template.jinja ~/models/MinerU2.5-Pro-2
 
 ```
 
-> 模型总共才 ~1.5GB，48G 内存下**不建议量化**主模型（Q4 会掉 OCR 精度），直接 f16 即可；mmproj 用 f16 或 f32 质量最佳。
+> 模型总共才 ~1.5GB，48G 内存下直接 f16 即可；想省内存/略提速可对主模型做 **Q8_0（几乎无损，详见后文「f16 vs Q8_0 量化」）**，但**不要用 Q4**（会掉 OCR 精度）；**mmproj 始终保持 f16/f32**，不要量化。
 
 转完后，把你 `paddle_local_daemon.sh` 里这几行指向新文件就行：
 
@@ -230,6 +300,88 @@ python convert_hf_to_gguf.py ~/models/MinerU2.5-Pro-2604-1.2B \
 
 ---
 
+## f16 vs Q8_0 量化
+
+结论先行：**对这类 OCR/VLM 小模型，Q8_0 是「几乎无损」的，可以放心用；真正要避开的是 Q4/Q5。**
+
+### 精度
+
+| 量化 | 位宽 | 困惑度损失 | OCR（数字/金额/单号）影响 |
+|---|---|---|---|
+| f16 | 16-bit | 基准 | 基准 |
+| **Q8_0** | 8-bit（每 32 权重一个 scale） | 通常 **< 0.1%**，业界视为"几乎无损" | 实测无可感知差异 |
+| Q5_K_M | ~5.5-bit | 较小 | 偶有个位错字，需评测 |
+| Q4_K_M | ~4.5-bit | 明显 | **数字/相似字易出错，不建议 OCR 用** |
+
+OCR 对权重精度比闲聊更敏感（要精确分辨 `8/0`、`3/5`、相似汉字），所以低位量化的风险高于普通文本生成；而 Q8_0 的误差量级远低于 OCR 容错阈值，安全。
+
+### 效率（Apple Silicon / Metal）
+
+- **体积**：Q8_0 约为 f16 的 ~53%。1.2B：~2.4GB → ~1.3GB；0.9B：~1.8GB → ~1.0GB。
+- **速度**：解码主要受**内存带宽**制约，权重读取量减半 → token 生成速度通常**持平或略快**；但 Q8_0 有反量化开销，算力充足时提升有限。对当前 ~168 t/s 的水平，预期持平到小幅提升。
+- **收益定位**：模型本就小，Q8_0 的主要价值是**省一半内存 + 不掉精度**，而非大幅提速。若内存不紧张，f16 也完全够用。
+
+### 为什么不直接 `convert_hf_to_gguf.py --outtype q8_0` 一步到位？
+
+**可以，而且对「只要 Q8_0」的场景完全够用、质量与两步法基本无差异。** `--outtype` 支持的类型是：
+
+```
+f32 / f16 / bf16 / q8_0 / tq1_0 / tq2_0 / auto
+```
+
+`q8_0` 在列，所以一步直出没问题：
+
+```bash
+python convert_hf_to_gguf.py ~/models/MinerU2.5-Pro-2604-1.2B \
+    --outfile ~/models/MinerU2.5-Pro-2604-1.2B-GGUF \
+    --outtype q8_0
+# mmproj 仍单独转、保持 f16（见前面步骤）
+```
+
+默认推荐**先 f16 母本再 `llama-quantize`**的真实理由（不是因为 `--outtype q8_0` 不行）：
+
+1. **K-quants 只能走 `llama-quantize`**：`--outtype` **不支持** `Q4_K_M`/`Q5_K_M`/`Q6_K` 等。一旦想试这些更优的低位量化，必须 f16 → `llama-quantize`。
+2. **留一份 f16 高精度母本**：之后想要 Q8_0、Q5_K_M、Q6_K 等任意量化都基于它**秒级生成**，无需每次从 safetensors 重转（重转慢，还要重跑 tokenizer 的 OTSL `special` 修复那步）。
+3. **imatrix 校准量化**也只能经 `llama-quantize`。
+
+一句话：**只用 Q8_0、不折腾其他 → `--outtype q8_0` 更省事；可能还要试别的量化 / 想留母本 → 走两步法。**
+
+### 量化脚本（基于已转好的 f16 主模型，用 `llama-quantize`）
+
+> 量化是对**已有 f16 GGUF**的再压缩，**无需**从 safetensors 重转，也**不动 mmproj**。
+> 之前对 MinerU2.5 做的 OTSL token `special` 修复已固化在 f16 里，量化会原样保留 tokenizer 元数据，**无需重做**。
+
+```bash
+LLAMA_BIN="$HOME/workspace/repository.git/llama.cpp/build/bin"
+
+# MinerU2.5：只量化语言主体，mmproj 保持 f16 不动
+"$LLAMA_BIN/llama-quantize" \
+    ~/models/MinerU2.5-Pro-2604-1.2B-GGUF/MinerU2.5-Pro-2604-1.2B-F16.gguf \
+    ~/models/MinerU2.5-Pro-2604-1.2B-GGUF/MinerU2.5-Pro-2604-1.2B-Q8_0.gguf \
+    Q8_0
+
+# PaddleOCR-VL-1.6：同理
+"$LLAMA_BIN/llama-quantize" \
+    ~/models/PaddleOCR-VL-1.6-GGUF/PaddleOCR-VL-1.6-F16.gguf \
+    ~/models/PaddleOCR-VL-1.6-GGUF/PaddleOCR-VL-1.6-Q8_0.gguf \
+    Q8_0
+```
+
+> 文件名按实际 f16 文件调整（转换产物一般是 `*-F16.gguf`）。`llama-quantize` 最后一个参数即量化类型，可选 `Q8_0`、`Q5_K_M`、`Q4_K_M` 等。
+
+启用：把对应 daemon 的 `MODEL_PATH` 指向 `*-Q8_0.gguf`（`MMPROJ_PATH` 不变），重启即可。
+
+### 验证（量化后务必做）
+
+```bash
+ocr_tools/daemons/mineru_local_daemon.sh restart
+ocr_tools/daemons/curl_local_mineru.sh
+```
+
+确认两点：①`content` 里 OTSL 结构 token（`<fcel>`/`<nl>`）仍在；②抽查几行金额/单号与 f16 输出是否一致。一致即可放心用 Q8_0。
+
+---
+
 ## 不推荐的路径
 
 - **transformers + MPS**：Mac 上 MPS 跑视觉模型慢，且官方明确说 transformers 路径只支持 element-level（单元素识别），**不支持整页解析**，会破坏你现在的流水线。

ocr_tools/daemons/curl_local_img.png

@@ -1 +0,0 @@
-/Users/zhch158/workspace/data/流水分析/A用户_单元格扫描流水/bank_statement_yusys_v4/A用户_单元格扫描流水/A用户_单元格扫描流水_page_003.png

ocr_tools/daemons/curl_local_ocr.sh

@@ -1,9 +1,9 @@
 # --media-path /Users/zhch158/workspace  # 设置基础目录
 # {"url": "file://test_ocr_image.png"}  # 相对于基础目录的相对路径
-curl http://127.0.0.1:8080/v1/chat/completions \
+curl http://127.0.0.1:8101/v1/chat/completions \
   -H "Content-Type: application/json" \
   -d '{
-    "model": "ocr-vl",
+    "model": "glm-ocr",
     "messages": [
       {
         "role": "user",

ocr_tools/daemons/mineru_local_daemon.sh

@@ -24,7 +24,8 @@ HOST="0.0.0.0"
 
 # 本地 GGUF 模型路径（llama-server -hf 下载后的实际路径）
 HF_CACHE="$HOME/models/MinerU2.5-Pro-2604-1.2B-GGUF"
-MODEL_PATH="$HF_CACHE/MinerU2.5-Pro-2604-1.2B-F16.gguf"
+# MODEL_PATH="$HF_CACHE/MinerU2.5-Pro-2604-1.2B-F16.gguf"
+MODEL_PATH="$HF_CACHE/MinerU2.5-Pro-2604-1.2B-Q8_0.gguf"
 MMPROJ_PATH="$HF_CACHE/MinerU2.5-Pro-2604-1.2B-F16-mmproj.gguf"
 
 # 模型别名（对外暴露的模型 ID，对应 yaml 中的 model 字段）

ocr_tools/daemons/paddle_local_daemon_1.6.sh

@@ -23,7 +23,8 @@ HOST="0.0.0.0"
 
 # 本地 GGUF 模型路径（llama-server -hf 下载后的实际路径）
 HF_CACHE="$HOME/models/PaddleOCR-VL-1.6-GGUF"
-MODEL_PATH="$HF_CACHE/PaddleOCR-VL-1.6-F16.gguf"
+# MODEL_PATH="$HF_CACHE/PaddleOCR-VL-1.6-F16.gguf"
+MODEL_PATH="$HF_CACHE/PaddleOCR-VL-1.6-Q8_0.gguf"
 MMPROJ_PATH="$HF_CACHE/PaddleOCR-VL-1.6-F16-mmproj.gguf"
 
 # 模型别名（对外暴露的模型 ID，对应 yaml 中的 model_name）