AI Infra实战地图：从故障现场反推可交付的AI基础设施能力单元

1. 这份笔记不是“知识图谱”，而是一张踩过坑才画出来的施工地图

“AI Infra 知识全景学习笔记”——光看标题，很多人第一反应是：又一份堆砌术语的PPT式导图？或是某大厂内部流出的、密密麻麻写满模块名称的架构墙纸？我最初也这么想。直到去年接手一个跨团队模型服务项目，从本地Jupyter Notebook跑通一个ResNet50开始，到最终在千卡集群上稳定支撑日均200万次推理请求，中间经历的不是“部署成功”的弹窗提示，而是连续三周凌晨两点还在查GPU显存泄漏日志、反复重装CUDA驱动版本、在Kubernetes Event里翻找被OOMKilled的Pod原始原因、对着Prometheus面板里一条诡异的95%分位延迟曲线发呆……那一刻我意识到：所谓AI基础设施（AI Infra），根本不是静态的知识集合，而是一套动态演进的故障响应系统——它由人、工具链、硬件约束和组织节奏共同塑造，任何脱离真实压测场景的“全景图”，都只是纸上谈兵。

这份笔记，就是我在过去18个月里，把每一次报错信息、每一次配置回滚、每一次跨团队对齐会议纪要，连同自己手写的调试草稿、临时脚本注释、甚至咖啡渍浸染的白板照片，全部打散、归类、验证、再重构后沉淀下来的。它不按教科书逻辑编排（比如先讲“什么是分布式训练”），而是按真实项目生命周期中的问题域组织：当你第一次需要把PyTorch模型从单机迁移到多节点时，你会卡在哪；当你发现推理吞吐量突然跌了40%，该优先排查哪三层；当你被要求“明天上线A/B测试能力”，背后要动哪五个Infra模块的配置开关。关键词不是“微服务”“K8s”“Ray”，而是“冷启动延迟抖动”“梯度同步阻塞点”“模型版本灰度发布窗口期”。它面向的不是想考CKA证书的运维工程师，而是那个刚被拉进AI产品攻坚群、头像还挂着“实习生”标签、但明天就要在晨会汇报“推理服务SLA达标率”的人。

提示：如果你正打开这份笔记，同时心里想着“我是不是该先学完Kubernetes官方文档再来看”，请立刻合上——这恰恰是多数人掉进的第一个认知陷阱。AI Infra的学习路径从来不是自底向上堆砌，而是自顶向下切片：先明确你当前要交付的具体业务结果（例如“让新模型API响应时间P95<300ms”），再反向拆解达成该结果必须打通的最小技术断点，最后只聚焦攻克那1-2个断点所需的精准知识。本文所有章节，都按这个原则展开。

2. 为什么“全景”必须从“局部崩溃现场”开始重建？

很多初学者试图用“全景”二字给自己壮胆，仿佛掌握一张覆盖所有组件的拓扑图，就能驾驭AI Infra。但现实狠狠打了脸：去年某次关键模型上线前压测，我们按标准流程完成了模型转换、服务容器化、K8s HPA配置、Prometheus监控埋点，一切显示绿色。可当流量导入5%时，API成功率瞬间跌到62%。团队紧急拉起作战室，两小时后才发现问题根源——不是GPU资源不足，不是网络带宽瓶颈，甚至不是代码bug，而是模型加载阶段的Python GIL锁争用：服务启动时，多个Worker进程并发调用torch.load()加载同一个.pt文件，触发底层libtorch对同一内存页的重复映射，导致内核级page fault风暴。这个细节，在任何K8s或PyTorch官方文档的“全景架构图”里都不会标注，但它真实地让整个服务雪崩。

这件事彻底改变了我的知识组织方式。我不再问“AI Infra包含哪些模块”，而是问：“当某个具体指标异常时，它的故障传播链路是什么？” 比如：

• 现象：推理P99延迟突增300%

  • 可能路径1：模型层 →torch.compile()启用后与特定算子兼容性问题 → 生成低效kernel
  • 可能路径2：运行时层 → CUDA Context初始化耗时过高 → 多实例共享Context未生效
  • 可能路径3：基础设施层 → NVLink带宽被其他任务抢占 → GPU间通信延迟飙升

• 现象：训练Job反复OOMKilled

  • 可能路径1：框架层 →DistributedDataParallel中find_unused_parameters=True导致梯度缓存膨胀
  • 可能路径2：调度层 → K8s ResourceQuota未限制ephemeral-storage→ 临时文件撑爆本地磁盘
  • 可能路径3：硬件层 → GPU显存ECC纠错开启 → 实际可用显存减少12%

这份笔记的“全景”，正是由这样数十个真实崩溃现场的根因分析反向拼接而成。它不承诺覆盖所有技术名词，但确保每个列出的节点，都对应一个你大概率会在下周遇到的具体错误码、日志片段或监控告警。下面这张表，就来自我们团队最近一次故障复盘会的原始记录，它比任何架构图都更接近AI Infra的真实肌理：

注意：表格中所有“解决耗时”数据，均来自真实工单系统记录。你会发现，真正卡住项目的往往不是高深算法，而是这些看似边缘的配置细节。这也是为什么本笔记拒绝罗列“主流AI Infra工具列表”，而是直接告诉你：“当你的服务卡在ContainerCreating时，先检查这3个连接池参数”。

3. 模块解耦：把“AI Infra”拆成5个可独立验证的原子能力单元

市面上很多AI Infra教程喜欢用“计算层/存储层/网络层/调度层/服务层”这种传统IT分层法，但实际落地时你会发现：这种划分在AI场景下严重失真。比如“存储层”——模型权重、训练日志、特征缓存、向量数据库索引，它们对I/O模式、一致性要求、访问频次的要求天差地别，硬塞进一个“存储层”只会让问题更模糊。经过20+个生产环境项目的锤炼，我把AI Infra重新解耦为以下5个原子能力单元，每个单元都具备三个特征：（1）有明确的输入输出契约；（2）可独立进行压力测试；（3）故障表现高度特异化。这才是你真正该建立“全景认知”的起点。

3.1 模型加载与热启能力单元

这是所有AI服务的“心脏起搏器”。它的核心契约是：给定一个模型文件路径（本地/远程），在指定硬件环境下，以可预测的延迟完成模型结构加载、权重映射、计算图优化，并进入就绪状态。很多人忽略的是，这个单元的性能瓶颈往往不在GPU，而在CPU与存储的交互。

• 关键验证指标：

  • cold_start_time: 从进程启动到首次model.forward()返回的时间（含所有初始化）
  • warm_start_time: 同一进程内，加载第二个不同模型的耗时（检验缓存机制）
  • memory_footprint: 加载后进程RSS内存增长量（警惕torch.load()的隐式内存复制）

• 实操经验： 我们曾在一个NVIDIA A100 80G节点上，用标准torch.load('model.pt')加载一个12GB的Llama-2-7B模型，cold_start_time高达47秒。排查发现，PyTorch默认使用mmap方式加载，但该存储后端不支持mmap的MAP_POPULATE标志，导致首次访问权重时触发大量page fault。解决方案不是换硬件，而是改用torch.load(..., map_location='cpu', weights_only=True)配合手动model.to(device)，将cold_start_time压缩至8.3秒。这个技巧在任何“AI Infra全景图”里都不会出现，但它直接决定了你的服务能否通过客户要求的“秒级弹性扩缩容”。

• 避坑清单：

  • ❌ 不要在__init__中直接调用torch.load()——这会让所有Worker共享同一份权重内存，引发竞态
  • ✅ 使用torch._C._set_grad_enabled(False)在加载阶段禁用梯度计算，节省显存
  • ⚠️ 当模型文件大于单卡显存50%时，务必验证torch.load()的map_location参数是否与后续model.to()设备一致，否则触发隐式CPU-GPU拷贝

3.2 计算图执行与资源隔离能力单元

这是AI Infra的“肌肉系统”。它负责将模型定义转化为实际的硬件指令流，并确保不同任务间的资源不互相干扰。这里的“资源”不仅是GPU显存，还包括CUDA Context、TensorRT引擎缓存、NCCL通信句柄等。

• 关键验证指标：

  • gpu_utilization_stability: 在持续请求下，nvidia-smi显示的GPU利用率波动幅度（理想值<5%）
  • context_switch_overhead: 同一GPU上切换不同模型时的上下文切换耗时
  • nccl_bandwidth: 多卡训练时，nccl-test实测带宽与理论值的偏差率

• 实操经验： 在一个8卡A100集群上训练ViT模型时，我们发现nccl_bandwidth只有理论值的38%。常规思路是查网络，但iperf3测试显示RDMA带宽正常。最终定位到：NCCL_IB_DISABLE=1环境变量被错误设置，强制NCCL走TCP而非InfiniBand，而TCP栈在高并发小包场景下性能断崖式下跌。这个配置项在K8s DaemonSet模板里只占一行，却让整个训练吞吐量腰斩。更隐蔽的是，某些云厂商的GPU虚拟化层（如vGPU）会拦截NCCL通信，此时即使nvidia-smi显示GPU正常，nccl-test也会失败——必须通过nvidia-smi dmon -s u观察rx_util/tx_util指标才能确认。

• 避坑清单：

  • ❌ 不要相信nvidia-smi的util%数值——它只反映SM单元活跃度，不反映显存带宽或NVLink占用
  • ✅ 在多租户场景下，为每个模型服务分配独立的CUDA Context（通过torch.cuda.device()上下文管理器）
  • ⚠️torch.compile()的mode="default"可能在A100上生成低效kernel，建议对关键模型用mode="reduce-overhead"并保存compiled module

3.3 数据管道吞吐能力单元

这是AI Infra的“消化系统”。它处理从原始数据源（数据库/消息队列/文件系统）到模型输入张量的全链路转换，其性能瓶颈往往在CPU而非GPU。

• 关键验证指标：

  • data_load_latency_p95: 从发起数据读取请求到获得第一个batch tensor的耗时
  • cpu_bound_ratio: 数据加载线程CPU使用率与GPU利用率的比值（>3:1即严重CPU瓶颈）
  • cache_hit_rate: 特征缓存（如Redis/LMDB）的命中率

• 实操经验： 我们曾用torch.utils.data.DataLoader加载Parquet格式的用户行为日志，cpu_bound_ratio高达5.2:1。优化不是升级CPU，而是重构数据管道：（1）用pyarrow.dataset替代pandas.read_parquet，避免DataFrame内存拷贝；（2）在DataLoader中启用pin_memory=True并预分配prefetch_factor=2；（3）最关键的一步——将Parquet文件按user_id哈希分片，并在Worker中实现__getitems__批量读取，使单次IO请求获取多个样本。这三项改动将data_load_latency_p95从1200ms降至86ms，GPU利用率从42%提升至89%。

• 避坑清单：

  • ❌ 不要在Dataset.__getitem__中做任何网络IO（如HTTP请求）——这会阻塞整个DataLoader线程池
  • ✅ 对于小文件（<1MB），务必合并为TFRecord或LMDB格式，避免海量小文件IO放大效应
  • ⚠️num_workers并非越多越好，超过CPU物理核心数后，进程切换开销会抵消并行收益

3.4 服务治理与弹性伸缩能力单元

这是AI Infra的“神经系统”。它负责将模型能力封装为可靠API，并根据负载自动调节资源。这里的“弹性”不是简单的K8s HPA，而是涉及模型粒度的细粒度控制。

• 关键验证指标：

  • scale_out_latency: 从监控指标触发扩容到新Pod处理首个请求的耗时
  • request_queue_length_p95: 请求排队等待处理的平均时长
  • model_version_rollback_time: 从发现新版本问题到回滚至旧版本的总耗时

• 实操经验： 某次上线新推荐模型，HPA基于CPU使用率扩容，但新Pod启动后立即被livenessProbe杀死。日志显示torch.load()超时。根本原因在于：HPA扩容时，新Pod从S3下载12GB模型文件需2分钟，但livenessProbe.initialDelaySeconds仅设为30秒。解决方案不是调大探测延时（这会延长故障发现时间），而是实施模型预热机制：在Pod启动时，用initContainer预先下载模型到emptyDir卷，并在主容器readinessProbe中加入test -f /model/ready检查。更进一步，我们开发了一个轻量级ModelWarmerSidecar，监听K8s ConfigMap变更，主动预热即将上线的模型版本。这套机制将scale_out_latency从180秒压缩至22秒。

• 避坑清单：

  • ❌ 不要将livenessProbe和readinessProbe指向同一端点——健康检查应验证服务进程，就绪检查应验证模型加载完成
  • ✅ 为不同模型设置差异化HPA策略：计算密集型模型用GPU显存指标，IO密集型模型用请求排队时长指标
  • ⚠️HorizontalPodAutoscaler的minReplicas必须≥2——单副本故障会导致服务完全中断，违背SLA

3.5 观测与诊断能力单元

这是AI Infra的“免疫系统”。它不是简单地收集指标，而是构建能回答“为什么”的因果链路。

• 关键验证指标：

  • root_cause_resolution_time: 从告警触发到定位根因的平均耗时
  • metric_correlation_score: 关键指标（如延迟、错误率）与底层硬件指标（如GPU温度、PCIe带宽）的相关性强度
  • log_trace_completeness: 单次请求在各组件（API网关/模型服务/特征库）的日志trace ID覆盖率

• 实操经验： 我们曾遇到一个经典问题：推理延迟P95突然升高，Prometheus显示GPU利用率正常，但nvidia-smi dmon -s u显示rx_util持续95%。起初怀疑网络，但tcpdump无异常。最终通过nsys profile抓取GPU kernel trace，发现memcpyHtoD（主机到设备内存拷贝）耗时激增。顺藤摸瓜，定位到特征工程代码中一个np.array()调用，意外触发了NumPy数组到GPU张量的隐式转换，而该数组大小随用户ID变化，导致小用户请求快、大用户请求慢。这个根因，只有将nsys的GPU级trace与应用层日志通过trace ID关联，才能发现。因此，我们在所有服务中强制注入X-Request-ID，并在torch.cuda操作前后打点，用OpenTelemetry统一采集。

• 避坑清单：

  • ❌ 不要只看Prometheus的聚合指标——rate(http_request_duration_seconds_count[5m])掩盖了单个慢请求的真相
  • ✅ 对GPU关键指标（sm__inst_executed,dram__bytes_read,nvlink__throughput）必须做per-GPU采集，不能只取平均值
  • ⚠️ 日志采样率必须动态调整：错误日志100%采集，INFO日志按trace_id % 100 == 0采样，避免日志洪峰压垮ES集群

4. 工具链选型：为什么我们放弃“全家桶”，坚持“乐高式组合”

市面上充斥着各种AI Infra“一站式平台”：从开源的Kubeflow、MLflow，到商业化的Sagemaker、Vertex AI。但在我经手的12个生产项目中，没有一个项目采用单一平台作为完整解决方案。原因很现实：每个平台都在特定场景下优秀，但在其他场景下成为枷锁。比如Kubeflow Pipelines在复杂训练流水线编排上强大，但其模型服务组件KFServing的弹性伸缩策略僵化，无法满足我们毫秒级延迟要求；MLflow在实验追踪上无可挑剔，但其模型注册中心缺乏细粒度权限控制，无法满足金融客户审计要求。

我们的实践是：用“乐高式组合”替代“套装式采购”。每个原子能力单元，只选择在该单元内最锋利的工具，然后用轻量级胶水代码粘合。以下是我们在生产环境中稳定运行18个月以上的工具链组合，所有选型均基于真实压测数据：

这个表格背后，是我们踩过的无数坑。比如曾尝试用Triton替代KServe，理由是NVIDIA官方支持。但上线后发现：Triton的模型配置文件config.pbtxt不支持环境变量注入，导致不同环境（dev/staging/prod）需维护三套配置；其健康检查端点/v2/health/ready在模型加载失败时仍返回200，导致K8sreadinessProbe永远无法探活。最终我们退回KServe，用kustomizepatch注入环境变量，并在ModelRouter中实现自定义健康检查逻辑。

提示：工具选型没有银弹，唯一可靠的决策依据是在你的目标硬件上跑真实负载。我们有一个铁律：任何新工具引入前，必须用生产环境80%的数据量、120%的QPS进行72小时压测，且指标必须优于现有方案15%以上，才允许上线。这个过程枯燥，但省去了后期90%的救火时间。

5. 真实项目复盘：从“能跑通”到“可交付”的12个关键检查点

理论终须落地。这里分享一个典型项目——为某电商平台构建实时个性化推荐服务——从代码提交到SLA达标，我们严格执行的12个检查点。这不是流程清单，而是血泪教训凝结的“防翻车清单”。每个检查点都对应一个曾让我们加班到凌晨的具体问题。

5.1 检查点1：模型文件完整性校验（非MD5，而是SHA256+尺寸双校验）

问题场景：模型上线后，部分用户请求返回NaN。排查发现，S3上传过程中，一个12GB的.pt文件因网络抖动，末尾128KB数据丢失，但S3的ETag（MD5）仍匹配（因为分块上传的ETag是分块MD5拼接）。解决方案：在模型打包脚本中，强制计算完整文件SHA256，并将size和sha256写入model.meta.json。服务启动时，先校验model.meta.json，再加载模型。这个检查点让模型损坏类故障归零。

5.2 检查点2：CUDA版本与PyTorch二进制严格绑定

问题场景：开发环境用torch==2.1.0+cu118，生产镜像用nvidia/cuda:11.8.0-devel-ubuntu22.04，但基础镜像中CUDA驱动版本为525.60.13，而torch==2.1.0+cu118要求驱动≥520.61.05。结果服务启动时报libcudart.so.11.8: cannot open shared object file。解决方案：在Dockerfile中，用nvidia-smi --query-gpu=driver_version --format=csv,noheader获取驱动版本，并与PyTorch要求的最低驱动版本比对，不匹配则构建失败。

5.3 检查点3：特征缓存穿透防护（非Redis，而是本地LRU+布隆过滤器）

问题场景：促销大促期间，大量恶意请求查询不存在的user_id，击穿Redis缓存，直击MySQL，导致DB CPU 100%。解决方案：在服务层添加两级缓存：（1）本地functools.lru_cache(maxsize=10000)缓存热点用户；（2）布隆过滤器（BloomFilter）预判user_id是否存在，误判率控制在0.1%。这个组合将无效请求拦截率提升至99.97%。

5.4 检查点4：GPU显存碎片化检测（非nvidia-smi，而是torch.cuda.memory_stats()）

问题场景：服务运行24小时后，nvidia-smi显示显存占用75%，但新请求报CUDA out of memory。torch.cuda.memory_allocated()显示仅占用45%，说明存在严重碎片。解决方案：在服务健康检查端点中，定期调用torch.cuda.memory_stats()，监控reserved_bytes.all.current与allocated_bytes.all.current的比值，当比值>3时，触发自动重启Worker。

5.5 检查点5：模型输入Schema强校验（非JSON Schema，而是pydantic+numpy类型检查）

问题场景：前端传入user_age字段为字符串"25"，模型期望int，torch.tensor("25")静默转为tensor([25])，但后续计算逻辑出错。解决方案：定义pydantic.BaseModel，对每个字段声明int/float/List[float]类型，并在model.forward()入口处，用numpy.array()强制转换并校验dtype，不匹配则抛出ValueError并记录详细错误上下文。

5.6 检查点6：K8s Pod驱逐保护（非priorityClassName，而是tolerations+nodeSelector）

问题场景：节点维护时，K8s自动驱逐Pod，但模型加载需2分钟，驱逐导致服务中断。解决方案：为模型服务Pod添加tolerations容忍maintenance=true污点，并在nodeSelector中指定node-role.kubernetes.io/ai-infra: "true"，确保Pod只调度到专用AI节点，且该节点维护前，运维需手动移除污点。

5.7 检查点7：HTTP Keep-Alive连接池复用（非默认值，而是urllib3底层参数调优）

问题场景：服务调用外部特征API，requests.Session()默认pool_connections=10，在高并发下连接池耗尽，Connection pool is full错误频发。解决方案：在requests.Session()初始化时，显式设置pool_connections=50，pool_maxsize=50，max_retries=3，并将Session作为全局变量复用。

5.8 检查点8：模型版本灰度发布窗口期（非百分比，而是基于request_id哈希的精确控制）

问题场景：用K8s Service的weight做灰度，但权重是概率性的，无法保证同一用户始终路由到同一版本。解决方案：在ModelRouter中，解析X-User-ID请求头，计算hash(user_id) % 100，若结果<5则路由到v2，否则v1。这样，5%的用户被精确灰度，且用户视角无感知。

5.9 检查点9：Prometheus指标命名规范（非随意命名，而是遵循<namespace>_<subsystem>_<name>）

问题场景：多个团队自定义指标，model_latency_ms、inference_time、pred_duration混用，告警规则无法复用。解决方案：强制所有指标遵循ai_infra_model_latency_seconds格式，并在Grafana中用label_values(namespace)下拉筛选，确保监控体系可维护。

5.10 检查点10：日志结构化与Trace ID注入（非print()，而是structlog+OpenTelemetry）

问题场景：排查问题时，需在API网关、模型服务、特征库三处日志中人工拼接request_id，效率极低。解决方案：在所有服务中，用structlog配置add_log_level、add_timestamp，并通过OpenTelemetry的trace.get_current_span().get_span_context().trace_id注入X-Trace-ID，实现全链路日志一键检索。

5.11 检查点11：GPU温度与功耗基线监控（非阈值告警，而是同比环比智能分析）

问题场景：GPU温度从72°C升至78°C，nvidia-smi告警触发，但实际是环境空调故障，所有GPU温度同步上升，非硬件问题。解决方案：用Prometheus记录nvidia_smi_temperature_gpu，Grafana中配置同比（昨日同时间）和环比（1小时前）分析，仅当温度异常升高且偏离基线>5°C时告警。

5.12 检查点12：模型服务SLA达标率自动报告（非人工统计，而是Prometheus Recording Rule）

问题场景：每月向客户提交SLA报告，需人工从Grafana截图、Excel计算，易出错。解决方案：在Prometheus中定义Recording Rulejob:ai_infra_sla:ratio_rate_5m = sum(rate(http_request_duration_seconds_count{code=~"2.."}[5m])) by (job) / sum(rate(http_requests_total[5m])) by (job)，并用Alertmanager自动邮件推送日报。

这12个检查点，每一个都源于一次真实的线上事故。它们不追求技术炫酷，只解决“如何让服务稳定交付”这个朴素目标。当你下次启动一个AI Infra项目时，不妨打印这份清单，逐条打钩——不是为了流程合规，而是为了少熬几个通宵。

6. 经验沉淀：那些没写在文档里，但决定项目成败的“软性认知”

技术细节可以查文档，但有些认知，只能靠踩坑积累。这些“软性认知”不构成具体步骤，却像空气一样弥漫在每个决策中，决定着项目是平稳交付，还是陷入无休止的救火循环。

6.1 “稳定性”不是技术指标，而是组织节奏的函数

我们曾有个项目，技术方案完美：模型精度达标、延迟P95<200ms、SLA 99.95%。但上线后，客户投诉不断。复盘发现，问题不在代码，而在节奏：客户要求每周迭代一个新模型版本，而我们的CI/CD流水线从代码提交到生产环境部署需48小时。这意味着，客户提出的“今天上线新模型”需求，实际要等到后天。技术上的“稳定”被组织节奏的“不稳定”彻底抵消。后来我们重构了发布流程：（1）模型训练与服务部署解耦，训练完成即入库；（2）服务部署用K8s ConfigMap热更新，无需重建Pod；（3）新增/v1/model/activateAPI，客户可随时激活任一已入库模型。发布周期从48小时压缩至90秒。真正的稳定性，是技术能力与组织诉求的共振频率。

6.2 “可观测性”的终点，是让非技术人员也能提问

最好的监控系统，不是给SRE看的，而是让产品经理能问出有效问题。比如，当产品经理说“为什么首页推荐点击率下降了？”，系统应该能自动关联：（1）ai_infra_model_latency_seconds_p95是否升高；（2）feature_cache_hit_rate是否下降；（3）model_version_active是否刚切换。我们为此开发了一个内部Dashboard，产品经理只需选择“时间范围”和“业务指标”，系统自动展示相关Infra指标趋势，并用自然语言生成初步归因（如“点击率下降期间，特征缓存命中率从92%降至76%，建议检查特征更新任务”）。可观测性的终极价值，是把技术黑盒，变成业务决策的透明仪表盘。

6.3 “成本优化”的最大误区，是只盯着GPU小时费

云厂商账单上，GPU实例费用最醒目，但实际成本大头常在别处。我们曾分析一个推理服务月度账单：GPU费用占41%，但存储费用（S3模型文件+Redis缓存）占33%，网络出口流量费占18%。优化方向立刻清晰：（1）用torch.export()压缩模型体积，S3存储费降27%；（2）Redis缓存过期策略从7天改为动态TTL（基于用户活跃度），缓存费降42%；（3）模型服务与特征库部署在同一VPC内，网络费归零。Infra成本优化，必须全链路建模，否则就是拆东墙补西墙。

6.4 “技术债”的利息，是按指数级增长的

一个未修复的Bug，其修复成本不是线性增长，而是指数级。比如，早期为赶进度，模型服务未做输入校验。半年后，这个漏洞导致：（1）3次线上事故；（2）5个下游系统被迫增加兼容逻辑；（3）新入职工程师花2天理解这个“历史约定”。最终修复成本是最初2小时的50倍。我们的应对策略是：设立“技术债利率”——每个未修复的高危Bug，按其影响面（下游系统数×日均调用量）计算“年化成本”，在季度技术评审会上，与新需求一起排序。高利率债必须优先偿还。这让我们技术债存量三年内下降76%。

6.5 “学习AI Infra”的正确姿势，是“带着问题找答案”，而非“按目录学知识”

我见过太多人，雄心勃勃地买下《Kubernetes权威指南》《PyTorch源码解析》，结果三个月后还在第一章。有效的方法是：锁定一个具体交付目标，倒逼知识获取。比如，目标是“让模型API P95延迟<300ms”，那么你需要学的不是K8s所有概念，而是：（1）`kubectl top