企业官网建设流程全解析

前几年做 RAG 知识库的时候，最难受的一个环节不是向量检索，而是文档解析。很多 PDF 扫描件、表格图片、拍照文档，普通 OCR 识别出来乱七八糟，版面乱、公式崩、表格结构全丢，喂给 Embedding 模型之后检索效果可想而知。所以当看到 DeepSeek-OCR 这个开源项目的时候，第一反应是：OCR 环节终于有大模型级别的解法了。这篇文章我会从部署环境、服务启动、接口调用、批量任务、RAG 集成，再到 LoRA 微调的理论和实战流程，完整带大家走一遍。不管你是想把本地扫描件批量结构化，还是想在现有知识库系统里替换传统 OCR 模块，都可以直接参考这套方案。

先说结论：DeepSeek-OCR 是开源 OCR 模型，定位是“文档分析与结构化输出”，不只是给一行识别文字，而是输出包含版面、表格、公式、阅读顺序的 Markdown 结构化结果。它可以直接部署成 API 服务，接到 RAG 流水线里当文档解析层，也可以用 LoRA 做领域微调，比如财务票据、医学报告、古籍文献这类专业场景。模型部署方式覆盖 GPU 和 CPU，显存占用取决于权重版本和推理参数，建议先用小分辨率图片做冒烟测试。下面先给一张核心能力速览表，再逐步展开。

1. DeepSeek-OCR 核心能力速览

需要说明的是，上面表格里的能力项来自项目定位和常见部署方式，显存占用、推理速度、批量吞吐都会受到权重尺寸、量化方式、图片长度和显卡型号影响。不要上来就全量跑，先小参数验证，再上批量。

2. 适用场景与使用边界

DeepSeek-OCR 最适合的场景有四个：第一，RAG 知识库里的 PDF 和图片预处理，传统 OCR 输出纯文本会丢失版面结构，它直接输出 Markdown，相关段落、表格、标题层级都能保留，检索效果会好很多。第二，批量文档数字化，比如把历史扫描件、单据、合同集中转成结构化文本，然后进数据库或知识库。第三，专业领域模型微调，LoRA 微调后可以针对票据、医疗报告、论文公式等特定版式做专项优化。第四，内容合规审核和资料归档，先转成文本再做后续处理。

使用边界也要清楚。它不是全能的，对极端复杂排版、手写体、严重倾斜的照片，效果需要实测。不要拿它处理涉及个人隐私的身份证、医疗记录等敏感文档，除非你有明确的授权和合规流程。也不要把第三方版权书籍、论文、商业合同直接批量抓取后用于公开传播，这会触碰版权问题。在本地或企业内部使用时，要确保 OCR 处理的内容来源合法，并且输出结果只用于授权范围内的检索、归档、摘要等用途。

3. 本地部署环境准备

部署 DeepSeek-OCR 之前，先把环境检查一遍。下面是通用检查清单，按照你自己的操作系统和显卡调整。

3.1 操作系统

Windows、Linux、macOS 理论上都能跑。生产或长期运行推荐 Linux 服务器，Windows 主要用于开发和测试。Linux 下文本处理、路径处理、依赖安装都更稳。

3.2 GPU 与驱动

如果使用 NVIDIA 显卡，先确认驱动版本，然后安装对应版本的 CUDA。现在的 PyTorch 通常使用 CUDA 12.x 以上版本，可以通过nvidia-smi查看驱动支持的 CUDA 版本。如果使用老显卡或 Intel 显卡，需要看项目文档是否支持相应推理后端，不支持就优先 CPU 模式。

3.3 Python 与虚拟环境

建议 Python 3.10 或 3.11，使用 conda 或 venv 创建独立环境，避免污染系统 Python：

conda create -n deepseek-ocr python=3.10 conda activate deepseek-ocr

python -m venv deepseek-ocr-env source deepseek-ocr-env/bin/activate

3.4 Python 依赖

安装依赖以requirements.txt或项目文档为准。通常 OCR 模型需要torch、transformers、accelerate、pillow、pandas、pypdf等。先安装 PyTorch，再安装其他依赖：

# CUDA 版 PyTorch 安装示例，实际版本以项目要求为准 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121

# 项目依赖安装示例 git clone https://github.com/your-project/deepseek-ocr.git cd deepseek-ocr pip install -r requirements.txt

注意：具体仓库地址要以你获取项目时的真实仓库为准，上面的your-project只是一个占位符。如果没有现成 requirements.txt，就手动安装主干依赖。

3.5 磁盘空间

模型权重通常占几个 GB 到十几 GB 不等，训练微调时还需要额外保存检查点。建议预留 50GB 以上可用磁盘。批量处理大量 PDF 时，输出目录也要预留足够空间。

3.6 端口占用

API 服务默认会监听一个端口，常见的是 8000、8080、7860 等。提前用下面命令检查端口是否被占用：

# Linux / macOS lsof -i :8000 # Windows netstat -ano | findstr :8000

如果端口被占用，启动时换一个端口。

4. 安装部署与启动方式

部署方式分为三种：命令行推理、Python 函数调用、API 服务。下面分别说明。

4.1 命令行推理

如果项目提供 CLI 入口，通常可以这样使用：

python -m deepseek_ocr.run --input ./test_images/sample.png --output ./outputs

参数说明：

• --input：输入图片路径，可以是单张图片或目录。
• --output：输出目录，用于保存 Markdown 结果。
• 有些实现还会支持--model_path指定权重路径。

不同仓库的 CLI 参数名不完全一样，跑之前先看项目的 README 或python -m deepseek_ocr.run --help。

4.2 Python 脚本推理

更灵活的方式是写一个 Python 调用脚本。通用步骤是：加载模型、读取本地图片、推理、拿到识别结果。

from PIL import Image from transformers import AutoModel, AutoTokenizer model_path = "./models/deepseek-ocr" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModel.from_pretrained(model_path, trust_remote_code=True, device_map="auto") image = Image.open("./test_images/sample.png").convert("RGB") # 伪代码，实际生成接口名称和参数以项目源码为准 result = model.generate( image=image, prompt="识别图片中的文字，并以Markdown格式输出", ) print(result)

这段代码的重点是trust_remote_code=True，很多开源多模态模型需要这个参数才能加载自定义模型结构。如果项目使用官方 GitHub 仓库代码，也可以直接 import 仓库里的模块。

4.3 API 服务启动

为了供上层应用调用，需要把它封装成一个 HTTP 服务。常见方案是用 FastAPI 或 Gradio。

FastAPI 版本的接口示例如下：

from fastapi import FastAPI, UploadFile, File from PIL import Image import io app = FastAPI() @app.post("/ocr") async def ocr(file: UploadFile = File(...)): image = Image.open(io.BytesIO(await file.read())).convert("RGB") # 调用模型推理函数 text = model_generate(image) return {"text": text}

保存为server.py，启动命令：

uvicorn server:app --host 0.0.0.0 --port 8000

这里要注意，host 0.0.0.0意味着局域网内其他机器也能访问。如果只是在本地调用，建议改成127.0.0.1。

5. OCR 功能测试与效果验证

部署完成之后，不要急着上批量任务，先准备一组测试素材，验证核心功能是否正常。

5.1 单张图片文字识别测试

选择一张包含标题、正文、列表的截图或扫描件，调用识别接口，确认以下几项：

• 识别文字是否准确。
• 标题层级是否体现为 Markdown 的#、##。
• 换行和分段是否正确。

判断标准：纯文本识别错误率在你的可接受范围内，Markdown 结构能明显区分标题和正文。

5.2 PDF 文档解析测试

用本地 PDF 测试时，需要先将 PDF 页面转换为图片再送入模型，或者使用项目内置的 PDF 解析接口。页面渲染分辨率建议 150 DPI 到 300 DPI。分辨率太低，小字会糊；分辨率太高，推理时间暴增。

操作步骤：

1. 选择一页排版较规范的 PDF 转成 PNG。
2. 调用 OCR 接口。
3. 检查输出的 Markdown 是否保留段落顺序。

5.3 表格识别测试

表格是传统 OCR 的高频失败点。测试时使用带边框表格和不带边框表格两种素材，观察模型是否输出为 Markdown 表格语法：

| 名称 | 数量 | 价格 | | --- | --- | --- | | 苹果 | 10 | 20元 |

如果表格内容被拆成普通文本，说明表格识别能力弱或输入图片分辨率不够。

5.4 公式与特殊符号测试

数学公式、化学式等特殊内容，普通 OCR 很难处理。测试时输入一页含有公式的 PDF 或图片，看模型是输出 LaTeX 形式还是普通文字形式。这个测试结果直接决定该模型适不适合论文、技术文档类场景。

5.5 CPU / GPU 推理对比

在本地环境，分别用 CPU 和 GPU 跑同一张图，记录：

• 单张推理耗时。
• 显存或内存峰值。
• 输出结果是否一致。

如果 CPU 单张耗时在 10 秒以上，说明批量处理对硬件压力很大。批量任务优先在 GPU 环境跑。

5.6 常见失败原因

• 图片分辨率太低，小字识别不全。
• 图片方向倾斜严重，模型输出乱序。
• 显存不足，推理报 OOM。
• 依赖版本不一致，加载模型时报错。

6. 接口 API 调用与批量任务实战

当 API 服务跑起来之后，就可以把它接到自己的工具链里。下面用 Python 演示常见调用方式。

6.1 单张图片调用接口

import requests url = "http://127.0.0.1:8000/ocr" files = {"file": open("./test_images/sample.png", "rb")} response = requests.post(url, files=files, timeout=120) print(response.status_code) print(response.json())

超时时间不要设置太短，模型推理和上传大图都需要时间。大图建议先压缩到长边 2000 像素以内。

6.2 Base64 方式调用

有些场景不方便直接传文件，可以用 Base64 编码图片：

import base64 import json import requests with open("./test_images/sample.png", "rb") as f: img_b64 = base64.b64encode(f.read()).decode("utf-8") payload = { "image_base64": img_b64 } url = "http://127.0.0.1:8000/ocr_base64" response = requests.post(url, json=payload, timeout=120) print(response.text)

注意：Base64 会比原文件大 1/3，传输和接口接收时要考虑大小限制。

6.3 批量图片目录处理

批量处理时，用一个循环遍历目录，把每张图片的结果保存成独立文件：

import os import requests import time URL = "http://127.0.0.1:8000/ocr" INPUT_DIR = "./input_images" OUTPUT_DIR = "./outputs" os.makedirs(OUTPUT_DIR, exist_ok=True) image_exts = {".png", ".jpg", ".jpeg", ".bmp", ".tiff"} for filename in os.listdir(INPUT_DIR): ext = os.path.splitext(filename)[1].lower() if ext not in image_exts: continue file_path = os.path.join(INPUT_DIR, filename) try: with open(file_path, "rb") as f: resp = requests.post(URL, files={"file": f}, timeout=180) if resp.status_code == 200: out_path = os.path.join(OUTPUT_DIR, os.path.splitext(filename)[0] + ".md") with open(out_path, "w", encoding="utf-8") as f_out: f_out.write(resp.json().get("text", "")) print(f"成功: {filename}") else: print(f"失败: {filename}, 状态码: {resp.status_code}") except Exception as e: print(f"异常: {filename}, 错误: {e}") time.sleep(0.5)

批量任务设计建议：每张图片单独保存结果，失败文件单独记录，方便重跑。不要把所有输出都拼到一个文件里，定位问题很麻烦。

6.4 失败重试建议

批量任务常见的失败原因是接口超时和显存不足。可以在代码里加一个重试机制，例如对超时的文件等待 5 秒后重试两次。如果连续失败，就把文件名写入failed.txt，最后统一查看。

7. 模型微调基础：从全量微调到 LoRA

微调之前，先搞清楚概念。大模型微调主要有三种方式：全量微调、冻结微调、LoRA 微调。

7.1 全量微调

全部参数参与训练，效果理论上最强，但显存和算力开销极大。对 OCR 模型来说，如果权重文件就有几十 GB，全量微调对个人开发者基本不现实。

7.2 冻结微调

冻结模型的大部分参数，只训练最后一层或少数模块。这种方式能降低训练成本，因为可训练参数变少，但效果提升上限也有限。

7.3 LoRA 微调

LoRA 的核心思想是在原始权重旁边插入低秩矩阵，只训练这些低秩矩阵。训练时冻结原始参数，推理时可以把训练好的 LoRA 权重加载进去，也可以用脚本把 LoRA 合并回主模型。

LoRA 的优势是：

• 可训练参数量很小，显存占用低。
• 训练时间短，适合领域快速适配。
• 一套基础模型可以适配多个领域，切换 LoRA 权重就能切换需求。

对 DeepSeek-OCR 这种多模态文档模型来说，LoRA 特别适合用来适配垂直行业文档。比如金融财报、法律卷宗、医学病历报告，这些文档版式固定，用 LoRA 训练后识别效果往往比通用模型稳定很多。

8. LoRA 微调实战流程

下面给出一套通用 LoRA 微调流程，替换成你的数据和模型路径就能跑通。

8.1 准备训练数据

数据格式一般是 JSON 数组，每个样本包含图片路径和期望输出的文本，字段名以项目为准。

[ { "image": "data/train/001.png", "ocr_text": "发票代码：12345678\n发票号码：87654321\n开票日期：2025年01月01日" }, { "image": "data/train/002.png", "ocr_text": "患者姓名：张三\n诊断结果：急性支气管炎" } ]

训练数据建议几百到几千张即可，关键在多样性：不同字体、不同清晰度、不同排版都放进去。不要只放同一类很干净的数据，测试时你会发现在真实数据上效果打折扣。

8.2 加载模型与 LoRA 配置

from transformers import AutoModel, AutoTokenizer from peft import LoraConfig, get_peft_model model_path = "./models/deepseek-ocr" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModel.from_pretrained(model_path, trust_remote_code=True, device_map="auto") lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) model.print_trainable_parameters()

参数解释：

• r：低秩矩阵的秩，越大可学习参数越多，也越容易过拟合。常用 8、16、32。
• lora_alpha：缩放系数，一般设为r的 2 倍。
• lora_dropout：正则化参数，0.05 比较常用。

8.3 训练脚本框架

from transformers import Trainer, TrainingArguments training_args = TrainingArguments( output_dir="./lora_output", per_device_train_batch_size=2, gradient_accumulation_steps=4, num_train_epochs=3, learning_rate=2e-4, fp16=True, logging_steps=20, save_steps=200, save_total_limit=2, ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, ) trainer.train()

这里fp16=True需要 GPU 支持半精度。如果你的显卡不行，改成fp16=False，但训练速度会变慢。

8.4 合并 LoRA 权重

训练完成后，可以将 LoRA 权重合并回主模型，方便直接用原生模型推理。

from peft import PeftModel base_model = AutoModel.from_pretrained(model_path, trust_remote_code=True) merged_model = PeftModel.from_pretrained(base_model, "./lora_output") merged_model = merged_model.merge_and_unload() merged_model.save_pretrained("./models/deepseek-ocr-lora-merged") tokenizer.save_pretrained("./models/deepseek-ocr-lora-merged")

合并后的模型可以像原模型一样加载推理，也可以继续作为 API 服务的基础模型。

8.5 微调后的效果验证

微调完成后，不要只看训练集 loss。准备一个和训练数据分布接近但完全不相交的验证集，对比微调前后的识别效果。如果训练集准确率很高但验证集很差，说明过拟合了，需要增加数据量或调小r和 epoch。

9. 基于 DeepSeek-OCR 构建 RAG 知识库

OCR 模型在 RAG 里的作用非常明确：把不可检索的图片、PDF 变成可检索的文本。一个完整的 RAG 流水线通常长这样：

原始文档 → OCR 结构化文本 → 文本切片 → Embedding 向量化 → 向量数据库存储 → 用户查询检索 → 大模型生成回答

9.1 文档解析环节改造

以前用传统 OCR 时，处理 PDF 经常面临一个问题：OCR 输出的纯文本失去了段落边界，导致切片非常生硬。用 DeepSeek-OCR 输出的 Markdown 之后，可以按照#、##、表格行、代码块等结构来做切片，切片质量明显提升。

比如一页报告里面有标题、总结段落、表格、图表注释，Markdown 输出天然把这些层级分开了。

9.2 文本切片策略

使用 Markdown 结构化文本做切片时，可以按这样的优先级：

1. 以#和##标题作为一级边界。
2. 每个标题下的正文按段落或固定 token 数切片。
3. 表格单独保留为一个完整切片。
4. 切片之间保留一行分隔符，便于后续拼接上下文。

如果切出来的文本包含大量冗余内容，比如页眉页脚、水印文字，要用规则过滤掉。这个步骤放在 OCR 输出之后、向量化之前。

9.3 向量化与检索

文本切片生成后，用 Embedding 模型转成向量存入向量库。用户提问时，先做语义检索，拿到相关片段，再交给大模型生成回答。这里有一个关键点：OCR 输出质量直接决定 Embedding 质量，一旦 OCR 把关键数字或者表格结构识别错了，后面的检索和生成都会受污染。

所以在 RAG 场景里，建议定期抽样检查 OCR 输出，特别是数字、日期、金额等高风险字段。

9.4 混合检索增强

如果 RAG 场景里既有 PDF 又有图片，可以考虑混合检索：先对图片走 OCR，提取文字字段，再走文本检索；同时可以保留图片 embedding。两者结合可以提升多模态文档的检索效果。

10. 资源占用与性能优化

本地部署 OCR 模型，性能观测是重要一环。下面介绍几个重点监控指标和优化方向。

10.1 显存占用观察

GPU 环境下，用nvidia-smi实时观察显存：

nvidia-smi -l 1

也可以写脚本读取 GPU 状态：

import subprocess result = subprocess.run(["nvidia-smi", "--query-gpu=memory.used,memory.total", "--format=csv"], capture_output=True, text=True) print(result.stdout)

观察重点：模型加载后的基础显存、单张图片推理时的峰值显存、批量请求并发时的显存增长。

10.2 CPU 与 GPU 的差异

CPU 推理在低分辨率任务上还可以接受，但处理高分辨率 Documents 时速度明显下降。如果你要批量处理几百页 PDF，还是建议用 GPU。没有 N 卡的话，可以试试项目是否支持 ONNX Runtime 或 OpenVINO 等加速方案。

10.3 降低显存占用的方法

• 将图片长边压到 1000 到 2000 像素以内。
• 使用半精度加载模型，fp16=True。
• 使用量化版本权重。
• 控制并发请求数量，避免同时塞过多图片。
• 用batch_size=1串行处理，牺牲速度换稳定性。
• 批量任务中间加torch.cuda.empty_cache()释放缓存。

10.4 避免端口冲突和进程残留

API 服务如果崩溃退出，端口可能被残留进程占用。排查方式：

lsof -i :8000 kill -9 <PID>

多次启动失败时，先清理旧进程再启动。

11. 常见问题与排查方法

12. 最佳实践与合规建议

基于 DeepSeek-OCR 的实际部署经验，下面几条建议可以直接用在实际项目中。

第一，第一次部署用最小配置跑通全链路。不要一上来就适配大模型、高分辨率、大批量，先用一张小图验证模型能加载、推理、输出结果，再逐步加大压力。

第二，分清模型服务和处理逻辑。OCR 服务只负责“图片/PDF 到文本”，不要在里面混入业务逻辑。切片、向量化、检索由上层 RAG 系统负责，各自独立部署，方便替换和升级。

第三，批量任务必须加日志。记录每个文件的输入路径、处理结果、耗时、失败原因，否则出了错误根本没法定位。日志文件和输出 Markdown 分开存放。

第四，模型文件、输入素材、输出结果分目录管理。建议目录结构：

project/ ├── models/ │ └── deepseek-ocr/ ├── input/ │ ├── images/ │ └── pdf/ ├── output/ │ ├── markdown/ │ └── logs/ └── scripts/

第五，接口服务要控制访问范围。如果只是在开发机本地调试，绑定127.0.0.1。如果部署在服务器供其他服务调用，加访问认证或放在内网环境，不要直接暴露到公网。

第六，涉及人脸、签名、身份证件、公司商业合同等敏感材料时，必须确认使用者的合法授权。OCR 输出的文本如果含有个人信息，存储和传输也要符合隐私保护要求。

第七，微调数据不要使用没有版权授权的数据。领域微调虽然可以提升识别效果，但训练数据来源必须合规。发布模型或公开部署前，要确认训练集和验证集的使用范围。

13. 总结与下一步

DeepSeek-OCR 最值得尝试的点在于把传统 OCR 的“纯文本输出”升级成了“结构化 Markdown 输出”，这一步让文档解析和 RAG 的衔接顺畅很多。最先应该验证的功能是表格和版面结构识别，因为这是普通 OCR 最容易翻车、也最能体现大模型类 OCR 价值的地方。最容易踩的坑是上来就直接跑高分辨率大图，导致显存溢出，建议把图片压缩到 2000 像素以内做冒烟测试。后续可以继续扩展的方向包括：把 API 服务加上认证和限流，用 RocketMQ、Redis 队列或 Celery 处理大批量文件，以及在垂直领域用 LoRA 做专项识别优化。部署完成之后，建议把最小可运行配置保存下来，包括依赖版本、模型路径、启动参数，这样新环境很快就能复制一遍。