5.2 演进方向与生态展望：K8s 上的大模型推理会往哪走

5.2 演进方向与生态展望：K8s 上的大模型推理会往哪走

写这一节有点诚惶诚恐。预测技术方向这事，我吃过不少亏——2023 年我赌 MoE 不会很快进生产，结果 2024 年一堆团队就在跑 DeepSeek-MoE 了；2024 年我觉得 disaggregated prefill 还只是论文里的概念，结果 2025 年就有团队在 POC。所以我下面说的方向，都是我自己在跟进、在 POC、或者至少在生产集群上做过小规模验证的，而不是"我看了一篇 paper 觉得有道理"。即便如此，也要提醒一句：到 2026 年你读这段的时候，有些方向可能已经落地、有些可能被证明是死路，具体以你那时的官方文档和实测为准。

方向一：KV Cache 的卸载与分层存储

这是我自己最看好的一个方向，因为它直接打在了一个最痛的点上：长上下文的显存爆炸。

现在的状况是，KV Cache 占的显存经常比权重还多。一个 GLM-5.2 32B 的模型，权重按 INT8 算 32GB，但你要跑 32K 上下文、batch 16，KV Cache 轻松吃掉 60GB 以上。这导致一个反直觉的现象——你买了 H100 80GB，跑长上下文的时候 KV Cache 撑爆显存，权重明明只占一半，但你还是 OOM。

KV Cache 卸载（offloading）的思路就是把那些"暂时用不到"的 KV Cache 移到 CPU 内存或者本地 NVMe 上，显存里只留当前正在 decode 的那部分。vLLM 社区里的 LMCache、SGLang 的 cache 管理，都是往这个方向走。我自己在测试集群上跑过一版基于 CPU offload 的方案，长上下文场景的显存占用降了 40% 左右，代价是 prefill 阶段慢了大概 30%——这个取舍在长上下文为主的场景里是值的，因为 prefill 本来就是一次性的、decode 才是高并发瓶颈。

坑也有。最大的坑是 CPU offload 的数据搬运带宽——如果你的节点是 PCIe Gen4，CPU↔GPU 的带宽 25GB/s 看着挺多，但真要搬几十 GB 的 KV Cache，搬运本身的延迟就不容忽视。我在做 POC 的时候发现，单纯粗暴地把所有 KV Cache 都 offload 反而比不 offload 还慢，因为搬运开销超过了显存释放的收益。所以这块的关键是"分层"——热数据留显存、温数据放 CPU、冷数据放 NVMe，根据访问频率动态调度。这套东西目前还没完全成熟，但方向是对的，我建议持续跟进 vLLM Production Stack 集成 LMCache 的进展。

方向二：disaggregated prefill（prefill / decode 分离）

这个方向更激进，原理上其实不复杂：prefill（生成第一个 token 的阶段）是计算密集型，要算大量 attention；decode（逐 token 解码）是访存密集型，每次只算一个 token。这两个阶段对硬件的需求完全不一样，混在一个实例里跑，意味着你的 GPU 既要算力拉满又要带宽拉满，但实际上任意时刻只有一个维度在工作，硬件利用率天然有浪费。

分离架构就是把 prefill 和 decode 拆到不同的实例组，用不同硬件配比。比如 prefill 组用算力强的 H100 SXM，decode 组用带宽强但算力相对便宜的卡（或者反过来，看你优化哪个维度）。中间用一个 KV Cache 传输通道把 prefill 算完的 KV 传给 decode 实例继续解码。

这事听上去美好，落地难点在 KV Cache 的传输。GLM-5.2 这种模型，一个请求 prefill 完的 KV 可能几个 GB，要快速从 prefill 节点传到 decode 节点，普通以太网扛不住，得上 RDMA 或者 NVLink 跨节点（如果硬件支持）。我看过几个团队的 POC，结论是收益巨大但工程复杂度也巨大——你需要自己实现调度、路由、KV 传输协议，目前没有开箱即用的稳定方案。我的判断是，2026 年下半年到 2027 年这块会开始有相对成熟的工程化方案出来，现在更多是大厂内部的探索。中小团队跟进的性价比暂时不高，但一定要知道这个方向，因为它代表了推理架构的下一个范式。

方向三：国产算力适配

如果你的集群是国产化路线，这块绕不开。GLM-5.2 已经做了 Day-0 的国产加速卡适配，比如昇腾系列。我在国产卡上跑大模型推理的真实体感是：理论性能跟 NVIDIA 同档次卡差不多，但生态成熟度差一大截。具体表现就是——同一个 vLLM 版本，在 NVIDIA 上跑得好好的，换到昇腾上经常因为算子缺失或者精度对不上要等框架方适配，等的过程很煎熬。

我的建议是：如果你必须走国产化，优先选有官方推理框架支持（比如 MindIE 之于昇腾）的方案，不要试图自己在 CUDA 兼容层上硬跑 vLLM，那条路我走过，坑深到让人怀疑人生。同时一定要有 fallback 方案——同一套部署清单能在 NVIDIA 上跑通，国产卡出问题的时候能临时切回去，否则国产化的稳定性风险会直接影响业务。

这块我比较乐观的地方是国产算力这几年的迭代速度确实快，从"勉强能跑"到"性能接近"用了不到两年。但生态成熟度这个东西急不来，得等。

方向四：基于大模型特征的调度与扩缩容

传统的 K8s HPA 是按 CPU 利用率扩缩容，对大模型推理基本无效——大模型推理瓶颈是 GPU，CPU 经常是闲的。直接按 GPU 利用率扩缩容也不够准，因为 GPU 利用率高不等于服务过载（也可能是某个长请求在算），利用率低也不等于能加并发（可能显存已经满了）。

真正有用的扩缩容信号，我自己的实践有这么几个：请求队列长度（vLLM 暴露的 vllm:num_requests_waiting 指标）、KV Cache 使用率、平均请求延迟。基于这些指标做扩缩容，比基于 CPU 准确得多。但 K8s 原生 HPA 不直接支持自定义指标扩缩容，要上 Prometheus Adapter 或者 KEDA，配置略繁琐。

更进一步是"预测式扩缩容"——大模型的流量很多时候有明显的周期性（白天高峰、夜间低谷），如果能基于历史流量预测提前扩容，就能避开冷启动的延迟（大模型 Pod 冷启动几分钟，等 HPA 触发已经晚了）。这块目前还没有特别成熟的开源方案，我看到一些团队在用自定义的 cron + 历史数据预测来触发扩容，效果不错但工程量不小。我判断这块会是未来一两年 K8s 大模型生态的重点方向之一。

方向五：服务网格与多模型路由

最后一个方向是运维层面的。当你集群里不止一个模型（比如同时跑 GLM-5.2、GLM-5.2-Flash、还有几个垂直小模型）的时候，怎么路由请求、怎么做多模型的负载均衡、怎么做模型版本的金丝雀发布，就变成一个独立的工程问题。

传统的 Istio / Linkerd 这些服务网格是为微服务设计的，对大模型推理的某些特性（比如长连接、流式响应、KV Cache 亲和）支持得不算好。我自己更倾向于写一个轻量的专用 router，按模型名 + session 亲和 + 实例负载做路由。这块的开源生态目前还比较散，KServe、vLLM Production Stack、Ray Serve 各有各的方案，没有统一的赢家。我建议关注 KServe 的演进，它的定位最贴近 K8s 原生，长期看可能是最稳的选择。

金丝雀发布这块特别值得提一句。大模型版本切换和传统微服务不一样——你不能简单按流量百分比切，因为同一个用户的多次请求如果打到不同版本，体验会很奇怪（前后回答风格不一致）。我自己的做法是按 user_id 做哈希分流，保证同一个用户始终打到同一个版本，新版本先放给 5% 的内部测试用户，观察一天没问题再逐步放量到 25%、50%、100%。这种"按用户粒度灰度"的策略，比按请求粒度灰度更适合大模型场景。

别忘了"反向"的方向：什么时候不该上 K8s

讲了一堆"K8s 上大模型推理的未来方向"，我想反过来聊一个容易被忽视的问题——什么时候你不应该用 K8s 跑大模型推理。这事我必须说，因为我见过太多团队为了"显得现代化"，把根本不需要 K8s 的场景硬塞进 K8s，反而把简单的事搞复杂。

判断标准其实很朴素。如果你的场景是：单机就能跑下（一张或几张卡）、不需要高可用（挂了重启就行）、流量稳定没波动、不追求弹性扩缩容——那 K8s 是过度设计。一个 docker-compose 加一个 systemd 服务，维护成本低一个数量级，出问题排查也简单。我自己维护过一些内部工具型的推理服务，就是裸机 + docker 跑，几年没出过事。

反过来，K8s 真正发挥价值的场景是：多副本需要调度、需要根据流量弹性扩缩容、需要跨节点故障转移、需要和其他微服务统一管理。这些场景下 K8s 的工程投入才值得。所以选不选 K8s 不是"先进 vs 落后"，是"匹配 vs 不匹配"。盲目上 K8s，会让你的大模型推理服务从"简单"变成"复杂"，但实际收益可能为零。

给你的真心话

讲完五个方向，我想说几句不那么技术的话。这本教程写到这里，其实最想交付给你的不是任何一个具体方向，而是一种判断力——当你看到一个新技术、新论文、新框架的时候，怎么判断它值不值得跟进。

我自己的判断标准大概有这么几条：第一，它解决的是不是我真实遇到的痛点？paper 里解决"想象中的痛点"的东西太多了。第二，它的工程复杂度和收益是否匹配？有些方向理论上很美，但工程落地成本超过团队能承受的范围，那就是别人的方向不是你的。第三，它的生态成熟度到了什么程度？再好的想法，如果只有一两个团队在做、没有开源社区支撑，跟进风险都很高。

disaggregated prefill 我判断是"未来 1-2 年值得重点投入"，因为它打的是真实的硬件利用率痛点，社区也开始有方案了。KV Cache 分层存储我判断是"现在就该开始 POC"，因为收益直接、复杂度可控。国产算力是"看你的业务约束决定"，不是技术问题是政策问题。智能调度是"中小团队可以先用 KEDA + 自定义指标快速落地"。多模型路由是"等 KServe 之类成熟后再说，别自己造轮子"。

最后，教程教的是一条验证过的路，但你的集群、你的流量、你的卡，才是真正的考场。K8s 上的大模型推理这个领域变化太快，任何教程都有保质期。我能给你的最好建议是：把原理吃透、把压测做真、把监控补齐，把这份清单和这几个方向当作你判断的起点，而不是终点。这样当下一个新模型、新硬件、新框架出来的时候，你不再需要任何教程告诉你该怎么做，你自己就能判断该怎么走。这，才是"从能跑到用好"的真正含义。