每个模型一条冒烟测试：一个脚本确认所有端点与模型仍然能答

为什么需要模型级冒烟测试

聚合站的核心价值在于用一个 API key 调多个模型。一旦某个模型的路由、上游密钥或计费逻辑出问题，用户请求就会失败。与其等用户反馈，不如自己每隔几分钟主动探测一遍所有「端点 × 模型」组合。

冒烟测试不问“回答得对不对”，只问“还能不能答”。一个固定、极简的提示词就够——目的是确认链路通畅，而不是评测模型质量。

测试设计原则

• 组合全覆盖：列出所有对外暴露的端点（如 /v1/chat/completions、/v1/embeddings 等），再与支持的模型列表做笛卡尔积。缺少任一组合，就等于留下一个监控盲区。
• 最小请求：用最短的提示词，例如 ping 或一个固定短句，把 token 消耗压到最低。
• 固定期望：不要求特定内容，只要求 HTTP 200 且响应体包含一个非空的文本字段。
• 独立超时：每个组合单独设置超时（如 10~15 秒），避免一个慢模型拖垮整轮检查。
• 并发控制：组合数量可能上百，但不要一次性全打出去。限制并发数（如 5~10），既快又不给上游造成瞬时压力。

脚本核心结构

用伪代码描述整体流程，方便迁移到任意语言：

读取模型清单和端点清单
生成所有 (endpoint, model) 组合
对每个组合：
    发送最小请求
    记录状态码、耗时、错误信息
    如果状态码非 200 或响应体为空 → 标记为失败
汇总结果，输出成功/失败列表
如有失败项 → 触发告警

关键点：

• 模型清单要动态获取：如果聚合站提供模型列表接口，优先从接口读取，避免硬编码导致新增模型漏测。如果只能硬编码，就在文档里注明需要同步更新。
• 区分错误类型：超时、401/403、429、5xx 等要分别记录。超时可能是上游慢，429 是限流，401/403 可能是密钥失效——不同错误对应不同的排查方向。
• 记录耗时：即便返回成功，耗时突然翻倍也值得关注，可能预示上游拥塞。

结果处理与告警

冒烟测试的价值在于“发现即通知”。

• 只对失败告警：成功是常态，不需要打扰。
• 聚合告警：如果同一轮里有多个失败，合并成一条消息发出，避免告警风暴。
• 包含关键信息：告警内容应包含失败的组合、状态码、错误摘要和时间戳，方便直接定位。
• 抑制重复：连续多轮失败时，不要每轮都发。可以设置“状态变化时才告警”，例如从成功变失败时发一次，恢复时再发一次。

定时调度

调度方式取决于运行环境：

• 系统 cron：最简单，适合单机。注意设置合理的执行间隔，避免上一轮未结束下一轮就启动。
• 容器化调度：把脚本打包成镜像，用 Kubernetes CronJob 或类似机制运行，便于水平扩展和日志收集。
• 外部监控服务：如果不想自己维护调度，可以用通用的定时任务服务来触发。

无论哪种方式，都要确保上一轮未完成时跳过下一轮，可以用锁文件或分布式锁实现。

维护与迭代

冒烟测试不是一次写完就结束：

• 模型上下线时更新清单：新增模型要加入测试，下线模型要移除，否则会持续误报。
• 端点变更时同步：如果新增了 API 端点，记得加入组合。
• 定期回顾失败历史：如果某个模型频繁失败，要么是上游不稳定，要么是测试方式需要调整（例如超时太短）。
• 结合真实用户请求：冒烟测试只能覆盖“能不能答”，真实业务还需要看错误率、延迟分布等指标，两者互补。

小结

一个简单的定时脚本，遍历所有端点与模型的组合，用最小请求确认它们仍然能答，就能让你在用户之前发现路由问题。重点在于：组合要全、请求要小、告警要准、调度要稳。随着模型和端点增加，这套机制会成为聚合站可用性的第一道防线。