1. 课程导学与AI推理基础：了解大模型推理的挑战，vLLM是什么，为什么选择在K8s上部署

1.1 大模型推理到底难在哪？

说实话，我刚接触大模型推理时，也被吓了一跳。

你想想看，一个几百亿参数的模型，光是加载到显存里就要几十GB。更别提每次推理还要做自回归生成，一个字一个字往外蹦。这跟传统的小模型推理完全是两码事。

大模型推理的核心挑战，我总结为三点：

• 显存瓶颈：模型参数 + KV Cache 会吃掉大量显存。我见过一个 70B 的模型，单卡 A100 根本放不下，必须做模型并行。
• 推理延迟：自回归生成是串行的，生成长文本时延迟会线性增长。用户等得不耐烦，老板催得紧。
• 吞吐量低：传统推理框架在批量处理时效率极低，因为每个请求的序列长度不一样，GPU 利用率上不去。

我在项目中遇到过最头疼的事：一个客户要求每秒处理 100 个请求，每个请求生成 512 个 token。用普通的推理框架，单机根本跑不动，集群调度又乱七八糟。嗯，那时候我就意识到，必须有一套专门为 LLM 推理优化的引擎。

1.2 vLLM 是什么？

vLLM 是一个专门为大模型推理加速的开源引擎。说白了，它解决的就是上面提到的那些痛点。

它的核心创新点，我列一下：

• PagedAttention：这是 vLLM 的杀手锏。它把 KV Cache 按页管理，像操作系统的虚拟内存一样，解决了显存碎片和浪费问题。我刚开始看论文时还不太信，直到自己跑了一遍 benchmark，发现显存利用率提升了 2-4 倍。
• 连续批处理：vLLM 支持动态的请求调度，不用等所有请求都准备好再一起推理。来一个处理一个，GPU 始终满载。
• 高性能推理内核：底层用了 FlashAttention 等优化技术，计算效率拉满。

vLLM 支持的主流模型包括 LLaMA、Mistral、Qwen、ChatGLM 等。基本上，只要是用 Transformer 架构的 decoder-only 模型，它都能跑。

1.3 为什么选择在 K8s 上部署？

这个问题，我其实纠结过很久。

单机部署 vLLM 很简单，docker run 一下就行。但生产环境哪有这么简单？

我总结了几点理由：

1. 弹性伸缩：大模型推理的流量波动很大。白天高峰期可能需要 10 个副本，晚上低谷期 2 个就够了。K8s 的 HPA 可以自动扩缩容，省成本。
2. 资源隔离：GPU 是稀缺资源。K8s 通过 device plugin 可以精确控制每个 Pod 使用哪张卡，避免互相抢占。
3. 高可用：单机挂了怎么办？K8s 的 Deployment + Service 可以保证服务不中断。我经历过一次节点宕机，K8s 自动把 Pod 调度到了另一台机器上，用户几乎无感知。
4. 统一管理：如果你的团队同时跑多个模型（比如一个 7B 的聊天模型，一个 70B 的代码模型），K8s 的 Namespace 和 ResourceQuota 可以帮你做精细化管理。

1.4 整体架构长什么样？

我画了一张图，帮你理解 vLLM 在 K8s 上的部署架构：

这张图展示的是最典型的部署方式。用户请求通过 Ingress 进入，K8s Service 做负载均衡，把请求分发到多个 vLLM Pod 上。每个 Pod 独占一张 GPU，HPA 根据 CPU/GPU 利用率自动调整副本数。

1.5 课程能带给你什么？

这门课不是纯理论，也不是纯操作。我会把两者结合起来。

具体来说，你会学到：

• vLLM 的核心配置参数，每个参数背后的原理
• 如何在 K8s 上编写 vLLM 的 Deployment YAML，包括 GPU 调度、资源限制
• 如何做性能调优，比如调整批处理大小、KV Cache 策略
• 生产环境中的避坑指南——这部分我会多讲一些真实案例

好了，第一章就到这里。记住一句话：大模型推理不是玄学，是工程。掌握了正确的工具和方法，你也能搭建出稳定高效的推理服务。