大模型部署适用场景：面向已有 Kubernetes 集群、需要部署推理服务的团队；本文讨论通用上线链路，不绑定单一推理框架，不承诺特定吞吐、延迟或成本结果。
大模型部署到 K8s 时，失败常常不是单点配置写错，而是资源、镜像、模型文件和服务暴露没有形成一致基线。GPU Pending、镜像拉取慢、模型加载超时、探针误判，都会让推理服务看似已经部署，实际却无法稳定接流量。
因此上线前要先把“资源可调度、镜像可拉取、模型可加载、服务可验证”串成最小闭环，再进入具体配置。
图1：大模型部署到 K8s 时从资源申请到服务验证的上线路线图
先确定大模型部署的最小上线链路
一个可上线的大模型服务，至少要回答四类问题：Pod 能否被调度到带 GPU 的节点，镜像能否稳定拉取，模型文件从哪里加载，服务如何被访问和验证。
最小链路可以拆成：
- 资源：GPU、CPU、内存、显存、临时存储和节点标签。
- 镜像：基础运行时、推理框架、模型依赖、镜像仓库和拉取策略。
- 模型文件：镜像内置、PVC 挂载、对象存储拉取或 Init Container 准备。
- 服务暴露：Service、Ingress、Gateway、推理网关或内部 API。
- 验证：健康检查、启动时间、首 token 延迟、错误率、日志和指标。
站内已有“大模型推理部署怎么做”“模型推理和模型训练有什么区别”等内容可在发布前确认正式 URL 后作为延伸阅读；当前草稿不保留未确认链接。
GPU 资源要让调度器和运行时都看得见
Kubernetes 通过设备插件机制让节点向集群暴露硬件设备资源，例如 GPU；Pod 需要在资源请求中声明对应扩展资源，调度器才会把它放到具备该资源的节点上<sup>[1]</sup>。NVIDIA GPU 场景通常还需要安装并维护 NVIDIA device plugin 或配套 GPU Operator<sup>[1]</sup>。
| 检查项 | 常见问题 | 验证方式 |
|---|---|---|
| 节点 GPU 可见 | 节点没有上报 GPU 资源 | `kubectl describe node` 查看 allocatable |
| Pod 资源声明 | 未声明 GPU 或资源名错误 | 检查 `resources.limits` |
| 节点标签 | 调度到无模型缓存或无 GPU 节点 | 使用 nodeSelector / affinity |
| 驱动运行时 | 容器内无法访问 GPU | 查看容器日志和 NVIDIA 工具输出 |
| 配额限制 | 命名空间资源配额不足 | 查看 ResourceQuota 和事件 |
GPU requests 和 limits 要按集群策略确认
Kubernetes 对 CPU、内存和扩展资源的调度依赖资源请求与限制；GPU 等扩展资源通常以整数设备形式声明，具体资源名和切分方式取决于设备插件或平台策略<sup>[1]</sup>。因此上线前要确认当前集群是整卡、MIG、时间片还是其他共享方式，不能直接复制别的环境 YAML。
镜像和模型文件要分开设计
大模型镜像常见问题是体积过大、依赖复杂、启动慢和拉取失败。把模型权重直接打进镜像可以简化运行时依赖，但会导致镜像巨大、版本更新慢；把模型放到 PVC 或对象存储更灵活，但需要处理下载时间、缓存一致性和权限。
图2：GPU 资源、推理镜像、模型文件和启动流程之间的过程匹配
常见组合方式：
- 镜像内置模型：部署简单，适合小模型或固定版本；缺点是镜像大、更新慢。
- PVC 挂载模型：适合复用模型缓存；要关注存储吞吐、权限和多副本读写。
- Init Container 下载：适合按版本拉取模型；要控制启动时间和失败重试。
- 对象存储运行时加载：适合模型版本多的场景；要关注网络、鉴权和缓存策略。
镜像拉取策略影响发布速度
Kubernetes 的镜像拉取行为由镜像名、tag、digest 和 `imagePullPolicy` 等因素共同影响<sup>[2]</sup>。大模型镜像体积通常较大，建议在生产发布前确认镜像仓库连通性、节点缓存策略、镜像版本不可变性和失败重试策略。不要在关键发布窗口首次拉取超大镜像。
Deployment、Service 和探针要服务上线验证
大模型推理服务启动时间可能显著长于普通 Web 服务，因此探针配置要避免过早判定失败。Kubernetes 支持 startupProbe、readinessProbe 和 livenessProbe，用于区分启动阶段、是否可接流量以及容器是否需要重启<sup>[3]</sup>。
apiVersion: apps/v1
kind: Deployment
metadata:
name: llm-inference
spec:
replicas: 1
selector:
matchLabels:
app: llm-inference
template:
metadata:
labels:
app: llm-inference
spec:
containers:
- name: server
image: registry.example.com/llm/inference:1.0.0
ports:
- containerPort: 8000
resources:
limits:
nvidia.com/gpu: 1
startupProbe:
httpGet:
path: /healthz
port: 8000
failureThreshold: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8000
periodSeconds: 5上面只是结构示例，具体镜像、资源名、探针路径和阈值必须按推理框架、模型加载时间和集群 GPU 策略调整。
服务暴露要区分内部调用和外部入口
模型服务可能只给内部应用调用，也可能需要通过 API 网关、Ingress 或推理网关对外提供服务。通常可以先用 Service 提供集群内稳定访问，再按认证、TLS、灰度和流量策略决定是否接入 Ingress、Gateway 或专用推理网关。
暴露方式可以按场景选择：
- ClusterIP：只给集群内应用调用，适合内部推理服务。
- Ingress / Gateway：需要 HTTP 路由、认证、TLS 和灰度时使用。
- 专用推理网关：需要配额、模型路由、多模型版本和审计时更合适。
- 批处理入口：离线推理或异步任务可通过队列、Job 或工作流系统触发。
图3：大模型服务上线前围绕资源、镜像、模型、服务和观测的决策路
验证不只看接口返回 200
大模型服务上线后，仅看健康接口返回成功是不够的。还要观察模型加载耗时、显存使用、请求排队、首 token 延迟、错误率、超时和节点资源水位。没有观测数据时，很难判断是模型服务本身慢，还是 GPU 调度、存储读取或入口限流导致异常。
上线前至少检查：
- GPU 节点、设备插件和资源配额是否正常。
- 镜像是否已推送到生产可访问仓库，tag 或 digest 是否固定。
- 模型文件来源、版本、校验和和访问权限是否明确。
- startupProbe 是否覆盖模型加载时间，readinessProbe 是否代表可接流量。
- Service、Ingress 或 Gateway 是否有认证、限流和超时策略。
- 日志、指标和 Trace 是否能定位到模型版本、请求 ID 和错误类型。
小结
大模型部署到 K8s 的关键是把资源、镜像、模型文件和服务暴露作为一条上线链路设计。GPU 资源决定能否调度，镜像和模型文件决定能否稳定启动，Service 与入口策略决定能否安全接流量，观测验证决定能否持续运行。团队可以先跑通单模型最小闭环，再逐步补充灰度、多模型路由和自动扩缩容。
参考资料
- [1] Kubernetes Device Plugins – 官方文档
- [2] Kubernetes Images – 官方文档
- [3] Kubernetes Configure Liveness, Readiness and Startup Probes – 官方文档
常见问题
大模型部署到K8s一定要使用 GPU 吗？
不一定，小模型、量化模型或低并发场景可以使用 CPU，但生产推理通常需要评估 GPU、显存和吞吐需求。是否使用 GPU 取决于模型规模、延迟目标、并发量和成本约束。
模型文件应该放进镜像还是挂载存储？
固定小模型可以放进镜像以简化部署；大模型或频繁更新的模型更适合使用 PVC、对象存储或 Init Container 拉取。选择时要权衡镜像体积、启动时间、版本管理和权限控制。
大模型部署后如何判断服务真的可用？
除了健康检查，还要验证真实推理请求、模型版本、显存占用、错误率、超时、首 token 延迟和日志链路。生产环境建议把这些指标纳入发布验证和回滚条件，而不是只看 Pod Running。
