LlamaParse 的 OCR 服务与 worker 的配置及扩容建议。

概述

LlamaParse 的组成部分：

• OCR 服务：从文档图像里抽取文字
• LlamaParse worker：文档处理（fast、balanced、agentic 三种模式）

OCR 服务配置

OCR 服务跑在 GPU 或 CPU 基础设施上。

硬件建议

CPU 部署：使用 x86 架构（吞吐比 ARM 高 50%）。

资源需求

配置	GPU	CPU
最少实例数	2	12
每 pod 每分钟页数	100	~2 per worker
建议每 pod 的 worker 数	4	核数 ÷ 2

注意

以上针对的是高分辨率扫描文档批次的高峰容量。

扩容比例

CPU：每个 LlamaParse worker 配 2 个 CPU OCR worker（各 2 核） GPU：每 8 个 LlamaParse worker 配 1 个 GPU OCR worker

LlamaParse worker 配置

worker 以三种模式处理文档：

各模式的性能

模式	每分钟页数	适用场景
Fast	~10,000	高并量的基础文本抽取
Balanced	~250	准确度不错的标准解析
Agentic	~100	需要 AI 分析的复杂文档

资源需求

计算：

• CPU：每个 worker 2 vCPU
• 内存：每个 worker 2-16 GB RAM

部署：

• 一个 Kubernetes 节点上跑多个 worker
• 生产环境每节点约 ~6 个 worker

扩容示例

目标吞吐	LlamaParse worker	CPU OCR pod	GPU OCR pod
1,000 页/分钟	8	16	2
10,000 页/分钟	64	128	12

生成式 AI 提供方

LlamaParse 用生成式 AI 提供方来做解析：

• parse_page_with_llm：LLM 解析（支持 gpt-4o-mini）
• parse_page_with_lvm：视觉模型解析（支持 gemini、openai、claude sonnet）
• parse_page_with_agent：智能体式解析（支持 claude、gemini、openai）

提供方回退：配置了多个提供方时，某一方不可用会自动回退。

受支持的提供方：

• Claude/Haiku：Anthropic（美区）、AWS Bedrock、Google VertexAI
• OpenAI：OpenAI（美区）、OpenAI EU（仅 parse_page_with_llm）、AzureAI
• Gemini：Google Vertex AI、Google GenAI

进阶配置

OCR worker 调优

终端窗口

OCR_WORKER=<value>  # Recommended: pod_core_count ÷ 2

OCR 并发控制

终端窗口

OCR_CONCURRENCY=8  # Default

• 调低：OCR pod 更少、处理更慢
• 调高：OCR pod 更多、处理更快

图像处理上限

终端窗口

MAX_EXTRACTED_IMAGES_PER_PAGES=30  # Default

任务队列并发

终端窗口

PDF_JOB_QUEUE_CONCURRENCY=1  # Default (recommended)

在不了解性能影响之前，不要改动 PDF_JOB_QUEUE_CONCURRENCY。

生成式 AI 吞吐调优

按模式限制吞吐，以匹配 TPM/RPM 配额：

终端窗口

ACCURATE_MODE_LLM_CONCURRENCY=250    # parse_page_with_llm (default)
MULTIMODAL_MODEL_CONCURRENCY=50      # parse_page_with_lvm (default)
PREMIUM_MODE_MODEL_CONCURRENCY=25    # parse_page_with_agent (default)

每 1k 页的 token 用量：

模式	请求数	输入 token	输出 token
parse_page_with_llm	1,010	1.2M	1.5M
parse_page_with_agent	2,000	4M	2M
parse_page_with_lvm	1,200	3M	1.5M

AWS Bedrock 这类提供方的默认配额偏低。请确认配额能容纳你想要的解析量。

自动扩缩

LlamaParse 支持基于 KEDA 的自动扩缩，可按队列深度自动调整 worker pod 数量，从而在不同负载下都保持合理的资源利用。

基于队列的扩缩

自动扩缩使用 LlamaCloud 的队列状态 API 来监视解析任务队列：

• 队列监视：/api/queue-statusz?queue_prefix=parse_raw_file_job
• 扩缩指标：所有健康队列的消息总数
• 目标队列深度：KEDA 力求维持的队列内消息总数（通常 20-100）

扩缩建议

环境	最少 pod	最多 pod	目标队列深度	特点
开发	3	12	20	扩得快，用于测试
预发	12	120	20	中等扩容，用于验证
生产	96	600	100	保守，高可用

与 OCR 服务的配合

扩 LlamaParse worker 时，要一并考虑 OCR 服务的容量：

• CPU OCR：每个 LlamaParse worker 配 2 个 OCR worker
• GPU OCR：每 8 个 LlamaParse worker 配 1 个 OCR worker

详细的自动扩缩配置见弹性伸缩配置指南。

监控与优化

关键指标

• OCR 吞吐：每分钟页数
• worker 利用率：CPU/内存使用
• 队列深度：待处理任务数
• 错误率：失败的操作
• 扩缩事件：自动扩缩的频率与有效性

优化

1. 节点摆放：把资源使用模式互补的负载放在同一节点
2. 水平扩容：先加 worker，再提高单个 worker 的资源
3. OCR 扩缩：让 OCR 服务独立伸缩
4. 内存管理：长期运行的部署要使用重启策略
5. 自动扩缩调优：盯住队列深度并调整扩缩参数