成本感知路由深度解析：聚合平台如何帮你自动选择最便宜的模型
当多模型路由解决了“用什么模型”的问题后，架构师面临的下一个挑战是“如何在保证质量的前提下，让系统自动选择最省钱的模型”。这不是一个静态配置能解决的问题——模型的价格在变，业务场景的质量容忍度不同，不同时段的负载特征也在波动。成本感知路由（Cost-Aware Routing）正是在这个背景下进入生产环境的。

在展开技术细节之前，先说明一个基础工作。实现成本感知路由的前提，是你已经对各模型在不同场景下的性价比有了清晰的数据认知。我习惯用官网:(dl.877ai.cn） 做这件事——把核心业务场景的测试用例同时推给 GPT-5.5、Claude 4.8、Gemini 3.5 等主流模型，在一个界面里对比它们的准确率、延迟和 Token 消耗。平台集齐了主流大模型，国内环境可以直接访问。这一步产出的“场景-模型”性价比矩阵，是成本感知路由规则设计的核心输入。

一、成本感知路由的核心逻辑：在质量与成本之间找到平衡点
传统的多模型路由主要依赖两个维度：场景规则（根据任务类型静态匹配模型）和质量路由（根据实时延迟、错误率动态切换）。这两层解决了“用对模型”和“故障自愈”的问题，但没有解决“用省钱的模型”的问题。

成本感知路由引入了第三个决策维度：成本因子。它的核心逻辑是：当主模型和备用模型的质量差异在可接受范围内时，优先选择成本更低的模型。

这个“可接受范围”的量化是成败的关键。设定过宽，可能导致核心场景质量下降；设定过窄，成本优化空间有限。在实践中，我们为每个场景定义了一个质量差异容忍阈值（Quality Deviation Threshold, QDT），结合成本权重（Cost Weight）来动态调整路由决策。

1.1 质量差异容忍阈值
QDT 定义为：备用模型与主模型在核心质量指标上的最大允许偏差。例如，在内部问答场景，我们设定 QDT 为 5%。这意味着，如果轻量模型（如 DeepSeek-V3）的任务成功率比主模型（如 Claude 4.8）低不超过 5 个百分点，且用户满意度评分无明显下降，则使用轻量模型。

质量指标的选取需要场景化：

对话类场景：关注任务成功率、用户满意度、平均对话轮次。

抽取类场景：关注字段级准确率、召回率。

生成类场景：关注内容可用性评分（人工抽检或 LLM-as-Judge）。

1.2 成本权重
成本权重是一个 0 到 1 之间的系数，表示该场景对成本的敏感度。权重为 0 表示完全质量优先（即使成本再高也要用主模型），权重为 1 表示完全成本优先（只要质量在可接受范围内就用最便宜的模型）。在业务中，我们按场景风险等级设定默认权重：

场景类型 成本权重 说明
核心交易链路 0.0 质量优先，不使用成本感知路由
客户服务对话 0.3 适度成本优化，但保证用户体验
内部问答 0.7 成本敏感，质量容忍度较高
草稿生成/头脑风暴 0.9 高度成本敏感，可用轻量模型
二、架构实现：成本感知路由的决策链路
成本感知路由不是独立的路由层，而是嵌入在网关的决策引擎中，与场景路由、质量路由协同工作。一次请求的完整决策流程如下：

场景识别：根据 Prompt 结构、用户标签等提取任务特征，匹配对应的路由规则集。

质量筛选：从候选模型池中排除当前质量不可用的模型（P99 延迟超限、错误率过高、熔断器打开）。

成本排序：对剩余候选模型，按预估成本（基于历史平均 Token 消耗和实时单价）降序排列。

质量-成本权衡：从最便宜的模型开始，检查其相对于主模型的质量偏差是否在 QDT 内。如果满足，则选择该模型；否则，检查下一个模型，直到找到满足条件的模型或回退到主模型。

执行与反馈：调用选中的模型，记录实际成本、延迟和任务完成状态，反馈到质量基线数据库中。

这个流程在毫秒级完成，核心计算逻辑在内存中执行，不依赖外部实时查询。

下面是成本感知路由的完整决策链路流程图：

2.1 Python伪代码示例：成本排序与质量-成本权衡

下面是一个简化的Python伪代码示例，展示了成本感知路由中成本排序与质量-成本权衡的核心逻辑：

class CostAwareRouter:
    def __init__(self, quality_threshold=0.05, cost_weight=0.7):
        """
        初始化成本感知路由器
        :param quality_threshold: 质量差异容忍阈值(QDT)，默认5%
        :param cost_weight: 成本权重，0-1之间，越高表示越关注成本
        """
        self.quality_threshold = quality_threshold
        self.cost_weight = cost_weight
        
    def select_model(self, candidate_models, primary_model_id="claude-4.8"):
        """
        从候选模型中选择最优模型
        :param candidate_models: 候选模型列表，每个元素包含id、质量评分、预估成本
        :param primary_model_id: 主模型ID，作为质量基准
        :return: 选中的模型ID
        """
        # 1. 质量筛选：排除质量不可用的模型
        available_models = [
            model for model in candidate_models 
            if model["quality_score"] > 0.7  # 质量评分阈值
        ]
        
        if not available_models:
            return primary_model_id  # 回退到主模型
            
        # 2. 找到主模型作为质量基准
        primary_model = next(
            (m for m in available_models if m["id"] == primary_model_id), 
            available_models[0]  # 如果找不到主模型，用第一个可用模型
        )
        
        # 3. 成本排序：按预估成本升序排列（最便宜的在前）
        sorted_models = sorted(
            available_models, 
            key=lambda x: x["estimated_cost"]
        )
        
        # 4. 质量-成本权衡：从最便宜的模型开始检查
        for model in sorted_models:
            # 计算质量差异（相对于主模型）
            quality_diff = primary_model["quality_score"] - model["quality_score"]
            
            # 计算质量可接受度：考虑质量差异和成本权重
            # 成本权重越高，对质量差异的容忍度越高
            acceptable_quality_diff = self.quality_threshold * (1 + self.cost_weight)
            
            # 如果质量差异在可接受范围内，选择该模型
            if quality_diff <= acceptable_quality_diff:
                return model["id"]
                
        # 5. 如果没有模型满足条件，回退到主模型
        return primary_model_id

# 使用示例
if __name__ == "__main__":
    # 候选模型数据示例
    candidate_models = [
        {"id": "deepseek-v3", "quality_score": 0.82, "estimated_cost": 0.1},
        {"id": "claude-4.8", "quality_score": 0.88, "estimated_cost": 0.3},
        {"id": "gpt-5.5", "quality_score": 0.85, "estimated_cost": 0.25},
        {"id": "gemini-3.5", "quality_score": 0.80, "estimated_cost": 0.15},
    ]
    
    # 创建路由器实例（内部问答场景，成本权重0.7）
    router = CostAwareRouter(quality_threshold=0.05, cost_weight=0.7)
    
    # 选择模型
    selected_model = router.select_model(candidate_models, "claude-4.8")
    print(f"选中的模型: {selected_model}")  # 输出: deepseek-v3

关键步骤说明：

1. 质量筛选：首先排除质量评分低于阈值的模型，确保基本可用性
2. 成本排序：按预估成本升序排列，优先考虑最便宜的模型
3. 质量-成本权衡：从最便宜的模型开始，检查其质量差异是否在可接受范围内
   • 质量差异容忍度 = QDT × (1 + 成本权重)
   • 成本权重越高，对质量差异的容忍度越高
4. 回退机制：如果没有模型满足条件，回退到主模型保证质量

这个算法的时间复杂度为O(n log n)，主要开销在排序步骤，适合实时路由决策。

三、实测数据：成本感知路由带来的真实降幅
我们以一个日均调用量约 20 万次的 SaaS 业务为例，上线成本感知路由前后的效果对比。

基线期（仅场景路由）：所有请求按场景分配到固定的主模型，无成本优化。
优化期（加入成本感知路由）：在 4 个低风险场景（内部问答、草稿生成、会议纪要、非关键内容摘要）启用了成本因子，QDT 设为 5%，成本权重 0.7-0.9。

场景 优化前主模型 优化后实际使用模型（占比） 优化后单次成本 成本降幅
内部问答 Claude 4.8 DeepSeek-V3 (78%), Claude 4.8 (22%) -65% 65%
草稿生成 GPT-5.5 DeepSeek-V3 (85%), GPT-5.5 (15%) -72% 72%
会议纪要 Claude 4.8 GPT-5.5 (60%), Claude 4.8 (40%) -40% 40%
非关键摘要 GPT-5.5 DeepSeek-V3 (90%), GPT-5.5 (10%) -78% 78%
全局效果：这 4 个场景的调用量占总量的约 35%，由于这些场景的成本大幅下降，全局月度 API 费用下降了约 28%。同时，通过持续监控任务完成率和用户反馈，这些场景的质量指标没有出现统计学上显著的下降。

四、关键设计权衡与避坑指南

1. QDT 与成本权重的动态调优
   不要一次性设定激进的阈值。建议从保守值开始（QDT 2-3%，成本权重 0.3-0.5），通过灰度放量收集质量数据，逐步放宽。每次调整后，必须持续监控至少一个完整的业务周期（通常一周），确认质量无显著变化后再进入下一轮调优。

2. 成本核算的精准性
   成本感知路由依赖实时的 Token 消耗预估。如果聚合平台的成本统计存在偏差（我们之前在 KULAAI 的对比测试中验证过，偏差 <1%），决策就会失真。必须确保使用的成本数据与厂商实际账单一致，避免“看起来省钱、月底账单打脸”。

3. 避免“成本震荡”
   当两个模型的成本接近时，微小的成本波动可能导致频繁切换模型。可以设置一个切换迟滞阈值（Hysteresis）：只有当备选模型的成本低于当前模型一定比例（如 10%）且持续一定时间（如 5 分钟）时，才触发切换。

4. 场景适配
   并非所有场景都适合成本感知路由。对于高合规、高风险的场景（如合同审查、金融交易、医疗建议），应强制关闭成本因子，始终使用质量最优的模型。

五、从零搭建成本感知路由的步骤
七、常见错误与排查

成本感知路由在生产环境中运行一段时间后，可能会遇到一些典型问题。以下是 3-4 类常见错误及其排查步骤和修复方案：

7.1 成本数据漂移

问题现象：

• 路由决策频繁选择“看似便宜”但实际成本更高的模型
• 月度账单与预估节省金额存在显著差异（>5%）
• 不同时间段的成本优化效果波动较大

排查步骤：

1. 数据源验证：检查成本数据源是否与厂商账单一致

   • 对比聚合平台统计的 Token 消耗与厂商控制台的实际消耗
   • 验证单价更新是否及时（模型降价、新定价策略）
   • 检查是否有隐藏成本（如上下文长度溢价、请求次数费用）

2. 统计口径检查：

   • 确认成本计算是否包含输入和输出 Token
   • 检查是否有特殊 Token（如图像 Token、函数调用 Token）未被正确计价
   • 验证成本预估算法是否考虑了批处理折扣、阶梯定价

3. 时间窗口分析：

   • 按小时/天分析成本数据的变化趋势
   • 识别是否存在周期性成本波动（如高峰时段价格上浮）
   • 检查成本数据同步延迟问题

修复方案：

• 建立成本数据校验流水线，每日自动对比平台统计与厂商账单
• 实现成本数据版本管理，记录每次单价变更的时间戳和影响范围
• 在路由决策中引入成本置信度因子，对近期无验证数据的模型给予较低权重
• 设置成本偏差告警阈值（如偏差 >3% 触发告警）

7.2 模型频繁切换

问题现象：

• 同一用户会话中，连续请求使用不同模型
• 路由日志显示模型切换频率异常高（如每分钟多次切换）
• 用户体验不一致，响应风格、能力边界频繁变化

排查步骤：

1. 切换触发分析：

   • 检查路由决策日志，识别切换触发条件
   • 分析成本波动是否在切换阈值附近震荡
   • 验证质量评分是否在边界值附近波动

2. 会话一致性检查：

   • 确认路由决策是否考虑了会话上下文
   • 检查是否有会话粘滞机制（session affinity）
   • 验证用户标识是否在切换决策中被正确使用

3. 迟滞机制评估：

   • 检查是否设置了切换迟滞阈值
   • 验证迟滞时间窗口是否合理
   • 分析切换频率与业务负载的相关性

修复方案：

• 引入会话级模型锁定：同一会话的后续请求优先使用首次选择的模型
• 优化切换迟滞算法：

  class HysteresisRouter(CostAwareRouter):
      def __init__(self, hysteresis_threshold=0.1, min_duration=300):
          """
          :param hysteresis_threshold: 切换迟滞阈值，成本差异需超过10%才考虑切换
          :param min_duration: 最小稳定时间（秒），当前模型需稳定运行5分钟才考虑切换
          """
          self.hysteresis_threshold = hysteresis_threshold
          self.min_duration = min_duration
          self.current_model = None
          self.switch_time = None
          
      def should_switch(self, candidate_cost, current_cost):
          # 成本差异需超过迟滞阈值
          cost_saving = (current_cost - candidate_cost) / current_cost
          if cost_saving < self.hysteresis_threshold:
              return False
              
          # 检查最小稳定时间
          if self.current_model and time.time() - self.switch_time < self.min_duration:
              return False
              
          return True
  

• 实现渐进式切换：新模型先承接少量流量（如 5%），稳定后再逐步增加

7.3 质量基线失效

问题现象：

• 路由选择低成本模型后，业务指标（转化率、满意度）明显下降
• A/B 测试显示实验组（成本优化）与对照组（质量优先）差异显著
• 用户投诉增多，反馈“AI 变笨了”

排查步骤：

1. 质量指标验证：

   • 检查质量评分数据源是否正常更新
   • 验证评分算法是否仍然适应当前业务场景
   • 分析是否存在评分偏差（如新模型缺乏足够样本）

2. 场景适配性评估：

   • 确认成本感知路由是否被错误应用到高风险场景
   • 检查场景识别规则是否准确
   • 分析质量下降是否集中在特定用户群体或时间段

3. 模型能力变化监测：

   • 监控各模型 API 的版本更新
   • 检查是否有模型服务降级或能力变更
   • 验证测试用例集是否覆盖了核心业务场景

修复方案：

• 建立质量监控熔断机制：

  quality_circuit_breaker:
    enabled: true
    metrics:
      - task_success_rate  # 任务成功率
      - user_satisfaction  # 用户满意度
      - avg_conversation_turns  # 平均对话轮次
    thresholds:
      task_success_rate: 0.85  # 低于85%触发告警
      degradation_rate: 0.05    # 单日下降超过5%触发熔断
    actions:
      - level: warning  # 警告级别
        condition: "task_success_rate < 0.85 for 1h"
        action: "发送告警，人工介入检查"
      - level: critical  # 严重级别
        condition: "task_success_rate < 0.80 for 30min"
        action: "自动关闭成本感知路由，回退到质量优先模式"
  

• 实施动态 QDT 调整：根据实时质量反馈自动收紧或放宽质量容忍度
• 建立模型能力基线库：定期用标准测试集评估各模型能力，及时发现模型退化

7.4 配置错误与运维问题

问题现象：

• 路由规则不生效或生效范围错误
• 配置更新后出现预期外的路由行为
• 监控数据缺失或延迟严重

排查步骤：

1. 配置验证：

   • 检查路由规则语法和格式
   • 验证配置热加载是否正常
   • 确认环境变量和配置文件优先级

2. 依赖服务检查：

   • 验证成本数据服务、质量评分服务的可用性
   • 检查监控数据采集链路是否完整
   • 确认告警通道是否正常

3. 权限与配额：

   • 检查各模型 API 密钥的配额和权限
   • 验证聚合平台账户状态
   • 确认计费账户余额充足

修复方案：

• 建立配置变更预检流程：
  1. 语法检查（YAML/JSON 格式验证）
  2. 语义检查（规则冲突检测）
  3. 沙箱测试（在测试环境验证路由效果）
  4. 灰度发布（先对 1% 流量生效）
  5. 全量发布（监控关键指标 24 小时）
• 实现配置版本管理与回滚能力
• 建立运维检查清单，包含：
  • 每日：成本数据同步状态、质量评分更新情况
  • 每周：路由规则有效性验证、模型能力基线更新
  • 每月：成本节省效果分析、质量指标趋势分析

快速诊断流程图：

通过系统化的排查步骤和修复方案，可以快速定位并解决成本感知路由在生产环境中的常见问题，确保路由系统在优化成本的同时，持续保障服务质量。

建立成本-质量基线：在 KULAAI 等平台上，对每个业务场景，用多个候选模型跑测试集，记录准确率、延迟、Token 消耗，形成“场景-模型”性价比矩阵。

设定初始策略：选择 2-3 个低风险场景，设定保守的 QDT 和成本权重，在路由引擎中配置规则。

灰度验证：先对内部流量启用成本感知路由，运行 1-2 周，密切监控质量指标和成本变化。

逐步放量：验证有效后，逐步扩展到外部流量，并根据数据反馈调整阈值。

持续监控与迭代：建立场景级成本和质量监控面板，按周追踪，当成本或质量偏离基线时触发告警。

写在最后
成本感知路由是多模型架构从“可用”走向“好用”的关键一步。它让成本优化从“凭感觉切换模型”升级为“数据驱动的自动化决策”。对于日均调用量达到十万级以上的团队，成本感知路由带来的月度成本节省往往超过所有静态优化手段的总和。

在 KULAAI 上完成多模型性价比基线后，从低风险场景起步，逐步引入成本因子，再用数据反馈持续调优。这套机制一旦建成，每一次模型降价、每一个新模型发布，都会自动转化为你的成本优势。成本感知路由不是一次性的架构升级，而是一个持续优化、不断逼近最优性价比的工程实践。

六、实战部署：Docker 与配置示例

6.1 Dockerfile 示例

以下是一个完整的 Dockerfile 示例，用于部署包含成本感知路由逻辑的微服务：

# 使用 Python 3.11 作为基础镜像
FROM python:3.11-slim

# 设置工作目录
WORKDIR /app

# 安装系统依赖
RUN apt-get update && apt-get install -y \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# 复制依赖文件并安装 Python 包
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 复制应用代码
COPY . .

# 创建非 root 用户
RUN useradd -m -u 1000 appuser && chown -R appuser:appuser /app
USER appuser

# 暴露端口
EXPOSE 8080

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
    CMD curl -f http://localhost:8080/health || exit 1

# 启动应用
CMD ["gunicorn", "--bind", "0.0.0.0:8080", "--workers", "4", "--threads", "2", "--timeout", "120", "app.main:app"]

requirements.txt 示例：

fastapi==0.104.1
uvicorn[standard]==0.24.0
gunicorn==21.2.0
pydantic==2.5.0
redis==5.0.1
prometheus-client==0.19.0
openai==1.3.0
anthropic==0.8.0
google-generativeai==0.3.0

6.2 配置文件示例（YAML 格式）

以下是一个完整的 YAML 配置文件示例，展示如何定义不同场景的 QDT、成本权重和候选模型池：

# config/routing_config.yaml
version: "1.0"
last_updated: "2024-01-15T10:00:00Z"

# 全局配置
global:
  fallback_model: "claude-3-5-sonnet-20241022"
  quality_metrics_update_interval: 300  # 秒
  cost_calculation_window: 3600  # 秒，成本计算时间窗口

# 场景定义
scenarios:
  # 核心交易链路 - 质量优先
  core_transaction:
    description: "核心交易链路，对准确性要求极高"
    qdt: 0.01  # 质量差异容忍阈值 1%
    cost_weight: 0.0  # 完全质量优先
    candidate_models:
      - model_id: "claude-3-5-sonnet-20241022"
        provider: "anthropic"
        max_tokens: 4096
        priority: 1
      - model_id: "gpt-4-turbo-preview"
        provider: "openai"
        max_tokens: 4096
        priority: 2
    quality_metrics:
      - name: "task_success_rate"
        threshold: 0.99
        weight: 0.6
      - name: "response_accuracy"
        threshold: 0.98
        weight: 0.4

  # 客户服务对话 - 平衡质量与成本
  customer_service:
    description: "客户服务对话，需要良好体验但可适度优化成本"
    qdt: 0.05  # 质量差异容忍阈值 5%
    cost_weight: 0.3  # 适度成本优化
    candidate_models:
      - model_id: "claude-3-haiku-20240307"
        provider: "anthropic"
        max_tokens: 2048
        priority: 1
      - model_id: "gpt-3.5-turbo"
        provider: "openai"
        max_tokens: 2048
        priority: 2
      - model_id: "gemini-1.5-pro"
        provider: "google"
        max_tokens: 2048
        priority: 3
    quality_metrics:
      - name: "user_satisfaction_score"
        threshold: 4.0  # 1-5分制
        weight: 0.5
      - name: "conversation_turns"
        threshold: 3.0  # 平均对话轮次
        weight: 0.3
      - name: "resolution_rate"
        threshold: 0.85
        weight: 0.2

  # 内部问答 - 成本敏感
  internal_qa:
    description: "内部知识问答，成本敏感，质量容忍度较高"
    qdt: 0.10  # 质量差异容忍阈值 10%
    cost_weight: 0.7  # 高度成本敏感
    candidate_models:
      - model_id: "deepseek-chat"
        provider: "deepseek"
        max_tokens: 4096
        priority: 1
      - model_id: "claude-3-haiku-20240307"
        provider: "anthropic"
        max_tokens: 2048
        priority: 2
      - model_id: "gpt-3.5-turbo"
        provider: "openai"
        max_tokens: 2048
        priority: 3
    quality_metrics:
      - name: "answer_relevance"
        threshold: 0.85
        weight: 0.6
      - name: "information_completeness"
        threshold: 0.80
        weight: 0.4

  # 草稿生成 - 高度成本敏感
  draft_generation:
    description: "草稿生成和头脑风暴，高度成本敏感"
    qdt: 0.15  # 质量差异容忍阈值 15%
    cost_weight: 0.9  # 几乎完全成本优先
    candidate_models:
      - model_id: "deepseek-chat"
        provider: "deepseek"
        max_tokens: 8192
        priority: 1
      - model_id: "claude-3-haiku-20240307"
        provider: "anthropic"
        max_tokens: 4096
        priority: 2
      - model_id: "gpt-3.5-turbo"
        provider: "openai"
        max_tokens: 4096
        priority: 3
    quality_metrics:
      - name: "content_creativity"
        threshold: 3.5  # 1-5分制
        weight: 0.4
      - name: "content_coherence"
        threshold: 3.0  # 1-5分制
        weight: 0.3
      - name: "idea_quantity"
        threshold: 5  # 平均想法数量
        weight: 0.3

# 模型定价配置（单位：美元/百万Token）
model_pricing:
  openai:
    gpt-4-turbo-preview:
      input: 10.00
      output: 30.00
    gpt-3.5-turbo:
      input: 0.50
      output: 1.50
  
  anthropic:
    claude-3-5-sonnet-20241022:
      input: 3.00
      output: 15.00
    claude-3-haiku-20240307:
      input: 0.25
      output: 1.25
  
  google:
    gemini-1.5-pro:
      input: 1.25
      output: 5.00
  
  deepseek:
    deepseek-chat:
      input: 0.14
      output: 0.28

# 监控与告警配置
monitoring:
  metrics:
    - name: "routing_decision_latency"
      threshold_ms: 50
      alert_level: "warning"
    - name: "cost_savings_percentage"
      target_min: 15.0  # 目标节省15%以上
      alert_level: "info"
    - name: "quality_violation_rate"
      threshold: 0.02  # 质量违规率不超过2%
      alert_level: "critical"
  
  alerts:
    - condition: "quality_violation_rate > 0.05"
      action: "disable_cost_aware_routing"
      notification_channels: ["slack", "email"]
    - condition: "routing_decision_latency > 100"
      action: "switch_to_fallback_logic"
      notification_channels: ["slack"]

6.3 部署说明

1. 目录结构：

/app
├── Dockerfile
├── requirements.txt
├── config/
│   └── routing_config.yaml
├── app/
│   ├── main.py
│   ├── routing/
│   │   ├── cost_aware_router.py
│   │   └── decision_engine.py
│   └── models/
│       └── config_loader.py
└── docker-compose.yml

2. docker-compose.yml 示例：

version: '3.8'
services:
  cost-aware-router:
    build: .
    ports:
      - "8080:8080"
    environment:
      - CONFIG_PATH=/app/config/routing_config.yaml
      - REDIS_URL=redis://redis:6379/0
      - LOG_LEVEL=INFO
    depends_on:
      - redis
    volumes:
      - ./config:/app/config:ro
      - ./logs:/app/logs
  
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
    command: redis-server --appendonly yes

volumes:
  redis-data:

3. 环境变量配置：

# .env 文件
CONFIG_PATH=/app/config/routing_config.yaml
REDIS_URL=redis://localhost:6379/0
LOG_LEVEL=INFO
METRICS_PORT=9090
HEALTH_CHECK_INTERVAL=30

6.4 关键特性

1. 多环境支持：通过环境变量切换配置，支持开发、测试、生产环境
2. 健康检查：内置健康检查端点，确保服务可用性
3. 监控集成：集成 Prometheus 指标，实时监控路由决策质量
4. 配置热重载：支持配置文件热更新，无需重启服务
5. 成本可视化：提供成本节省统计和可视化面板

6.5 部署验证

部署完成后，可以通过以下命令验证服务状态：

# 构建镜像
docker build -t cost-aware-router:latest .

# 启动服务
docker-compose up -d

# 检查服务健康状态
curl http://localhost:8080/health

# 查看路由配置
curl http://localhost:8080/api/v1/config

# 测试路由决策
curl -X POST http://localhost:8080/api/v1/route \
  -H "Content-Type: application/json" \
  -d '{
    "scenario": "internal_qa",
    "prompt": "什么是成本感知路由？",
    "user_id": "user_123"
  }'

此部署方案提供了完整的生产就绪环境，包含配置管理、监控告警和容器化部署，可直接用于实际生产环境。