标准 HPA

在 temporalWorkloads.llamaParse 下配置 Kubernetes HPA，按 CPU 或内存利用率来伸缩 Parse worker。这需要 Kubernetes Metrics Server。设置了 horizontalPodAutoscalerSpec 时 chart 才会创建 HPA，它默认为空。

temporalWorkloads:
  llamaParse:
    replicas: null
    horizontalPodAutoscalerSpec:
      minReplicas: 2
      maxReplicas: 8
      metrics:
        - type: Resource
          resource:
            name: cpu
            target:
              type: Utilization
              averageUtilization: 40
        - type: Resource
          resource:
            name: memory
            target:
              type: Utilization
              averageUtilization: 60

chart 会把 HPA 的目标设为 llamacloud-temporal-parse。副本范围与利用率目标请按你的负载调整。其他服务（例如 backend 与 llamaParseOcr）同样接受 horizontalPodAutoscalerSpec。

已有的 KEDA scaler

如果你用 KEDA 管理伸缩，就把该组件的 horizontalPodAutoscalerSpec 留空，以免两套伸缩器同时控制同一个 Deployment。Parse worker 的目标是 llamacloud-temporal-parse。

已废弃的 llamacloud-parse deployment 不再创建，llamaParse.* 的值也会被忽略。升级前请先替换掉指向它的 scaler。/api/queue-statusz 端点现在返回 410 Gone，它不再报告 Temporal 积压或健康状况；用到它的 scaler 同样要在升级前替换掉。

读取旧 AMQP 队列的 OCR scaler 也需要换一个信号源。你可以在 llamaParseOcr.horizontalPodAutoscalerSpec 下配置 CPU 或内存 HPA，并按 OCR 的实际利用率调优。升级次序见从 RabbitMQ 迁出。