Atoms多模型同时调用返回异常排查步骤

Atoms平台多模型调用异常需分四步定位：先压并发至3确认限流降级，再直连各模型排除网络层问题，接着校验session_id唯一性及模型名大小写防上下文污染，最后通过X-Atoms-Subcall-Duration和stream调试区分三类超时。

Atoms平台支持多模型并行调用，但当返回异常（如部分模型无响应、混合状态码、空响应体、字段缺失或超时混杂）时，不能简单归因为“某个模型挂了”，必须按调用链路逐层剥离干扰项。

确认是否为并发触发的限流叠加效应

Atoms对单次请求的并发模型数有硬性限制，超出后不返回429，而是静默降级部分子请求——这是最常被忽略的“假成功”场景。

第一步：在请求体中显式添加

字段，强制将并发数压至平台默认安全阈值（多数环境为3），重发相同请求。

第二步：对比两次响应中的 response_metadata 字段，检查 failed_models 数组是否从空变为含模型名；若出现 qwen-plus 和 glm-4 同时标记为“timeout_in_subcall”，说明是并发超限导致子通道被内核丢弃，而非网络或模型本身故障。

第三步：若降低并发后异常消失，需在客户端侧增加信号量控制，禁止未经节流的 burst 请求。

分离网络层与模型层错误

多模型调用共用同一HTTP连接池和DNS解析结果，一个模型的TCP连接失败可能拖垮整批请求。

方法一：用 curl 分别直连各模型 endpoint（绕过Atoms网关）

curl -X POST https://api.atoms.ai/v1/chat/qwen-plus -H "Authorization: Bearer sk-xxx" -d '{"messages":[{"role":"user","content":"hi"}]}' -m 15

方法二：抓包验证首包抵达时间

执行tcpdump -i any host api.atoms.ai -w atoms.pcap命令，触发一次多模型调用，接着用Wireshark打开，筛选http.request.uri contains "qwen"，观察qwen-plus与claude-3-haiku的SYN→SYN-ACK时间差是否超过800ms——若差值＞500ms，那就意味着DNS缓存未命中，或者TLS握手存在模型专属证书链问题。

检查模型间上下文污染

Atoms在多模型调度时若复用同一 session_id，且某模型返回结构异常（如未闭合JSON、插入注释字符串），会导致后续模型解析前置响应失败，表现为“第二个模型返回400 but message is empty”。

第一步：在每次多模型请求中强制传入唯一 session_id，格式为 atoms-{timestamp}-{uuid4}。

第二步：检查请求体中所有 models 字段是否全部使用全小写模型标识符（如 "qwen-plus" 而非 "Qwen-Plus"）——Atoms路由层对模型名大小写敏感，混用将导致部分模型被跳过调度，却仍计入并发计数。

第三步：禁用所有 RAG 插件与工具调用（设置 tools: []），仅保留基础 messages 字段，排除外部服务注入非法字符的可能性。

定位超时类型归属

多模型调用中，超时可能发生在三个不同阶段：网关聚合超时、单模型推理超时、子响应反序列化超时。它们对应完全不同的修复路径。

方法1：查看响应头 X-Atoms-Subcall-Duration

该字段以逗号分隔各子调用耗时，例如 "qwen-plus=2841,glm-4=1973,claude-3-haiku=-1" 表示前两个模型返回正常，第三个未完成。若数值全部＞25000，则是网关聚合超时；若仅 claude-3-haiku 显示 -1 且其他均＜5000，说明该模型服务端卡死。

方法2：启用流式响应调试

在请求参数里添加stream: true，并监听event: chunk数据流。当收到qwen-plus的data: {...}后，如果长时间没有新事件，而HTTP连接仍保持打开状态，这意味着claude-3-haiku在生成首token阶段被阻塞了，此时需要切换到低延迟节点或者降低max_tokens的值。