llm-d 是什么？为什么说 LLM 推理正在云原生化？

大模型从实验走向生产后，平台团队开始遇到一批新问题：推理请求延迟高、GPU 利用率不稳定、KV Cache 占用大、不同模型需要不同加速器、扩容缩容不能只看 CPU。传统 Web 服务的部署经验还不够，LLM 推理正在变成一种新的云原生工作负载。

llm-d 就是这个趋势下的项目。CNCF 项目页显示，llm-d 是 Kubernetes-native 的高性能分布式 LLM 推理框架，基于 vLLM 和 Kubernetes Gateway API Inference Extension，支持智能推理调度、前缀缓存感知路由、prefill/decode 分离、KV 分层卸载，以及面向流量和硬件的自动伸缩。

为什么 LLM 推理和普通服务不一样

普通 HTTP 服务大多关注 QPS、CPU、内存、连接数。LLM 推理还要关注：

• 首 token 延迟。
• 输出 token 速度。
• 输入输出 token 数量。
• KV Cache 命中率。
• prompt 长度差异。
• GPU 显存碎片。
• prefill 和 decode 阶段资源差异。

这意味着“请求进来随便找一个 Pod”不再足够。平台需要更懂模型、更懂 GPU、更懂缓存的调度和路由。

llm-d 关注哪些能力

从运维角度看，llm-d 不是简单再部署一个推理服务，而是把 LLM 推理拆成可调度、可扩缩、可观测的云原生系统。

关键能力包括：

• 基于 Kubernetes 的部署和调度。
• 基于 vLLM 的推理能力。
• prefix cache aware routing，避免相似请求反复浪费计算。
• prefill/decode disaggregation，把不同阶段拆开优化。
• 面向 NVIDIA、AMD、Intel、Google TPU 等不同加速器。
• 结合 Gateway API Inference Extension 处理推理流量入口。

这说明未来 AI 平台运维不只是会部署模型，还要理解推理请求路径。

运维人员应该怎么入门

第一步，先理解模型服务基础：

• 模型权重如何加载。
• 显存如何占用。
• batch size、max tokens、并发数如何影响延迟。
• vLLM、TensorRT-LLM、TGI 等推理引擎有什么区别。

第二步，理解 Kubernetes 资源：

kubectl get deploy,svc,pod -n <namespace>
kubectl top pod -n <namespace>
kubectl describe pod <model-pod> -n <namespace>
kubectl logs <model-pod> -n <namespace>

第三步，加入 GPU 维度：

nvidia-smi
kubectl get nodes -L nvidia.com/gpu.product
kubectl describe node <gpu-node>

第四步，加入推理指标：首 token 延迟、token throughput、错误率、GPU 利用率、显存使用率。

适合什么场景

llm-d 这样的方向适合：

• 企业内部自建大模型推理平台。
• 多模型、多租户、多加速器集群。
• 希望用 Kubernetes 统一管理 AI 工作负载。
• 希望优化推理成本和 GPU 利用率。

如果只是单机跑一个小模型，直接使用 vLLM 或 Ollama 可能更简单。不要为了追新把系统复杂度拉满。

常见问题 FAQ

llm-d 是模型吗？

不是。它是围绕 LLM 推理的基础设施框架，不是某个具体模型。

llm-d 和 vLLM 是什么关系？

llm-d 基于 vLLM 等推理能力，把分布式推理、路由和 Kubernetes 集成做成平台能力。

运维学习它的价值是什么？

它代表 LLM 推理正在进入 Kubernetes 平台工程范畴。未来 AI 平台运维会越来越需要理解这类架构。

现在生产能不能直接上？

要谨慎评估。CNCF Sandbox 说明方向有价值，但仍处于较早成熟度。适合先做 PoC 和学习验证。

参考资料

• CNCF llm-d 项目页: https://www.cncf.io/projects/llm-d/
• CNCF: Welcome llm-d to the CNCF: https://www.cncf.io/blog/2026/03/24/welcome-llm-d-to-the-cncf-evolving-kubernetes-into-sota-ai-infrastructure/