企业级大模型落地二：基于K8s、VLLM、LiteLLM、vGPU落地高可用AI网关和大模型

如果你已经能把一个开源模型跑在自己的显卡上，回答几个问题，那么下一步真正卡住你的，通常不是模型本身，而是：多个人要同时用，模型怎么放、显存怎么切、请求怎么排队、接口怎么统一、某个节点挂了怎么办。这门课处理的就是这一层问题——把单机跑通的大模型，变成企业内部可持续提供服务的 AI 网关和大模型服务。

先确认你是不是这门课的目标读者

几种典型情况，对上一种就说明这门课对你有效：

• 单机能跑 vLLM，但没在 K8s 里部署过，不知道 GPU 是怎么被 Pod 申请和分配的。
• 团队只有一两张卡，却要同时服务多个业务方，不知道怎么把一张物理卡切给多个负载。
• 线上接了多个模型（本地 vLLM、外部 API 混合），每个业务各写一套调用代码，想收口成统一网关。
• 模型服务上线后经常被打爆或超时，需要限流、缓存、多实例负载均衡，但没做过这类改造。

如果以上都不沾边，只是想让模型在自己电脑上跑起来，那这门课偏重基础设施侧，不是你当前需要的。

课程主线：三段能力缺口

第一段：K8s 里的 GPU 到底是怎么被用起来的

不搞清楚 Device Plugin 和 GPU Operator 这条链路，后面所有调度问题都会变成玄学。这一段要解决的是：GPU 作为一种特殊资源，如何被 K8s 识别、上报、分配给具体容器；驱动、容器运行时、调度器各自负责哪一部分。很多人部署失败，卡点就在这一层没打通。

第二段：vGPU 与显存切分，让一张卡承载多个负载

企业里最常见的现实是卡不够。这段围绕 vGPU 调度展开，重点是把物理 GPU 的算力和显存按需切分给不同模型或不同租户，并让 K8s 能按切分后的粒度调度。你需要在这里建立起「资源怎么分、隔离边界在哪、切多了会出什么问题」的判断力。

第三段：vLLM 服务化 + LiteLLM 网关

vLLM 负责把模型跑成高吞吐的推理服务，LiteLLM 负责把它收成一个统一入口。这一段的具体内容包括：用 vLLM 部署大模型并接入 K8s；用 LiteLLM 搭建网关层，做多模型路由、限流和缓存；最后把两者拼成高可用结构——多副本、健康检查、故障转移。限流和缓存不是可选项，它们决定了你的服务在真实并发下会不会崩。

配套练习应该怎么用

这门课的价值集中在动手环节，建议按下面的顺序自检，而不是看完视频就算过：

• 能独立把一个 GPU 节点接入集群，并确认调度器看得见这块卡。
• 能把一块卡切成多份，让两个不同的推理负载同时跑起来且互不干扰。
• 能把 vLLM 服务部署成多副本，并验证杀掉其中一个实例后请求仍能正常返回。
• 能在 LiteLLM 侧配出限流规则，并实际压出触发限流的效果。
• 能说清楚缓存命中与不命中时，请求分别走到了哪里。

做不到其中任何一条，就回到对应章节重做一遍，别急着往下走。

学完之后，你应该能回答这些问题

• 一个 Pod 申请 GPU 时，从提交到真正拿到设备，中间经过了哪些组件？
• vGPU 切分粒度定得太细或太粗，分别会带来什么后果？
• vLLM 多副本前面挂 LiteLLM，请求是怎么被分发的，某个副本不健康时如何被摘掉？
• 限流和缓存放到网关层而不是模型层，理由是什么？
• 私有化场景下，这套结构的瓶颈最可能出现在哪一环？

这些问题答不上来，说明你只是跟着敲了一遍命令；能答上来，才说明这套 AI 基础设施你真的能自己搭、自己排障。