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 模型权重约 14GB70B 模型权重约 140GB。量化到 INT8 可以减半INT4 再减半但量化会带来精度损失上线前必须做充分的评估。KV Cache 显存取决于序列长度、批大小和模型结构。粗略估算公式KV Cache 字节数 2K 和 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 调度、模型管理方案会像当年的容器编排一样普及。现在花时间把系统工程的底子打好等下一波模型能力升级时你就能比别人跑得更稳、更快。