国产AI API路由器的运行时成本熔断器设计

大多数 AI 成本控制都来得太晚。

每小时更新一次的仪表盘对财务审查有帮助。每日的使用量导出对对账有帮助。带有当前供应商报价的电子表格对规划有帮助。但这些控制手段都无法阻止以下情况：刚进入重试循环的编码 Agent、在每一轮都发送相同 400K token 上下文的摘要生成器、或者从紧凑执行模型切换到长上下文推理模型但没有更改输出上限的客户工作流。

对于位于美国、英国、加拿大、德国、荷兰、日本、新加坡、韩国、澳大利亚以及其他一级/二级市场的生产团队，更安全的模式是运行时成本断路器。路由器在请求离开应用之前估算成本，在响应返回后记录实际使用量，并在某个路由、租户、工作流或模型系列开始超出策略运行时断开电路。

本文展示了一种面向中国 AI API 路由器的实用设计，这些路由器调用 DeepSeek、Qwen、GLM、Kimi 或 OpenAI 兼容的聚合服务（如 AIWave）。这不是基准测试，也不是价格排名表。这是一项面向希望拥有模型选择权但又不想出现失控支出的团队的工程控制手段。

示例仅使用占位符和环境变量。

定价事实核查日期：2026 年 8 月 14 日

运行时断路器需要带日期的定价输入。没有核查日期的路由策略不是可操作的事实，而是一个过时的假设。

以下公开来源页面已于 2026 年 8 月 14 日核查：

DeepSeek 官方定价

QwenCloud 定价文档

AIWave 对话补全文档

这些价格是示例控制平面的来源事实。你的应用应该检查实际结算所依据的定价来源，然后将核查日期与路由策略一起存储。

断路器保护什么

运行时断路器保护四种通常在造成损失后才由仪表盘捕获的故障模式。

第一种故障模式是请求膨胀。提示词模板的更改可能将 12K token 的请求变成 120K token 的请求。模型可能仍然能处理，尤其是有 1M 上下文路由的情况下，但单位经济学已经不同了。

第二种故障模式是输出膨胀。Agent 循环、冗长的工具摘要和薄弱的停止条件可能将生成的 token 推送到远超响应产品价值的程度。输出通常是调用中成本较高的一侧，所以它值得单独设置上限。

第三种故障模式是缓存失效。一个长上下文工作流在重复前缀命中缓存时可能看起来是可持续的。提示词排序、每用户元数据或检索文档顺序的小变化可能将缓存命中的输入变成缓存未命中的输入。

第四种故障模式是路由漂移。路由器可能将流量从紧凑模型移到推理模型，从 Flash 路由移到 Pro 路由，或从一个聚合路由移到另一个。请求仍然成功，但其成本 envelope 发生了变化。

断路器不应该决定一个模型是否好用。它应该决定一个请求是否被允许在产品、财务和工程已批准的策略内支出。

在工作流层面定义策略

不要从全局美元上限开始。全局上限是粗暴的，会造成混乱的事故：一个吵闹的租户可能阻塞无关的客户，或者一个昂贵的 admin 工作流可能消耗原本用于面向用户流量的预算。

从工作流策略开始：

workflow: "doc_summarizer"
route: "deepseek_flash_current"
preflight_ceiling_usd: 0.08      # 拒绝超过 8 美分的预检
daily_tenant_ceiling_usd: 12.00  # 每租户每天 12 美元上限
max_output_tokens: 8192          # 限制输出 token
temperature: 0.3                 # 降低随机性
fallback_routes:                 # 显式回退路由
  - "deepseek_flash_current"
  - "qwen_flash_current"
escalation: "human_approval"     # 断路器断开时的升级路径

上面的确切数字是示例。重要的是形态：

• 显式的回退路由
• 一个预检上限
• 一个滚动租户窗口
• 断路器断开时的一条升级路径

路由器然后可以在昂贵调用发生之前拒绝、降级、修剪上下文或要求人工审批。

将价格存储为版本化的路由元数据

将价格从提示词代码中分离出来。将它们存储为带来源 URL 和核查日期的路由元数据。

from dataclasses import dataclass
from decimal import Decimal
from typing import Optional

@dataclass(frozen=True)
class PriceCard:
    route: str
    model: str
    source_url: str
    checked_date: str
    input_per_mtok: Decimal
    output_per_mtok: Decimal
    cached_input_per_mtok: Optional[Decimal] = None
    effective_from_utc: Optional[str] = None

PRICE_CARDS = {
    "deepseek_flash_current": PriceCard(
        route="deepseek_flash_current",
        model="deepseek-v4-flash",
        source_url="https://api-docs.deepseek.com/quick_start/pricing/",
        checked_date="2026-08-14",
        input_per_mtok=Decimal("0.14"),
        cached_input_per_mtok=Decimal("0.0028"),
        output_per_mtok=Decimal("0.28"),
    ),
    "kimi_k3_current": PriceCard(
        route="kimi_k3_current",
        model="kimi-k3",
        source_url="https://www.kimi.com/resources/kimi-k3-pricing",
        checked_date="2026-08-14",
        input_per_mtok=Decimal("3.00"),
        cached_input_per_mtok=Decimal("0.30"),
        output_per_mtok=Decimal("15.00"),
    ),
}

价格计算使用 Decimal 而不是 float。当供应商宣布未来变化时，也要保留计划中的价格卡片。例如，DeepSeek 的页面列出了 2026 年 8 月 16 日 16:00 UTC 生效的新的高峰/非高峰 schedule。生产路由器应该能够按请求时间加载正确的卡片。

在发送请求之前估算

预检估算不需要精确的 token 计算就能有用。它只需要足够保守以阻止明显的错误。

from decimal import Decimal

def estimate_cost_usd(
    card: PriceCard,
    input_tokens: int,
    max_output_tokens: int,
    cached_input_tokens: int = 0,
) -> Decimal:
    uncached = max(input_tokens - cached_input_tokens, 0)
    cached_rate = card.cached_input_per_mtok or card.input_per_mtok
    input_cost = Decimal(uncached) * card.input_per_mtok / Decimal(1_000_000)
    cache_cost = Decimal(cached_input_tokens) * cached_rate / Decimal(1_000_000)
    output_cost = Decimal(max_output_tokens) * card.output_per_mtok / Decimal(1_000_000)
    return input_cost + cache_cost + output_cost

def should_allow_request(policy, estimate: Decimal, tenant_spend_today: Decimal) -> bool:
    if estimate > policy.preflight_ceiling_usd:
        return False
    if tenant_spend_today + estimate > policy.daily_tenant_ceiling_usd:
        return False
    return True

在输出侧使用配置的 max_tokens 或 max_completion_tokens。不要用昨天的平均输出进行估算。如果请求允许模型生成 64K token，断路器应该评估该请求仿佛该输出可能发生。

对于长上下文工作流，估算缓存命中和缓存未命中两种场景。如果路由仅在缓存命中率高时才具有经济性，则将其作为显式策略：

def require_cache_health(observed_hit_ratio: Decimal, required_hit_ratio: Decimal) -> None:
    if observed_hit_ratio < required_hit_ratio:
        raise RuntimeError("cache_hit_ratio_below_route_policy")

该错误不是供应商故障。这是发布控制在履行其职责。

带降级状态的路由

断开断路器并不总是意味着丢弃请求。一个好的路由器有降级状态。

第一种状态是修剪。移除可选的检索文档，减少对话历史，或从完整文件切换到相关片段。

第二种状态是紧凑。对不需要深度规划的任务使用更小的执行路由。

第三种状态是延迟。将工作移到异步队列，尤其是当供应商有实时与批量定价差异时。

第四种状态是审批。在高价值工作流使用长上下文或推理路由之前要求人工标记。

以下是一个小型的路由器形态：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("AIWAVE_API_KEY", "YOUR_API_KEY_HERE"),
    base_url="https://aiwave.live/v1",
)

def complete_with_breaker(workflow, messages, token_estimate, tenant_state):
    route = choose_primary_route(workflow)
    card = load_price_card(route)
    policy = load_workflow_policy(workflow)

    estimate = estimate_cost_usd(
        card=card,
        input_tokens=token_estimate.input_tokens,
        cached_input_tokens=token_estimate.cached_input_tokens,
        max_output_tokens=policy.max_output_tokens,
    )

    if not should_allow_request(policy, estimate, tenant_state.spend_today):
        route, messages = downgrade_route(workflow, route, messages, tenant_state)
        card = load_price_card(route)

    response = client.chat.completions.create(
        model=card.model,
        messages=messages,
        max_tokens=policy.max_output_tokens,
        temperature=policy.temperature,
    )

    record_actual_usage(
        workflow=workflow,
        route=route,
        model=card.model,
        usage=response.usage,
        price_card=card,
    )
    return response

代码假设你有本地辅助函数如 choose_primary_route、load_price_card 和 record_actual_usage。保持这些函数的简单。业务价值在策略和事件日志中，而不是在巧妙的路由代码中。

每次调用后记录实际使用量

预检保护前门。实际使用量关闭账务循环。

这也是 AIWave 等聚合服务有用的地方。如果你的应用使用一个 OpenAI 兼容端点访问 25+ 个中国模型，你的路由器可以专注于工作流策略，而平台处理供应商访问和模型目录暴露。你仍然需要自己的断路器，因为只有你的应用知道是哪个租户、工作流和客户操作创建了该请求。

监控斜率而非仅监控总量

每日上限是必要的，但仅靠它太慢了。监控斜率：

• 过去 5 分钟内每个租户的支出
• 过去 20 次调用中每次请求的输出 token
• 过去 50 次调用中每个路由的缓存命中率
• 过去一小时内每个工作流的降级次数
• 请求估算值与实际成本的差异

斜率告警能快速捕获错误的部署。如果新版本的提示词使输出 token 加倍，你希望在每日上限被消耗之前让断路器断开。如果缓存命中率从 80% 降到 10%，你希望在财务询问长上下文账单为什么变化之前收到路由级告警。

将策略与供应商偏好分离

生产级 AI 路由有两个不同的决策：

• 哪个模型适合这个工作流？
• 这个特定请求是否被允许在当前策略下支出？

不要将这两个决策合并到一个 if 语句中。模型选择可能取决于质量、延迟、上下文长度、工具支持、地区策略和客户层级。支出许可取决于估算的 token、当前价格卡片、租户窗口和路由健康状况。

当这些决策分开时，团队可以在不重写模型选择的情况下更改定价策略，也可以在不绕过成本控制的情况下更改模型选择。

断路器的发布检查清单

在启用新的中国 AI 模型路由之前，要求：

• 一份带来源 URL 和日期的价格卡片
• 一份带有预检和滚动窗口上限的工作流策略
• 长上下文工作流的缓存命中率策略
• 实际使用量账本
• 一个可以在不重新部署应用代码的情况下禁用路由的回滚标志

这个检查清单有意做得很小。它可以放进 pull request。它给工程、产品、财务和安全一个共同的对象来审查。

中国 AI API 现在已经足够多样化，单个静态供应商表是脆弱的。DeepSeek 暴露了缓存命中和缓存未命中的定价，并带有计划的高峰/非高峰变化。Kimi K3 使 1M token 上下文变得实用，但输出侧需要护栏。GLM 和 Qwen 路由有各自的缓存输入、工具、思考和分级计费规则。像 AIWave 这样的聚合服务使访问和切换更简单，但应用仍然需要工作流感知的控制。

运行时成本断路器就是那个控制手段。

在请求之前估算。在响应之后记录。在路由、租户、工作流和缓存异常时断开电路。在产品价值允许的情况下降级而不是失败。将来源日期存储在每个价格卡片旁边。

这就是一个团队可以在生产中使用多个中国 AI 模型系列而不会将每次模型发布变成账单惊喜的方式。