企业官网建设流程全解析

这次我们来看 DeepSeek 多模态模型怎么测评。社区讨论热度一直不低，尤其是图表理解、文档 OCR、截图问答和复杂版面解析这几个方向。但多数教程只讲模型是什么，不讲怎么在自己环境里跑通并量化效果。这篇文章把测评流程拆开：先确认模型范围，再准备环境，然后部署服务、逐项做功能测试，最后用接口跑批量任务，附上排错清单。文章不会写死显存数字，因为模型档位、batch_size、图片分辨率、输出长度不同，显存占用差异很大；我会给出一套记录和判断方法，你用自己的机器跑一遍，就能得到属于自己环境的测评结果。

DeepSeek 多模态模型目前可以分成两个方向：通用图文理解方向，对应 DeepSeek-VL、DeepSeek-VL2 系列；文档文字识别方向，对应 DeepSeek-OCR 这类专注 OCR 和版面解析的模型。测评这类模型，核心不是看榜上跑分，而是看它在自己的真实任务里能不能稳定输出。比如票据识别是否错字、图表理解是否读懂坐标、截图问答是否给出可用答案、长文档 PDF 解析是否丢掉页脚页眉、多图对比是否混淆两图内容。这些才决定工具能不能接进业务流程。

以下内容基于公开资料整理。所有具体参数、接口路径、显存占用和依赖版本，以你实际下载的模型卡和运行环境为准。

1. DeepSeek 多模态模型核心能力速览

这张表只做选型参考。真正决定能不能用的是两步：第一步是官方仓库能否在当前环境正常加载，第二步是同一批测试图片在不同提示词下的输出是否稳定。下面按顺序展开。

2. DeepSeek 多模态模型适用场景与使用边界

先说适合谁。多模态模型的测评价值主要体现在内容生产和文档处理场景。做运营的人可以用它批量提取截图中的文字和表格；做数据分析的人可以拿它读图表、解释趋势；做开发的人可以把它封装成 API，接到工单审核、商品信息入库、拍照识别这类工具里。只要是“图片进、文字出”的任务，都值得拿 DeepSeek 多模态模型跑一轮对比。

具体能解决的问题包括：

• 截图、拍照图片转文字，清洗后进入文档库。
• PDF 页面转 Markdown，保留标题层级和表格结构。
• 图表类图片的问答，例如“这个折线图的最高点出现在哪个季度”。
• 商品图、附属文字的多模态信息抽取。
• 多张图片的差异对比，例如两张设计稿的共同点与差异点。
• OCR 预处理后的关键字段提取，例如票据号、日期、总金额。

也要说清楚不适合的场景。如果业务对延迟极度敏感，例如线上实时审核，本地多模态推理的稳定性还不一定能满足；如果任务要求的是复杂逻辑推理，多模态模型的边界也比较明显，不能拿它当纯推理引擎用；如果没有 GPU 环境，CPU 跑小模型可以验证流程，但大规模批量任务不现实。

使用边界必须明确。处理他人照片、人脸、声音、版权文档之前，要取得授权。含有个人隐私的票据、合同、身份证信息不能在公共接口里传输。模型输出的内容要人工复核，尤其是涉及金额、姓名、编号这类关键字段。搜索 DeepSeek 多模态时经常能看到 DeepSeek-Hermes、DeepSeek-Harness 等名字，前者一般是社区基于 DeepSeek 基座模型微调的版本，不是 DeepSeek 官方发布；后者是社区开发者做的部署与任务编排工具。这些项目可以关注，但下载前务必确认模型卡里的发布组织、基础模型和许可证。

3. DeepSeek 多模态模型本地部署环境准备

环境准备遵循“先确认硬件，再确认依赖，最后下载模型”的顺序。不要一上来就下载几十 GB 的权重文件，先把环境跑通，再下模型。

第一步是确认操作系统和 GPU 环境。Windows 和 Linux 都能做，但生产环境建议用 Linux 服务器。NVIDIA 显卡必须装好驱动，然后在终端里确认：

nvidia-smi

如果能正常输出显卡型号、驱动版本和显存容量，显卡驱动这一步就通过。如果提示命令不存在，说明没有安装 NVIDIA 驱动，或者驱动没有放进系统 PATH。CUDA 版本不一定需要手动安装，因为 PyTorch 和 vLLM 会带着自己的 CUDA 运行库，关键是显卡驱动版本要足够新。

第二步是准备 Python 环境。建议使用 Python 3.10 或 3.11，并创建独立的虚拟环境，避免依赖冲突。以 Linux 为例：

python3 -m venv deepseek_env source deepseek_env/bin/activate pip install --upgrade pip

第三步是安装深度学习依赖。这里给出通用安装命令，具体版本以模型仓库的 requirements.txt 为准：

pip install torch torchvision torchaudio transformers accelerate sentencepiece huggingface_hub

如果计划用 vLLM 启动 API 服务，再单独安装：

pip install vllm

注意：不同模型对 transformers 版本的要求可能不一样，安装后不要随意升级，否则容易出现trust_remote_code相关错误。

第四步是确认磁盘空间。模型文件通常从几个 GB 到几十 GB 不等，实际大小以 Hugging Face 模型页面的文件列表为准。批量测试时，还要预留输入图片目录和输出结果目录的空间。

第五步是确认端口。API 服务常用 8000 端口，可以先检查占用：

ss -lntp | grep 8000

如果有进程占用，要么停掉旧进程，要么启动时换一个端口，例如 8001 或 7860。

4. DeepSeek 多模态模型下载、部署与启动

4.1 下载模型权重

模型权重建议从 Hugging Face 官方仓库下载。以通用多模态模型为例，仓库 ID 需要去 DeepSeek 官方页面确认，因为模型名可能带版本后缀。下载命令模板如下：

pip install -U huggingface_hub huggingface-cli download deepseek-ai/DeepSeek-VL2 \ --local-dir ./models/DeepSeek-VL2

网络不稳定时，可以只下载推理必需的权重文件和配置文件。模型文件较大，中途断开的话，重新执行同一条命令即可续传。

4.2 transformers 脚本加载模型

DeepSeek-VL 系列这类模型通常需要官方仓库里的建模代码，不能只靠 transformers 的通用加载接口。稳妥的做法是克隆官方仓库，然后按官方 examples 跑推理脚本：

git clone https://github.com/deepseek-ai/DeepSeek-VL2 cd DeepSeek-VL2 pip install -e .

然后在项目目录下放置一张测试图片，比如demo.jpg，运行推理脚本。下面是通用命令模板，实际参数以官方仓库 README 为准：

python examples/inference.py \ --model_path deepseek-ai/DeepSeek-VL2 \ --image_path demo.jpg \ --prompt "请详细描述这张图片的内容"

如果官方只提供模型文件而没有可直接运行的脚本，可以写一段通用加载逻辑。但要注意，不同仓库的图片编码接口不一致，下面代码只做流程参考：

import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "./models/DeepSeek-VL2" tokenizer = AutoTokenizer.from_pretrained( model_path, trust_remote_code=True ) model = AutoModelForCausalLM.from_pretrained( model_path, trust_remote_code=True, torch_dtype=torch.bfloat16, device_map="auto" ) # 图片编码接口与提示词模板需参考官方仓库 examples 代码 # 这里不能直接照搬，否则会报图特征维度不匹配

第一个测试目标不是准确率，而是“模型能不能在本地跑起来”。只要模型加载完成、图片编码和生成都不报错，环境就基本通了。

4.3 vLLM 启动 OpenAI 兼容 API

如果部署工具的 vLLM 版本支持目标多模态模型，可以用 OpenAI 兼容接口启动服务，这样后续脚本接入成本最低。启动命令模板如下：

python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-VL2 \ --trust-remote-code \ --max-model-len 4096 \ --gpu-memory-utilization 0.8 \ --port 8000

如果 vLLM 对该模型支持不完整，会报模型架构无法识别之类的错误，这时候就退回 transformers 官方脚本方案。不用为了 API 形式强行装 vLLM，先把推理链路跑通更重要。

4.4 自建 FastAPI 服务

对批量任务来说，自建一个图片路径进、文字出的服务也够用。下面是一个 FastAPI 服务模板，模型推理函数需要替换成官方仓库的实际调用方式：

from fastapi import FastAPI from pydantic import BaseModel class GenerateRequest(BaseModel): image_path: str prompt: str = "请识别图片中的文字，并输出为 Markdown 格式" max_new_tokens: int = 512 app = FastAPI() @app.post("/generate") def generate(req: GenerateRequest): # 这里替换为实际模型推理函数 result = run_inference( image_path=req.image_path, prompt=req.prompt, max_new_tokens=req.max_new_tokens ) return {"result": result}

保存为api_server.py后启动：

uvicorn api_server:app --host 127.0.0.1 --port 8000

注意监听地址。如果只想本机调用，写127.0.0.1；如果需要局域网内用，再改成0.0.0.0，但不要把未加鉴权的服务直接暴露到公网。

5. DeepSeek 多模态模型功能测试与效果验证

功能测试不能只用一两张图，要做成一套固定评测集。建议准备至少 20 张测试图片，覆盖印刷体截图、手写体、表格、图表、多图组、扫描件、深色背景、低分辨率图片。每张图提前写好预期结果，例如“这张发票的发票号是 XXXX，总金额为 XXXX”。这样模型输出后可以对照，而不是凭感觉判断。

5.1 OCR 文字识别测试

测试目的：验证模型对图片中文字内容的提取能力，尤其是简繁体、数字、标点和排版顺序。

准备三张图片：一张清晰印刷体截图、一张白底文字截图、一张包含表格或票据的扫描件。推荐提示词：

请识别图片中的所有文字，按原版面顺序输出。如果是表格，请用 Markdown 表格表示。

判断标准：

1. 关键字段是否与预期完全一致。
2. 多行文字是否保持原顺序。
3. 表格的列数、行数是否与原图一致。
4. 是否有重复行或漏字。

常见失败原因是图片分辨率太低，小字号文字挤在一起，模型识别不出边界。可以先放大图片再重新测试。

5.2 图表理解测试

测试目的：验证模型能否读取坐标轴、数值趋势和数据点之间的关系。

输入一张折线图，推荐提示词：

这张图的横轴和纵轴分别代表什么？数据在哪些区间出现明显变化？最高点对应的坐标是什么？

判断标准：模型是否同时给出了横纵轴含义和具体数值。如果输出只是“这是一张折线图，显示趋势变化”这类套话，视为不稳定。图表类任务还要多做两次重复测试，因为同一张图在不同解码参数下可能输出不同结论。

5.3 文档解析测试

测试目的：验证模型对复杂版面的解析能力，包括标题层级、列表、表格、页脚页眉。

输入一页 PDF 的截图，推荐提示词：

请将该页内容转换为 Markdown，保留标题层级、列表和表格结构。不要遗漏页脚、页码和注释。

判断标准：

1. 一级标题和二级标题是否用正确的 Markdown 符号。
2. 表格是否变成可复制的行列结构。
3. 页脚页码是否被保留。
4. 是否有把正文和注释混在一起的情况。

如果目标是批量转 Markdown，这一项测试结果最值得记录。

5.4 多图对比测试

测试目的：验证模型在多图输入时是否会把两张图的内容混淆。

输入左右两张相似但有小差异的图片。推荐提示词：

请对比这两张图片。先分别描述图 A 和图 B 的内容，再列出共同点和差异点。

判断标准：图 A 的描述不能混入图 B 的元素。常见问题有两种：一种是模型只分析了第一张图；另一种是两张图的特征交叉串位。这个测试直接决定模型能不能用在设计稿审查、商品对比这类场景。

5.5 批量任务测试

批量测试之前先把单图链路跑通。建立两个目录：

batch_images/ # 输入图片目录 outputs/ # 输出结果目录

然后写 Python 脚本循环处理，下面是通用模板：

import os import requests image_dir = "./batch_images" output_dir = "./outputs" os.makedirs(output_dir, exist_ok=True) for idx, name in enumerate(sorted(os.listdir(image_dir))): image_path = os.path.join(image_dir, name) payload = { "image_path": image_path, "prompt": "识别图片中的文字，输出为 Markdown 格式", "max_new_tokens": 1024 } try: response = requests.post( "http://127.0.0.1:8000/generate", json=payload, timeout=180 ) response.raise_for_status() result = response.json() output_name = os.path.splitext(name)[0] + ".md" with open(os.path.join(output_dir, output_name), "w", encoding="utf-8") as f: f.write(result["result"]) print(f"done: {name}") except Exception as e: print(f"failed: {name}, error: {e}")

批量任务不要只打印成功失败，还要把失败原因写进日志文件，后续才能定位是图片问题、显存问题还是服务超时。

6. DeepSeek 多模态模型接口 API 调用与批量任务

接口 API 的价值在于接入现有系统。如果用 vLLM 启动了 OpenAI 兼容接口，可以直接用 OpenAI Python SDK 调用：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY" ) response = client.chat.completions.create( model="deepseek-ai/DeepSeek-VL2", messages=[ { "role": "user", "content": [ { "type": "image_url", "image_url": {"url": "file:///data/test.png"} }, { "type": "text", "text": "请识别图片中的文字" } ] } ] ) print(response.choices[0].message.content)

如果用自建 FastAPI 服务，调用方式更简单。下面是一个 curl 示例：

curl -X POST http://127.0.0.1:8000/generate \ -H "Content-Type: application/json" \ -d '{ "image_path": "/data/test.png", "prompt": "识别图片文字，输出 Markdown", "max_new_tokens": 1024 }'

从工程角度看，批量任务不能简单理解为“循环调用”。稳定的批量任务至少需要三部分：任务清单、失败重试、结果核对。

任务清单用文件名作为唯一标识，结果输出到独立目录。每条任务在数据库中或日志文件中保留状态：

失败重试建议最多两次。重试前把报错信息原样保存，不要覆盖。如果同一张图连续失败两次，就把图片路径写入failed_list.txt，跳过继续处理下一张，避免整个队列被阻塞。

7. DeepSeek 多模态模型资源占用与性能观察方法

资源占用测评不能只盯着模型参数量。多模态推理的显存峰值同时取决于图片分辨率、图片 token 数、batch_size、max_new_tokens 和是否量化。要得到可靠的显存占用结论，必须固定测试条件。

先用命令实时查看显卡状态：

nvidia-smi -l 2

如果只想记录显存和利用率，可以用 dmon 模式：

nvidia-smi dmon -s mu -d 2

测试时建议固定以下参数：

• batch_size = 1
• 使用同一张测试图片
• 使用同一段提示词
• 固定 max_new_tokens 为 512
• 同一张图连续跑 5 次，取中位数

然后分别改变图片分辨率、max_new_tokens、batch_size，记录每一组配置下的显存峰值和单张图片耗时。这样得到的数据才有可比性。

影响显存占用的主要因素有四个：

1. 图片编码产生的视觉 token 数量。图片越大，token 越多，显存占用越高。
2. 输出长度。max_new_tokens 越大，推理阶段缓存越多，显存峰值越高。
3. batch_size。批量越大，峰值显存近似线性增长。
4. 是否启用量化。FP16 转 8bit 后显存占用明显下降，但推理速度可能受到影响。

降低显存占用的通用办法：

1. 使用 8bit 量化加载模型。 2. 降低输入图片分辨率，但需注意小字识别效果。 3. 限制 max_new_tokens，避免模型输出过长。 4. 调低 gpu-memory-utilization 参数。 5. 关闭不用的进程，清理其他显存占用。

CPU 推理不是完全不可行。小规模模型可以在 CPU 上做功能验证，但速度会明显慢于 GPU。测评报告里要分别记录 CPU 和 GPU 的耗时，方便判断是否值得上 GPU。

有一点要特别说明：显存占用千万不要照搬别人的截图，因为模型版本、依赖版本、图片尺寸都不同。正确做法是把自己环境的 nvidia-smi 截图和参数表一起保存，这份数据才有价值。

8. DeepSeek 多模态模型常见问题与排查方法

排查的第一原则是看日志。启动服务时不要直接uvicorn api_server:app完事，后面加上日志输出：

uvicorn api_server:app --host 127.0.0.1 --port 8000 --log-level info

出现问题时，先看日志定位是模型加载阶段、图片处理阶段还是解码阶段出了问题，再针对性解决。

9. DeepSeek 多模态模型最佳实践与使用建议

第一次测试时先开小参数，不要一上来就处理高清扫描件或超长 PDF。跑通一个最小用例后，再逐渐增加图片复杂度和输出长度。这样做的好处是，出问题能快速定位是模型问题还是环境问题。

工程上建议保留一套最小可运行配置。把模型路径、依赖版本、提示词模板和启动命令写进同一个 README 文件，以后换电脑或换环境可以快速恢复。

一套基础配置文件长这样：

{ "model_path": "./models/DeepSeek-VL2", "repo_id": "deepseek-ai/DeepSeek-VL2", "device": "cuda", "max_new_tokens": 512, "temperature": 0.1, "top_p": 0.9, "input_dir": "./batch_images", "output_dir": "./outputs", "port": 8000 }

输入素材、模型文件、输出结果要分目录管理，不要混在一起。批量任务必须加日志和失败重试。接口服务限制访问范围，监听 127.0.0.1 比 0.0.0.0 安全得多。

涉及人脸、隐私、版权材料时必须先确认授权。票据、身份证、合同这类敏感图片不要提交到公共 API 服务，也不要在未经授权的情况下做批量解析。模型生成的 OCR 结果和图表结论只能作为辅助结果，正式发布或商用前要做人工复核。

关于社区项目，要注意识别来源。DeepSeek-Harness 这类社区工具能加快任务编排，但部署前要检查它的启动脚本、模型路径和依赖版本，避免因为它封装的代码和当前模型仓库不一致而排查半天。总之，先跑通官方推理，再考虑社区封装。

10. 总结与下一步

多模态模型的测评重点不是“哪张图好看”，而是“关键字段准不准、批量任务稳不稳、显存能不能扛住”。建议第一批测试优先验证两件事：OCR 小字识别和图表理解。这两个场景最能暴露模型在实际业务流程里的可靠性。

最容易踩的坑也先提前说：一是模型仓库和依赖版本不匹配，导致图片编码接口报错；二是图片分辨率不足导致小字识别失败，被误判为模型能力不行；三是批量任务没有日志和超时机制，一张坏图卡死整个队列。这些在前面几章已经给了解法，部署前可以对照过一遍。

如果模型基础能力达标，后续可以扩展的方向不少：把 DeepSeek 多模态模型接进 RAG 管道，做图片搜索和文档问答；批量把票据和报告转成 Markdown 后进入结构化存储；或者封装成一个内部工具，让运营和产品直接在网页端上传图片、获取文字结果。以当前模型的迭代速度，建议每隔一段时间重新跑一遍本文的测试集，用固定评测集对比新旧版本，这样模型更新后能立刻量化出提升或回退。

这篇测评报告没有给死板的显存和耗时数据，原因很简单：不同显卡、不同模型档位、不同图片分辨率的结果差异太大。把测试方法带回去，跑出属于自己环境的数据，这份报告才算真正落地。