收官寄语：少说漂亮话，继续把基础设施做好

2026/7/31 23:34:03

收官寄语：少说漂亮话，继续把基础设施做好

一、最后一天，不说告别，说下一程

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 资源可以被抢占。