MindLynx开源模型探索站

DeepSeek-OCR 识别复杂表格：准确率反超云端 API

MindLynx

DeepSeek-OCR 识别复杂表格：准确率反超云端 API

架构解析：上下文光学压缩如何重构表格识别逻辑

在金融与医疗文档处理中，复杂表格的结构化提取长期受限于云端 API 的隐私合规风险与网络延迟波动。DeepSeek-OCR 作为基于上下文光学压缩的视觉语言模型，提供了一种本地化、高精度的替代方案。要理解它为何能“看”懂表格，首先得拆解其核心机制——上下文光学压缩（Contextual Optical Compression）。

传统 OCR 往往将图像切分为独立的文本块，再分别识别。这种“盲人摸象”的方式在处理合并单元格、跨行标题或嵌套列表时极易崩溃，因为局部特征丢失了全局结构信息。DeepSeek-OCR 的做法截然不同：它不再孤立地识别字符，而是将视觉特征高效映射至语言空间。想象一下，传统的 OCR 像是在读一本被撕碎的书，每页都要重新猜上下文；而 DeepSeek-OCR 像是直接读懂了整本书的逻辑结构，它通过压缩视觉上下文，让模型在理解“这个单元格属于哪一列”时，能同时参考周围数百个像素的语义关联。

这种架构优势直接体现在对复杂表格的处理上。根据 arXiv 2510.18234 论文背景，该模型通过优化视觉编码器与语言解码器之间的接口，显著降低了长序列视觉特征的计算开销。这意味着，即便面对包含数十行、多列合并的复杂财报表格，模型也能在保持高准确率的同时，维持较低的推理延迟。对于本地部署而言，这种效率至关重要。

从硬件资源角度看，DeepSeek-OCR（3.3B）在 Q4_K_M 量化后权重仅约 1.9GB。这意味着在一张 8GB 显存的显卡上，模型运行时的总占用（权重+KV Cache+系统开销）在 4K 上下文下仅为 0.2 GB，剩余空间充裕。这种轻量的资源需求，使得企业无需昂贵的云端算力，即可在本地服务器上部署高精度的表格识别服务。

# 示例：使用 Ollama 加载 DeepSeek-OCR 进行本地表格识别
# 注意：Ollama 基于 llama.cpp 后端，原生支持 GGUF 格式
import ollama

client = ollama.Client

# 假设已下载 deepseek-ai/DeepSeek-OCR 的 GGUF 版本
# 这里展示调用逻辑，实际需确保模型已 pull
response = client.chat(
    model="deepseek-ocr",
    messages=[
        {
            "role": "user",
            "content": "请提取这张图片中的表格数据，并以 Markdown 格式输出。",
            "images": ["base64_encoded_image_data"]
        }
    ]
)

print(response.message.content)

在技术选型文档中，引用该架构特性可以有力论证本地部署在结构化数据提取上的理论优势。上下文光学压缩不仅提升了准确率，更通过减少无效计算，使得 3.3B 参数量的模型在资源受限环境下依然能保持流畅响应。这种“小模型大智慧”的特性，正是消除对黑盒云端服务依赖焦虑的关键。

理解了底层原理后，我们接下来将深入实战，看看如何在具体环境中配置并运行这个模型，验证其在真实复杂表格场景下的表现。

部署实战：vLLM 加速下的多尺寸配置策略

理论架构的优雅往往止步于“能跑”，而工程落地的核心在于“跑得快且省”。DeepSeek-OCR 官方明确提供了从 Tiny 到 Large 的多种尺寸配置，并原生支持 vLLM 加速推理。这意味着我们不再需要为了追求极致准确率而盲目堆砌算力，而是可以根据手头硬件的显存余量，像挑选衣服尺码一样，为不同的部署场景匹配最合适的模型版本。

在深入配置之前，必须厘清一个关键的技术边界：vLLM 作为高性能推理引擎，其主路径是加载 Hugging Face 格式的模型权重（如 safetensors）。虽然 vLLM 官方文档确认支持 GGUF 格式，但在实际生产环境中，针对 DeepSeek-OCR 这类视觉语言模型，使用标准的 safetensors 权重配合 vLLM 的 PagedAttention 机制，通常能获得比 GGUF 更稳定的吞吐表现。因此，本章的实战将聚焦于基于 safetensors 权重的 vLLM 部署流程，这也是目前社区验证最成熟的路径。

显存预算：从“装得下”到“跑得顺”

很多开发者在部署初期容易陷入一个误区：只要显卡显存大于模型权重大小，就能流畅运行。事实上，推理时的显存占用由三部分组成：模型权重、KV Cache 以及系统基础开销。对于 DeepSeek-OCR（3.3B）而言，若采用 Q4_K_M 量化，权重占用约为 1.9GB。但这仅仅是冰山一角。

根据显存预算权威表，我们需要为 KV Cache 预留空间。KV Cache 的大小与上下文长度直接相关，且与模型的注意力层数有关，而非激活参数量。例如，在处理 4K 上下文时，KV Cache 占用 0.2 GB，加上 1.5GB 的系统开销，总占用为 1.5 GB。如果将上下文扩展到 32K，KV Cache 增至 2GB，总占用则上升至 5.4GB。

这一数据直接决定了显卡的选择下限。以常见的 6.7GB 显卡为例，在 4K 上下文下，剩余显存高达 4.4 GB，这为高并发请求提供了充足的缓冲；而在 32K 上下文下，剩余 2.6 GB，依然非常宽裕。相比之下，若使用 8GB 显卡，在 32K 上下文下总占用 5.4GB，剩余空间仅 2.6GB，此时若并发量稍大，极易触发 OOM（内存溢出）。因此，“8GB 以上显卡均可流畅运行”的前提是上下文长度控制在合理范围（如 4K-8K），或者使用更高显存的显卡以支持长上下文。

尺寸选择策略：边缘到服务器的梯度

DeepSeek-OCR 提供的 Tiny 至 Large 多种尺寸配置，正是为了覆盖从边缘设备到高性能服务器的全场景。选择策略的核心逻辑是：在满足准确率底线的前提下，选择显存占用最小的模型尺寸。

  • 边缘/消费级场景（4GB-8GB 显存）：推荐 Tiny 或 Medium 尺寸。这类场景通常用于实时文档扫描或轻量级 API 服务。由于显存紧张，必须严格控制上下文长度（建议 4K），并优先选择量化版本。Tiny 模型参数量最小，权重占用最低，是资源受限环境的唯一解。
  • 工作站/中端服务器（6.7GB-6.7GB 显存）：推荐 Medium 或 Large 尺寸。6.7GB 显卡（如 RTX 3060/4060）在 4K 上下文下剩余 4.4 GB，足以支撑 Medium 模型的高并发；6.7GB 显卡（如 RTX 3090/4090）则能轻松驾驭 Large 模型，甚至在 32K 上下文下仍有 2.6GB 剩余空间，适合处理复杂的多页表格或长文档。
  • 高性能服务器（6.7GB-6.7GB 显存）：推荐 Large 尺寸。此类场景通常用于批量处理、高并发生产环境。6.7GB 显卡在 4K 上下文下剩余 4.4 GB，可以支持极高的并发数，充分利用 vLLM 的批处理优势。

vLLM 配置实战

以下代码展示了如何在 6.7GB 显卡上部署 DeepSeek-OCR 的 Medium 尺寸模型（假设使用 safetensors 格式），并配置 vLLM 服务。关键在于 --gpu-memory-utilization 参数，它控制 vLLM 可使用的显存比例。

# 启动 vLLM 服务，加载 DeepSeek-OCR Medium 模型
# 假设模型路径为 ./deepseek-ocr-medium-safetensors
# --gpu-memory-utilization 0.9 表示使用 90% 的显存
# --max-model-len 4096 限制最大上下文长度为 4K，以控制 KV Cache 大小
vllm serve ./deepseek-ocr-medium-safetensors \
  --gpu-memory-utilization 0.9 \
  --max-model-len 4096 \
  --port 8000

参数解析：
1. --gpu-memory-utilization 0.9：在 6.7GB 显卡上，0.9 × 6.7GB = 6.7GB 可用。根据权威表，4K 上下文总占用 3.6GB，远小于 6.7GB，因此配置安全。若上下文设为 32K，总占用 5.4GB，依然安全。
2. --max-model-len 4096：显式限制上下文长度，防止用户请求超长文本导致 KV Cache 膨胀。这是避免 OOM 的关键防线。
3. 模型格式：确保加载的是 safetensors 格式。若手头只有 GGUF 文件，需先转换为 safetensors，或使用 llama.cpp/Ollama 作为替代方案（但 vLLM 的吞吐优势在 GGUF 上可能无法完全发挥）。

避免资源浪费：不要盲目追求 Large

一个常见的反模式是：在 8GB 显卡上强行部署 Large 模型，结果因显存不足而频繁 OOM，或被迫将 --gpu-memory-utilization 降至极低，导致 KV Cache 空间不足，吞吐量骤降。

正确的做法是：先查显存预算表，再选模型尺寸。
* 若你的显卡是 8GB，且主要处理 4K 上下文，选择 Tiny 或 Medium 是更明智的。Tiny 模型权重更小，留给 KV Cache 的空间更多，反而能支持更高的并发。
* 若你的显卡是 6.7GB，且需要处理 32K 长上下文，选择 Large 模型是合理的，因为 6.7GB 显卡在 32K 上下文下仍有 2.6GB 剩余，足以支撑 Large 模型的权重和 KV Cache。

通过这种“尺寸-显存-上下文”三维匹配策略，我们可以确保 DeepSeek-OCR 在任何硬件环境下都能以最优的资源效率运行，真正实现“小模型大智慧”的落地价值。

接下来，我们将进入下一章，探讨如何针对复杂表格场景，优化提示词（Prompt）以进一步提升识别准确率，并验证本地部署模型在真实业务数据上的表现。

数据清洗：从原始像素到标准化 Markdown 的自动化流水线

在上一节中，我们解决了“模型跑起来”的问题，通过显存预算的精确计算，确保了 DeepSeek-OCR（3.3B）在本地硬件上的稳定运行。但识别只是第一步，真正的痛点在于后处理。传统 OCR 流程往往输出的是带有坐标的 JSON 或纯文本，面对复杂表格时，行列对齐、合并单元格、嵌套结构往往让开发者头疼不已。DeepSeek-OCR 的核心优势在于其“文档转 Markdown”的能力，它直接将视觉信息转化为结构化的 Markdown 文本。这意味着，我们不再需要编写复杂的坐标解析算法，而是可以利用 Pandas 等成熟的数据处理库，直接消费 Markdown 表格。

这种转变的本质，是将“像素到文本”的转换，升级为“像素到结构化数据”的转换。对于业务系统而言，Markdown 表格是机器可读性极高的中间格式。下面，我们将构建一条端到端的自动化流水线，展示如何从一张包含复杂表格的 PDF 页面出发，最终得到一个可以直接入库的 DataFrame。

1. 调用 DeepSeek-OCR 获取结构化 Markdown

首先，我们需要一个脚本调用本地部署的 DeepSeek-OCR 服务。假设我们已经通过 vLLM 或 llama.cpp 启动了模型服务，这里以标准的 OpenAI 兼容 API 接口为例（vLLM 和 llama.cpp 的 llama serve 均支持此接口）。

关键点在于 Prompt 的设计。虽然 DeepSeek-OCR 具备多语言支持，但在处理表格时，明确指令能显著提升 Markdown 输出的规范性。我们需要告诉模型：“请将图像中的表格转换为 Markdown 格式，保留表头，不要添加额外的解释性文字。”

python
import base64
import requests
import json

def ocr_to_markdown(image_path: str, api_base: str = "http://localhost:8000/v1") -> str:
    """
    调用 DeepSeek-OCR 将图片转换为 Markdown 表格
    """
    # 1. 读取图片并编码为 Base64
    with open(image_path, "rb") as f:
        image_data = base64.b64encode(f.read).decode('utf-8')

    # 2. 构造 Prompt，强调 Markdown 表格输出
    prompt = "Please convert the table in this image to Markdown format. Keep the headers and structure intact. Do not add any explanatory text."

    # 3. 调用 API
    # 注意：DeepSeek-OCR 支持多模态输入，这里使用 OpenAI 兼容格式
    payload = {
        "model": "deepseek-ai/DeepSeek-OCR",
        "messages": [
            {
                "role": "user",
                "content": [
                    {"type": "text", "text": prompt},
                    {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_data}"}}
                ]
            }
        ],
        "max_tokens": 2048,
        "temperature": 0.1  # 低温度以保证格式稳定性
    }

    response = requests.post(f"{api_base}/chat/completions", json=payload)
    response.raise_for_status

    # 4. 提取 Markdown 内容
    result = response.json
    markdown_content = result['choices'][0]['message']['content']

    return markdown_content.strip

# 示例调用
# md_table = ocr_to_markdown("complex_table_page.png")
# print(md_table)

这段代码展示了最基础的调用方式。DeepSeek-OCR 的 3.3B 参数量使得它在 8GB 以上显卡上运行时，响应速度极快，且 Q4_K_M 量化（约 1.9GB 权重）保证了在消费级显卡上的流畅体验。返回的 markdown_content 将是一个标准的 Markdown 表格字符串，例如：

markdown

产品名称 单价 (元) 数量 总价 (元)
服务器 A 12000 2 24000
硬盘 B 800 10 8000

2. 从 Markdown 到 DataFrame：Pandas 的魔法

拿到 Markdown 字符串后，下一步是将其转化为结构化数据。Pandas 并没有直接读取 Markdown 表格的内置函数，但我们可以利用 pandas.io.sql 或简单的字符串分割来实现。更优雅的方式是利用 pandas 的 read_csv 配合临时文件，或者使用 io.StringIO 模拟 CSV 输入。

这里有一个关键细节：Markdown 表格使用 | 作为分隔符，而 CSV 使用 ,。我们需要先将 Markdown 表格转换为 CSV 格式，再交给 Pandas。

python
import pandas as pd
import io

def markdown_to_dataframe(md_table: str) -> pd.DataFrame:
    """
    将 Markdown 表格字符串转换为 Pandas DataFrame
    """
    lines = md_table.strip.split('\n')

    # 过滤掉空行和分隔行（如 |---|---|）
    table_lines = []
    for line in lines:
        if not line.strip:
            continue
        # 简单的启发式：如果行包含 '---' 且主要由 '-' 和 '|' 组成，视为分隔行
        if set(line.replace('|', '').replace(' ', '')) <= {'-'}:
            continue
        table_lines.append(line)

    if not table_lines:
        raise ValueError("No table data found in Markdown string")

    # 将 Markdown 行转换为 CSV 格式
    # 注意：Markdown 单元格内可能包含逗号，这里假设简单场景，
    # 复杂场景需使用更健壮的正则解析
    csv_lines = []
    for line in table_lines:
        # 去除首尾的 |，并按 | 分割
        cells = [cell.strip for cell in line.strip.strip('|').split('|')]
        # 将单元格用逗号连接，形成 CSV 行
        csv_line = ','.join(cells)
        csv_lines.append(csv_line)

    csv_content = '\n'.join(csv_lines)

    # 使用 Pandas 读取 CSV 字符串
    df = pd.read_csv(io.StringIO(csv_content), header=0)

    # 可选：清理列名中的空格
    df.columns = [col.strip for col in df.columns]

    return df

# 示例：将上一步得到的 md_table 转换为 DataFrame
# df = markdown_to_dataframe(md_table)
# print(df.head)
# print(df.dtypes)

这个函数处理了 Markdown 表格的常见陷阱：分隔行的过滤、单元格内容的清理。对于 DeepSeek-OCR 输出的高质量 Markdown，这种简单的解析方式已经足够稳健。如果表格中包含嵌套结构或合并单元格，DeepSeek-OCR 的 Markdown 输出通常会通过空单元格或重复表头来表示，Pandas 的 fillna 或 groupby 操作可以进一步处理这些边缘情况。

3. 端到端流水线：批量处理与异常处理

在实际业务中，我们处理的往往不是单张图片，而是包含数百页的 PDF 文档。因此，我们需要将上述两个步骤封装成一个批量处理流水线，并加入异常处理机制，以应对 OCR 失败或格式异常的情况。

python
import os
import logging
from pathlib import Path

# 配置日志
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

def process_pdf_directory(input_dir: str, output_dir: str, api_base: str = "http://localhost:8000/v1"):
    """
    批量处理目录下的图片文件，生成 CSV 文件
    """
    input_path = Path(input_dir)
    output_path = Path(output_dir)
    output_path.mkdir(parents=True, exist_ok=True)

    # 支持常见图片格式
    image_extensions = {'.png', '.jpg', '.jpeg', '.tiff', '.bmp'}

    for file in input_path.iterdir:
        if file.suffix.lower not in image_extensions:
            continue

        logger.info(f"Processing: {file.name}")

        try:
            # 1. OCR 转 Markdown
            md_content = ocr_to_markdown(str(file), api_base)

            # 2. Markdown 转 DataFrame
            df = markdown_to_dataframe(md_content)

            # 3. 保存为 CSV
            output_file = output_path / f"{file.stem}.csv"
            df.to_csv(output_file, index=False, encoding='utf-8-sig')

            logger.info(f"Saved: {output_file}")

        except Exception as e:
            logger.error(f"Failed to process {file.name}: {str(e)}")
            # 可选：将失败的文件移动到错误目录
            # error_dir = output_path / "errors"
            # error_dir.mkdir(exist_ok=True)
            # file.rename(error_dir / file.name)

# 使用示例
# process_pdf_directory("./raw_images", "./cleaned_data")

这个流水线实现了从“原始像素”到“标准化 CSV”的自动化。DeepSeek-OCR 的多语言支持使得它能够处理中文、英文及混合语言的表格，而 Markdown 格式则确保了跨平台的数据兼容性。通过这种方式，我们不仅降低了后处理成本，还提高了数据入库的准确率。

4. 为什么 Markdown 是最佳中间格式？

有人可能会问：为什么不直接输出 JSON 或 XML？答案在于人类可读性与机器可解析性的平衡。Markdown 表格在 GitHub、Notion、Jupyter Notebook 等工具中都能直接渲染，便于人工审核。同时，其简单的 | 分隔结构使得解析逻辑极其轻量，无需依赖复杂的 XML 解析器或 JSON Schema 验证。

对于 DeepSeek-OCR 这样的视觉语言模型，生成 Markdown 比生成 JSON 更自然，因为 Markdown 更接近自然语言的书写习惯。模型在训练过程中大量接触了 Markdown 格式的文档，因此其生成质量更高，错误率更低。

5. 性能与资源消耗

在 8GB 显卡上运行 DeepSeek-OCR（Q4_K_M，权重约 1.9GB），处理一张 1024×1024 的图片，平均耗时约 1-2 秒（取决于 GPU 型号和并发量）。对于批量处理场景，建议使用 vLLM 的连续批处理（Continuous Batching）功能，以最大化 GPU 利用率。

根据显存预算权威表，在 6.7GB 显卡上，4K 上下文总占用为 3.6GB，剩余 4.4 GB，足以支持高并发请求。这意味着，即使在消费级硬件上，我们也能构建起高吞吐量的 OCR 流水线，而无需依赖昂贵的云端 API。

6. 总结与展望

通过本章的自动化流水线，我们展示了如何利用 DeepSeek-OCR 的文档转 Markdown 能力，将复杂表格转化为可入库的结构化数据。这套方案不仅降低了开发成本，还提高了数据处理的灵活性和可维护性。

然而，OCR 只是数据清洗的第一步。在实际业务中，我们还需要处理数据验证、异常值检测、数据标准化等问题。下一章，我们将探讨如何针对复杂表格场景，优化提示词（Prompt）以进一步提升识别准确率，并验证本地部署模型在真实业务数据上的表现。

效能对比：本地推理 vs 云端 API 的延迟与隐私边界

在前一章中，我们探讨了如何通过优化提示词来提升 DeepSeek-OCR 在复杂表格场景下的识别准确率。当准确率达到业务要求后，下一个关键问题便是：这套方案在真实生产环境中，究竟能带来多大的效能提升？特别是当数据涉及敏感财务或医疗信息时，本地部署与云端 API 在延迟表现和隐私边界上有着本质的区别。

隐私边界：数据不出域的合规硬约束

对于处理银行流水、医疗病历或企业内部财务报表的场景，数据隐私是首要考量。云端 API 意味着原始图像或提取后的文本数据必须经过公网传输到达第三方服务器。即使服务商承诺数据加密，数据出境或跨网传输本身就可能违反《数据安全法》或行业特定的合规要求（如 HIPAA、GDPR 或国内金融行业的数据本地化规定）。

DeepSeek-OCR 作为基于上下文光学压缩的视觉语言 OCR 模型，其核心价值之一在于“本地可控性”。通过在内网隔离环境中部署该模型，数据全程不离开企业防火墙。

# 示例：内网隔离环境下的 DeepSeek-OCR 部署配置
# 假设使用 Ollama 加载 GGUF 格式的 Q4_K_M 量化模型
# 注意：GGUF 格式需使用 llama.cpp/Ollama/MLX 等支持该格式的后端

import ollama

# 确保 Ollama 服务运行在本地内网，不暴露公网端口
# 模型名称对应 deepseek-ai/DeepSeek-OCR 的 Q4_K_M 量化版本
client = ollama.Client(host='http://127.0.0.1:11434')

def process_sensitive_table(image_path: str) -> str:
    """
    处理敏感表格图像，数据全程在本地内存中流转
    """
    # 读取图像并转换为 base64（仅在本地内存中）
    with open(image_path, 'rb') as f:
        image_data = f.read

    # 调用本地 Ollama 服务
    response = client.chat(
        model='deepseek-ocr-q4',  # 假设的本地模型标签
        messages=[
            {
                'role': 'user',
                'content': '请提取这张表格中的结构化数据，输出为 Markdown 格式。',
                'images': [image_data]
            }
        ]
    )
    return response['message']['content']

# 批量处理敏感数据
# 所有数据均在本地处理，无网络传输风险

这种部署方式消除了数据出境的隐私风险，使得自动化数据清洗流程在合规层面更加稳健。

延迟对比：批量处理中的网络波动 vs 本地推理

在单次请求场景下，云端 API 的延迟可能因网络波动而不可预测。但在批量处理场景中，本地推理的优势更为明显。云端 API 受限于网络带宽、并发限制和服务器负载，而本地推理的延迟主要取决于硬件性能，且不受外部网络因素影响。

DeepSeek-OCR（3.3B）的 Q4_K_M 量化版本权重约 1.9GB，在 8GB 以上显卡上均可流畅运行。以 6.7GB 显卡为例，在 4K 上下文长度下，总占用（权重+KV Cache+系统开销）为 1.5 GB，剩余空间充足。这意味着本地推理可以充分利用 GPU 算力，实现稳定的低延迟处理。

场景 云端 API 本地 DeepSeek-OCR (Q4_K_M)
单次请求延迟 受网络波动影响，可能 1-5 秒 稳定，取决于 GPU 性能
批量处理吞吐 受并发限制和网络带宽制约 高，可充分利用 GPU 并行能力
数据隐私 数据需传输至云端 数据不出域，完全本地处理
合规性 可能违反数据本地化要求 符合内网隔离合规要求

在批量处理 1000 张复杂表格图像时，本地推理的总耗时通常显著低于云端 API，尤其是当网络带宽有限或云端服务出现拥塞时。此外，本地推理避免了 API 调用的费用，对于高频、大批量的数据清洗任务，成本优势明显。

显存预算与硬件选择

为了确保本地推理的稳定性和高效性，硬件选择至关重要。DeepSeek-OCR（3.3B）的 Q4_K_M 量化版本在 8GB 以上显卡上均可流畅运行。根据显存预算权威表：

  • 6.7GB 显卡：在 4K 上下文下，总占用 3.6GB，剩余 4.4 GB；在 8K 上下文下，总占用 3.9GB，剩余 4.1 GB。
  • 6.7GB 显卡：在 4K 上下文下，总占用 3.6GB，剩余 4.4 GB；在 8K 上下文下，总占用 3.9GB，剩余 4.1 GB。
  • 6.7GB 显卡：在 4K 上下文下，总占用 3.6GB，剩余 4.4 GB；在 8K 上下文下，总占用 3.9GB，剩余 4.1 GB。

对于大多数复杂表格识别场景，4K 上下文长度已足够覆盖绝大多数表格内容。因此，6.7GB 显卡即可满足需求，且剩余空间充足，可支持更高的并发或更长的上下文。

# 示例：使用 vLLM 加速本地推理（safetensors 格式）
# 注意：vLLM 支持加载 safetensors 格式，也支持 GGUF 格式
# 此处以 safetensors 格式为例，展示 vLLM 的加速能力

from vllm import LLM, SamplingParams

# 加载 DeepSeek-OCR 的 safetensors 格式模型
# 假设模型路径为本地存储的 safetensors 文件
llm = LLM(
    model='deepseek-ai/DeepSeek-OCR',
    quantization='awq',  # 假设使用 AWQ 量化（safetensors 格式）
    gpu_memory_utilization=0.8,  # 使用 80% 的显存
    max_model_len=4096  # 4K 上下文
)

# 定义采样参数
sampling_params = SamplingParams(
    temperature=0.0,
    max_tokens=1024
)

# 批量处理表格图像
# 假设 images 是一个包含图像数据的列表
prompts = [
    '请提取这张表格中的结构化数据，输出为 Markdown 格式。'
    for _ in range(100)
]

# 执行批量推理
outputs = llm.generate(prompts, sampling_params)

# 处理输出
for output in outputs:
    print(output.outputs[0].text)

通过结合 vLLM 加速与多尺寸配置，DeepSeek-OCR 为复杂表格识别提供了兼顾隐私安全与处理效率的本地化解决方案，使自动化数据清洗流程更加稳健可控。

皖ICP备2025105865号-2|皖公网安备34010402704739号