并发与最大页数配置

概述

本文说明并发设置如何影响 LlamaParse 能处理的最大页数，以及如何为不同 AI 模型配置这些设置。

工作原理

可处理最大页数的算法

系统依据两个因素决定最多能处理多少页：

解析模式默认值：不同解析模式有不同的默认上限
模型专有并发：某些模型的 API 速率限制更高，因而能处理更多页

最终的 maxProcessablePages 按下式计算：

maxProcessablePages = max(defaultForParseMode, modelConcurrency * 12)

其中 12 这个乘数，代表在一个任务的时间窗口内、每一个并发请求估计能处理多少页。

各解析模式的默认最大页数

解析模式	默认最大页数	说明
`PARSE_PAGE_WITHOUT_LLM`	10,000	不用 LLM 的快速模式
`PARSE_PAGE_WITH_AGENT`	700	基于智能体的逐页解析
`PARSE_DOCUMENT_WITH_AGENT`	700	基于智能体的整篇解析
`PARSE_PAGE_WITH_LVM`	700	大视觉模型解析
`PARSE_DOCUMENT_WITH_LLM`	700	基于 LLM 的整篇解析 / 持续模式
`PARSE_PAGE_WITH_LLM`	5,000	逐页的 LLM 解析

模型级的并发覆盖

若某模型定义了并发值、按其算出的页数高于默认上限，该上限会被自动抬高。最大页数即 concurrency * 12。

示例：

解析模式：PARSE_PAGE_WITH_AGENT（默认 700 页）
模型：gemini-2.5-flash（并发 250）
算出的上限：250 * 12 = 3,000 pages
最终上限：3,000 页（取较高者）

如何修改并发设置

方案一：按模型配置（生产环境推荐）

对于用 Helm 的自托管部署，可以在 values.yaml 里配置模型级并发。这是生产环境的推荐做法，因为不需要改代码。

在 Helm 里配置模型并发

编辑你的 Helm values 文件（或用 override 传入）：

config:
  parse:
    concurrency:
      # Google Gemini Models
      gemini25Flash: 250      # Gemini 2.5 Flash
      gemini25Pro: 100        # Gemini 2.5 Pro
      gemini20Flash: 250      # Gemini 2.0 Flash
      gemini20FlashLite: 250  # Gemini 2.0 Flash Lite
      gemini15Flash: ""       # Leave empty to use hardcoded defaults
      gemini15Pro: ""

      # OpenAI Models
      openaiGpt4oMini: 250    # GPT-4o Mini
      openaiGpt4o: ""         # GPT-4o
      openaiGpt41: ""         # GPT-4.1
      openaiGpt41Mini: 250    # GPT-4.1 Mini
      openaiGpt41Nano: 250    # GPT-4.1 Nano
      openaiGpt5: ""          # GPT-5
      openaiGpt5Mini: ""      # GPT-5 Mini
      openaiGpt5Nano: ""      # GPT-5 Nano
      openaiWhisper1: ""      # Whisper-1

      # Anthropic Claude Models
      anthropicSonnet35: ""   # Claude Sonnet 3.5
      anthropicSonnet45: ""   # Claude Sonnet 4.5
      anthropicHaiku45: ""    # Claude Haiku 4.5

重要说明：

一旦设置，这些值会覆盖该模型的所有地域与主机级并发设置
留空（""）则使用代码里写死的默认值
这些设置同时作用于 llamaParse 与 temporalParse.llamaParse 两段
值会以环境变量传入：GEMINI_2_5_FLASH_CONCURRENCY、OPENAI_GPT_4O_MINI_CONCURRENCY 等

部署更新后的配置

终端窗口

# Update your Helm deployment
helm upgrade llamacloud ./charts/llamacloud \
  --namespace llamacloud \
  --values your-custom-values.yaml

方案二：按解析模式修改默认并发

除模型级并发之外，LlamaParse 还有若干控制处理各环节的并发设置。它们现在除环境变量外也都能通过 Helm 配置。

各解析模式的并发设置

这些控制不同解析模式的整体并发：

变量	默认值	说明	Helm 路径
`ACCURATE_MODE_LLM_CONCURRENCY`	250	accurate 模式的 LLM 处理并发 (parse_page_with_llm)	`config.parse.concurrency.accurateModeLLMConcurrency`
`MULTIMODAL_MODEL_CONCURRENCY`	50	多模态模型的并发 (parse_page_with_lvm)	`config.parse.concurrency.multimodalModelConcurrency`
`PREMIUM_MODE_MODEL_CONCURRENCY`	25	premium 模式处理的并发 (parse_page_with_agent)	`config.parse.concurrency.premiumModeModelConcurrency`

Helm 配置示例：

config:
  parse:
    # Parse mode concurrency settings
    accurateModeLLMConcurrency: 300    # Increase from default 250
    multimodalModelConcurrency: 75     # Increase from default 50
    premiumModeModelConcurrency: 40    # Increase from default 25

算清影响

设定并发值时，考虑三点：

API 速率限制：查提供方文档里的 TPM（每分钟 token 数）与 RPM（每分钟请求数）
目标最大页数：用期望的最大页数除以 12
- 例如：想要 6,000 页上限？把并发设为 500（6000 ÷ 12）
保守取值：把并发设在理论上限之下，以免触发限流

最佳实践

1. 从保守起步

先用较低的并发值，再根据监控逐步上调：

监视 API 限流错误
跟踪任务成功率
观察处理耗时

2. 与提供方上限对齐

让并发与提供方文档里的限制相匹配：

RPM（每分钟请求数）：并发不应超过 RPM
TPM（每分钟 token 数）：要考虑每次请求的平均 token 数
留出余量：给突发流量留 10-20% 的余量

3. 充分测试

改动并发之后：

用各种大小的文档测试
在日志里监视限流错误
核对任务完成率
检查处理耗时

4. 注意地域差异

不同地域的 API 配额可能不同：

EU 地域的限制通常更严
自定义 API key 的配额可能不同
BYOC 部署可以有更高的上限

处理流水线的并发

这些控制具体的处理阶段：

变量	默认值	说明	Helm 路径
`OCR_CONCURRENCY`	8	OCR 处理的并发	`config.parse.concurrency.ocrConcurrency`
`LAYOUT_EXTRACTION_CONCURRENCY`	10	版面检测的并发	`config.parse.concurrency.layoutExtractionConcurrency`
`LAYOUT_EXTRACTION_V2_CONCURRENCY`	10	版面检测 v2 的并发	`config.parse.concurrency.layoutExtractionV2Concurrency`
`LAYOUT_MODE_BLOCK_PARSE_CONCURRENCY`	5	版面模式下的块解析	`config.parse.concurrency.layoutModeBlockParseConcurrency`
`LAYOUT_MODE_PAGE_CONCURRENCY`	15	页级的版面处理	`config.parse.concurrency.layoutModePageConcurrency`
`LAYOUT_MODE_READING_ORDER_DETECTION_CONCURRENCY`	1	阅读顺序检测	`config.parse.concurrency.layoutModeReadingOrderDetectionConcurrency`

Helm 配置示例：

config:
  parse:
    # Pipeline concurrency settings
    ocrConcurrency: 12                                    # Increase from default 8
    layoutExtractionConcurrency: 15                       # Increase from default 10
    layoutModePageConcurrency: 20                         # Increase from default 15
    layoutModeReadingOrderDetectionConcurrency: 2         # Increase from default 1

队列并发

变量	默认值	说明	Helm 路径
`PDF_JOB_QUEUE_CONCURRENCY`	1	同时处理的任务数量	`config.parse.maxQueueConcurrency`

Helm 配置示例：

config:
  parse:
    maxQueueConcurrency: 3  # Process 3 jobs at once

它们如何互相作用

这几类并发是协同工作的：

队列并发（maxQueueConcurrency）：控制有多少任务并行运行
模式并发（如 ACCURATE_MODE_LLM_CONCURRENCY）：控制一个任务内有多少操作并发
模型并发（按模型）：控制具体模型的 API 调用数
流水线并发（OCR、版面等）：控制具体处理阶段

扩容策略示例：

# High-throughput configuration
config:
  parse:
    # Queue concurrency - how many jobs to process simultaneously
    maxQueueConcurrency: 5
    concurrency:
      # Parse mode concurrency - operations within each job
      accurateModeLLMConcurrency: 300
      multimodalModelConcurrency: 75
      premiumModeModelConcurrency: 40

      # Pipeline concurrency - specific processing stages
      ocrConcurrency: 12
      layoutExtractionConcurrency: 15
      layoutModePageConcurrency: 20

      # Model-specific concurrency - API call limits per model
      gemini25Flash: 300        # High API concurrency for Gemini
      openaiGpt4oMini: 250      # High API concurrency for OpenAI
      anthropicSonnet45: 150    # Moderate concurrency for Anthropic

这套配置会：

同时处理 5 个任务（队列并发）
每个任务最多对 Gemini 2.5 Flash 发起 300 个并发调用（模型并发）
允许处理更大的文档：300 * 12 = 每任务最多 3,600 页
提升 accurate 模式的吞吐（300 个并发 LLM 调用）
加快 OCR 与版面处理的速度

**重要：**更高的并发意味着更多的系统资源（CPU、内存、网络）。请盯住你的部署并相应调整。

最佳实践

1. 从保守起步

先用较低的并发值，再根据监控逐步上调：

监视 API 限流错误
跟踪任务成功率
观察处理耗时

2. 与提供方上限对齐

让并发与提供方文档里的限制相匹配：

RPM（每分钟请求数）：并发不应超过 RPM
TPM（每分钟 token 数）：要考虑每次请求的平均 token 数
留出余量：给突发流量留 10-20% 的余量

3. 充分测试

改动并发之后：

用各种大小的文档测试
在日志里监视限流错误
核对任务完成率
检查处理耗时

4. 注意地域差异

不同地域的 API 配额可能不同：

EU 地域的限制通常更严
自定义 API key 的配额可能不同
BYOC 部署可以有更高的上限

故障排查

任务失败并报 “DOCUMENT_TOO_LARGE” 错误

表现：

Error: Job would parse X pages, max pages allowed for parse mode Y is Z

解决办法：

通过 Helm 提高模型并发（推荐）：

config:
  parse:
    concurrency:
      gemini25Flash: 400  # Increase from default

提高队列并发以处理更多任务：

config:
  parse:
    maxQueueConcurrency: 5  # Process 5 jobs simultaneously

改用默认并发更高的模型
把文档拆成更小的批次

限流报错

表现：

API 报错里提到 rate limit
任务间歇性失败
出现 “429 Too Many Requests” 错误

解决办法：

通过 Helm 降低模型并发：

config:
  parse:
    concurrency:
      openaiGpt4oMini: 150  # Reduce from 250

降低队列并发：

config:
  parse:
    maxQueueConcurrency: 1  # Process one job at a time

联系提供方提高 API 配额
考虑用多个 API key 做负载均衡

最大页数低于预期

检查：

你的 Helm values 里是否配置了模型并发？

终端窗口

# Check current ConfigMap values
kubectl get configmap llamacloud-llamaparse-config -n llamacloud -o yaml | grep CONCURRENCY

该并发值是否真的被应用了？

终端窗口

# Check environment variables in the pod
kubectl exec -it deployment/llamacloud-llamaparse -n llamacloud -- env | grep CONCURRENCY

核对算式：concurrency * 12 应当大于解析模式的默认上限

配置没生效

Helm values 没起作用时：

确认你的值写在正确的段落里：

config:
  parse:
   concurrency:
    gemini25Flash: 300

显式指定 values 文件重新部署：

终端窗口

helm upgrade llamacloud llamacloud \
  --values your-values.yaml \
  --debug

检查生成的 ConfigMap：

终端窗口

kubectl get configmap llamacloud-temporal-parse -o yaml

有疑问或问题，请联系 LlamaParse 开发团队。

索引

数据加载

查询

存储

成本分析

应用

聊天机器人

问答

结构化数据

智能体

Chat Engines

Query Engine

连接器

文档与节点

摄取流水线

节点解析器

大语言模型

提示词

回调

节点后处理器

响应合成器

检索器

路由

结构化输出

现有数据

Presets and Modes

能力

起步

能力

Examples

Azure Deployment

Databases and Queues

LLM Integrations

并发与最大页数配置

概述

工作原理

可处理最大页数的算法

各解析模式的默认最大页数

模型级的并发覆盖

如何修改并发设置

方案一：按模型配置（生产环境推荐）

在 Helm 里配置模型并发

部署更新后的配置

方案二：按解析模式修改默认并发

各解析模式的并发设置

算清影响

最佳实践

1. 从保守起步

2. 与提供方上限对齐

3. 充分测试

4. 注意地域差异

处理流水线的并发

队列并发

它们如何互相作用

最佳实践

1. 从保守起步

2. 与提供方上限对齐

3. 充分测试

4. 注意地域差异

故障排查

任务失败并报 “DOCUMENT_TOO_LARGE” 错误

限流报错

最大页数低于预期

配置没生效

友情链接