集中式的提供方配置

集中式的 LLM 提供方配置，就是你这套自托管 LlamaParse 部署可调用的模型端点的部署期登记表。

config.llms.* 下那些更简单的提供方设置，登记的是每个提供方的默认端点。当你需要多套凭据、自定义端点、自定义请求头、提供方原生的模型名，或要接 Bifrost、Portkey、LiteLLM 这类 API 网关时，用 config.llms.providerConfigs 追加显式条目。

每个条目把一个 LlamaParse 的 model_id 映射到一个提供方端点：

model_id 是平台各项能力所请求的 LlamaParse 模型标识。
provider 决定使用哪个客户端实现。
provider_model_name 是发给上游提供方或网关的模型名／部署名。省略时，LlamaParse 会用它为该 model_id 内置的提供方原生名。
priority 与 tags 是路由提示。它们只影响会去看它们的能力，例如解析档位的模型先后顺序，或某个产品专有的模型偏好。

被识别的 model_id 并不代表上游一定可用。提供方账号、地域、Azure 部署、Vertex 位置或网关，仍然必须真的能提供所配置的提供方原生模型。

使用场景

自定义 API 网关：让 LLM 请求经 Bifrost、Portkey、LiteLLM 这类网关出去
自定义端点：为代理或某个地域的端点指定自定义 base URL
自定义请求头：为每个提供方实例加自定义 HTTP 请求头（例如用于网关认证）
多套凭据：用不同的 API key 配置多个提供方实例
托管嵌入：让托管的 Index 嵌入走集中配置的 OpenAI 兼容提供方

配置结构

把提供方配置加在你的 Helm values 的 config.llms.providerConfigs 之下：

config:
  llms:
    providerConfigs:
      - id: "my-config-name"               # User-defined identifier (can be anything)
        provider: "openai"                 # Provider type accepted by this config entry
        model_id: "openai-gpt-4o"          # Recognized LlamaParse model identifier (fixed values, see below)
        provider_model_name: "gpt-4o"      # Optional: Provider-specific model name override, usually only needed if using an LLM gateway that requires a specific model name
        enabled: true                      # Enable/disable this configuration
        tags:                              # Optional: see "Controlling Parsing Model Order"
          - "llamaparse-tier:agentic"
        priority: 100                      # Optional: higher = preferred within a tier (default 100)
        credentials:                       # Provider-specific credentials
          api_key: "sk-..."
          base_url: "https://custom.api.endpoint"  # Optional custom endpoint
        headers:                           # Custom HTTP headers (optional)
          X-Custom-Header: "value"

多数条目不需要 tags。只有当某能力明确写了它所约定的 tag 用法时（比如解析档位的 tag）才使用 tags。

受支持的服务商

下面这些提供方小节说明本指南覆盖哪些 provider 取值，以及每个提供方被识别的 model_id 取值。

OpenAI

- id: "openai-primary"
  provider: "openai"
  model_id: "openai-gpt-4o"
  credentials:
    api_key: "sk-..."                    # Required
    org_id: "org-..."                    # Optional
    base_url: "https://api.openai.com/v1"  # Optional
  headers:                               # Optional
    X-Custom-Header: "value"

被识别的 model_id 取值：

openai-gpt-4o
openai-gpt-4o-mini
openai-gpt-4o-mini-text-only
openai-gpt-4o-mini-multimodal
openai-gpt-4-1
openai-gpt-4-1-mini
openai-gpt-4-1-nano
openai-gpt-5
openai-gpt-5-mini
openai-gpt-5-nano
openai-gpt-5-2
openai-gpt-5-4
openai-gpt-5-4-mini
openai-gpt-5-4-nano
openai-text-embedding-3-small
openai-text-embedding-3-large

openai-gpt-4o-mini-text-only 与 openai-gpt-4o-mini-multimodal 这两个 id 都路由到 gpt-4o-mini 模型；它们用来选择 cost_effective 解析路径中的纯文本版与截图版，而裸的 openai-gpt-4o-mini 仍是遗留的纯文本绑定。

Anthropic

- id: "anthropic-primary"
  provider: "anthropic"
  model_id: "anthropic-sonnet-4.5"
  credentials:
    api_key: "sk-ant-..."               # Required
    base_url: "https://api.anthropic.com"  # Optional
  headers:                               # Optional
    X-Custom-Header: "value"

被识别的 model_id 取值：

anthropic-sonnet-4.6
anthropic-sonnet-4.5
anthropic-sonnet-3.5
anthropic-haiku-4.5
anthropic-opus-4.6
anthropic-opus-4.5

Azure OpenAI

- id: "azure-sweden"
  provider: "azure"
  model_id: "openai-gpt-4o"
  credentials:
    api_key: "..."                      # Required
    endpoint: "https://your-resource.openai.azure.com"  # Required
    deployment_id: "gpt-4o"             # Optional
    api_version: "2024-08-06"           # Optional
  headers:                               # Optional
    X-Custom-Header: "value"

被识别的 model_id 取值：

openai-gpt-4o
openai-gpt-4o-mini
openai-gpt-4o-mini-text-only
openai-gpt-4o-mini-multimodal
openai-gpt-4-1
openai-gpt-4-1-mini
openai-gpt-4-1-nano
openai-gpt-5
openai-gpt-5-mini
openai-gpt-5-nano
openai-gpt-5-2
openai-gpt-5-4
openai-gpt-5-4-mini
openai-gpt-5-4-nano
openai-text-embedding-3-small
openai-text-embedding-3-large

openai-gpt-4o-mini-text-only 与 openai-gpt-4o-mini-multimodal 这两个 id 都路由到 gpt-4o-mini 模型（默认部署名也是 gpt-4o-mini）；它们用来选择 cost_effective 解析路径中的纯文本版与截图版，而裸的 openai-gpt-4o-mini 仍是遗留的纯文本绑定。

对于托管在 Azure 上的嵌入模型，把 model_id 设为 LlamaParse 的模型标识，把 credentials.deployment_id 设为你的 Azure 部署名。

Google Gemini

- id: "gemini-primary"
  provider: "gemini"
  model_id: "gemini-2.5-flash"
  credentials:
    api_key: "AIza..."                   # Required
    base_url: "https://generativelanguage.googleapis.com"  # Optional
  headers:                               # Optional
    X-Custom-Header: "value"

被识别的 model_id 取值：

gemini-3.1-pro
gemini-3.1-flash-lite
gemini-3.0-pro
gemini-3.0-flash
gemini-2.5-pro
gemini-2.5-flash
gemini-2.5-flash-lite
gemini-2.0-flash
gemini-2.0-flash-lite

Google Vertex AI

Vertex AI 同时服务 Gemini 与 Anthropic Claude 模型。默认情况下 Vertex 配置用服务账号认证，即 project_id + location + credentials（JSON 序列化的服务账号密钥）。当已配置的网关代为处理 Vertex 认证时，设 credentials_type: "proxy"。

- id: "vertex-primary"
  provider: "vertexai"
  model_id: "gemini-2.5-flash"
  credentials:
    project_id: "your-gcp-project-id"    # Required
    location: "us-central1"              # Required
    credentials: |-                      # Required (service account key JSON)
      {
        "type": "service_account",
        "project_id": "your-gcp-project-id",
        "private_key_id": "...",
        "private_key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n",
        "client_email": "...@your-gcp-project-id.iam.gserviceaccount.com",
        "client_id": "..."
      }
    base_url: "https://us-central1-aiplatform.googleapis.com"  # Optional
  headers:                               # Optional
    X-Custom-Header: "value"

注意

private_key 要保持成单行、里面用字面的 \n 转义序列（也就是从下载的服务账号密钥文件里直接拿到的那种形式）。把它们展开成真正的新行会让内层 JSON 解析失败 —— JSON 字符串里不允许出现裸的换行符。

被识别的 model_id 取值（Vertex 上的 Gemini）：

gemini-3.1-pro
gemini-3.1-flash-lite
gemini-3.0-pro
gemini-3.0-flash
gemini-2.5-pro
gemini-2.5-flash
gemini-2.5-flash-lite
gemini-2.0-flash
gemini-2.0-flash-lite

被识别的 model_id 取值（Vertex 上的 Anthropic）：

anthropic-sonnet-4.6
anthropic-sonnet-4.5
anthropic-haiku-4.5
anthropic-opus-4.6
anthropic-opus-4.5

控制各档位的解析模型顺序

解析时，每个档位都会对着一份有序模型列表运行：先试第一个，某模型不可用或失败时就回退到下一个。在自托管 / BYOC 部署上，你通过给提供方配置条目打 tag 并设置其 priority，来决定某档位用哪些模型、以什么顺序用。

本节只影响解析档位的成员与顺序，不控制嵌入、聊天或抽取的模型选择。

可配置的档位

Tag	档位	用于
`llamaparse-tier:cost_effective`	Cost Effective	低成本的解析档位
`llamaparse-tier:agentic`	Agentic	默认的智能体式转写
`llamaparse-tier:agentic_plus`	Agentic Plus	带自我批判评审的智能体式转写
`llamaparse-tier:specialized_chart_parsing`	Chart parsing	专门的图表转表格模型

顺序是如何生效的

把 llamaparse-tier:<tier> 加进应当属于该档位列表的每个配置条目的 tags。只有带该 tag 的条目才会加入列表。
在同一档位内，模型按 priority 降序尝试 —— priority 最高的那个就是主模型，其次是第一回退，依此类推。priority 默认为 100，因此请给档位内每个条目一个互不相同的值，把顺序显式写出来。
模型仍只有在启动时凭据校验通过、且提供方可达时才会被使用；不可用的模型会被跳过并尝试下一个。
若某档位没有任何带 tag 的条目，部署会回退到所部署应用版本里该档位的内置默认模型列表。 所以你只需要给想覆盖的档位打 tag。
同一个条目可以带多个档位 tag（例如某模型同时被 agentic 与 agentic_plus 使用）。

示例：为 BYOC 的 `agentic` 档位排序

这样就把 Sonnet 4.5 变成 agentic 的主模型、GPT-4.1 为第一回退、Haiku 4.5 作最后手段：

config:
  llms:
    providerConfigs:
      - id: "agentic-primary-sonnet"
        provider: "anthropic"
        model_id: "anthropic-sonnet-4.5"
        enabled: true
        tags:
          - "llamaparse-tier:agentic"
          - "llamaparse-tier:agentic_plus"
        priority: 30                       # highest → tried first (primary)
        credentials:
          api_key: "sk-ant-..."

      - id: "agentic-fallback-gpt"
        provider: "openai"
        model_id: "openai-gpt-4-1"
        enabled: true
        tags:
          - "llamaparse-tier:agentic"
        priority: 20                       # middle → first fallback
        credentials:
          api_key: "sk-..."

      - id: "agentic-fallback-haiku"
        provider: "anthropic"
        model_id: "anthropic-haiku-4.5"
        enabled: true
        tags:
          - "llamaparse-tier:agentic"
        priority: 10                       # lowest → last fallback
        credentials:
          api_key: "sk-ant-..."

得到的 agentic 顺序为 anthropic-sonnet-4.5 → openai-gpt-4-1 → anthropic-haiku-4.5。这里的 agentic_plus 档位只解析出 anthropic-sonnet-4.5（它是唯一打了该 tag 的条目）；要扩充它，就再加几条带各自 priority 的 llamaparse-tier:agentic_plus 条目。

示例：为 `cost_effective` 档位配备具备视觉能力的 GPT-4o-mini

GPT-4o-mini 的执行器绑定变体，让部署能以截图式转写路径为主、纯文本路径为最后手段来跑 cost_effective 档位 —— 当文档里有纯文本转写看不见的栅格化表格时，这尤其有用：

config:
  llms:
    providerConfigs:
      - id: "ce-gpt-4o-mini-vision"
        provider: "openai"            # or "azure"
        model_id: "openai-gpt-4o-mini-multimodal"
        enabled: true
        tags:
          - "llamaparse-tier:cost_effective"
        priority: 20                       # highest → tried first (primary)
        credentials:
          api_key: "sk-..."

      - id: "ce-gpt-4o-mini-text"
        provider: "openai"
        model_id: "openai-gpt-4o-mini-text-only"
        enabled: true
        tags:
          - "llamaparse-tier:cost_effective"
        priority: 10                       # lowest → last fallback
        credentials:
          api_key: "sk-..."

得到的 cost_effective 顺序为 openai-gpt-4o-mini-multimodal → openai-gpt-4o-mini-text-only。由于只给这两条打了 tag，该档位的内置默认列表被整体替换 —— 其他默认模型不会被尝试。

注意

tags 与 priority 只影响一个档位列表的成员与顺序。它们本身并不能启用某个模型 —— 条目仍必须像上面任何一条那样，为其提供方配好有效凭据。

常见用例

自定义 API 网关

使用自定义的 API 网关或代理（例如 Bifrost、Portkey、LiteLLM）：

config:
  llms:
    providerConfigs:
      - id: "portkey-openai"
        provider: "openai"
        model_id: "openai-gpt-4o-mini"
        provider_model_name: "@openai/gpt-4o-mini"
        enabled: true
        credentials:
          api_key: "your-portkey-api-key"
          base_url: "https://api.portkey.ai/v1"
        headers:
          x-portkey-api-key: "your-portkey-api-key"

      - id: "portkey-anthropic"
        provider: "anthropic"
        model_id: "anthropic-sonnet-4.5"
        provider_model_name: "@anthropic/claude-sonnet-4-5"
        enabled: true
        credentials:
          api_key: "your-portkey-api-key"
          base_url: "https://api.portkey.ai"
        headers:
          x-portkey-api-key: "your-portkey-api-key"
          x-portkey-strict-open-ai-compliance: "False"

      - id: "portkey-vertex-gemini"
        provider: "vertexai"
        model_id: "gemini-2.5-flash"
        provider_model_name: "gemini-2.5-flash"
        enabled: true
        credentials:
          credentials_type: "proxy"
          project_id: "your-gcp-project-id"
          location: "us-central1"
          base_url: "https://api.portkey.ai/v1"
        headers:
          x-portkey-api-key: "your-portkey-api-key"
          x-portkey-provider: "@your-portkey-vertex-provider-id"
          x-portkey-strict-open-ai-compliance: "false"

验证

配置完成后，请这样验证：

在管理界面核对：在 LlamaCloud 管理界面查看可用的模型
测试解析：向 LlamaParse 上传一份文档，确认所配置的提供方确在工作

索引

数据加载

查询

存储

成本分析

应用

聊天机器人

问答

结构化数据

智能体

Chat Engines

Query Engine

连接器

文档与节点

摄取流水线

节点解析器

大语言模型

提示词

回调

节点后处理器

响应合成器

检索器

路由

结构化输出

现有数据

Presets and Modes

能力

起步

能力

Examples

Azure Deployment

Databases and Queues

LLM Integrations

使用场景

配置结构

受支持的服务商

OpenAI

Anthropic

Azure OpenAI

Google Gemini

Google Vertex AI

控制各档位的解析模型顺序

可配置的档位

顺序是如何生效的

示例：为 BYOC 的 agentic 档位排序

示例：为 cost_effective 档位配备具备视觉能力的 GPT-4o-mini

常见用例

自定义 API 网关

验证

友情链接

示例：为 BYOC 的 `agentic` 档位排序

示例：为 `cost_effective` 档位配备具备视觉能力的 GPT-4o-mini