DeepSeek 推理服务私有化部署实战：基于 Kubernetes 的 AI 推理平台构建指南

引言：从模型到服务的最后一公里

2024年以来，开源大语言模型呈现爆发式增长，尤其是 DeepSeek V2/V3、Qwen2.5、Yi 等国产模型在推理能力上不断突破，接近甚至部分超越了闭源商业模型。然而，训练一个优秀的模型只是第一步——如何将模型高效、稳定、经济地部署为生产级服务，才是大多数技术团队面临的真正挑战。

汤不热吧技术社区近期完成了基于 Kubernetes 的 AI 推理平台建设，全面支持 DeepSeek 系列模型的私有化部署。本文将详细记录这一过程，涵盖模型量化、推理引擎选型、K8s 集群配置、自动扩缩容策略、API 网关设计以及生产运维的完整实践。希望对正在搭建或优化 AI 推理基础设施的同行有所帮助。

注意：本文涉及的所有组件均为开源方案，不依赖任何商业授权产品。整体架构已在社区的生产环境稳定运行超过 2000 小时。

整体架构设计

推理平台的整体架构采用分层设计，从上到下分为四个层次：

每个层次都有独立的容错机制，单点故障不会影响全局服务。调度层是整个架构的核心，它决定了推理服务的弹性能力和资源利用率。

模型量化：从 FP16 到 INT4 的工程实践

DeepSeek V2 拥有 236B 总参数，其中 21B 激活参数，采用 MoE（Mixture of Experts）架构。即使只有 21B 激活参数，FP16 精度下加载也需要约 42GB 显存，对于单卡 GPU 部署来说显然不够。量化是必须的。

量化方案对比

我们在实践中对比了三种主流方案：

• GPTQ：基于后训练量化，精度损失小，但对 MoE 模型支持不够完善，量化后稀疏门控路由可能出现偏差
• AWQ：激活感知量化，通过保留 1% 的”重要”权重通道为 FP16 来减少精度损失，在 DeepSeek 系列上表现优异
• bitsandbytes (BNB)：NF4 量化，支持 4bit 双重量化（DQ），但推理速度较慢，适合低成本场景

经过多轮测试，我们最终选择 AWQ INT4 量化方案。以下是关键的量化命令：

1
2
3
4
5
6
7
8
9
10
11
12
# 使用 AutoAWQ 对 DeepSeek V2 进行量化

python -m autoawq.quantize \

  --model_path /data/models/deepseek-v2-chat \

  --quant_path /data/models/deepseek-v2-chat-awq-int4 \

  --quant_method awq \

  --bits 4 \

  --group_size 128 \

  --zero_point True \

  --version gemm \

  --calib_dataset /data/pile_val_100k.jsonl \

  --calib_samples 512 \

  --calib_seqlen 2048

量化完成后，模型大小从约 42GB（FP16 激活参数）降至约 66GB（总参数 INT4），但实际推理时仅加载 6GB 左右的激活参数，配合 MoE 的稀疏计算特性，能够在单张 A100-80G 上流畅运行。

量化效果评估

我们在 MMLU、HumanEval、GSM8K 三个基准上对比了量化前后的精度：

INT4 量化精度损失在 1% 以内，完全可以接受。而显存需求的大幅降低，意味着我们可以用更少的 GPU 服务更多的用户，或在同一台机器上部署多个模型副本。

推理引擎选型与部署

推理引擎是模型服务的核心组件，它负责将模型权重加载到 GPU、管理 KV Cache、处理请求批处理等。我们对比了三个主流引擎：

vLLM

vLLM 是当前最流行的推理引擎，其核心创新是 PagedAttention 算法——将 KV Cache 分页管理，消除显存碎片，将显存利用率从 20-40% 提升到 95% 以上。vLLM 对 DeepSeek V2 的 MoE 架构有专门优化，支持 tensor parallelism 和 pipeline parallelism。

1
2
3
4
5
6
7
8
9
10
11
# 使用 vLLM 启动 DeepSeek V2 推理服务

python -m vllm.entrypoints.openai.api_server \

  --model /data/models/deepseek-v2-chat-awq-int4 \

  --served-model-name deepseek-v2 \

  --tensor-parallel-size 1 \

  --max-model-len 8192 \

  --gpu-memory-utilization 0.90 \

  --quantization awq \

  --max-num-batched-tokens 4096 \

  --enable-prefix-caching \

  --port 8000

SGLang

SGLang 是新兴的推理引擎，引入了 RadixAttention 和结构化生成语言（SGL）。RadixAttention 通过前缀树高效共享公共前缀的 KV Cache，在有大量系统提示词的场景下可以将首 Token 延迟降低 30-50%。SGLang 还支持约束解码（如 JSON Schema 约束），非常适合需要结构化输出的 AI 应用。

1
2
3
4
5
6
7
8
9
10
# 使用 SGLang 启动推理服务

python -m sglang.launch_server \

  --model-path /data/models/deepseek-v2-chat-awq-int4 \

  --host 0.0.0.0 \

  --port 8000 \

  --quantization awq \

  --context-length 8192 \

  --mem-fraction-static 0.85 \

  --enable-prefix-caching \

  --disable-radix-cache

性能对比

最终我们选择 vLLM 作为主力引擎，原因有三：社区更成熟、文档完善、生态集成更丰富。SGLang 作为备选引擎，用于需要结构化输出的特定场景。

Kubernetes 集群部署

推理服务需要 GPU 支持，因此 Kubernetes 集群需要配置 GPU 设备管理和调度。我们使用以下方案：

集群配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Kubernetes 节点配置（3 台 A100 节点 + 2 台 CPU 节点）

# GPU 节点：

#   - 2x Intel Xeon Gold 6438M

#   - 512GB RAM

#   - 1x NVIDIA A100-80G SXM

#   - 2x 3.84TB NVMe SSD (RAID 1)

#   - Ubuntu 22.04 + NVIDIA Driver 550.54 + CUDA 12.4



# 安装 NVIDIA GPU Operator（自动配置 nvidia-container-toolkit）

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia

helm repo update



helm install gpu-operator nvidia/gpu-operator \

  --namespace gpu-operator \

  --create-namespace \

  --set driver.enabled=false \

  --set toolkit.enabled=true \

  --set devicePlugin.enabled=true

部署推理服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# vLLM 推理 Deployment 配置示例

apiVersion: apps/v1

kind: Deployment

metadata:

  name: deepseek-v2-inference

  namespace: ai-inference

spec:

  replicas: 2

  selector:

    matchLabels:

      app: deepseek-v2

  template:

    metadata:

      labels:

        app: deepseek-v2

    spec:

      containers:

      - name: vllm

        image: vllm/vllm-openai:latest

        command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]

        args:

          - "--model"

          - "/model"

          - "--served-model-name"

          - "deepseek-v2"

          - "--tensor-parallel-size"

          - "1"

          - "--max-model-len"

          - "8192"

          - "--gpu-memory-utilization"

          - "0.90"

          - "--quantization"

          - "awq"

          - "--port"

          - "8000"

        ports:

        - containerPort: 8000

        resources:

          limits:

            nvidia.com/gpu: 1

            memory: "128Gi"

            cpu: "16"

        volumeMounts:

        - name: model-storage

          mountPath: /model

          readOnly: true

      volumes:

      - name: model-storage

        persistentVolumeClaim:

          claimName: model-storage-pvc

自动扩缩容配置

推理服务的负载波动很大，白天高峰时段可能需要 5-6 个副本，夜间低峰时段 1 个副本就够。使用 KEDA 结合 Prometheus 指标实现智能扩缩容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# KEDA ScaledObject 配置

apiVersion: keda.sh/v1alpha1

kind: ScaledObject

metadata:

  name: deepseek-v2-scaler

  namespace: ai-inference

spec:

  scaleTargetRef:

    name: deepseek-v2-inference

  minReplicaCount: 1

  maxReplicaCount: 8

  triggers:

  - type: prometheus

    metadata:

      serverAddress: http://prometheus.monitoring:9090

      metricName: vllm_request_queue_size

      query: |

        avg(vllm:request_queue_size{namespace="ai-inference"})

      threshold: "5"

  - type: prometheus

    metadata:

      serverAddress: http://prometheus.monitoring:9090

      metricName: vllm_gpu_memory_usage

      query: |

        avg(vllm:gpu_memory_usage{namespace="ai-inference"})

      threshold: "85"

  advanced:

    restoreToOriginalReplicaCount: true

    horizontalPodAutoscalerConfig:

      behavior:

        scaleDown:

          stabilizationWindowSeconds: 300

          policies:

          - type: Percent

            value: 50

            periodSeconds: 60

关键配置说明：当请求队列长度超过 5 或 GPU 显存使用率超过 85% 时触发扩容；缩容有 5 分钟稳定窗口，防止频繁抖动。

API 网关与生产运维

API 网关设计

我们使用 Kong API Gateway 作为统一的入口层，负责请求路由、限流、认证和日志记录：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Kong 路由配置示例

# 速率限制：每用户每分钟最多 60 次请求

curl -X POST http://kong:8001/plugins \

  --data "name=rate-limiting" \

  --data "config.second=1" \

  --data "config.minute=60" \

  --data "config.policy=local"



# 请求日志记录

curl -X POST http://kong:8001/plugins \

  --data "name=file-log" \

  --data "config.path=/var/log/kong/ai-inference.log"



# 负载均衡：轮询到多个推理 Pod

curl -X POST http://kong:8001/upstreams \

  --data "name=deepseek-v2-upstream" \

  --data "healthchecks.active.http_path=/health" \

  --data "healthchecks.active.healthy.interval=10"

生产运维要点

推理服务上线后，运维是确保长期稳定运行的关键。以下是我们在实际运维中积累的经验：

• 健康检查：vLLM 提供 /health 端点，配合 Kong 的主动健康检查，每 10 秒探测一次，连续 3 次失败自动摘除节点
• 模型预热：Pod 启动后自动发送一个空请求，触发模型加载到 GPU，避免用户请求等待模型加载时间
• 优雅关闭：配置 preStop hook 等待正在处理的请求完成后再终止 Pod，避免用户请求中断
• OOM 保护：通过 cgroup 限制容器内存，配合 NVIDIA MPS 控制 GPU 显存分配上限
• 日志聚合：使用 Loki + Grafana 收集和分析推理日志，关键指标包括请求延迟分布、错误率、Token 吞吐量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 优雅关闭配置

lifecycle:

  preStop:

    exec:

      command:

      - /bin/sh

      - -c

      - |

        echo "Starting graceful shutdown..."

        # 通知负载均衡器停止接收新请求

        curl -X POST http://localhost:8000/-/stop

        # 等待正在处理的请求完成（最多 120 秒）

        sleep 60

        echo "Shutdown complete"

模型预热与缓存优化

在生产线环境下，模型加载到 GPU 是一个非常耗时的过程。DeepSeek V2 的 AWQ 量化模型从磁盘加载到 GPU 显存大约需要 45-60 秒。如果不做预热处理，用户请求就会遇到长达一分钟的等待时间。

我们的解决方案是：

1. 生命周期钩子：在容器启动后立即发送一个空请求，强制模型加载
2. 前缀缓存：vLLM 的 enable-prefix-caching 功能，对系统提示词进行前缀缓存，减少重复计算
3. Radix Cache：对于 SGLang 部署，RadixAttention 通过前缀树共享公共前缀，显著降低首 Token 延迟
4. Redis 缓存：对高频请求的完整响应做缓存，直接命中缓存的请求延迟降至 5ms 以内

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 模型预热脚本

#!/bin/bash

# 等待服务就绪

until curl -s http://localhost:8000/health > /dev/null 2>&1; do

  echo "Waiting for vLLM server to be ready..."

  sleep 2

done



echo "Model loading initiated, sending warmup request..."

# 发送预热请求，触发模型加载到 GPU

curl -X POST http://localhost:8000/v1/chat/completions \

  -H "Content-Type: application/json" \

  -d '{

    "model": "deepseek-v2",

    "messages": [{"role": "user", "content": "Hello"}],

    "max_tokens": 1,

    "temperature": 0.1

  }' > /dev/null 2>&1



echo "Warmup complete, model is ready"

性能监控与成本优化

关键监控指标

我们建立了完善的监控体系，重点关注以下指标：

成本优化策略

GPU 资源是推理服务的主要成本来源。我们通过以下策略优化成本：

• Spot 实例：非高峰时段使用 Spot 实例，成本降低 60-70%。配合 PodDisruptionBudget 和优雅关闭，确保 Spot 实例被回收时不影响服务
• 弹性缩容：夜间低峰时段（00:00-08:00）自动缩容到 1 个副本，高峰期弹性扩容
• 请求批处理：vLLM 自动将多个请求合并为批次处理，提高 GPU 利用率。单个请求的延迟增加了，但整体吞吐量提升了 3-5 倍
• 模型分片：对于大型模型，通过 tensor parallelism 将模型分布到多张 GPU 上，但会引入通信开销。需要根据实际模型大小和 GPU 显存权衡

常见问题与排错指南

在部署和运维过程中，我们遇到了不少问题，整理如下供参考：

显存不足（OOM）

vLLM 启动时如果显存不足，会直接报错退出。解决方案：降低 gpu-memory-utilization 参数（从 0.90 降到 0.80），或启用 swap 作为显存扩展（不推荐，会大幅降低性能）。

MoE 负载不均衡

DeepSeek V2 的 MoE 架构中，部分专家（Expert）被频繁访问，部分专家几乎闲置，导致 GPU 利用率不均。vLLM 0.5.0+ 引入了专家负载均衡策略，可以在启动时通过 –enable-experts-load-balancing 参数开启。

请求超时

长文本推理场景下，如果 max-model-len 设置过大，单个请求可能占用大量显存和计算时间。建议设置合理的 max-model-len（如 8192），并配合 Kong 的请求超时设置（如 60 秒）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 排查步骤

# 1. 检查 Pod 状态

kubectl get pods -n ai-inference



# 2. 查看日志

kubectl logs -n ai-inference -l app=deepseek-v2 --tail=100



# 3. 检查 GPU 状态

kubectl exec -n ai-inference deploy/deepseek-v2-inference -- nvidia-smi



# 4. 手动测试推理

curl -X POST http://<service-ip>:8000/v1/chat/completions \

  -H "Content-Type: application/json" \

  -d '{"model":"deepseek-v2","messages":[{"role":"user","content":"Hello"}],"max_tokens":100}'

总结与展望

经过两个月的持续迭代，汤不热吧技术社区的 AI 推理平台已经稳定运行，支撑了社区内的多个 AI 应用场景，包括智能问答、代码审查、文档生成等。整体架构的技术选型总结如下：

• 模型量化：AWQ INT4，精度损失 < 1%，显存降低 85%
• 推理引擎：vLLM（主力）+ SGLang（备选结构化输出）
• 集群调度：Kubernetes + KEDA，自动弹性扩缩
• API 网关：Kong，统一限流、认证、路由
• 监控告警：Prometheus + Grafana + Loki，全链路可观测

下一步的规划包括：

• 引入 speculative decoding，将推理速度再提升 1.5-2 倍
• 支持多模型路由（根据请求类型自动选择最优模型）
• 实现推理缓存层，对重复请求做到零延迟响应
• 探索 AMD ROCm + MI300X 作为 NVIDIA 替代方案

开源大模型的推理部署是一个快速发展的领域，几乎每周都有新的优化方案出现。本文记录的是截至 2026 年 7 月的最佳实践，后续我们会持续跟进社区的最新进展，并将经验分享给更多技术同行。

如果你对本文中的任何技术细节有疑问或建议，欢迎在评论区留言讨论。也欢迎加入汤不热吧技术社区，一起探索 AI 基础设施的更多可能性。