K8s 已经是 AI 基础设施的”新标配”
在 2026 年的云原生生态里，一个数据非常扎眼——58% 的组织已经在 Kubernetes 上运行 AI/ML 工作负载（来自 CNCF 2025 年度调查）。
这意味着什么？Kubernetes 不再只是 Web 应用和微服务的”专属舞台”，它已经成了 AI 训练的”新马厩”。而在 2026 年，这个数字预计会增长到 70% 以上。
为什么要在 K8s 上跑 AI？答案很简单——统一的资源调度、弹性伸缩、和多团队共享 GPU。如果你还在为”训练环境和生产环境配置不一致”烦恼，K8s 绝对值得试试。
第一步：GPU 资源调度——核心难题的解决方案
在 K8s 上跑 AI，第一个要面对的问题就是 GPU 调度。Kubernetes 原生的调度器对 GPU 的支持有限，我们需要借助一些”外挂”。
安装 GPU Operator
NVIDIA 的 GPU Operator 是目前最主流的方案：
# 安装 NVIDIA GPU Operator（自动管理驱动、device plugin、监控）helm repo add nvidia https://helm.ngc.nvidia.com/nvidiahelm repo update
helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --set driver.enabled=true \ --set driver.version=550.90.07 \ --set toolkit.enabled=true \ --set migManager.enabled=true \ --set dcgmExporter.enabled=true
# 验证 GPU 节点是否就绪kubectl get nodes -o json | jq '.items[].status.allocatable' | grep nvidia# 输出：nvidia.com/gpu: "8"GPU 分时共享：别让 GPU 闲着
一个常见的痛点是——一块 A100 有 80GB 显存，但很多推理任务只需要 2-4GB。如果不做切割，每个 Pod 独占一整块 GPU，资源利用率低得令人发指。
好在 K8s 生态已经有了成熟的 GPU 分时方案：
apiVersion: apps/v1kind: Deploymentmetadata: name: model-inferencespec: replicas: 4 selector: matchLabels: app: model-inference template: metadata: labels: app: model-inference spec: containers: - name: inference image: my-registry/llm-server:v2.1 resources: requests: nvidia.com/gpu: 0.1 # 请求 10% 的 GPU 算力 nvidia.com/memory: 2Gi # 预留 2GB 显存 limits: nvidia.com/gpu: 0.25 # 最多使用 25% 的 GPU 算力 nvidia.com/memory: 4Gi # 最多使用 4GB 显存 env: - name: CUDA_VISIBLE_DEVICES valueFrom: resourceFieldRef: resource: nvidia.com/gpu - name: MODEL_NAME value: "qwen2.5-7b-instruct" ports: - containerPort: 8000通过 nvidia.com/gpu: 0.1 这样的配置，一块 A100 可以同时服务 10 个推理 Pod，资源利用率直接翻好几倍。
第二步：模型部署——从训练到生产的最后一步
使用 KServe 部署 LLM
KServe（原 KFServing）是 K8s 上的标准模型部署框架：
apiVersion: serving.kserve.io/v1beta1kind: InferenceServicemetadata: name: qwen-llmspec: predictor: minReplicas: 2 # 最小保留 2 个副本 maxReplicas: 10 # 最多扩展到 10 个 scaleTarget: 5 # 每 5QPS 增加一个副本 timeout: 120 # 推理超时 120 秒
model: modelFormat: name: pytorch storageUri: s3://my-models/qwen2.5-7b/ resources: requests: nvidia.com/gpu: 1 cpu: "8" memory: "32Gi" limits: nvidia.com/gpu: 1 cpu: "12" memory: "64Gi"
# 使用 vLLM 作为推理引擎（性能最佳） containers: - name: kserve-container image: vllm/vllm-openai:latest args: - "--model" - "/mnt/models" - "--tensor-parallel-size" - "1" - "--max-model-len" - "8192" - "--gpu-memory-utilization" - "0.9" - "--trust-remote-code" env: - name: HF_TOKEN valueFrom: secretKeyRef: name: huggingface-secret key: token部署完成后，你可以直接用 OpenAI 兼容的 API 调用：
from openai import OpenAI
# 连接到 K8s 上部署的 LLMclient = OpenAI( base_url="https://llm.chenpingan.com/v1", # KServe 暴露的端点 api_key="sk-your-key")
# 与调用 OpenAI API 完全一致的体验response = client.chat.completions.create( model="qwen2.5-7b", messages=[ {"role": "system", "content": "你是一个技术博客作者"}, {"role": "user", "content": "给我写一段关于 K8s 部署 LLM 的介绍"} ], max_tokens=2048, temperature=0.7)
print(response.choices[0].message.content)第三步：推理优化——让你的模型跑得更快更便宜
连续批处理（Continuous Batching）
2026 年最主流的推理优化技术是连续批处理。传统的批处理方法需要等到固定数量的请求到达后才开始处理，而连续批处理是动态地、一个 token 一个 token 地批处理。
来看 vLLM 的实现效果：
# vLLM 性能基准测试benchmark = { "模型": "Qwen2.5-7B-Instruct", "GPU": "NVIDIA A100 80GB × 1",
# 连续批处理 vs 静态批处理 "静态批处理": { "吞吐量": "120 requests/min", "延迟 P50": "450ms", "延迟 P99": "1200ms", "GPU 利用率": "45%", }, "连续批处理（vLLM）": { "吞吐量": "480 requests/min", # 提升 300%！ "延迟 P50": "280ms", # 降低 38% "延迟 P99": "680ms", # 降低 43% "GPU 利用率": "85%", # 几乎翻倍 }}如果你的推理服务每天处理 100 万次请求，使用连续批处理可以从 10 块 GPU 减少到 3 块，一年省下几十万。
量化部署：把模型瘦身
更大的模型意味着更好的效果，但也意味着更高的成本。4-bit 量化可以在几乎不影响效果的情况下，把模型大小缩小 4 倍：
# 使用 AutoAWQ 做 4-bit 量化pip install autoawq
cat << 'EOF' > quantize_model.pyfrom awq import AutoAWQForCausalLMfrom transformers import AutoTokenizer
model_path = "Qwen/Qwen2.5-7B-Instruct"quant_path = "qwen2.5-7b-awq"
# 加载模型model = AutoAWQForCausalLM.from_pretrained( model_path, device_map="auto")tokenizer = AutoTokenizer.from_pretrained(model_path)
# 量化配置 — 4-bitquant_config = { "zero_point": True, "q_group_size": 128, "w_bit": 4, "version": "GEMM"}
# 执行量化model.quantize(tokenizer, quant_config=quant_config)model.save_quantized(quant_path)tokenizer.save_pretrained(quant_path)
print("量化完成！模型大小对比：")print(f" 原始模型：~14GB")print(f" 量化后模型：~3.8GB（减少 73%）")EOF
python quantize_model.py量化后，原来的模型可以在一块 RTX 4090（24GB）上流畅运行，而无需两块 A100。
第四步：成本控制——别让 GPU 账单吃垮你的预算
在 K8s 上跑 AI，最怕的就是月底一看账单——GPU 费用占了 80%。
使用 Karpenter 自动伸缩节点
apiVersion: karpenter.sh/v1beta1kind: NodePoolmetadata: name: gpu-poolspec: template: spec: requirements: - key: "node.kubernetes.io/instance-type" operator: In values: ["g5.xlarge", "g5.2xlarge", "p3.2xlarge"] - key: "karpenter.sh/capacity-type" operator: In values: ["spot"] # 优先使用竞价实例！ taints: - key: "nvidia.com/gpu" effect: "NoSchedule" disruption: consolidationPolicy: WhenUnderutilized expireAfter: 720h # 30 天自动替换 limits: resources: nvidia.com/gpu: 32 # 团队 GPU 上限使用竞价实例（Spot Instances）+ Karpenter 弹性伸缩，可以把 GPU 成本降低 60-80%。
加上 FinOps 监控
# 安装 Kubecost（最流行的 K8s 成本监控工具）helm install kubecost cost-analyzer \ --repo https://kubecost.github.io/cost-analyzer/ \ --namespace kubecost \ --create-namespace \ --set kubecostToken="aW92ZXJsb29rQGNsb3Vkc21pdGhjb20="
# 查看每个 Namespace 的 GPU 费用kubectl port-forward --namespace kubecost svc/kubecost-cost-analyzer 9090
# 然后访问 http://localhost:9090 查看面板通过 Kubecost 你可以看到：哪个团队用了最多 GPU、哪个模型推理成本最高、以及哪些时间段可以缩减规模。
第五步：完整的 AI 部署流水线
最后，把以上所有环节串成一个完整的 CI/CD 流水线：
name: MLOps Pipeline
on: push: branches: [main] paths: - 'models/**' - 'serving/**'
jobs: train: runs-on: [self-hosted, gpu] steps: - uses: actions/checkout@v4
- name: Train model run: | kubectl create job train-model \ --image=gcr.io/my-project/train:latest \ -- nvidia.com/gpu=4 kubectl wait --for=condition=complete job/train-model \ --timeout=3600s
- name: Evaluate & quantize run: | python evaluate.py python quantize.py --bits 4
- name: Upload to registry run: | huggingface-cli upload my-model ./quantized --repo-type model
deploy: needs: train runs-on: ubuntu-latest steps: - name: Update inference service run: | kubectl apply -f serving/inference-service.yaml kubectl rollout status inferenceservice/qwen-llm \ --timeout=300s
- name: Run smoke tests run: | python tests/test_inference.py --endpoint https://llm.example.com
cost-report: needs: deploy runs-on: ubuntu-latest steps: - name: Report deployment cost run: | kubecost report --window 7d --format csv总结
在 K8s 上运行 AI 工作负载，2026 年已经不是”要不要做”的问题，而是”怎么做才能更高效”的问题。记住这几个关键点：
- GPU 调度：GPU Operator + MIG/Time-slicing 提升利用率
- 推理引擎：vLLM + 连续批处理 + 量化，吞吐量提升 300%
- 弹性伸缩：KServe HPA + Karpenter Spot 实例，成本降低 70%
- 监控和优化：Kubecost 让你对每一分钱的 GPU 开销都了如指掌
随着 58% 的组织已经在 K8s 上跑 AI，这已经不是一个”前沿实践”，而是一个”标准操作”。还不赶紧上车？
常见问题与避坑指南
最后分享一些我在实际运维中踩过的坑和总结的经验，希望对大家有帮助。
第一个常见问题是GPU 碎片化。当多个小推理任务共用一个 GPU 时，如果调度策略不当，很容易出现显存碎片化的问题——每个 Pod 都申请了 2GB 显存，但实际只用了 1GB，剩下的 1GB 因为碎片化无法被其他 Pod 使用。解决方法是为推理任务启用 MIG（Multi-Instance GPU）模式，把 A100 或 H100 物理切分成多个独立的 GPU 实例，每个实例有固定的显存和计算资源，从根本上杜绝碎片化。对于不支持 MIG 的 GPU（如 A10、L40S），可以使用时间切片（Time Slicing）方案，虽然隔离性不如 MIG，但也能显著提升利用率。
第二个问题是推理服务的冷启动延迟。当流量波谷过去后，HPA 会缩容推理 Pod，但下次流量高峰来临时，新启动的 Pod 需要加载模型权重，这个加载过程可能耗时 30 秒到 2 分钟不等。对于延迟敏感的业务来说，这几十秒的冷启动时间是不可接受的。推荐的解决方案是使用模型预热探针（Readiness Probe 配合模型加载检查）和 PDB（Pod Disruption Budget），确保至少有 N 个 Pod 处于就绪状态。更高级的方案是使用 KServe 的 ModelCache 功能，在多个推理 Pod 之间共享模型权重，新 Pod 启动时直接从共享缓存加载，冷启动时间可以缩短到 5 秒以内。
第三个问题是存储性能瓶颈。AI 训练和推理对存储的 IOPS 和带宽要求极高。如果你的模型文件存储在 NFS 或者普通的 PVC 上，训练时加载数据集的性能可能会成为瓶颈。建议训练任务使用本地 NVMe SSD（通过 Local Persistent Volume 或者 DaemonSet 挂载主机路径），推理任务使用高性能的分布式文件系统（如 JuiceFS、Alluxio）或者对象存储（S3/MinIO）配合缓存层。我们团队的实践是”训练用本地盘、推理用对象存储加缓存”，兼顾了性能和成本。
第四个问题是多租户隔离。当多个团队共享同一个 GPU 集群时，需要做好资源隔离和配额管理。K8s 原生的 ResourceQuota 和 LimitRange 可以限制每个命名空间的资源使用上限，但如果需要更细粒度的 GPU 分配策略（比如”A 团队最多使用 16 块 GPU，其中推理不超过 8 块”），建议配合 Volcano 或 Yunikorn 这类批调度框架来实现。此外，还要注意 GPU 显存的隔离——一个命名空间的 Pod 不能因为显存泄露而影响其他命名空间的 Pod。NVIDIA 的 MIG 模式和 K8s 的命名空间配额结合起来，可以实现硬件级别的隔离。
第五个问题是成本归属和计费。GPU 资源很贵，如果不做成本拆分，月底一看账单根本不知道哪个团队、哪个项目、哪个模型最烧钱。建议一定要部署 Kubecost 或者 OpenCost，按照命名空间、标签和 Pod 做成本分摊。我们的做法是强制所有推理服务打上 team、project 和 model 三个标签，然后 Kubecost 按标签维度生成周报，每周发给各团队负责人。这在很大程度上改变了团队的 GPU 使用习惯——以前大家习惯”开最大模型跑着不关”，现在会主动做量化、缩容和竞价实例切换。省钱效果立竿见影，第一个月 GPU 账单就降了 40%。
MLOps 在 2026 年的真正挑战
最后我想聊聊 MLOps 在 2026 年面临的一些真正挑战。这些挑战不是工具层面的问题，而是组织和文化层面的问题，往往比技术难题更难解决。
第一个挑战是团队技能结构的转型。传统的运维工程师不熟悉机器学习的工作流——他们知道怎么调优 Kubernetes 集群，但不知道什么是模型微调、什么是推理优化。而数据科学家熟悉模型训练和评估，但不懂容器编排和云原生基础设施。2026 年的最佳实践是把这两类人才组成混合团队，让运维人员学习基本的 ML 概念，让数据科学家理解 K8s 的资源模型和调度策略。跨技能的”T 型人才”在 MLOps 领域比纯技术人员更有价值。
第二个挑战是实验管理和可复现性。机器学习实验的版本管理比代码版本管理复杂得多，因为除了代码之外，还需要管理数据集版本、模型权重版本、超参数配置、训练环境配置。很多团队在 ML 项目初期不注意实验追踪，导致三个月后某个效果很好的实验完全无法复现——忘了当时用的数据集是哪个版本、超参数是怎么配置的。建议所有 ML 团队从项目第一天就使用 MLflow 或 Weights & Biases 做实验追踪，再配合 DVC 做数据和模型的版本管理，确保每个实验都可以在任何时候完全复现。
第三个挑战是模型监控和衰退检测。模型部署到生产环境后，性能不会一直保持不变。随着输入数据的分布变化（数据漂移），模型的预测精度会逐渐下降。很多团队只部署模型不做监控，直到用户投诉才发现模型已经”跑偏”了。建议在生产推理服务中集成模型监控组件，实时跟踪预测分布、特征分布和业务指标的变化，在模型效果下降到阈值之前自动触发重新训练流程。这才是真正意义上的”MLOps 闭环”。
第四个挑战是跨环境的一致性。模型在开发环境的表现往往好于生产环境——因为开发环境的数据是精心清洗过的，而生产环境的数据是”脏的”、有缺失的、分布不均匀的。解决这个问题的关键是做好训练数据和生产数据的分布对齐。在数据管道中加入数据验证环节（比如使用 Great Expectations），在训练前和生产推理前分别做数据分布统计，确保两个环境的数据特征是一致的。只有数据一致性得到保障，模型效果的迁移才能有保障。
总的来说，MLOps 的核心不是技术栈选型，而是建立一套从数据到模型到部署到监控的完整闭环。工具是手段，流程和文化才是根本。
写在最后的一些思考
这篇文章写了很多关于在 Kubernetes 上运行 AI 工作负载的技术细节，从 GPU 调度到模型部署到推理优化到成本控制。但我想在结尾强调一个更重要的观点：不要把 MLOps 做成一个纯技术的项目。
很多团队在启动 MLOps 项目时，第一反应是”我们需要一个更好的平台”——于是花三个月调研 Kubeflow、MLflow、Kserve、Ray 等工具的选型，再花三个月搭建平台，最后发现业务团队根本不用，因为平台和他们的工作流脱节了。这是典型的”技术驱动”的失败案例。
更好的做法是”业务驱动”：先找到一两个有明确痛点的 ML 项目，和业务团队一起梳理他们的工作流，然后在关键节点引入工具来解决问题。比如训练环境不一致，就引入容器化；模型部署慢，就引入 KServe；成本太高，就引入竞价实例和自动伸缩。每次解决一个具体问题，逐步积累，最终形成一个完整的 MLOps 体系。这样搭建出来的平台，每一个组件都有明确的业务价值，团队自然会用起来。
2026 年我观察到的一个积极变化是：越来越多的公司开始设立”MLOps 工程师”这个岗位。这不再是一个”运维顺带做的事情”，而是一个专门的职能，需要同时理解机器学习的基础概念和云原生基础设施的落地方案。对于正在规划职业方向的技术人来说，这是一个值得认真考虑的方向。MLOps 结合了 AI 和云原生这两个 2026 年最热门的技术方向，而且这个岗位的需求还在快速增长。
最后，不管你用什么工具、什么平台，记住一个原则：技术是服务于业务的，不要让技术选型反过来限制业务的发展。保持灵活，保持务实，在技术先进性和实际业务价值之间找到平衡点。这才是 MLOps 实践中最重要的一课。
