在 Kubernetes 上构建 AI 基础设施，GPU 治理 / 推理平台 / 模型治理 并不是孤立组件，而是一个强耦合的系统工程。
其核心目标只有一句话：
用最少的 GPU 成本，稳定支撑可规模化的 AI 服务。
一、整体技术架构分层（增强版）
二、底层：GPU 资源治理（补强版）
2.1 精细化调度与隔离（必做）
要实现 GPU 资源的有效治理，首先要实现精细化调度。这包括为 GPU 节点打上特定标签，并设置污点（Taint），以确保只有特定的 Pod 才能调度到这些昂贵的 GPU 节点上。
# GPU 节点打标签
kubectl label node gpu-node-1 accelerator=nvidia-a100
# GPU 节点加污点
kubectl taint node gpu-node-1 nvidia.com/gpu=present:NoSchedule
相应地，推理服务 Pod 需要通过容忍（Tolerations）来声明它可以接受这个污点。
# 推理 Pod 容忍 GPU 污点
tolerations:
- key: “nvidia.com/gpu”
operator: “Exists”
effect: “NoSchedule”
👉 结论：
GPU 节点 必须专用，这是所有 AI 平台稳定性的前提。
2.2 GPU 共享与超配（推理必备）
将一整张 GPU 卡只分配给一个推理服务通常会造成资源浪费。在实践中，我们需要根据场景选择合适的 GPU 共享技术来提升利用率。
| 技术 |
适用场景 |
| MIG |
强隔离、稳定 SLA |
| Time-Slicing |
高并发推理 |
| 小数 GPU |
云厂商特性 |
| DRA（趋势） |
动态 GPU 能力分配 |
未来趋势：
GPU 不再是「数量」，而是「能力集合（显存 / 带宽 / NVLink / RDMA）」。
2.3 自动化运维与健康监控
GPU 的稳定运行离不开完善的监控体系。这通常由以下组件构成：
- NVIDIA GPU Operator：自动化部署和管理 GPU 驱动、容器运行时等。
- DCGM Exporter：采集 GPU 各项指标。
- 核心监控项：GPU 温度、显存使用率、ECC 错误、计算利用率等。将这些指标集成到你的 云原生 监控栈中是至关重要的一步。
三、中层：推理平台与服务化（重点增强）
这是 LLM 成败的核心层，直接决定了服务的性能、成本和扩展性。
3.1 为什么必须是 vLLM
对于生产级的大语言模型（LLM）推理，选择合适的推理引擎是关键。vLLM 凭借其核心创新已成为事实标准。
| 能力 |
vLLM |
| PagedAttention |
✅ |
| KV Cache 复用 |
✅ |
| 高并发 |
✅ |
| 多模型 |
✅ |
👉 结论：
生产级 LLM 推理，vLLM 已经是事实标准。
3.2 引入 Kthena Router：Prompt-aware 调度
核心思想
不同 Prompt，成本完全不同
传统的负载均衡器无法感知请求的复杂性。一个长上下文提示（Prompt）和一个简短聊天的提示，对 GPU 显存（尤其是 KV Cache）的压力截然不同。
| Prompt 类型 |
代价 |
| 短 Chat |
显存友好 |
| 长上下文 |
KV Cache 杀手 |
| Batch |
吞吐优先 |
架构
引入 Kthena Router 这类智能路由组件，可以根据 Prompt 的长度、类型等信息，将请求智能地路由到最合适、最“空闲”的后端 vLLM 实例，从而实现全局资源的最优利用。
3.3 KV Cache 治理（核心差异点）
为什么 KV Cache 必须治理？
- KV Cache = 显存炸弹。它是 Transformer 模型推理时占用显存的大户。
- 无治理 = GPU 利用率 < 40%。大量显存被无法复用的 KV Cache 占据，导致实际能并发的请求数锐减。
Kthena 提供能力
一个优秀的推理平台需要具备 KV Cache 治理能力，例如：
- KV Cache 感知路由：将可能命中缓存的请求（如同主题对话的后续轮次）路由到同一实例。
- Cache 命中优先调度。
- Decode 阶段复用。
👉 实测收益：
3.4 vLLM 生产级 Deployment（示例）
以下是一个在 Kubernetes 中部署 vLLM 服务的基础示例。注意其中的资源请求、容忍度以及优先级设置。
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-qwen
namespace: llm-inference
spec:
replicas: 2
selector:
matchLabels:
app: vllm-qwen
template:
metadata:
labels:
app: vllm-qwen
spec:
priorityClassName: llm-online-high
tolerations:
- key: “nvidia.com/gpu”
operator: “Exists”
containers:
- name: vllm
image: vllm/vllm-openai:latest
args:
- “--model=Qwen/Qwen2-7B”
- “--tensor-parallel-size=1”
- “--max-model-len=8192”
resources:
limits:
nvidia.com/gpu: 1
3.5 Kthena Router（Prompt-aware）示例
智能路由器的部署示例如下，它通过环境变量控制路由策略。
apiVersion: apps/v1
kind: Deployment
metadata:
name: kthena-router
namespace: llm-inference
spec:
replicas: 2
template:
spec:
containers:
- name: router
image: kthena/router:latest
env:
- name: PROMPT_TOKEN_THRESHOLD
value: “2048”
- name: ENABLE_KV_AWARE_ROUTING
value: “true”
四、顶层：模型治理与安全（增强）
当平台能够稳定运行后，治理与安全便成为保障服务质量与合规性的关键。
4.1 模型版本 & 输出治理
每次推理请求，必须能回答 3 个问题：
- 用的哪个模型？（版本、哈希）
- 用的什么参数？（Temperature, Top-p 等）
- 输出是否异常？（内容、分布）
👉 推荐实施：
- Prompt Hash
- Model Version 标识
- Sampling Params 记录
- 输出分布监控（如拒绝率、特定 token 分布）
4.2 LLM 安全防护（必备）
人工智能 服务，尤其是大语言模型，面临独特的安全挑战：
- Prompt 注入：诱导模型突破预设指令。
- 越权指令：执行非授权的操作。
- 内容合规：输出违法、有害或不适当的内容。
需要在 API 网关或路由层集成相应的安全过滤模块。
4.3 成本与 SLA 治理
必须建立核心指标体系，并持续监控：
| 指标 |
必须监控 |
| GPU 利用率 |
✔ |
| QPS (每秒查询数) |
✔ |
| P99 延迟 |
✔ |
| Token / 秒 |
✔ |
| GPU-小时 (成本) |
✔ |
五、训练 & 推理混部（工程级）
为了最大化 GPU 集群利用率，训练任务和推理服务混部是常见场景，但需要严格的规则。
核心规则
- 推理 最高优先级：在线服务延迟敏感，必须优先保障。
- 训练 可抢占：离线训练任务应允许被高优先级的推理任务抢占资源。
- 必须 Checkpoint：训练任务必须支持断点续训，以应对被抢占的情况。
通过 Kubernetes 的 PriorityClass 可以轻松实现这一策略。
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: llm-online-high
value: 100000
preemptionPolicy: PreemptLowerPriority
六、总结：你现在具备的是「平台级」能力
按照以上架构与实践构建的系统，其内涵已经超越了简单的模型部署。你这套内容已经不是：
“如何在 K8s 上跑模型”
而是：
如何构建一个可规模化、可治理、可控成本的 AI Infra
从底层的 GPU 资源抽象与隔离，到中层的智能调度与高性能推理引擎，再到顶层的模型治理与安全合规，每一层都环环相扣。这不仅需要深厚的技术选型能力，更需要对 AI 工作负载特性 和 云原生体系 的深刻理解。
希望这份全景实践能为你构建自己的企业级 AI 基础设施 提供清晰的蓝图。如果你想就某个具体环节进行更深入的探讨，欢迎来到 云栈社区 与更多的开发者和架构师交流实战经验。
发表于 13 小时前
|
查看: 1|
回复: 0
