收官寄语：少说漂亮话，继续把基础设施做好
收官寄语：少说漂亮话，继续把基础设施做好
一、最后一天，不说告别，说下一程
7 月的最后一天，310 篇文章的产出量到了终点。但技术的终点从来不等于写的终点——它只意味着上一个阶段的结论已经被提炼，下一个阶段的更深的课题已经浮出水面。
收官这天不想写一篇教科书式的总结，只想把 31 天写作过程中反复打磨出的一条价值观再用最后一篇文字说透：在云原生 AI 这个领域，值得做的事情从来都不漂亮——它是在凌晨三点排查 GPU 显存泄漏的枯燥，是 Prometheus 告警响起时按 SOP 走应急流程的机械，是在 nobody cares 的时候把 etcd 备份频率从一天一次调到六小时一次的固执。
二、这 31 天磨出的三件事
从用 AI 到管 AI
这是 7 月写作中被论证次数最多的一条认知主线。会用一个模型生成代码、生成文本、生成摘要——这是 AI 时代的最低门槛，在 2025 年连非技术人员都能做到。但真正的技术能力是把模型的推理服务管好——管它的可用率、管它的延迟、管它的成本、管它的版本更新、管它在极端情况下的降级策略。
在这个领域，"管理"的价值远大于"使用"。一个会写 prompt 的团队和两个能管推理集群的工程师之间，后者对业务连续性的影响是前者的一百倍。不是因为后者更聪明，而是因为后者让前者写的 prompt 能真正在生产环境里稳定运行。
从搭平台到建体系
搭建一个平台很容易——K8s 集群 + vLLM 实例 + HTTP API = 一个基础推理平台，三天能搭完。但搭建一套体系需要的是一整套基础设施能力矩阵：自动故障转移、优雅降级、灰度发布、可观测性、成本归因、故障演练、备份恢复——每一样都要设计、验证、演练、迭代。
平台是一块拼图，体系是整幅图画。7 月的写作，最大篇幅花在了怎样把"拼图"变成"图画"的路径上——不是技术路线的规划，而是每一步为什么这样做、做了之后的核心数据是什么。
从写代码到担责任
AI 时代代码的产出速度在空前提升，但代码的责任归属反而更模糊了——一段 AI 生成的推理调用代码，是谁的锅？写的人觉得是 AI 的问题，AI 觉得是 prompt 的问题，最后锅悬在空中。
7 月关于工程师素养的文章反复在讲一个观点：一个人对你写的代码负有无限责任，无论这段代码的来源是你自己敲的、AI 生成的、还是从 Stack Overflow 复制来的。这个责任包括：有没有写单元测试？有没有做异常处理？有没有考虑并发安全？有没有设计降级策略？有没有监控指标埋点？
以前这些是加分项，现在它们是最低要求——因为在 AI 帮你完成了 80% 的编码工作量之后，你没有借口不把剩下的 20% 的可靠性和可观测性工作做好。
三、八月要解决的真问题
收官不是结束，是从一个阶段的结论开始下一个阶段的深化。以下列出的不是计划，而是基于 7 月数据已经暴露出的、迫切需要解决的工程问题：
GPU 碎片化的自动治理：7 月数据暴露了 T4 集群显存碎片化的规律——高频率的 Pod 扩缩容会在 GPU 上产生不可分配的小块显存碎片，累积到一定程度后 GPU 节点"有显存但无法分配新 Pod"。K8s 没有原生的显存碎片整理，这条路需要自己趟。
推理网关的零中断升级：当前推理网关升级时，SSE 连接会因 Pod 重启而断开。客户端的自动重连策略虽然在功能上可用，但在重连窗口期（2-5 秒）内的推理请求全部丢失。这个问题需要在八月份通过连接优雅迁移机制来解决。
成本模型的精细化：当前的成本计算基于"GPU 类型 × 推理耗时"的线性模型。但实际上不同模型的推理效率差距巨大——同样是 A100、同样的输入 token 数，模型 A 的 GPU 耗时可以是模型 B 的 1.8 倍。成本模型需要从"按 GPU 型号算"进化到"按模型算 + 按 token 算"。
多租户下的 QoS 保障：当多个业务线同时跑在推理平台上时，"一个业务线的批量任务打满 GPU 影响其他业务线的实时请求"是反复出现的故障场景。需要在 K8s 层面引入 GPU QoS 分级调度——实时推理请求具有绝对优先级，批量任务的 GPU 资源可以被抢占。
四、这一个月最感谢的三样东西
不说人，说东西——因为作为基础设施工程师，最可靠的依赖从来不是人。
第一个是Prometheus。过去 31 天的所有数据驱动决策，根子都在 Prometheus 的时间序列数据里。没有它，P99 延迟恶化这种事只能靠"最近越来越慢了"的主观感觉来发现。
第二个是Kubernetes。没有 K8s 的声明式 API 和调度器扩展能力，GPU 资源管理会是地狱级的运维复杂度。它对基础设施抽象的统一表达方式——"你描述你想要的终态，我来达成它"——和在基础设施领域"少说漂亮话"的价值观，在我眼里是一致的。
第三个是Go。不是因为它是最好看的语言，而是因为它在云原生 AI 的编排层上几乎没有真正的竞争者。高性能 HTTP 处理、原生并发模型、与 K8s 的深度集成——在需要使用 Go 的场景里，没有比它更好的选择。
五、总结
七月的 310 篇文章到这里就写完了。最后一篇没有给建议，没有列路线图，更没有总结全文——因为前面 309 篇已经做了这些。
这一篇只有一个想法：如果说七月是"发现问题、定义问题、初步解决"的阶段，那八月就是"深化方案、打磨可靠性、追求零中断"的阶段。云原生 AI 平台的目标不是做一个看起来很厉害的工程，是做一个业务方完全信任、凌晨三点没人值班也能自动恢复、GPU 成本永远透明的平台。
收官日想说的话就这一句——少说漂亮话，继续把基础设施做好。
因为好的基础设施应该像空气一样：用户感受不到它的存在，但离了它一切都会崩塌。
资料说明
本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。