企业官网建设流程全解析

1. 这不是理论课，是AI应用架构师的“现场施工图”

“AI系统架构设计实战：AI应用架构师的深度指南”——这个标题里没有一个字在讲概念、模型或论文，它直指一个正在快速成型的职业现场：AI应用架构师。我从2018年开始带团队落地工业质检、金融风控、医疗影像辅助诊断三类AI项目，前五年几乎全是“模型能跑通就行”，后三年却越来越频繁地被业务方拉着问：“这个系统上线后，每天能扛住多少并发？模型更新时要不要停服务？新旧版本怎么灰度？日志里报的‘CUDA out of memory’到底是GPU没配够，还是推理服务没做资源隔离？”——这些问题，模型工程师答不了，运维工程师看不懂，而答案，就藏在这份“实战”二字里。

所谓“AI系统架构”，不是把PyTorch模型丢进Docker再挂个Nginx就完事。它是数据流、计算流、控制流、状态流四条主线在真实生产环境中的物理编排。比如一个推荐系统，用户点击行为实时进Kafka，经Flink做特征实时拼接，写入Redis供在线服务低延迟读取；同时离线任务每天跑一次Spark生成用户长期兴趣向量，存入HBase；线上服务调用时，既要查Redis里的秒级特征，又要查HBase里的天级特征，还要在毫秒内完成多路召回+精排打分+业务规则过滤——这中间任何一环卡顿、超时、数据不一致，都会直接导致CTR下降0.3%。而这些，全靠架构设计兜底。

这篇指南不讲Transformer原理，不推导损失函数，只讲你拿到一个需求文档后，第一张草图该画什么、第二步该压测哪几个接口、第三天该和DBA确认哪些索引、第四周该给测试团队提供什么Mock方案。它面向三类人：刚从算法岗转岗想补工程能力的工程师、带AI团队但常被线上事故反向教育的技术负责人、以及正准备考“AI应用架构师”认证（如AWS Certified Machine Learning – Specialty或Google Cloud Professional Machine Learning Engineer）的备考者。全文所有方案，均来自我亲手交付的7个千万级DAU项目、踩过的43次P0事故现场记录，以及和12家头部云厂商架构师闭门对齐的落地共识。

2. 架构设计的核心逻辑：从“模型交付”到“能力交付”的范式迁移

2.1 为什么传统软件架构思维在AI系统里会失效？

很多资深后端工程师第一次接手AI项目时，会本能地套用微服务那一套：API网关→业务服务→数据服务→缓存→数据库。但很快就会发现，这套逻辑在AI场景下处处碰壁。举个典型例子：某电商搜索排序服务，按传统思路，把召回、粗排、精排拆成三个独立服务，通过gRPC链式调用。结果上线后TP99从80ms飙到1200ms，监控显示90%耗时卡在精排服务的GPU显存分配上。问题出在哪？——传统架构假设“计算是轻量、可并行、无状态”的，而AI推理恰恰相反：计算重、有显存上下文依赖、状态敏感（如Batch Size变化直接影响显存占用）。

我画过一张对比图，左边是标准微服务调用链，右边是AI推理的真实执行路径：

这张表不是理论推导，而是我们连续三个月监控23台A10服务器后，从Prometheus抓取的故障根因统计。你会发现，AI系统的“健康”定义必须重构：CPU使用率低于30%不代表健康，GPU显存占用率95%且持续10分钟才真正危险；HTTP 500错误率0.1%可能只是网络抖动，但GPU OOM错误率0.01%就足以触发熔断。

所以，AI应用架构设计的第一步，不是画UML图，而是定义“AI健康基线”：明确你的系统里，哪些指标是“黄金信号”（Golden Signals），它们的阈值是多少，谁来负责盯这些指标。比如在我们的OCR票据识别系统中，黄金信号是：gpu_memory_used_percent > 92% for 5m+inference_latency_p99 > 800ms，这两个条件同时满足时，自动触发告警并降级到CPU推理备用通道。

2.2 四层架构模型：为什么必须放弃“单体AI服务”幻想？

市面上很多AI平台宣传“一键部署模型”，背后隐藏着一个危险假设：所有AI能力都能封装成一个黑盒API。现实是，一个生产级AI能力，必然由四个物理隔离、职责分明的层构成，缺一不可：

• 接入层（Ingress Layer）：处理协议转换、流量调度、安全校验。关键点在于：它必须理解AI请求的语义结构。比如图像识别API，不能只做HTTP转发，要能解析multipart/form-data里的图片尺寸、格式、EXIF信息，并根据这些元数据决定路由到哪个GPU集群（小图走T4，大图走A10）。

• 编排层（Orchestration Layer）：这是AI架构的“大脑”。它不直接执行模型，而是协调数据预处理、模型加载、后处理、结果聚合。我们用自研的FlowEngine替代了Airflow（后者太重，调度粒度到分钟级），核心是支持亚秒级动态编排：当检测到某路视频流帧率突增，自动插入帧抽样节点；当某类文本长度超限，自动切片并行处理再合并。

• 执行层（Execution Layer）：真正的模型运行单元。这里的关键认知是：同一模型在不同硬件上需要完全不同的部署形态。我们在A10集群上用Triton Inference Server做多模型共享GPU，在边缘设备（Jetson Orin）上用TensorRT优化后的单模型引擎，在CPU-only环境用ONNX Runtime量化版。三者API完全一致，但底层实现天差地别——这正是编排层的价值。

• 治理层（Governance Layer）：最容易被忽视，却是保障长期可用的核心。包括：模型版本灰度发布（基于请求Header里的canary=1）、A/B测试分流（按用户ID哈希）、数据漂移检测（用KS检验对比线上输入分布与训练集分布）、模型性能衰减预警（当p99延迟连续3小时上升5%即告警）。我们曾因忽略这一层，导致一个推荐模型上线两周后CTR下降12%，回溯发现是新接入的用户画像数据源引入了噪声特征，而治理层没配置漂移检测。

这四层不是抽象概念，而是我们每个项目都强制落地的物理隔离。比如在某银行反欺诈系统中，接入层用Kong网关，编排层是Go写的轻量引擎（<5k LOC），执行层分三组：GPU集群跑XGBoost+DeepFM融合模型，CPU集群跑规则引擎，FPGA集群跑实时图计算。治理层则独立部署，所有指标上报到统一的Grafana看板，告警直接对接运维值班系统。

2.3 成本视角：为什么说“GPU利用率”是最具欺骗性的指标？

几乎所有AI项目初期都会陷入一个误区：盯着nvidia-smi里GPU Util 95%欢呼雀跃，以为资源用足了。实测下来，这是最大的成本陷阱。我们做过一组对照实验：同一套BERT文本分类服务，在相同QPS下，分别用三种方式部署：

1. 单模型单GPU：每卡只跑一个模型实例，GPU Util 85%，推理延迟p99=120ms
2. 多模型共享GPU（Triton）：单卡并发跑3个模型，GPU Util 92%，推理延迟p99=180ms
3. 动态批处理（Dynamic Batching）：Triton开启auto-batching，GPU Util 96%，推理延迟p99=210ms

表面看方案3最“高效”，但算总成本：方案1需12张A10，方案2需8张，方案3需6张。然而方案3的p99延迟超标（业务要求≤150ms），导致大量请求超时重试，实际有效QPS反而比方案2低18%。最终选择方案2，因为在满足SLA前提下，GPU Util 92%已是性价比拐点。

更深层的成本陷阱在存储。AI系统里，模型权重文件动辄GB级，每次更新都要全量下发。我们曾有个视觉模型，权重3.2GB，用rsync同步到20台GPU服务器，平均耗时4分32秒，期间服务不可用。后来改用分层加载策略：基础框架（PyTorch/Triton）预装，模型权重拆分为backbone.bin（2.1GB）、head.bin（0.8GB）、config.json（12KB）三部分，其中config.json和head.bin热更新（秒级），backbone.bin只在重大升级时全量更新。配合CDN分发，热更新平均耗时1.7秒，业务无感。

所以，AI架构师的第一成本意识，不是“买多少卡”，而是定义每个组件的“成本敏感维度”：对GPU集群，敏感维度是“满足SLA下的最小卡数”；对存储，是“模型更新RTO（恢复时间目标）”；对网络，是“跨AZ调用的带宽成本”。这些必须在架构设计初期就量化，写进技术方案评审Checklist。

3. 核心细节解析：从需求文档到第一版架构图的七步法

3.1 第一步：需求解构——把“智能”翻译成可测量的工程指标

客户说：“我们要一个智能客服，能理解用户情绪，给出贴心回复。” 这句话里藏着至少五个待澄清的工程变量：

• “理解情绪”的精度要求：是二分类（积极/消极）还是细粒度（愤怒/焦虑/失望/惊喜）？业务能接受的F1-score下限是多少？（我们约定：F1≥0.85，否则影响满意度评分）
• “贴心回复”的响应机制：是纯检索式（从知识库匹配）还是生成式（LLM输出）？生成式的话，最大token数限制？（业务要求≤256 tokens，避免冗长）
• “实时性”定义：从用户发送消息到收到回复，端到端延迟的P95必须≤1.2秒（含网络传输）
• “高并发”基准：日常峰值QPS是多少？大促期间是否要支持3倍弹性？（日常2000 QPS，大促6000 QPS）
• “可解释性”要求：是否需要返回决策依据？比如标注“此回复基于知识库第3.2.1条”？（必须，用于客诉溯源）

这五点，我们用一张《需求-指标映射表》固化，每个指标都标注来源（PRD第几条）、责任人（算法/后端/测试）、验收方式（压测报告/AB测试结果）。没有这张表，后续所有架构设计都是空中楼阁。曾有个项目跳过这步，算法团队按学术标准做了7分类情绪识别（F1=0.72），上线后因准确率不足被业务方拒收——而如果早期对齐过F1≥0.85的要求，算法团队完全可以用蒸馏小模型在精度和速度间取得平衡。

3.2 第二步：数据流建模——画出“数据从哪里来，到哪里去，中间怎么变”

AI系统里，数据流比控制流更重要。我们不用UML序列图，而用一种叫“Data Journey Map”的草图法，只关注三件事：源头、变形点、终点。

以一个设备故障预测系统为例：

• 源头：IoT平台MQTT Topicdevice/+/telemetry（+代表设备ID），每秒10万条原始JSON
• 变形点1（清洗）：Flink作业过滤掉status!=online的设备，补全缺失字段（用Redis缓存的设备元数据）
• 变形点2（特征工程）：将原始温度、振动、电流等时序数据，滑动窗口计算：过去5分钟均值、标准差、峰峰值、FFT频谱能量占比
• 变形点3（模型输入）：特征向量拼接设备静态属性（型号、安装位置），序列化为Protobuf
• 终点：写入Kafka Topicml/predict_input，供在线服务消费；同时存入Delta Lake供离线训练

关键技巧：每个变形点必须标注“数据契约”。比如变形点2的输出契约是：{device_id: string, window_start: timestamp, features: float32[128]}。这个契约就是上下游的接口协议，一旦变更，必须走变更评审流程。我们吃过亏：某次算法团队优化了特征计算逻辑，没通知Flink开发，导致在线服务收到的feature维度从128变成132，服务直接panic——后来强制要求所有契约变更，必须更新Swagger文档并触发CI自动校验。

3.3 第三步：计算拓扑设计——GPU、CPU、FPGA不是并列选项，而是分层协作

很多团队一上来就想“All in GPU”，结果发现OCR服务里90%的耗时其实在图像预处理（缩放、二值化、透视矫正），GPU只占10%。正确的做法是按计算特性分层：

• GPU层：只承载模型推理核心（矩阵乘、激活函数），且必须是FP16/INT8量化后的模型。我们规定：未经Triton/TensorRT优化的PyTorch模型，禁止上生产GPU。
• CPU层：承担所有IO密集型、逻辑密集型任务：协议解析、数据清洗、特征工程、后处理（如NMS）、结果组装。用Rust重写了所有CPU密集型模块，相比Python提速8-12倍。
• FPGA/ASIC层：针对固定模式的超高吞吐场景，如实时视频流的H.264解码、特定加密算法。我们用Xilinx Alveo U280加速了金融交易日志的实时脱敏，吞吐达12GB/s，是CPU的23倍。

分层不是静态的，而是动态路由。我们的编排引擎会根据请求头里的x-compute-hint字段决定路径：hint=gpu走GPU集群，hint=cpu走CPU集群，hint=low-latency强制走FPGA。这样既保证SLA，又避免资源浪费。

3.4 第四步：状态管理设计——AI系统里最危险的“无状态”幻觉

AI服务常被误认为“无状态”，其实充满隐式状态：

• 模型状态：Triton加载的模型引擎、TensorRT的context、ONNX Runtime的session
• 数据状态：特征缓存（Redis）、用户会话（Session Store）、模型版本映射（Consul KV）
• 控制状态：灰度开关、熔断器状态、限流计数器

我们采用分层状态管理策略：

• 瞬时状态（<1s）：存在CPU L1/L2 cache，如单次推理的中间tensor
• 短时状态（1s-1h）：存在Redis Cluster，如用户最近10次对话历史（用于上下文感知）
• 长时状态（>1h）：存在PostgreSQL，如模型版本发布记录、A/B测试配置
• 全局状态（跨集群）：存在etcd，如当前生效的模型版本号、熔断阈值

特别注意：所有状态操作必须幂等。比如模型热更新，不是“删除旧模型+加载新模型”，而是“原子切换模型句柄指针”，旧模型句柄在无引用后由GC回收。我们曾因未实现幂等，导致一次更新操作被重复执行，服务短暂返回空结果。

3.5 第五步：可观测性埋点——不是加日志，而是定义“AI健康仪表盘”

传统日志对AI系统意义有限。我们定义了三类必埋点：

• 输入健康度：请求体大小、字段完整性、数据分布（如图像分辨率直方图）。当某天突然涌入大量1024x768图片（训练集是640x480），立即告警。
• 计算健康度：GPU显存占用率、CUDA kernel执行时间、batch size实际值。我们发现，当batch size从32突降到8时，p99延迟会飙升，这是显存碎片化的征兆。
• 输出健康度：预测置信度分布、类别偏移（如某类预测概率从30%升至70%）、结果一致性（同一输入多次请求的输出差异）。曾发现一个OCR模型对“0”和“O”的识别在夜间批量任务中一致性骤降，根源是夜间GPU温度升高导致浮点计算误差累积。

所有埋点数据，统一用OpenTelemetry Collector采集，打标service=ocr-api, model_version=v2.3, gpu_type=A10，导入Grafana。看板首页只有4个指标：input_valid_rate（输入合规率）、gpu_oom_count_5m（5分钟OOM次数）、output_confidence_p50（输出置信度中位数）、latency_p99_ms。这四个数字，就是值班工程师的“生命体征”。

3.6 第六步：灾备与降级设计——AI系统没有“优雅降级”，只有“可控退化”

AI服务的降级，不是简单返回HTTP 503，而是定义清晰的退化路径。以搜索排序为例：

• L1降级：关闭精排，只用粗排结果（效果损失30%，延迟降低70%）
• L2降级：粗排也关闭，返回热门商品列表（效果损失80%，延迟降低95%）
• L3降级：返回静态缓存页（效果损失100%，延迟<10ms）

每级降级都有明确触发条件和自动开关。比如L1降级触发条件是：gpu_oom_count_5m >= 3或latency_p99_ms > 1500。开关是Kubernetes ConfigMap，降级脚本会自动修改ConfigMap并滚动重启Pod。关键是，所有降级路径必须提前验证。我们每月做一次“混沌工程演练”：用Chaos Mesh随机kill GPU Pod，验证L1降级是否在15秒内生效，且监控指标符合预期。

3.7 第七步：安全与合规设计——不是加防火墙，而是嵌入数据生命周期

AI系统的安全风险不在网络层，而在数据层。我们遵循“数据不动模型动”原则：

• 训练数据：全部在私有云VPC内处理，禁止公网访问。敏感字段（身份证、手机号）在进入特征工程前，已用国密SM4加密。
• 推理数据：用户上传的图片/语音，处理完立即删除（S3 lifecycle rule设为1小时过期）。内存中绝不留存原始数据，只存特征向量。
• 模型资产：权重文件用AES-256加密存储，密钥由Hashicorp Vault托管，每次加载时动态获取。

合规不是事后审计，而是设计阶段嵌入。比如GDPR要求“被遗忘权”，我们在用户注销时，不仅删用户表，还触发异步任务：从Redis删除会话、从Delta Lake删除该用户所有行为日志、从模型特征库中抹除该用户ID关联的所有特征向量——这个流程写死在注销API里，不可绕过。

4. 实操过程：从零搭建一个高可用OCR服务的完整手记

4.1 环境准备与工具链选型——为什么我们放弃Kubeflow，选择Triton+Argo

项目需求：为某政务大厅部署OCR服务，支持身份证、营业执照、户口本三类证件识别，QPS峰值3000，P99延迟≤800ms，支持灰度发布。

第一步不是写代码，而是定工具链。我们对比了主流方案：

最终栈：

• 编排层：Go + Gin + Redis（状态存储） + Consul（服务发现）
• 执行层：NVIDIA Triton Inference Server 23.08 + TensorRT 8.6
• 基础设施：Kubernetes 1.25 + NVIDIA Device Plugin + KubeSphere（可视化运维）
• CI/CD：GitLab CI + Argo CD（GitOps）

选型理由：Triton原生支持模型热更新、动态批处理、多框架（PyTorch/TensorFlow/ONNX），且NVIDIA官方维护，驱动兼容性有保障。我们实测，Triton在A10上，相比裸PyTorch，吞吐提升3.2倍，显存占用降低40%。

4.2 模型优化与打包——从.pth到.trt的七道工序

原始模型是PyTorch训练的CRNN+CTC，.pth文件2.1GB。直接部署会OOM，必须优化：

1. ONNX导出：用torch.onnx.export()导出，注意dynamic_axes参数声明input和output的动态维度（batch_size, seq_len）
2. ONNX Simplifier：用onnxsim简化计算图，消除冗余op，文件缩小35%
3. TensorRT转换：用trtexec命令行工具，指定--fp16 --workspace=2048，生成.plan文件
4. 显存优化：在Triton config.pbtxt中设置max_batch_size=32，dynamic_batching启用，preferred_batch_size=[16,32]
5. 模型分片：将大模型拆为encoder.plan和decoder.plan，Triton支持Pipeline模型，自动串联
6. 权重加密：用openssl enc -aes-256-cbc加密.plan文件，启动时由Triton插件解密
7. 签名验证：每个模型包附带SHA256摘要，Triton启动时校验，防篡改

关键细节：trtexec转换时，必须用与生产环境完全一致的CUDA/cuDNN版本，否则运行时报错CUDA driver version is insufficient。我们建立了一个“模型构建镜像”，里面固化了CUDA 11.8.0 + cuDNN 8.6.0 + TensorRT 8.6.1，所有模型都在此镜像中构建，杜绝环境差异。

4.3 Triton服务部署与调优——那些文档里不会写的坑

Triton部署不是docker run那么简单。我们的config.pbtxt核心配置：

name: "ocr_service" platform: "tensorrt_plan" max_batch_size: 32 input [ { name: "INPUT__0" data_type: TYPE_FP32 dims: [ 3, 32, 100 ] # C,H,W } ] output [ { name: "OUTPUT__0" data_type: TYPE_FP32 dims: [ 25, 11 ] # seq_len, vocab_size } ] optimization { execution_accelerators { gpu_execution_accelerator : [ { name : "tensorrt" parameters { key: "precision_mode" value: "FP16" } } ] } } dynamic_batching { max_queue_delay_microseconds: 100000 } # 100ms

实操心得：

• max_queue_delay_microseconds是灵魂参数：设太小（如10000），batch size难凑满，吞吐低；设太大（如500000），延迟飙升。我们通过压测找到拐点：100000μs时，batch size平均24，p99=720ms，完美。
• dims必须严格匹配模型输入，少一个负号（如[-1,3,32,100]）会导致Triton启动失败，错误日志只显示Failed to initialize model，毫无提示。解决方案：用polygraphy inspect model xxx.plan查看真实输入shape。
• GPU显存碎片是隐形杀手。我们发现，连续部署10个模型后，第11个总是OOM。根源是Triton默认不释放显存。解决：在config.pbtxt中加model_control_mode: EXPLICIT，用model_repository_indexAPI显式unload不用的模型。

4.4 编排层开发——用Go写一个200行的AI路由引擎

编排层核心逻辑：接收HTTP请求 → 解析图片 → 路由到对应模型 → 聚合结果 → 后处理。我们用Go实现，关键代码片段：

// 根据图片类型路由 func routeModel(imgBytes []byte) (string, error) { // 用libjpeg-turbo快速读取EXIF exif, _ := jpeg.ReadExif(imgBytes) if exif.Get("Make") == "IDCardScanner" { return "idcard_v3", nil // 身份证专用模型 } // 用轻量CNN判断证件类型（10ms内） pred := quickClassifier.Predict(imgBytes) switch pred { case "idcard": return "idcard_v3", nil case "business_license": return "bizlicense_v2", nil default: return "general_v1", nil // 通用模型 } } // 熔断器：基于GPU健康度动态路由 func getAvailableEndpoint() string { // 从Redis读取各GPU节点GPU Util和OOM次数 util, _ := redis.Get("gpu:a10-01:util").Float64() oom, _ := redis.Get("gpu:a10-01:oom_5m").Int64() if util < 85 && oom == 0 { return "http://a10-01:8000" } return "http://a10-02:8000" // 切换备用节点 }

为什么用Go不用Python？实测：Python的GIL让并发处理图片时CPU利用率卡在1核，QPS上限1200；Go goroutine无锁调度，同样硬件QPS达3200。且Go二进制体积小（<15MB），容器启动快。

4.5 全链路压测与SLA验证——用真实数据模拟“大考”

压测不是用ab或wrk发随机请求。我们用真实业务数据：

• 数据集：从生产环境脱敏抽取10万张证件图，按比例混合身份证（60%）、营业执照（25%）、户口本（15%）
• 流量模型：用Gatling模拟阶梯式流量：500→1000→2000→3000 QPS，每级持续5分钟
• 观测重点：
  • Triton指标：nv_gpu_utilization、nv_gpu_memory_used_bytes、inference_request_success（成功率）
  • 编排层指标：http_request_duration_seconds（P99）、route_latency_ms（路由耗时）
  • 基础设施：K8s Pod Pending Rate、Node Disk Pressure

压测发现两个关键问题：

1. GPU显存泄漏：连续压测2小时后，nv_gpu_memory_used_bytes持续上涨。根源是Triton的dynamic_batching在高并发下未及时清理batch context。解决方案：在config.pbtxt中加dynamic_batching { max_queue_delay_microseconds: 100000 batch_timeout_microseconds: 500000 }，强制超时清理。
2. DNS解析瓶颈：编排层调用Triton时，http_request_duration_seconds中30%耗在DNS lookup。解决方案：在Deployment中加dnsConfig: { options: [{name: "ndots", value: "1"}] }，减少DNS查询次数。

最终结果：3000 QPS下，P99=782ms，GPU Util=89%，OOM=0，SLA达标。

4.6 灰度发布与监控看板——让每一次上线都像呼吸一样自然

上线不是kubectl apply，而是分三阶段：

阶段1：金丝雀（Canary）

• 将1%流量（Header含x-canary: true）路由到新版本
• 监控canary_output_confidence_p50，若比基线低5%，自动回滚

阶段2：分批次（Phased）

• 每10分钟提升5%流量，持续2小时
• 每批检查latency_p99_ms和gpu_oom_count_5m，任一超标暂停

阶段3：全量（Full）

• 流量100%后，观察24小时，确认无异常后，旧版本自动下线

监控看板（Grafana）核心面板：

• 实时流量热力图：X轴时间，Y轴模型版本，颜色深浅表示QPS
• 健康度雷达图：5个维度（输入合规率、GPU Util、OOM次数、延迟P99、置信度P50），满分100，低于80标红
• 降级路径追踪：显示当前生效的降级级别（L0=正常，L1=粗排，L2=热门列表）

这个流程，我们已迭代7个版本，平均上线时间从45分钟缩短到8分钟，0次P0事故。

5. 常见问题与排查技巧实录：43次P0事故沉淀的避坑清单

5.1 GPU相关问题：显存不是越大越好，而是越准越好

问题现象：新模型上线后，GPU显存占用率95%，但QPS只有预期的60%，监控显示nv_gpu_utilization仅40%。

排查路径：

1. nvidia-smi dmon -s u查看显存带宽利用率（sm__inst_executed_op_memory），若远低于100%，说明不是计算瓶颈，是显存带宽瓶颈
2. nvidia-smi -q -d MEMORY查看显存ECC错误计数，若>0，说明硬件故障
3. nsys profile -t cuda,nvtx抓取CUDA trace，看kernel launch间隔是否过大（说明CPU侧数据准备慢）

根本原因：模型输入预处理（图像解码+归一化）在CPU上串行执行，GPU等待数据。
解决方案：用torchvision.io.read_image()替代PIL，启用num_workers=4，预处理耗时从120ms降至28ms。

提示：永远不要相信nvidia-smi的单一指标。我们总结出GPU健康三要素：Util > 70%（计算忙）、Memory Used < 90%（显存够）、Power Draw > 250W（供电足），三者缺一不可。

5.2 模型服务问题：Triton报错“Model not found”，但文件明明存在

问题现象：Triton容器启动成功，但curl http://localhost:8000/v2/models返回空数组，日志只有一行Failed to load model 'xxx'。

排查路径：

1. 进入容器：kubectl exec -it triton-pod -- sh
2. 检查模型目录权限：ls -l /models/xxx/1/，确认config.pbtxt和.plan文件属主是root:root（Triton默认以root运行）
3. 检查config.pbtxt语法：用python -c "import google.protobuf.text_format"验证protobuf语法
4. 检查CUDA版本：cat /usr/local/cuda/version.txt，必须与模型构建时一致

根本原因：模型文件从Mac打包（APFS文件系统），上传到Linux服务器后，config.pbtxt末尾多了\r\n（Windows换行符），Triton解析失败。
解决方案：所有配置文件用dos2unix处理，CI流水线加校验步骤。

5.3 数据漂移问题：模型精度肉眼可见下降，但AUC指标没变

问题现象：某推荐模型上线两周，业务反馈“推荐结果不准”，但离线评估AUC=0.82（和训练时一致）。

排查路径：

1. 抽样线上请求日志，用scipy.stats.ks_2samp对比线上输入特征分布 vs 训练集分布
2. 发现user_age特征：训练集集中在18-45岁（正态分布），线上出现大量60岁以上用户（长尾），且该群体CTR极低
3. 检查特征工程代码，发现年龄分桶逻辑age_bucket = min(10, age//10)，60+全归入bucket 10，但训练时bucket 10样本极少