Go AI 网关怎么避免模型降级误用：预算检查、超时边界与路由状态

AI 网关最容易出现的一类故障，不是上游完全不可用，而是请求明明不该降级，却被路由器送进了备用模型：预算已经超限、上下文已经接近上限，或者上游正处于短暂降级状态，三种原因被一个“失败就换模型”吞掉后，用户只会看到回答质量突然变差。Go 里可以把这三个判断拆成独立状态，再让路由函数只返回一个可解释的选择结果。

先检查请求预算和路由状态，再在请求级上下文里决定唯一上游；超时只负责结束本次尝试，不应自动把所有错误都变成降级。

先把“模型变差”拆成三种可判断的状态

实际排查时，先问一句：这是预算不够、主模型不可用，还是请求本身已经超时？它们对应的处理并不一样。预算不够时应拒绝或选择低成本模型；主模型降级时可以选择能力相近的备用模型；请求超时则应结束当前尝试，并把超时原因交给上层决定是否重试。

下面的示例把路由所需的实体收敛到四个：Request 保存请求意图，BudgetCheck 保存预算判断，RouteState 表示上游状态，ModelRoute 是最终选择及其原因。这样做的好处是，日志不再只有一个模糊的 fallback=true。

type Request struct {
    Model string
    InputTokens int
    OutputLimit int
}

type BudgetCheck struct {
    Allowed bool
    Remaining int
    Reason string
}

type RouteState string

const (
    StateReady RouteState = "ready"
    StateDegraded RouteState = "degraded"
    StateOpen RouteState = "open"
)

type ModelRoute struct {
    Model string
    Reason string
    Budget BudgetCheck
}

预算检查要先于模型选择

路由函数不要一上来就读取“主模型”配置。先估算本次请求需要的输入和输出额度，再和租户或请求级剩余额度比较。示例中的 checkBudget 不改变外部余额，只返回判断结果；余额扣减应由真正提交上游请求的环节负责，否则失败重试会把账算乱。

func checkBudget(req Request, remaining int) BudgetCheck {
    needed := req.InputTokens + req.OutputLimit
    if needed > remaining {
        return BudgetCheck{
            Allowed: false,
            Remaining: remaining,
            Reason: "request_budget_exceeded",
        }
    }
    return BudgetCheck{
        Allowed: true,
        Remaining: remaining - needed,
        Reason: "budget_ok",
    }
}

这里有个常见坑：把 OutputLimit 当成一定会消耗的真实输出量。路由阶段只能按上限做准入判断，实际计费或配额确认要以后端收到的用量为准。否则短回答会被过度拒绝，长回答又可能突破保护线。

用路由状态约束备用模型，而不是看到错误就切换

主模型处于 StateReady 时直接使用它；处于 StateDegraded 时，只有请求显式允许降级才选择备用模型；处于 StateOpen 时则停止尝试，返回可观察的拒绝原因。状态名称可以按项目习惯调整，但“降级”和“熔断打开”不能混成一个布尔值。

func chooseModel(req Request, budget BudgetCheck, state RouteState, allowFallback bool) (ModelRoute, error) {
    if !budget.Allowed {
        return ModelRoute{Reason: budget.Reason, Budget: budget}, errors.New("budget rejected")
    }
    if state == StateOpen {
        return ModelRoute{Reason: "upstream_circuit_open", Budget: budget}, errors.New("upstream unavailable")
    }
    if state == StateDegraded && allowFallback {
        return ModelRoute{Model: "backup-model", Reason: "primary_degraded", Budget: budget}, nil
    }
    if state == StateDegraded {
        return ModelRoute{Reason: "fallback_not_allowed", Budget: budget}, errors.New("fallback disabled")
    }
    return ModelRoute{Model: req.Model, Reason: "primary_ready", Budget: budget}, nil
}

注意 allowFallback 是请求策略，不是“系统出错后的默认开关”。摘要、分类和审计类请求可以明确允许备用模型；需要严格工具调用或固定输出格式的请求，宁可返回原因，也不要静默切换到能力不匹配的模型。

超时只结束当前请求，不负责制造降级理由

调用上游时，为每个请求创建自己的 RequestContext；它只负责承载本次调用的取消与超时边界：

func callUpstream(parent context.Context, route ModelRoute, send func(context.Context, string) error) error {
    ctx, cancel := context.WithTimeout(parent, 8*time.Second)
    defer cancel()
    return send(ctx, route.Model)
}

如果返回 context.DeadlineExceeded，记录 timeout；如果路由状态本来就是 StateDegraded，记录 primary_degraded。两者可以同时发生，但不能用后一个覆盖前一个。上层若要重试，应重新做预算与状态判断，并设置次数上限；不要在 callUpstream 内部递归调用备用模型。

日志和用户提示要能对上同一个原因

网关日志至少保留 ModelRoute.Model、ModelRoute.Reason、预算结果和上下文结束原因。对用户的提示可以简化，但内部事件应保持原词，例如 fallback_not_allowed 和 request_budget_exceeded 不要都写成“服务繁忙”。这会让监控误把策略拒绝统计成上游故障。

常见问题：降级路由最容易踩到的边界

预算不足时应该自动换便宜模型吗？

只有请求策略允许且备用模型的能力满足最低要求时才可以。默认返回预算原因更安全，避免用户以为拿到的是原模型能力。

超时后能不能马上请求备用模型？

可以由上层策略决定，但必须重新检查预算、路由状态和剩余重试次数。不要把每次超时都视作主模型永久降级。

为什么要保留 ModelRoute.Reason？

它让日志、指标和用户提示共享同一判定依据，能区分策略拒绝、熔断和网络超时。

把路由器收敛成一个可验证的边界

一个稳妥的 AI 网关不是“主模型失败就换备用”，而是先做预算准入，再读取明确的上游状态，最后在请求上下文内完成一次有边界的调用。只要 ModelRoute 携带选择原因，后续的计费、监控和重试策略就能围绕同一份事实展开，模型降级也不会再变成用户无法解释的质量波动。