LLM 网关与统一接入

• 理解 LLM 网关作为统一接入层的核心价值（多供应商抽象、能力收口）
• 掌握鉴权、限流、路由、缓存、审计五类横切能力的实现方式
• 区分网关与业务应用层各自的职责边界

LLM 网关是位于业务应用与各模型供应商（OpenAI、Anthropic、开源自部署等）之间的反向代理/统一接入层，其核心价值是把"模型调用"这一横切关注点从业务代码中抽离出来，形成统一的 API 面。鉴权上，网关统一校验 API Key/JWT、租户身份与权限，屏蔽下游供应商的认证差异；限流上，网关在租户、Key、模型、并发多维度做令牌桶/并发限制，保护下游并发配额并平滑突发；路由上，网关按模型能力、任务类型、SLA、成本、地域做多目标路由，并支持 failover；缓存上，网关对精确命中与语义命中做缓存，降低重复调用成本；审计上，网关记录每一次请求的调用方、模型、token 用量、耗时与结果，形成可追溯的合规日志。Portkey、Lunary 是托管型可观测+路由网关，OpenRouter 是公共模型聚合路由，Higress 是云原生 AI 网关（Golang 实现，原生支持语义缓存与多 Provider 路由），它们的共同点是让上层只面向统一接口，供应商切换对业务透明。

网关的定位本质是"集中式横切面"，把分布式系统里每个服务都要重复做的鉴权、限流、重试、缓存、日志收口到一处，既降低业务复杂度，也让成本与合规可控。选择网关而非在业务代码里内联实现，是为了可观测性、策略一致性（灰度、切流）与运营效率。

• 按任务类型（生成/分类/embedding）划分模型池的建模思路
• 按 SLA（延迟、成本、可用性）做供应商选择的策略与排序
• failover 的判定（超时、错误码、熔断）与灾备切换的降级策略

多模型路由通常分两层：第一层按任务类型选模型，生成类走 LLM 生成池、分类走小模型或专用分类模型、embedding 走 embedding 池，避免用大模型做分类造成浪费；第二层在同类模型池内按 SLA 选供应商，例如低延迟需求优先选本地/边缘、高可用走多活云、低成本走幻方/Qwen 等按量便宜通道。SLA 选择可建模为加权评分或分级路由：把每个候选供应商的延迟分布、可用性、成本、历史错误率量化成分数，在满足约束的前提下选最优。failover 实现上是"重试+降级"组合：上游请求失败（超时/5xx/限流）后，按优先级顺序切换到下一个供应商，切换前做熔断闸门（如连续失败超过阈值则临时摘除该供应商），避免对故障源持续打爆。灾备切换则需在路由配置里维护主备/多活拓扑，采用健康检查（探活）与故障状态共享，保证主链路故障时能自动切到备链路，同时在业务侧保留降级模板（如返回兜底答案或排队）。

路由的本质是"把请求映射到最合适的模型+供应商"，是一套带约束的决策问题。关键不在算法多复杂，而在判据可观测：每个供应商的延迟、错误率、成本必须被持续采集，路由才能基于真实数据而非拍脑袋。failover 必须配合熔断与健康检查，否则故障时会无限重试放大故障。

• 精确缓存（key 完全相同）与语义缓存（语义相似）的适用场景
• 用 embedding 余弦相似度 + 阈值做 hit/miss 判定的机制
• 命中率提升与误命中（语义近但答案不同）代价的权衡

精确缓存要求请求的 key（通常为模型+参数+Prompt 的哈希）完全一致才命中，命中率高但只适用于完全重复的请求；语义缓存则把用户请求转成 embedding，与缓存中已存条目的 embedding 做余弦相似度比较，超过阈值（如 0.92）即视为命中，直接返回缓存答案，从而覆盖"语义相同但措辞不同"的请求。判定流程是：请求 → embedding 模型编码 → 与缓存向量库（如 Redis/FAISS）做相似度搜索 → 相似度 ≥ 阈值则命中（返回缓存），否则 miss（走模型并写入缓存）。命中率优化可从阈值、缓存容量、embedding 模型质量、分桶（按路由的模型/租户分桶降低干扰）入手；误命中代价则表现为"语义相近但上下文/时间前提不同，答案其实不同"，例如带时间敏感或个性化条件的请求被错误复用旧答案，其代价可能是事实错误或合规风险，因此阈值不能一味调低，高风险场景（金额、法律、医疗）建议关闭语义缓存或提高阈值。

语义缓存本质是"近似键值查找"，用向量相似度代替精确相等。核心权衡是阈值：阈值越高命中率越低但误命中少，阈值越低命中率越高但误命中风险越大。工程上常用"命中分数 + 成本/风险分级"：低成本请求可放宽阈值，高风险请求收紧或禁用。缓存还需考虑失效（TTL、源数据变更时主动失效）。

• 按模型能力（参数量、上下文、工具调用）匹配任务需求
• 按成本（单次调用成本、预算）做成本优先或成本上限路由
• 按租户（贵宾/普通、配额）与地域（数据驻留、延迟就近）路由

多维度路由可抽象为"请求特征 × 路由约束 → 最合适供应商"的决策树/评分模型。按模型能力路由：根据任务复杂度（简单分类→小模型，深度推理→大模型）、上下文长度需求、工具调用/JSON 输出能力、多模态需求匹配模型，超出能力上限的请求不可路由到该模型。按成本路由：为每个模型/供应商打上单 token 成本，设置租户预算与成本上限，成本敏感的请求优先走低成本通道，或在预算超额时降级。按租户路由：贵宾/企业租户走高可用高质通道，普通/免费租户走低成本通道，并叠加各自配额。按地域路由：隐私与合规要求数据驻留（如国内数据不出国），优先路由到本地供应商；同时考虑就近低延迟。多个维度常加权组合，形成"能力必须满足、成本/地域/租户作为约束或偏好"的优先级排序。

多维度路由的难点是约束冲突，例如高能力与低成本不可兼得。工程上常用"能力约束优先 + 偏好加权"：先过滤掉不满足硬约束（能力、地域、合规）的候选，再在剩余候选中按成本/延迟/租户优先级加权选择。维度要可配置、可观测，路由决策要留痕以便审计。

• 网关计量（token 数、请求数）与供应商 usage 报告的差异来源
• 缓存命中、重试、prompt 舍入、模型版本差异导致的账面差异
• 对账流程与容差（tolerance）设计，防止双计费或少计费

网关计费与供应商 usage 的差异主要来自四类：一是缓存命中——网关层缓存命中时没真正调用供应商，但若网关仍计费会造成重复计费，需在计量中标记 cache_hit 不计入模型调用；二是重试——网关失败重试会产生多次真实调用，供应商按实际调用计费，网关需把最终成功的那次与重试次数关联，避免按成功响应计费而漏计重试；三是舍入——供应商按 tokenizer 的 token 数与模型输入规整（如按 4 的倍数、固定 max_tokens）与网关自行统计的 token 数有差异；四是模型版本/价格变更导致同一 token 数价格不同。对账做法是：网关记录每次调用的原始请求与响应（含供应商返回的 usage 字段），定时与供应商账单按时间窗口、Key、模型一一核对，对差异设定容差（如 token 偏差 <5% 视为正常），超出容差则标记待人工/finops 复核，同时用缓存与重试的埋点来解释差异来源。

对账的本质是"以供应商真实 usage 为准、网关计量为准的交叉验证"，关键是要保留可对账的原始凭证（每次调用的 usage、cache、retry、price 字段）。容差阈值要合理，过严会有大量误报，过松则漏掉真实计费错误。FinOps 场景还常按租户/项目做成本归因，与账单对账形成闭环。

• 各供应商 SSE 事件格式（OpenAI / Anthropic / 自建）的差异
• 流式中断（中断恢复、取消、错误）在各供应商的语义差异
• 网关做协议归一化（统一事件结构、统一错误码、统一取消语义）

各供应商的流式协议差异显著：OpenAI 用 SSE 的 data: 行分段下发 delta 与 usage，以 [DONE] 结束；Anthropic 用多条带 content_block_delta 等事件的 SSE；自建/开源（vLLM、Ollama）又各有 JSON 结构。中断语义也各异：有的支持 End-Of-Stream 正常结束，有的在中途出错时直接断连，有的需要客户端发送 cancel 才能终止。网关做协议归一化的核心是把各供应商的流式事件映射成统一的内部事件模型（如 {type:'text_delta'|'tool_call'|'usage'|'end'|'error', data}），翻译错误码为统一错误类别，并统一取消/中断语义给上层。网关同时处理流式透传（对不需要改动的场景直接透传字节）与流式改写（需要过滤/脱敏/聚合 usage 时做缓冲重组）。实现上要管理背压与缓冲，避免把供应商的流式错误直接暴露给上层。

流式适配的价值在于"一次接入、多供应商无缝切换"，上层只依赖统一事件接口。工程难点是流式数据无法像普通响应那样整体重写，需要增量解析与重组，且要处理"半途错误"与"usage 只在流尾出现"的情况。归一化后，缓存、脱敏、审计也能以流式事件为粒度执行。

• 权重轮询（weighted round-robin）与加权随机（weighted random）的差异
• 用价格/延迟/可用性动态计算权重的方法
• 熔断器对故障供应商的摘除与恢复

供应商负载均衡的目标是在多个等价供应商之间分配流量，避免单一供应商过载并提升总体可用性。基础做法是加权轮询或加权随机：按供应商的可用性、延迟、价格动态计算权重，可用性高的权重高、延迟低的权重高、价格低的权重高，再用权重做轮询或随机抽样。实际实现中常把权重建模为"得分 = 可用性系数 × 延迟惩罚 × 价格系数"，且权重随健康指标动态更新（如滑动窗口内错误率上升则权重下降）。熔断器与负载均衡配合：熔断器监视每个供应商的失败率，超过阈值（如 5xx 连续超过 N 或错误率超 50%）则打开熔断、临时摘除该供应商，不再分配流量；经过冷却期与半开探测成功后再恢复。二者结合既保证流量均衡，又防止故障供应商被持续打爆。

负载均衡与熔断是"分流量 + 保健康"的组合。权重轮询解决"流量怎么分"，熔断解决"故障源怎么躲"。纯静态权重会随供应商健康状况漂移失效，所以权重必须实时、可观测。加权随机在平滑方面优于轮询，可避免突发流量同时打向同一供应商。

• 密钥的存储、加密与引用方式（不落地明文）
• 密钥轮换的策略（双密钥灰度、平滑切换）与审计
• 租户隔离：Key 与租户绑定、配额映射、防串租

网关层密钥管理遵循"密钥不落明文"原则：供应商的 API Key 通常加密存储于密钥管理服务（如 KMS/Vault），网关只持有引用或解密后短期驻留内存，业务侧用租户/项目标识而非明文 Key 调用。密钥轮换采用"双密钥并行"策略：先为租户生成新 Key 并配置灰度（部分请求走新 Key），验证稳定后再全量切换、下线旧 Key，整个过程记录审计日志并避免中断。租户隔离上，每个租户绑定自己的密钥集合（AK/SK 或供应商 Key），路由时按租户身份映射到对应 Key 与配额，防止 A 租户的请求误用 B 租户的凭证或被共享配额串扰；敏感 Key 通过租户级加密在对外请求时注入，返回时剔除。

密钥管理是网关安全的地基。核心是"引用而非分发"——业务代码不接触明文 Key，减少泄露面；轮换用双密钥灰度避免切换瞬间中断；租户隔离保证密钥与配额维度都按租户切分，满足多租户合规。审计记录密钥的创建、使用、轮换与吊销，便于追踪。

• 日志中 PII 与凭证的识别与脱敏（掩码、替换、删除）
• 脱敏的触发时机（写入前、查询时）与留存策略
• 合规（GDPR/SOC2）对日志保留、访问控制、可追溯的要求

网关日志脱敏策略要求在日志写入前对敏感字段做处理：识别 PII（姓名、邮箱、身份证、信用卡）与凭证（API Key、Token、密码），然后用掩码（如 a***@x.com）、替换（哈希化）或删除处理。为兼顾性能与准确性，常用"字段白名单 + 正则/规则引擎 + 可选 PII 识别模型"三层：默认只记录白名单字段，非白名单字段不落日志；对必须记录的内容做脱敏。脱敏可采取写时脱敏（存储前即脱敏，最安全）或读时脱敏（查询时按角色掩码）。审计合规方面，GDPR 要求个人数据最小化、可删除（right to be forgotten）、数据驻留；SOC2 要求访问控制、审计日志完整、留存策略明确。因此网关需提供日志分级访问（仅授权角色可见原始数据）、明确留存周期（过期自动删除）、以及不可篡改的审计轨迹，并支持按数据主体导出/删除。

脱敏与合规的关键是"能少记就少记、必须记的脱敏"。核心原则是数据最小化：默认不记录原始 Prompt/响应内容，只记录元数据与用量；必须记录的内容脱敏。合规不是单一功能，而是存储、访问、留存、删除、审计的体系，需在架构层面预置。GDPR 强调删除权，SOC2 强调控制与审计，二者都要求日志可追溯且访问受控。

• 流式响应与"整响应缓存"的冲突
• 缓存命中时如何以流式方式回放缓存内容
• 缓存与流式改写、脱敏的协同

网关缓存通常缓存"完整响应"，但流式传输是边生成边下发的增量，二者天然冲突：缓存命中时没有供应商实时流，需要网关把缓存内容转成流式事件回放给上层。实现思路是：对流式请求同样计算缓存 key，命中时从缓存取出完整响应，按统一事件格式逐块（如按句子/固定 token 块）伪装成流式 text_delta 事件下发，客户端感知不到差异；未命中则正常转发真实流，并在流结束后把完整响应写入缓存。为兼容流式中的改写/脱敏，网关可先做"缓冲式改写"（对低延迟敏感的不改，需改写时短暂缓冲再下发）。缓存命中后不再产生供应商 token 计费，但需把 usage 里的 cache 标记透传，避免重复计费。

兼容的关键是"把缓存当作流式数据源"，让上层无论如何都拿到统一流式事件。难点在于回放时机与背压，以及流式场景下缓存写入要等流结束拼接完整。缓存与会话、脱敏、计费需协同，命中时标记 cache-hit 并透传 usage，避免双计费。

• 用量计量的维度（租户、模型、场景、供应商）与准确统计
• 成本归因：把 token 用量按单价还原为成本并分摊到租户/项目
• 配额管理：硬配额（拒绝）与软配额（限流/告警）的层级

多租户用量计量需在网关层按"租户 × 模型 × 场景 × 供应商"维度统计 token 数与请求数，数据来源是每次调用的 usage 字段（input/output/cache/reasoning token），并区分缓存命中与真实调用。成本归因是基于单价把 token 用量换算成成本，再按租户/项目/成本中心分摊，形成成本看板与账单；对重试、缓存命中需特殊处理避免重复计费或漏计。配额管理分硬配额与软配额：硬配额超限直接拒绝（返回 429），软配额触发告警或限流降级，配额可设日/月/并发多级，超限时按租户优先级降级（贵宾租户可透支）。计量与配额需实时（流式累加）与准实时（批量对账）结合，并保证计量数据本身高可用、不丢。

多租户计量与配额是把"用多少、花多少、能不能用"收口到网关的核心。关键在计量准确（单一数据源、防重复）与配额可执行（硬拒绝+软告警）。成本归因是 FinOps 基础，需支持多维度下钻与对账，且计费口径与供应商账单一致。

• 多 Provider 接入的统一抽象（同一 API 面，差异在内部适配）
• 鉴权（身份校验、租户/Key 校验）的位置与方式
• 配额（按租户/Key/模型）的强制执行与限流

LLM 网关的核心职责是把"模型调用"收口为统一服务，具体包括三块：多 Provider 接入——网关对外暴露统一的 OpenAI 兼容 API，对内通过适配器连接各供应商与自部署推理服务，供应商差异（协议、鉴权、计费、流式）在适配层消化，业务无感；鉴权——网关在入口校验请求身份（API Key、JWT、租户标识），校验通过后按该身份映射到对应供应商凭证与权限，未授权直接拒绝；配额——网关按租户/Key/模型/并发维度执行配额与限流，超限返回 429 或降级。这三者共同保证"平接入、严鉴权、控用量"。

网关的职责边界是"横切、不越界"：接入、鉴权、配额属于网关，业务逻辑与 Prompt 优化属于业务层。其价值在于把供应商切换、鉴权升级、配额调整都收敛到一处，避免每个业务服务各自对接供应商造成重复与失控。

• OpenTelemetry GenAI 语义约定（gen_ai.* 属性、span 类型）
• usage 指标细粒度（input/output/cache/reasoning token）的采集
• 把 trace 与成本关联（按 span 的 token×单价）做成本可观测

网关可观测性依托 OpenTelemetry 的 GenAI 语义约定：用 gen_ai.operation.name（如 chat/completion）、gen_ai.request.model、gen_ai.response.model、gen_ai.usage.input_tokens 等属性标记 LLM 调用 span，使各厂商的 LLM 调用可被统一追踪与关联。usage 指标需细分 input/prompt token、output/completion token、cache token（命中/写）、reasoning token（推理模型），这些 token 分别有不同单价，细分才能准确估算成本。trace 与成本关联是把每个 span 的 token 用量乘以其单价得到成本，并把成本作为 span 属性或关联到成本指标，从而支持"按请求/租户/模型下钻的成本 trace"，与供应商账单对账。

可观测性的核心是"标准化 + 可关联"。标准化（OTel GenAI 语义约定）让跨供应商调用可统一查询；usage 细分让成本可精确计算；trace 关联成本让运维能从一次请求追溯到花了多少钱。这样既能监控延迟/错误率，也能监控成本漂移。

• 路由规则的多副本分发与一致性（版本化、配置中心）
• 缓存的多活一致性（分布式缓存、失效传播）
• 限流状态的分布式一致性（Redis 原子计数、本地近似 + 集中校准）

多活网关部署下，路由规则、缓存与限流状态都需要分布化。路由规则是低频、可版本化的配置，应放在分布式配置中心（如 etcd/Consul/Nacos），多副本订阅并做版本校验，保证所有实例看到同一版本规则，避免灰度切换时实例间路由不一致。缓存是多活的关键，用分布式缓存（Redis/内存缓存+共享层）承载，命中写入后需处理失效传播（源数据变更时广播失效），对一致性要求高则用带 TTL 与主动失效的缓存。限流状态天然跨实例，需用 Redis 原子计数（如令牌桶/滑动窗口的 LUA 脚本）做集中式限流以保证全局公平；但每次请求都走 Redis 有延迟，工程上常用"本地桶 + 集中校准"的混合方案：本地以近似限额快速放行，周期性向 Redis 汇总校准，牺牲少量精度换取低延迟。

多活高可用的矛盾是"分布式状态一致性 vs 低延迟"。路由规则低频可强一致；缓存用 TTL+失效可容忍最终一致；限流则需权衡精度与延迟，用本地近似+集中校准。设计原则是"能最终一致的尽量最终一致，只有强约束（如硬配额）才走集中原子操作"。

• 私有网络边界（VPC/VPN/防火墙）内网关的暴露面控制
• 传输加密（TLS/mTLS、内部服务间加密）
• 网关与业务、模型服务之间的网络拓扑与隔离

私有化部署下网关的网络边界设计目标是"缩小暴露面、全程加密"。在 VPC/VPN 内，网关通常只暴露必要的入口（如内部 API 或经 VPN 接入的接口），不直接暴露公网；通过安全组/防火墙/子网隔离限制谁可以访问网关，业务服务与网关之间用 mTLS 双向认证，防止内网横向移动。网关到模型推理服务（自部署 vLLM/Ollama）之间走内网私有地址，同样加密传输（TLS），并做最小权限：模型服务只对网关的特定端口开放。跨地域或混合云时用 VPN/专线加密隧道。密钥、证书集中管理，双向证书轮换，所有边界入口记录访问审计。

私有化网络安全的本质是"最小暴露 + 纵深防御"。网关作为唯一入口，必须控制进出的网络边界；加密不仅对外，也要对内（mTLS 防内网横向）。边界设计需与合规（数据不出域）结合，确保模型调用全程在受控网络内完成。

• 模型切换（切到备选供应商/本地模型）的降级路径
• 降级模板（兜底回答、缓存答案）的兜底策略
• 排队与限流保护，避免故障期雪崩

网关故障降级的目标是"尽量保住可用性，哪怕降级体验"。策略分三层：模型切换——主供应商故障时自动切到备选供应商或本地模型，保留核心能力但牺牲部分质量；降级模板——当所有模型都不可用时，返回预设兜底模板（如"服务暂时不可用"、常用问题的缓存答案），或把复杂请求降级为简单请求（如不检索直接生成）；排队与保护——故障时开启排队/限流，拒绝部分非关键请求，保护尚存的服务资源，避免雪崩。降级要可配置、可观测，并记录降级原因便于事后恢复与统计。

优雅降级的核心是"有兜底、有边界"。纯失败会把错误抛给用户，降级则用可接受的体验替代硬失败，保留可用性；同时要设置降级边界并使其可观测、可配置，避免故障期雪崩。

• 令牌桶（限速率）、并发限制（限在途）与排队（缓冲）的定位
• 客户端退避（重试）与网关排队/拒绝的配合
• 突发流量与多租户公平之间的平衡

网关流控需组合多种机制：令牌桶控制平均速率（突发用桶容量预留给余量），并发限制控制同时在途请求数（防止模型服务被并发打爆），排队在超过并发时缓冲请求而不是直接拒绝，退避让客户端在收到 429/5xx 时按指数退避重试，减少重试风暴。突发与公平平衡上，令牌桶允许一定的突发（桶容量），但多租户要按配额/权重分配桶，防止单一租户占满；用"公平队列"（按租户/优先级加权排队）保证各租户都有资源，拒绝时优先拒绝低优先级或超配额请求。组合原则：速率限制在前、并发限制在中间、排队消化突发、退避交给客户端。

流控是"限速 + 限并发 + 缓冲 + 退避"的组合拳，单靠一种不够。令牌桶管速率、并发限制管资源占用、排队管突发、退避管重试风控。公平性靠按租户分配配额与加权队列，避免"大用户饿死小用户"。突发被允许但受桶容量约束，既平滑又不死板。

• token 计费指标（input/output/cache 分项、成本）
• 延迟指标（TTFT、总延迟、分位延迟）
• 错误率指标（分供应商、分错误码）与告警

网关可观测的三类核心指标：token 计费——按 input/output/cache/reasoning token 分项统计，乘单价得到成本，按租户/模型/供应商聚合，形成成本看板并支持对账；延迟——监控首 token 延迟（TTFT）、端到端延迟、模型生成延迟，用分位数（P50/P95/P99）反映真实体验，按供应商/模型对比发现慢链路；错误率——按供应商、模型、错误码（超时/限流/5xx/熔断）统计错误率，设置告警阈值（如错误率>5% 或 P95 延迟超阈值告警），并关联到 trace 定位根因。三者结合形成"延迟、错误、成本"三维健康度，支撑容量规划与供应商优化。

可观测的三大指标对应运维的三大诉求：成本（token 计费）、性能（延迟）、稳定性（错误率）。关键是分维度（租户/模型/供应商）下钻，让问题可定位、成本可归因。告警要设合理阈值并与其他指标关联，避免噪声。

• 租户级 Provider 凭证的存储、加密与按租户注入
• 凭证与配额、路由的映射（按租户找凭证与配额）
• 密钥轮换的租户级隔离，避免影响其他租户

多租户密钥管理要求"凭证按租户隔离、映射清晰、轮换互不影响"。租户级 Provider 凭证：每个租户拥有自己的供应商凭证（AK/SK 或 API Key），加密存储于密钥管理，网关按请求中的租户身份解析出对应凭证并注入到对外请求，租户间凭证互不可见。配额映射：把租户标识映射到其配额（速率、并发、预算）与允许的模型/供应商集合，路由时按映射执行。密钥轮换的隔离：轮换是"租户级"操作，为某租户生成新凭证并灰度，只影响该租户，其他租户凭证与配额不受扰动；轮换过程记录审计，避免中断。所有凭证访问有权限控制，内部网络传输加密。

多租户密钥管理的核心是"租户维度贯穿一切"：凭证、配额、路由、轮换都按租户隔离，杜绝跨租户串用。安全上凭证加密存储+引用调用，运维上轮换灰度+审计。这与网关的多租户鉴权、计量、配额形成一体化的隔离体系。

• 配置热更新与版本化（灰度比例、按租户/流量灰度）
• 切换瞬间结果不一致的治理（原子切换、版本对齐）
• 审计断档的避免（变更前后审计记录完整）

路由规则热更新要求"可灰度、可回滚、可审计"。实现上把路由规则做成版本化配置，通过配置中心下发，支持按比例（如 1%→10%→50%→100%）、按租户、按请求特征灰度，观察新规则下延迟/错误/成本符合预期后再放量。切换瞬间结果不一致的治理：多活实例需保证同一规则版本（实例订阅同一版本号，启动时校验版本），灰度期间新旧规则并存时，用请求级标记区分是走旧规则还是新规则，避免同一请求在网关实例间被二次路由到不同结果；规则变更做成原子提交+版本号，探测到新版本失败可快速回滚。审计断档：规则变更本身记录审计（变更人、时间、变更前后差异、生效范围），保证变更前后调用审计连续，不因切换丢失请求记录。

热更新的难点是"变更即时生效"与"结果一致"的矛盾。灰度+版本化解决"出错可控"，原子切换+版本对齐解决"瞬间不一致"，审计记录解决"可追溯"。原则是任何变更都可灰度、可回滚、可审计，避免大爆炸式切换。