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

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

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

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

第一步：在请求体中显式添加 【"concurrency_limit": 3】 字段，强制将并发数压至平台默认安全阈值（多数环境为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握手存在模型专属证书链问题。

【注意：不要复用同一curl命令反复测试不同模型，务必清空DNS缓存（systemd-resolve --flush-caches）后再测下一个】

检查模型间上下文污染

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。