配置参数参考
Halro 使用 YAML 配置文件。这里说明 config.yaml 与 configs/config.example.yaml 的区别，并按功能列出参数的示例值、作用和调整注意事项。
两个配置文件有什么区别
Section titled “两个配置文件有什么区别”| 文件 | 用途 | 是否应直接修改 |
|---|---|---|
config.yaml | 当前实例实际读取的运行配置。首次执行 halro start 时，如果文件不存在，Halro 会创建它 | 是。调整实例时修改这个文件，并先备份 |
configs/config.example.yaml | 源码仓库中受版本控制的完整参考模板，包含字段说明和推荐起始值 | 通常不修改。新部署可以复制一份再按环境调整 |
发布包中的 config.yaml、源码仓库中的模板以及旧实例保留下来的配置可能属于不同版本。升级时不要用模板直接覆盖现有 config.yaml；应先备份，再把新版本增加的字段按需合并进去。本文表格中的“示例值”来自当前文档版本对应的 configs/config.example.yaml，运行时仍以你传给 --config 的文件为准。
有一个容易混淆的刻意差异：源码参考模板把 usage.timezone 写成 Asia/Shanghai，而 Halro 首次自动生成的 config.yaml 使用 UTC。两者都合法；应在首次初始化前选择实例实际采用的 IANA 时区。
安全修改流程
Section titled “安全修改流程”# 1. 确认服务实际使用的配置路径ps aux | grep '[h]alro start'
# 2. 备份并编辑cp ./config.yaml ./config.yaml.bak
# 3. 使用即将运行的 Halro 版本做静态校验./halro config check --config ./config.yaml
# 4. 重启服务后检查 Gateway 就绪状态curl -fsS http://127.0.0.1:8080/health/ready使用 systemd 时，第 4 步前执行 sudo systemctl restart halro；Docker 或 Kubernetes 部署则重建容器或 Pod。若校验失败，错误信息会给出完整字段路径，例如 server.shutdown_timeout。
YAML 缩进只能使用空格。时长支持 Go duration 写法，例如 250ms、30s、5m、8h；文件大小类参数使用字节或 MB，具体见字段说明。
除下表中的项目外，修改配置后都需要重启 Halro。
可在 Linux/macOS 上通过 SIGHUP 重载的内容 | 说明 |
|---|---|
logging.level | 会重新读取配置文件；整个文件仍必须通过校验 |
tls.certificates 指向的证书与私钥内容 | 只重读原路径中的文件内容；改变路径或增删证书仍需重启 |
metrics.tls 指向的证书、私钥与客户端 CA 内容 | 三者作为一组更新，路径改变仍需重启 |
| 日志文件句柄 | 供外部日志轮转工具“改名后发信号”使用 |
发送信号可运行 systemctl reload halro，或 kill -HUP <PID>。Windows 不投递 SIGHUP，所有变更都通过重启生效。监听地址、超时、安全代理设置、admin.external_origin、存储和 Master Key 等参数始终需要重启。
| 参数 | 示例值 | 说明 |
|---|---|---|
version | 1 | 配置结构版本。当前必须为 1，它不是 Halro 的发布版本号 |
Server：监听与 HTTP 限制
Section titled “Server：监听与 HTTP 限制”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
server.gateway_listen | 127.0.0.1:8080 | 模型请求入口。生产环境建议由反向代理终止 TLS，而不是直接暴露明文端口 |
server.admin_listen | 127.0.0.1:8081 | Admin API 和管理界面。不要直接暴露到公网 |
server.metrics_listen | 127.0.0.1:9090 | Prometheus Metrics 和审计锚拉取端点的监听地址 |
server.read_header_timeout | 5s | 完整读取请求头的最长时间，必须大于 0 |
server.read_body_timeout | 15s | 完整读取请求体的最长时间，必须大于 0 |
server.shutdown_timeout | 120s | 优雅关闭预算，必须大于 0，且不得短于 gateway.route_total_timeout |
server.max_header_bytes | 32768 | 单个请求头最大字节数，最小 1024 |
server.max_request_bytes | 10485760 | 单个非流式请求最大字节数，必须大于 0；示例为 10 MiB |
三个启用中的监听地址必须互不相同。非回环监听还会触发额外的 TLS 和认证安全校验。
TLS：Gateway 与 Admin 入站加密
Section titled “TLS：Gateway 与 Admin 入站加密”生产环境只要允许其他机器访问 Gateway 或 Admin，就必须使用 HTTPS，但证书不一定由 Halro 保存。推荐让 Caddy、nginx 或 Traefik 在前面终止 TLS，Halro 继续监听受保护的回环或容器网络，并保持 tls.enabled: false。只有客户端直接连接 Halro 时，才需要启用下面的配置并把证书只读挂载进容器。完整 Docker 示例见安装&部署：生产环境配置 HTTPS 证书。
| 参数 | 示例值 | 作用与限制 |
|---|---|---|
tls.enabled | false | 为 Gateway 和 Admin 的入站连接启用 TLS |
tls.certificates | [] | 证书列表；启用 TLS 后至少一项，最多 16 项 |
tls.certificates[].cert_file | — | PEM 证书链路径，不能在列表中重复 |
tls.certificates[].key_file | — | 对应的 PEM 私钥路径 |
示例：
tls: enabled: true certificates: - cert_file: /etc/halro/tls/fullchain.pem key_file: /etc/halro/tls/privkey.pem第一项证书用于没有 SNI 的连接；其他证书按其声明的域名选择。tls.enabled: false 时不能保留证书列表。
Storage：数据与 Master Key
Section titled “Storage：数据与 Master Key”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
storage.data_dir | ./data | 数据库、账本、审计和用量数据的根目录；相对路径基于进程工作目录 |
storage.metadata_file | halro.db | 元数据库文件名，只能是文件名，不能包含目录 |
storage.master_key.mode | file | Master Key 来源；普通单机部署使用本地文件，高级部署可使用外部 key slots |
storage.master_key.file | ./master.key | file 模式的 Master Key 路径；相对路径同样基于进程工作目录 |
容器部署建议将数据目录和 Master Key 分别挂载到不同持久卷。企业 KMS 的 key_slots 模式涉及 provider、region、account、key ID、算法和启动超时等边界，应按照实际 KMS 方案单独设计，不要从 file 模式直接试改。
Admin：会话与管理功能
Section titled “Admin：会话与管理功能”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
admin.session_ttl | 8h | 管理员会话最长有效期，必须大于 0 |
admin.idle_timeout | 30m | 空闲会话失效时间，必须大于 0 且不超过 session_ttl |
admin.login_rpm | 5 | 每分钟允许的管理员登录尝试数，至少为 1 |
admin.mfa_policy | optional | MFA 策略：optional 或 required |
admin.developer_workbench | enabled | Admin 监听端上的真实 Gateway 调试入口：enabled 或 disabled |
admin.reauth_elevation_window | 10m | 删除、替换凭据或削弱防护时，重新验证对当前 Session 保持有效的时间；0s 表示每次都验证 |
admin.external_origin | "" | 浏览器访问管理端的规范外部源；经反向代理对外时填纯 HTTPS origin，如 https://admin.example.com，不能带路径、查询或片段。非空时首次初始化必须提交一次性令牌 |
admin.setup_token_file | "" | 生产环境挂载的一次性初始化令牌绝对路径；已有管理员后不再读取。v0.8.3 起可用 |
admin.setup_token_ttl | 30m | 生成 Token 的有效期，或文件在加载时允许的最大剩余有效期；必须大于 0，最大 24h，重启不续期。v0.8.3 起可用 |
当 Admin 不再只监听回环地址时，建议将 developer_workbench 设为 disabled。external_origin 必须和用户实际访问的协议、域名及端口一致，否则登录跳转和来源校验会失败。设置它会强制首次创建管理员时使用一次性初始化令牌。
v0.8.3 起，生产 serve 不生成无法安全取回的 Token：远程零管理员实例必须配置绝对路径 setup_token_file，或在启动前执行离线 admin bootstrap。Token 文件缺失、格式错误、过期或剩余 TTL 超限时启动失败，不回退到日志。文件只在进程启动时读取一次；修改 Secret 后必须停止旧 Pod并启动读取新版本的 Pod。已存在管理员时不读取文件，但编排层仍需解除强制 Secret mount，才能在删除 Secret 后重新调度。
完整生成、挂载、自动化 Job、Audit 验证与泄露恢复流程见生产环境 Admin 初始化与 Secret 生命周期。v0.8.2 及更早的发布包不包含这两个字段，不要把更新后的配置直接交给旧二进制。
MFA 策略
Section titled “MFA 策略”admin.mfa_policy 是实例级配置开关，不是所有部署都强制开启 MFA：
| 策略 | 没有验证器时 | 已有验证器时 | 适用场景 |
|---|---|---|---|
optional | 可以正常进入控制台，自行决定是否绑定 MFA | 登录仍会要求现有验证器；策略变为可选不会自动删除或绕过已经绑定的 MFA | 仅本机回环访问的开发或个人实例 |
required | 密码登录后，控制台只开放 MFA 设置流程，完成绑定前不能使用其他功能 | 每次登录需要密码和 TOTP；不能停用 MFA，也不能撤销最后一个有效验证器 | 任何可被其他机器访问的 Admin，尤其是生产环境 |
修改策略后必须重启 Halro。若从 required 改为 optional，重启后“必须先设置 MFA”的控制台门槛会消失，但已经绑定的验证器仍然有效；需要管理员在“设置 → 安全”中另行停用。
如果所有验证器和恢复码都已丢失，应先停止 Halro，再离线重置指定管理员的 MFA：
./halro admin reset-mfa --config ./config.yaml --username admin该命令会删除该账号的验证器与恢复码，使现有 Session 和待处理的 MFA challenge 失效，并写入 Audit。若策略仍是 required，下一次密码登录仍只允许重新绑定 MFA；需要永久改为可选时，应先修改 admin.mfa_policy 并重启。
模型能力检测
Section titled “模型能力检测”能力检测只在管理员明确确认后运行，可能产生计费的 Provider 调用。
| 参数 | 示例值 | 作用与限制 |
|---|---|---|
admin.model_capability_detection.fresh_ttl | 24h | 检测结果无需重测的有效时间，必须大于 0 |
admin.model_capability_detection.retention | 720h | 检测记录保留期，不得短于 fresh_ttl |
admin.model_capability_detection.refresh_cooldown | 5m | 同一模型两次手动刷新之间的最短间隔 |
admin.model_capability_detection.total_timeout | 90s | 单次任务总超时，必须大于 0 且不超过 2m |
admin.model_capability_detection.global_concurrency | 4 | 全实例并发检测上限，至少为 1 |
admin.model_capability_detection.provider_concurrency | 1 | 单 Provider 并发上限，至少为 1 且不超过全局上限 |
admin.model_capability_detection.max_provider_calls | 10 | 单次检测允许的计费调用上限 |
admin.model_capability_detection.create_rpm | 6 | 每位管理员每分钟新建检测任务上限，范围 1–60 |
Usage：用量持久化与导出
Section titled “Usage：用量持久化与导出”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
usage.durability | balanced | balanced 优先吞吐和低延迟；strict 提高持久性保证但会增加写入开销 |
usage.timezone | Asia/Shanghai | 只在首次初始化时设置记账时区；初始化后应在管理界面的实例设置中修改 |
usage.wal_queue_capacity | 4096 | 等待写入用量 WAL 的记录容量，至少为 1 |
usage.wal_max_batch | 128 | 单次 WAL 批次记录数，至少为 1 且不超过队列容量 |
usage.wal_flush_interval | 2ms | 未满批次等待持久化的最长时间，必须大于 0 |
usage.analytics_queue_capacity | 4096 | 等待分析处理的记录容量，至少为 1 |
usage.checkpoint_interval | 1m | 生成持久化检查点的频率，必须大于 0 |
usage.parquet_interval | 1h | 将聚合用量写入分析分区的频率，必须大于 0 |
usage.retention_days | 90 | 本地分析用量保留天数，至少为 1 |
usage.console_window_days | 30 | 控制台 Attempt 与失败请求的内存查询窗口；只在首次启动时作为初值，之后从实例设置修改，范围不超过 retention_days |
usage.export_format | parquet | 新分区格式：parquet 或 ndjson；改变它不会重写已有分区 |
已经初始化的实例即使修改 usage.timezone 也不会改变正在使用的记账时区；halro doctor 会报告文件值与实例设置不一致。
Ledger：账本封存
Section titled “Ledger：账本封存”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
ledger.seal.enabled | false | 活动 Accounting WAL 达到阈值后封存整代；默认关闭 |
ledger.seal.max_active_bytes | 8589934592 | 触发封存的活动 WAL 大小，最小 16 MiB |
ledger.seal.compress | true | 已安全越过导出和 checkpoint 边界后，将封存代替换为校验过的 gzip 副本 |
封存不会删除会计历史，重放仍从封存段接到活动 WAL。启用前应根据磁盘、备份和恢复演练结果决定， 不能把它当作普通日志轮转。
Gateway：请求预算、尝试与限流
Section titled “Gateway：请求预算、尝试与限流”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
gateway.route_total_timeout | 120s | 一次请求跨所有尝试的总预算，必须大于 0 |
gateway.pricing_clock_rollback_tolerance | 2s | 价格选择时允许的时钟回退容差，不能低于安全下限 |
gateway.pricing_clock_forward_tolerance | 30s | 允许价格时间超前当前时钟的容差，不能为负数 |
gateway.pricing_unknown_policy | reject | 未知价格策略：reject 或 allow_without_cost_governance |
gateway.attempt_connect_timeout | 5s | 单次上游连接建立超时，必须大于 0 |
gateway.attempt_response_header_timeout | 60s | 单次尝试等待上游响应头的超时，必须大于 0 |
gateway.downstream_write_timeout | 15s | 向客户端执行单次响应写入的超时，必须大于 0 |
gateway.stream_max_duration | 10m | 单个流式请求最长持续时间，必须大于 0 |
gateway.max_total_attempts | 3 | 一次请求跨所有目标的总尝试上限，至少为 1 |
gateway.deferred_response_workers | 4 | 全实例延迟响应 Worker 数；提高它会增加延迟层对上游的并发压力 |
gateway.health_probe_interval | 30s | 后台部署健康探测间隔，必须大于 0 |
gateway.source_rate_limit.requests_per_minute | 600 | 认证前每个来源地址的分钟预算；0 关闭限流，不能为负数 |
gateway.source_rate_limit.max_tracked_sources | 16384 | 独立跟踪限流状态的来源数上限；超出后共享一个预算 |
增大某个单次尝试超时并不会自动增大总预算。规划时应同时检查 gateway.route_total_timeout 和 server.shutdown_timeout，否则请求可能在重试完成前被总预算终止。
请求失败诊断捕获
Section titled “请求失败诊断捕获”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
gateway.failure_capture.enabled | false | 保存受控、脱敏后的最终请求失败诊断；默认关闭 |
gateway.failure_capture.max_bytes | 65536 | 单条诊断记录允许保存的最大字节数 |
gateway.failure_capture.max_records_per_day | 1000 | 每个记账日允许保存的诊断记录上限 |
gateway.failure_capture.retain | 24h | 诊断记录保留时间 |
它不保存 Provider 凭据，也不应被当作请求正文归档。只有错误计数不足以定位问题且磁盘与隐私边界已经审核时再启用。
Retry 与 Circuit Breaker
Section titled “Retry 与 Circuit Breaker”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
retry.max_attempts_per_target | 2 | 对同一上游目标的最大尝试次数，至少为 1 |
retry.base_delay | 100ms | 重试退避初始延迟，必须大于 0 |
retry.max_delay | 2s | 单次退避上限，不得短于 base_delay |
retry.jitter | true | 为退避加入随机抖动，避免请求同时重试 |
circuit_breaker.consecutive_failures | 5 | 连续失败达到该值后打开断路器，至少为 1 |
circuit_breaker.open_duration | 30s | 进入半开状态前保持打开的时间，必须大于 0 |
circuit_breaker.half_open_max_requests | 1 | 半开状态允许并行执行的探测请求数，至少为 1 |
retry.max_attempts_per_target 是单目标上限，gateway.max_total_attempts 是整次请求跨目标的上限；最终生效的是两者和可用路由目标共同形成的边界。
Alerts：告警投递
Section titled “Alerts：告警投递”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
alerts.queue_capacity | 1024 | 待投递告警队列容量，至少为 1 |
alerts.workers | 2 | 并行投递工作数，至少为 1 |
alerts.timeout | 5s | 单次投递超时，必须大于 0 |
alerts.max_attempts | 3 | 单条告警最大投递次数，至少为 1 |
alerts.base_delay | 250ms | 告警重试初始退避，必须大于 0 |
alerts.max_delay | 5s | 告警重试退避上限，不得短于 base_delay |
alerts.dedup_cooldown | 1m | 相同告警再次允许投递前的冷却时间，必须大于 0 |
Security：私网访问与代理信任
Section titled “Security：私网访问与代理信任”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
security.allow_private_provider_endpoints | false | 是否允许 Provider 端点解析或连接私网地址；开启会扩大 SSRF 可达范围 |
security.allow_private_webhooks | false | 是否允许 Webhook 目标解析或连接私网地址；开启前应限制可配置目标的人员 |
security.trust_proxy_headers | false | 是否信任反向代理提供的客户端地址转发头 |
security.trusted_proxy_cidrs | [] | 允许提供可信转发头的代理 CIDR 列表 |
只有 Halro 确实位于受控反向代理之后时才开启 trust_proxy_headers，并把 trusted_proxy_cidrs 缩到实际代理网段；开启信任但不配置 CIDR 会被拒绝。
security: trust_proxy_headers: true trusted_proxy_cidrs: - "10.42.0.0/16"Metrics：Prometheus 与独立 mTLS
Section titled “Metrics：Prometheus 与独立 mTLS”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
metrics.enabled | true | 启用 Metrics 服务 |
metrics.require_auth | true | 要求抓取请求携带独立凭据 |
metrics.credential_file | "" | Metrics Bearer 凭据文件路径；设置它时 require_auth 必须为 true |
metrics.max_concurrent_scrapes | 2 | 同时处理的抓取请求数，范围 1–32 |
metrics.write_timeout | 5s | 写回抓取响应的超时，必须大于 0 且不超过 30s |
metrics.tls.enabled | false | 为 Metrics 监听器启用独立 TLS 与客户端证书认证 |
metrics.tls.cert_file | "" | Metrics 服务端证书链路径 |
metrics.tls.key_file | "" | Metrics 服务端私钥路径 |
metrics.tls.client_ca_file | "" | 验证抓取客户端证书的 CA 路径 |
Metrics 只监听回环地址时，凭据文件可以为空；当 require_auth: true 时，Halro 会从 Master Key 派生默认 Bearer Token，可用 halro metrics token --config ./config.yaml 读取。生产环境建议配置可独立轮换、撤销的 credential_file。只要 server.metrics_listen 改为非回环地址，就必须同时提供独立 credential_file，并启用包含证书、私钥和客户端 CA 的 mTLS。metrics.tls.enabled: false 时不能残留这三个 TLS 文件字段。
Audit Anchor：外部审计锚
Section titled “Audit Anchor：外部审计锚”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
audit.anchor.enabled | false | 发布不含事件正文的审计链摘要，由独立主机留存 |
audit.anchor.sink | dead_man_pull | 当前唯一实现的接收方式；其他保留名称尚不可用 |
audit.anchor.interval | 5m | 即使记录数未达阈值也发布锚的最长间隔，必须大于 0 且不超过 1h |
audit.anchor.record_delta | 500 | 触发新锚所需的新增审计记录数，至少为 1 |
audit.anchor.credential_file | "" | dead-man 拉取锚时使用的独立凭据文件 |
启用外部锚定时必须同时启用 Metrics mTLS，并设置与 metrics.credential_file 不同的锚定凭据文件。审计锚用于让另一台主机持有可核对的链头，两个端点共用凭据会破坏这层隔离。
Model Catalog：签名模型目录
Section titled “Model Catalog：签名模型目录”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
model_catalog.enabled | false | 后台从固定端点刷新签名模型目录；Gateway 请求路径不会下载目录 |
model_catalog.refresh_interval | 6h | 检查更新的间隔，范围 5m–168h |
model_catalog.pinned_revision | "" | 可选的固定 revision，格式必须是 sha256: 加 64 位十六进制摘要 |
model_catalog.max_download_bytes | 1048576 | 压缩响应体上限，范围 4 KiB–16 MiB |
model_catalog.max_decoded_bytes | 4194304 | 解压后上限，不小于下载上限且不超过 64 MiB |
model_catalog.max_compression_ratio | 20 | 最大解压展开比，范围 1–100 |
model_catalog.max_entries | 10000 | 单个验证清单的模型条目上限，范围 1–100000 |
Providers：v0.8.1 配置兼容
Section titled “Providers：v0.8.1 配置兼容”v0.8.2 不再使用全局 providers.bedrock.region。Bedrock Mantle 的 Region 由 Admin 中保存的
Credential 决定，并绑定到该 Region 的端点。
为保证原地升级，v0.8.2 起的版本仍会接受并校验旧配置中的以下字段，因此已有系统不需要在升级前删除它：
providers: bedrock: region: us-east-1这个旧字段必须仍是合法的 AWS Region 名称，但它不再改变已保存的 Credential 或 Provider。
确认 Admin 中的 Bedrock Credential 已绑定到预期区域端点后，可以从 config.yaml 删除整个旧
providers 块。新的 Region 变更应通过创建或选择对应 Region 的 Credential 完成。
Logging：日志输出与轮转
Section titled “Logging：日志输出与轮转”| 参数 | 示例值 | 作用与限制 |
|---|---|---|
logging.level | info | debug、info、warn 或 error；这是唯一可直接通过 SIGHUP 改变的语义参数 |
logging.format | json | json 适合采集器，text 适合终端；两种格式都会脱敏 |
logging.output | stderr | stderr、file 或 both |
logging.file | "" | 留空时使用 <data_dir>/logs/halro.log；仅当输出包含 file 时使用 |
logging.max_size_mb | 64 | 单个日志文件上限，范围 1–4096 MiB |
logging.max_files | 5 | 保留文件总数，包含正在写入的文件，范围 1–100 |
logging.error_file 是独立的 ERROR 级别诊断文件，不受 logging.output 选择影响：
| 参数 | 示例值 | 作用与限制 |
|---|---|---|
logging.error_file.enabled | false | 是否写入独立 ERROR 日志 |
logging.error_file.file | "" | 留空时使用数据目录下的默认错误日志路径 |
logging.error_file.max_size_mb | 32 | 单个错误日志文件上限 |
logging.error_file.max_files | 10 | 错误日志保留文件数 |
systemd、Docker 和 Kubernetes 通常使用 stderr 交给平台采集。没有外部采集器时选择 file 或 both，并确保数据卷有足够空间。
常见调整场景
Section titled “常见调整场景”| 目标 | 需要一起检查的参数 |
|---|---|
| 通过反向代理开放管理后台 | server.admin_listen、admin.external_origin、security.trust_proxy_headers、security.trusted_proxy_cidrs，以及代理自身的 TLS 与访问控制 |
| 延长长响应或流式请求 | gateway.stream_max_duration、gateway.route_total_timeout、server.shutdown_timeout，以及外层代理超时 |
| 提高请求大小上限 | server.max_request_bytes，以及反向代理或 Ingress 的 body size 限制 |
| 将 Metrics 暴露给其他主机 | server.metrics_listen、metrics.credential_file 和完整的 metrics.tls mTLS 配置 |
| 提高重试次数 | retry.max_attempts_per_target、gateway.max_total_attempts、总超时，并评估非幂等请求和 Provider 成本 |
| 使用真实客户端 IP 限流 | 仅信任受控代理 CIDR，再开启 security.trust_proxy_headers；不要信任公网来源的转发头 |
| 修改记账时区 | 新实例在初始化前改 usage.timezone；已有实例在管理界面的实例设置中改 |
| 调整控制台历史窗口 | 在实例设置修改运行时值；同时核对 usage.console_window_days 与 usage.retention_days |
| 扩大延迟响应吞吐 | gateway.deferred_response_workers、Project 延迟队列、Project/Deployment 并发与 gateway.route_total_timeout |
| 启用失败诊断 | gateway.failure_capture.*、数据卷容量、保留期和组织的隐私策略 |
哪些运行治理参数不在 config.yaml
Section titled “哪些运行治理参数不在 config.yaml”Run Governance 是 Project 级策略，必须在 Admin Console 的 Project 编辑页配置，不是实例 YAML：
| Project 参数 | 作用与限制 |
|---|---|
run_governance.enabled | 启用 Work Unit/Run API 与请求归因；存在 active Run 时不能关闭 |
default_run_budget_micros_usd | 创建 Run 未传预算时使用的默认值 |
max_run_budget_micros_usd | 单 Run 可声明的最大生命周期预算 |
default_run_ttl_seconds | 创建 Run 未传 TTL 时使用的默认值 |
max_run_ttl_seconds | 单 Run 最大 TTL，不超过 30 天 |
max_active_runs | Project 的 active Run 上限，最大 1000 |
max_open_work_units | Project 的 open Work Unit 上限，最大 1000 |
控制台以 USD 和小时显示预算、TTL；Run API 使用 micros USD 和秒。完整流程见 接入运行治理。
若还要检查证书、目录权限、磁盘和运行数据，应先停止 Halro，再离线运行：
./halro doctor --config ./config.yamlconfig check 负责结构、取值范围和参数组合；doctor 还会检查部署条件，但它需要独占数据目录，不能与运行中的 Halro 同时执行。检查通过后再启动服务，最后检查 /health/ready 和日志。
生产配置组合示例见最佳实践案例库。需要从控制台完成第一条模型链路， 阅读首次配置 Admin Console；价格、Project 与 Token Guard 的 任务顺序见版本化定价与 Project/Token Guard。