AI 服务错误归因推理失败到底该怪模型还是基础设施一、背景与问题AI 推理服务的错误分类是一个被低估的问题。一次推理请求返回 500错误日志可能写着 inference failed。但这个 failed 的含义太宽了可能是 GPU OOM基础设施问题可能是模型加载失败基础设施模型问题可能是输入 token 超限业务逻辑问题可能是外部 API 超时依赖服务问题也可能是模型输出格式异常模型质量问题。不区分错误类型后果很直接错误率 1% 时你只知道有 1% 的请求失败了不知道该给谁提 bug。GPU 团队说GPU 正常模型团队说模型没问题基础设施团队说服务没宕机然后问题没人修。错误归因的目标不是找到谁的责任那是管理问题是建立错误类型和故障域的映射关系让每次错误能快速定位到对应的排查路径。GPU OOM 去 GPU 指标面板看内存曲线模型输出异常去模型质量指标看输出分布外部 API 超时去依赖服务追踪看调用链路。归因就是建立这个映射。二、错误分类体系flowchart TD A[推理请求错误] -- B{错误根因分类} B -- C[基础设施层] B -- D[模型层] B -- E[业务逻辑层] B -- F[依赖服务层] C -- C1[GPU OOM] C -- C2[节点不可达] C -- C3[磁盘 IO 错误] C -- C4[K8s 资源驱逐] D -- D1[模型加载失败] D -- D2[输出格式异常] D -- D3[推理超时-模型侧] D -- D4[量化精度丢失] E -- E1[输入超限] E -- E2[参数校验失败] E -- E3[权限拒绝] F -- F1[外部 API 超时] F -- F2[向量库不可达] F -- F3[缓存服务故障] style C fill:#b71c1c,color:#fff style D fill:#880e4f,color:#fff style E fill:#4a148c,color:#fff style F fill:#311b92,color:#fff四层错误分类每层对应不同的排查路径和修复团队错误层级排查路径修复团队恢复策略基础设施GPU/节点/存储指标面板基础设施/SRE自动重启/扩容模型模型质量指标/输出分布模型/算法降级备用模型业务逻辑请求日志/参数校验业务开发返回错误码依赖服务依赖追踪/外部服务指标外部服务负责人重试/熔断三、实现方案3.1 错误码标准化推理服务的错误码必须区分层级。不要用一个INTERNAL_ERROR涵盖所有场景// 错误码定义层级前缀 具体错误 const ( // 基础设施层 INF_ ErrGPUOOM INF_GPU_OOM ErrNodeUnreachable INF_NODE_UNREACHABLE ErrDiskIO INF_DISK_IO_ERROR // 模型层 MOD_ ErrModelLoad MOD_LOAD_FAILED ErrOutputFormat MOD_OUTPUT_FORMAT_ERROR ErrInferenceTimeout MOD_INFERENCE_TIMEOUT // 业务逻辑层 BIZ_ ErrInputTooLong BIZ_INPUT_TOKEN_LIMIT ErrParamInvalid BIZ_PARAM_INVALID // 依赖服务层 DEP_ ErrExternalAPI DEP_EXTERNAL_API_TIMEOUT ErrVectorDB DEP_VECTOR_DB_UNREACHABLE ) func handleError(ctx context.Context, err error) { span : trace.SpanFromContext(ctx) // 从错误码提取层级 code : extractErrorCode(err) layer : code[:3] // INF, MOD, BIZ, DEP span.SetAttribute(error.code, code) span.SetAttribute(error.layer, layer) span.SetStatus(codes.Error, err.Error()) }error.layer属性是关键。它让 Prometheus 可以按层级聚合错误率# 各层错误率 sum(rate(inference_request_total{statuserror}[5m])) by (error_layer) # 基础设施层错误占比 sum(rate(inference_request_total{statuserror, error_layerINF}[5m])) / sum(rate(inference_request_total{statuserror}[5m]))当基础设施层错误占比从 10% 涨到 60%排查方向立刻转向 GPU 和节点指标不再在模型代码里浪费时间。3.2 自动归因逻辑某些错误类型可以根据上下文自动归因不需要人工判断func autoAttribute(ctx context.Context, err error) string { // GPU OOM检查 GPU 内存指标 if strings.Contains(err.Error(), CUDA out of memory) { return INF_GPU_OOM } // 模型加载失败检查模型文件是否存在 if strings.Contains(err.Error(), model not found) { if !modelExistsOnDisk() { return INF_DISK_IO_ERROR // 文件缺失→存储问题 } return MOD_LOAD_FAILED // 文件存在但加载失败→模型问题 } // 推理超时区分模型侧和基础设施侧 if strings.Contains(err.Error(), timeout) { gpuUtil : getGPUUtilization() if gpuUtil 90 { return INF_GPU_OVERLOAD // GPU 满载→基础设施侧 } return MOD_INFERENCE_TIMEOUT // GPU 未满载→模型侧 } // 默认未归因 return UNATTRIBUTED }推理超时的归因逻辑值得说明GPU 利用率 90% 时超时是因为 GPU 资源不足基础设施问题GPU 利用率正常但仍然超时是因为模型计算本身慢模型问题。这个区分直接影响修复策略——前者扩容 GPU 节点后者优化模型或降低 batch size。3.3 未归因错误的处理自动归因不可能覆盖所有场景。UNATTRIBUTED类错误必须人工分析并补充归因规则。流程每周统计未归因错误的数量和错误消息分布。对于出现频率 5次/周的未归因错误编写新的归因规则并加入autoAttribute。未归因错误的占比应控制在 10%。超过 10% 说明归因体系覆盖不全需要补充规则。四、告警与故障响应4.1 分层告警规则不同层级的错误对应不同的告警级别和响应流程错误层级告警级别响应时间响应动作基础设施 (INF)P15 分钟自动扩容人工确认模型 (MOD)P215 分钟降级备用模型人工排查依赖服务 (DEP)P215 分钟熔断降级通知外部团队业务逻辑 (BIZ)P3不告警日志记录用户提示基础设施层 P1 是因为 GPU OOM 或节点不可达会导致整个推理服务不可用影响面最大。业务逻辑层不告警是因为输入校验错误是正常业务行为不是故障。4.2 错误率趋势与容量规划按层级统计错误率趋势直接关联容量规划# 基础设施层错误率趋势用于GPU容量规划 sum(rate(inference_request_total{statuserror, error_layerINF}[1d])) # 模型层错误率趋势用于模型质量评估 sum(rate(inference_request_total{statuserror, error_layerMOD}[1d]))基础设施层错误率持续上升→GPU 容量不足需要扩容。模型层错误率持续上升→模型质量下降需要重新训练或更换模型版本。两个趋势对应完全不同的资源投入方向混在一起看就无法做决策。4.3 踩坑记录错误消息的格式不统一。不同推理框架的错误消息格式不同vLLM 和 TGI 的 OOM 消息文本不同自动归因的字符串匹配需要覆盖多种格式。建议维护一个错误消息 → 错误码的映射表定期更新。跨层级的复合错误。一个请求可能同时遇到GPU 内存不足和输入超限——输入太长导致 GPU OOM。这种复合错误的归因优先级基础设施层优先。因为 GPU OOM 是直接导致服务不可用的原因输入超限是间接诱因。在 Span 上标注两个错误码但error.layer只取优先级最高的那个。错误归因不能替代根因分析。归因把错误分类到正确的排查路径但不告诉你具体的根因。GPU OOM 的归因指向基础设施层但根因可能是输入 batch_size 设置太大、可能是模型参数加载了双份、也可能是其他服务占用了 GPU 内存。归因是第一步根因分析是第二步两者不能混淆。五、总结推理服务的错误归因不是追责是建立错误类型和排查路径的映射。没有归因每次错误都是推理失败排查方向模糊有了归因GPU OOM 直奔 GPU 指标面板模型异常直奔模型质量面板响应效率提升数倍。三个关键实践错误码按层级前缀区分INF基础设施、MOD模型、BIZ业务、DEP依赖error.layer属性让 Prometheus 按层级聚合。自动归因覆盖高频场景GPU OOM、模型加载失败、推理超时根据上下文条件自动判断层级。未归因错误持续补充规则占比 10% 说明覆盖不全每周补充高频未归因错误的归因规则。基础设施不需要漂亮话。错误归因的目标不是把推理失败变成更详细的错误描述是把每个错误指向正确的排查路径。指向对了30 分钟解决问题指向错了30 分钟还在争论该谁查。