KubeCon 2026 上海这一场下来，我最强烈的感受是：AI 的话题终于不再围着"哪个模型分数高"打转了。从 Keynote 到展区，从厂商白皮书到工程师之间的私下交流，反复出现的词是"编排""调度""稳定性""成本"。换句话说，当模型能力逐渐趋同，真正拉开差距的地方，已经转移到"怎么把 AI 可靠地跑起来、跑得稳、跑得省"这件事上。这就是我理解标题里"系统工程时代"的含义——AI 落地不再是一场模型竞赛，而是一场平台工程、基础设施工程、可靠性工程的综合比拼。
这篇文章我打算结合我们在生产环境里实践大模型服务化的一年多经验，围绕 KubeCon 2026 上海透露出的技术风向，把 AI 系统工程的几个核心问题拆开讲清楚：算力怎么调度、推理服务怎么做成生产级、模型版本怎么管理、线上出了故障怎么排查。适读人群包括正在做 AI 应用落地的后端工程师、平台/SRE 工程师，以及对"模型上线之后发生了什么"好奇的技术管理者。内容里不会有太多焦虑式的趋势分析，更多是可复用的实操方法和踩坑记录。
1. 为什么说 AI 落地进入了系统工程时代
1.1 模型不再是瓶颈，系统才是
过去两年，很多团队的路径几乎一模一样：先选定一个开源大模型，跑通推理，把 API 暴露给业务方，然后发现事情远没有结束。单机跑通和规模化服务之间隔着一条巨大的鸿沟，而这条鸿沟里全是系统工程问题。
举个例子。你本地用 transformers 加载一个 7B 模型，输入一个 prompt，几秒钟出结果，你觉得一切都很顺利。一旦放到线上，你会立刻遇到这些问题：GPU 显存不够怎么办？并发请求来了是不是要排队？排队多久算超时？模型加载要花两分钟，Kubernetes 探活失败被反复重启怎么办？显存碎片化导致新的 Pod 调度不上去怎么办？一个租户把显存打满，其他租户全部受影响怎么办？
这些问题没有一个是模型算法层面的，但每一个都能让项目死掉。KubeCon 2026 上海传递的最清晰的信号就是：行业已经意识到，AI 落地的瓶颈已经从"模型能力够不够强"转移到"基础设施能不能接住"。我在会场听到一个比喻很贴切——模型就像一个顶级厨师，你光有厨师没用，还得有厨房、供应链、排班系统和消防预案。过去大家拼命找更好的厨师，现在发现厨房才是决定餐厅能不能规模化经营的关键。
1.2 KubeCon 议题在往哪里走：AI 基础设施成为主线
从议程设置来看，这届 KubeCon 有几个明显的板块变化。第一个是 GPU 调度和资源管理类 session 的数量大幅增加，从 device plugin 的增强到自定义调度器的实践，再到 GPU 共享、时间片切分、内存池化，内容密度非常高。第二个是推理服务化相关的分享密度上来了，vLLM、Triton、TensorRT-LLM 这些推理框架与 Kubernetes 原生能力的整合，几乎成了平台工程师的标配话题。第三个是 AI Agent 也进入了基础设施讨论的视野——Agent 的任务编排、会话状态管理、工具调用追踪，正在催生新的平台层需求。
这些议题不是孤立的技术点，它们背后有一个共同的指向：云原生基础设施的边界正在被 AI 工作负载重塑。Kubernetes 不再是只管无状态 Web 服务的调度平台，它需要理解 GPU 的拓扑结构、显存容量、推理延迟的敏感度，甚至需要和模型仓库、特征平台、向量数据库这些 AI 组件做深度联动。这已经不是传统 PaaS 的玩法，而是一套新的、面向 AI 的工程体系。
2. 系统工程视角下的三个核心问题
2.1 算力调度：GPU 资源的精细化管理
GPU 和 CPU 有一个很大的不同，它不是可任意分割的资源。CPU 有核数，可以按 vCPU 来分，一个容器 100 毫核也能跑。GPU 的调度粒度要么是整卡，要么通过 MIG、时间片、显存隔离来做细粒度切分，每种方案都有取舍。
整卡调度最简单，但浪费也最大。一个推理服务可能只需要 20GB 显存，你给它一整张 80GB 的 A100，剩下的 60GB 就闲置了。更麻烦的是显存碎片化：集群里有三张卡，分别剩下 30GB、40GB、50GB，但你有一个需要 40GB 的 Pod，如果调度器只看"剩余显存是否大于 40GB"，那么它可能把 Pod 放到只剩 30GB 的那张卡上，然后调度失败。这类问题在推理集群里非常常见，特别是多个不同规格模型混合部署时。
解决这个问题通常需要组合拳。第一层是驱动层，用 NVIDIA 的 MIG 或者 vGPU 技术把物理卡切成更小的实例。第二层是调度器层，Kubernetes 默认调度器对 GPU 的理解太浅，你需要扩展调度器逻辑，把"显存请求""算力请求""模型亲和性"变成可感知的调度维度。第三层是运行时层，通过推理框架的显存池化能力，让多个模型副本共享同一张卡上的显存，把碎片利用起来。
我们实践中比较有效的一个配置是：按模型维度的资源画像做调度策略。比如小模型采用 binpack 策略，尽量堆在同一张卡上，提高单卡利用率；大模型采用 spread 策略，分散到不同节点，避免单点故障影响整个服务。这个策略听起来简单，但一旦混部场景多了，你会发现调度策略本身也需要做成可配置的平台能力，而不是写死在调度器代码里。
2.2 推理服务化：从单机脚本到生产级服务
模型推理服务化是系统工程里最核心、也最容易踩坑的一环。很多人把"用 FastAPI 包一层模型调用"当成服务化，这是第一步，但距离生产级还差得很远。
生产级推理服务至少需要具备四个能力：高吞吐、低延迟、稳定性和可观测性。高吞吐靠推理框架的持续优化，比如 vLLM 的 PagedAttention 和连续批处理，可以在同样的显存下显著提升并发能力；低延迟需要做前缀缓存、请求路由和动态批大小的调优；稳定性靠优雅启动、优雅退出、限流熔断和副本冗余；可观测性则需要把模型层的指标，比如首字延迟、生成速度、排队长度，接入到现有的监控体系里。
这里面有一个经常被忽略的问题：推理框架和业务流量的匹配。vLLM 适合文本生成这类连续批处理友好的场景，Triton 在多模型、多框架混合场景更有优势，TensorRT-LLM 在极致性能追求下有不可替代性。没有"最好的推理框架"，只有"适合你业务场景的推理框架"。
另外，模型服务的健康检查不能只看进程是否存活。模型加载完成之前，服务端口虽然监听，但一接请求就会超时或者返回 500。所以 readiness probe 必须检查模型加载状态和显存初始化状态，这个我们在下文实操部分详细写。
2.3 模型生命周期管理：发布、灰度与回滚
模型和普通代码有一个本质区别：代码的行为是确定的，模型的行为是概率性的。同一个 prompt，不同版本的模型给出的回答可能完全不同，这意味着模型的版本管理比代码版本管理要复杂得多。
模型生命周期管理涉及三个维度的版本对齐：代码版本、模型权重版本、数据/特征版本。你更新了一版模型权重，但对应的 prompt 模板还是旧的，或者训练数据的分布发生了变化，都会导致线上行为异常。所以我们内部要求模型发布必须携带完整的元数据：模型版本、训练数据版本、评估指标、上线时间、负责人。没有这套元数据，模型发布就是一个黑盒操作。
灰度发布在模型场景下比传统应用更复杂。传统应用灰度看错误率和延迟就够了，模型灰度还要看回答质量、幻觉率、指令遵循度这些内容层面的指标。这就意味着，模型灰度发布需要引入评测系统和人工抽检机制。我们目前的做法是把新模型副本的流量逐步从 5% 增加到 10%、30%、50%、100%，每一档停留时间不少于 15 分钟，由评测任务自动对比新旧版本的输出质量，出现指标下滑就自动回滚。
3. 实操：在 Kubernetes 上搭一套大模型推理服务
3.1 资源规划：显存到底怎么算
很多人在部署大模型时对显存的预估是拍脑袋的，导致 Pod 反复调度失败或者 OOM。显存占用的计算其实有规律可循，核心公式大致是：显存需求 = 模型权重显存 + KV Cache 显存 + 激活值和运行时显存。
模型权重显存 = 参数量（B）× 字节数。以 FP16 精度为例，1B 参数大约需要 2GB 显存，所以 7B 模型权重约 14GB，70B 模型权重约 140GB。量化到 INT8 可以减半，INT4 再减半，但量化会带来精度损失，上线前必须做充分的评估。
KV Cache 显存取决于序列长度、批大小和模型结构。粗略估算公式：KV Cache 字节数 = 2（K 和 V）× 层数 × 头维度 × 序列长度 × 批大小 × 字节数。对于 7B 模型，支持 4K 上下文、批大小 16 的话，KV Cache 可能额外占用 8-16GB。激活值显存相对较小，但也需要预留 10% 左右的余量。
实操建议是：以模型权重的 1.2 到 1.5 倍作为基础显存需求，再根据你的并发目标和上下文长度叠加 KV Cache 预估。比如部署 7B 模型，至少准备 32GB 显存，如果用 80GB 显存卡，可以再考虑混部小模型提升利用率。
3.2 部署编排：模型加载、探活与滚动发布
这里给一个我们生产环境用过的最小部署示例，基于 vLLM 镜像。需要说明的是，这个 YAML 精简掉了安全相关和私有镜像仓库配置，只保留核心逻辑。
apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference labels: app: llm-inference spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: llm-inference template: metadata: labels: app: llm-inference spec: containers: - name: vllm image: vllm/vllm-openai:latest args: - --model - /models/qwen-7b - --served-model-name - qwen-7b - --max-model-len - "4096" - --gpu-memory-utilization - "0.85" ports: - containerPort: 8000 name: http resources: limits: nvidia.com/gpu: "1" requests: nvidia.com/gpu: "1" readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 30 lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 20"]有几个细节值得展开说。
--gpu-memory-utilization 0.85的意思是让推理框架最多使用 GPU 显存的 85%，剩下的留给运行时和其他进程。这个值不是越大越好，我之前贪心调到 0.95，结果小幅并发波动就触发 OOM，后来稳定在 0.85 左右。
readiness probe 的failureThreshold设成 30，配合periodSeconds10，允许最长 300 秒的启动时间。大模型从冷启动到加载完成通常需要 2-5 分钟，这个阈值必须给足，否则 Pod 会被反复重启，永远进不了 Ready 状态。我们最早踩过这个坑，默认的 failureThreshold 是 3，模型还没加载完就被 kill，导致无限重启循环。
preStop里的sleep 20是给优雅下线留时间。推理请求是长连接，Pod 被删除时如果立即断连，正在生成的请求会直接中断。sleep 几十秒，等新 Pod ready、负载均衡摘除旧 Pod 后，再把进程杀掉，用户体验会好很多。
3.3 流量治理：容量预估与弹性伸缩
推理服务的容量预估和普通 Web 服务不太一样，因为它有两个独特指标：TTFT（首 Token 延迟）和 TPOT（每个输出 Token 的时间）。用户能感知到的核心体验是"第一个字多久出来"和后继 token 的流畅度。所以压测时不要只看 QPS，要把这两个指标纳入验收标准。
我们走过一段弯路：一开始用固定副本，然后发现白天流量高峰和夜间低谷差异很大，固定副本要么在高峰时排队严重，要么在低谷时大量 GPU 空转。后来引入 KEDA 做基于自定义指标的弹性伸缩，以"请求队列深度"为主要伸缩指标，配合 TTFT 作为辅助指标。队列超过阈值就扩容，TTFT 持续偏高也扩容，低谷时缩到最小副本数。
这里需要特别提醒：推理服务的弹性伸缩有一个天然的矛盾，冷启动太慢。新增一个副本要等模型加载完，最长可能 5 分钟，而流量高峰往往以秒级速度到来。所以单纯依赖 HPA 事后扩容在推理场景下是不够的，必须配合"提前扩容"的策略——比如基于定时任务预测高峰时段，提前 10 分钟扩容；或者让 KEDA 在队列深度刚开始增长时就触发扩容，而不是等到队列已经堵死了再扩。
3.4 可观测性：给模型服务装上仪表盘
模型服务可观测性的核心指标分成三类：资源类、性能类和业务类。
资源类指标有 GPU 利用率、显存占用、显存带宽、温度功耗，这些建议用 DCGM Exporter 采集。性能类指标有 TTFT、TPOT、总延迟、吞吐量、排队长度、队列等待时间，这些需要推理框架或者网关层暴露，vLLM 本身有 metrics 接口，Prometheus 直接抓取就行。业务类指标包括请求量、错误率、token 消耗量、按用户的调用分布，这些依赖网关层的业务埋点。
把三类指标打通之后，就能做很多有意思的联动分析。比如"某个客户反馈响应变慢"，先看是不是 GPU 利用率打满，再看是不是特定模型的 queue 堆积，再看是不是某个上游 prompt 特别长导致 KV Cache 占用飙升。链路追踪在模型场景也需要专门设计，当前的做法是在请求进入网关时生成 trace，贯穿"网关 -> 推理服务 -> 外部工具调用"整条链路，这样 Agent 类应用出现故障时才能快速定位问题到底出在模型调用还是工具调用。
4. 常见的坑和排查方法
4.1 冷启动超时导致 Pod 反复重启
现象：新扩容的 Pod 一直处于 CrashLoopBackOff，日志显示模型加载到一半进程被杀。
原因：Kubernetes 默认的探活机制没有给模型加载留足时间。readiness probe 失败达到阈值后 Pod 会被标记未就绪，如果 liveness probe 也失败就直接重启进程。
解决：把 readiness 的 failureThreshold 调大，给足 5 分钟；liveness probe 一般建议不做或者放宽到 10 分钟级别，避免模型加载过程中被误杀。更进阶的方案是引入模型预热服务，在模型真正加载完成之前，先由一个 sidecar 容器占用网络端口，主容器加载完毕后才切换到主容器服务。
4.2 GPU 显存碎片化导致调度失败
现象：集群剩余总显存充足，但新建 Pod 提示 GPU 资源不足。
原因：调度器把 Pod 调度到显存剩余不足的节点，或者多个 Pod 分布在不同节点，每个节点剩余显存都不够整卡需求。
解决：一是用 binpack 策略让同规格模型尽量集中，减少碎片；二是将显存请求拆小，结合推理框架的显存池，支持多个 Pod 共享一张物理卡；三是定期做 GPU 节点整理，把可迁移的 Pod 滚动重启，回收碎片化显存。
4.3 请求排队导致雪崩
现象：流量突增后服务延迟飙升，甚至整体不可用，重启后恢复。
原因：推理服务在并发超过某个阈值后，排队时间非线性增长。用户等不及超时重试，重试请求又加剧排队，形成雪崩。
解决：网关层必须配置排队和限流，而不是把请求无限透传给推理服务。具体做法是设置队列最大深度，超过就返回"服务繁忙"并配合客户端退避重试；同时在推理层设置最大并发数，与显存容量匹配，避免在请求层做无谓的超卖。扩容机制的触发阈值要比雪崩点低得多，至少留出 30% 的余量。
4.4 模型更新引发线上行为异常
现象：模型升级后回答质量波动，部分 prompt 出现完全不同的输出，某些场景幻觉率上升。
原因：模型是概率系统，权重更新后行为天然会变。即使评测集上指标相当，线上长尾 prompt 的行为也可能出现明显漂移。
解决：严格遵守灰度流程，第一档流量极低，比如 1%-5%，并且配自动评测对照。评测任务要有针对性，至少包含：标准问答集、敏感场景集、历史线上真实 prompt 的回放集。一旦质量指标低于旧版本阈值，立即自动回滚。
4.5 幻觉问题的工程化解法
幻觉在系统工程层面也有自己的治理手段。很多人以为幻觉只是模型问题，但工程上完全可以通过架构来缓解。
第一层是路由与护栏：把用户请求按领域分发到更合适的模型，或者在小模型回答前加一个"是否值得回答"的预判层。第二层是检索增强（RAG）：对于知识类问题，强制模型基于检索结果作答，并设置"检索不到就拒绝回答"的策略。第三层是输出校验：对模型输出做事实一致性校验、关键词合规校验、格式校验，不合格直接拦截重生成。这些手段叠加起来，幻觉率能显著下降，虽然不能完全消除，但能把风险控制到业务可接受的范围。
工程师排查线上问题时，不要把"模型回答得不对"简单甩给算法团队，很多回答错误其实是链路问题：检索召回了错误内容、prompt 模板写坏了、上下文截断导致信息丢失、路由规则把问题发给了不擅长该类任务的模型。先排查系统工程链路，再归因到模型本身，顺序不能反。
5. 我的一些体会和建议
这一年多下来，如果说有什么最深刻的教训，那就是不要一开始就追求"全自动、全智能"的系统。AI 落地的系统工程是一个逐步成熟的过程，哪怕你现在只是手动管理十几个模型副本，也比搭建一个半生不熟的全自动平台更可靠。先得跑得稳，再谈跑得巧。
具体到操作层面，我强烈建议团队先建立一套"模型版本 + 服务配置 + 评测报告"三位一体的档案。每次模型上线，这份档案里要有权重文件哈希、推理框架版本、prompt 模板版本、评测集得分、线上灰度数据。没有这套档案，遇到问题根本无从回滚——你不知道当前跑的是哪一版，也不知道上一版好在哪。
另外，GPU 成本是 AI 落地系统工程里绕不开的议题。优化思路不要只盯着显卡利用率一个指标，要结合业务收益来看。有些请求用 7B 模型就够了，没必要都挤到 70B 上去。做一个模型路由层，把简单的任务分给小模型、难的任务分给大模型，成本能省下一大截，而且用户几乎感知不到差异——这个工作在行业里已经有不少成熟模板可以抄。
最后再说一句，我在 KubeCon 2026 上海现场最直观的感受是：AI 基础设施的工具链正在快速收敛，标准化的推理服务、GPU 调度、模型管理方案会像当年的容器编排一样普及。现在花时间把系统工程的底子打好，等下一波模型能力升级时，你就能比别人跑得更稳、更快。