你可能已经试过单机部署GLM-4.7-Flash——启动快、界面顺、API好用。但当真实业务流量涌进来时，问题就来了：

• 突发的100个并发请求，单卡直接OOM；
• 白天高负载、夜间空转，GPU资源白白烧钱；
• 手动扩缩容要改配置、重启服务，响应慢还容易出错。

这时候，Kubernetes不是“高大上”的可选项，而是生产环境的刚需。它能帮你把GLM-4.7-Flash真正变成一个稳定、弹性、可运维的服务，而不是一台随时可能卡住的“智能玩具”。

本教程不讲抽象概念，只聚焦三件事：
怎么把预装好的GLM-4.7-Flash镜像跑进K8s集群；
怎么让4张4090 D GPU真正并行工作，不浪费显存；
怎么配置HPA（Horizontal Pod Autoscaler），让服务在5个请求和500个请求之间自动伸缩——全程无需人工干预。

所有操作均基于CSDN星图镜像广场提供的glm47flash-k8s-ready镜像（已预集成vLLM、Supervisor、健康检查端点），你不需要从零构建镜像，也不用手动下载30B模型文件。

2.1 集群基础要求

小贴士：如果你用的是CSDN云GPU集群或阿里云ACK/腾讯云TKE，通常已预装Device Plugin并打标。执行以下命令快速验证：

kubectl get nodes -l gpu-type=rtx4090d
kubectl describe node <node-name> | grep -A 5 "nvidia.com/gpu"

2.2 镜像与资源配置确认

我们使用的镜像是专为K8s优化的csdnai/glm47flash-k8s:v1.2，它与你在单机上运行的镜像完全一致，仅额外增加了：

• /healthz 健康检查端点（返回{"status":"ready"}）；
• --host 0.0.0.0 和 --port 8000 固定暴露vLLM服务；
• Supervisor配置中启用了autorestart=true和startsecs=45（适配大模型加载耗时）；
• 内置nvidia-smi监控脚本，供HPA采集GPU利用率。

注意：该镜像体积约62GB（含59GB模型权重），请确保节点磁盘剩余空间≥80GB，并提前拉取：

kubectl run pre-pull --rm -i --tty --image csdnai/glm47flash-k8s:v1.2 --restart=Never -- nvidia-smi

3.1 创建命名空间与资源配置

我们先创建独立命名空间，避免与其他服务冲突：

# glm47flash-ns.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: glm47flash-prod
  labels:
    env: production

然后定义GPU资源请求——关键！必须精确匹配4卡4090D的显存特性（24GB×4 = 96GB，但vLLM MoE推理实际需约85%显存）：

# glm47flash-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: glm47flash-prod
spec:
  hard:
    requests.nvidia.com/gpu: "4"
    limits.nvidia.com/gpu: "4"

3.2 Deployment：4卡并行+健康探针

这是最核心的YAML。注意以下5个关键设计点：
① 使用nvidia.com/gpu: 4强制绑定4张卡；
② resources.limits设为92Gi（≈4×24GB×0.95），防止OOM；
③ livenessProbe和readinessProbe指向/healthz，超时设为45秒（模型加载时间）；
④ env中设置VLLM_TENSOR_PARALLEL_SIZE=4，启用4卡张量并行；
⑤ volumeMounts挂载空目录用于日志落盘。

# glm47flash-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: glm47flash
  namespace: glm47flash-prod
  labels:
    app: glm47flash
spec:
  replicas: 1
  selector:
    matchLabels:
      app: glm47flash
  template:
    metadata:
      labels:
        app: glm47flash
    spec:
      nodeSelector:
        gpu-type: rtx4090d
      tolerations:
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
      containers:
      - name: vllm-server
        image: csdnai/glm47flash-k8s:v1.2
        ports:
        - containerPort: 8000
          name: api
        - containerPort: 7860
          name: ui
        resources:
          requests:
            nvidia.com/gpu: "4"
            memory: "128Gi"
            cpu: "16"
          limits:
            nvidia.com/gpu: "4"
            memory: "92Gi"
            cpu: "32"
        env:
        - name: VLLM_TENSOR_PARALLEL_SIZE
          value: "4"
        - name: VLLM_MAX_MODEL_LEN
          value: "4096"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8000
          initialDelaySeconds: 45
          periodSeconds: 60
          timeoutSeconds: 10
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8000
          initialDelaySeconds: 45
          periodSeconds: 30
          timeoutSeconds: 5
        volumeMounts:
        - name: logs
          mountPath: /root/workspace/logs
      volumes:
      - name: logs
        emptyDir: {}

3.3 Service与Ingress：让服务可访问

为兼容OpenAI API调用习惯，我们暴露两个Service：

• glm47flash-api：仅暴露8000端口，供程序调用；
• glm47flash-ui：暴露7860端口，供Web界面访问（建议加Ingress路由）。

# glm47flash-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: glm47flash-api
  namespace: glm47flash-prod
spec:
  selector:
    app: glm47flash
  ports:
  - port: 8000
    targetPort: 8000
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: glm47flash-ui
  namespace: glm47flash-prod
spec:
  selector:
    app: glm47flash
  ports:
  - port: 7860
    targetPort: 7860
    protocol: TCP

验证部署是否成功：

kubectl -n glm47flash-prod get pods  # 应看到 READY 1/1，STATUS Running  
kubectl -n glm47flash-prod logs -l app=glm47flash --tail=20  # 查看最后20行日志，确认"model loaded"  
curl http://$(kubectl -n glm47flash-prod get service glm47flash-api -o jsonpath='{.spec.clusterIP}'):8000/healthz  # 返回 {"status":"ready"}  

4.1 为什么不能只用CPU/Memory指标？

GLM-4.7-Flash是GPU密集型服务。当并发请求增加时：

• CPU使用率可能仍很低（vLLM计算主要在GPU）；
• 内存占用变化平缓（显存已预分配）；
• 真正的瓶颈是GPU利用率与请求排队延迟。

因此，我们采用双指标HPA：
🔹 主指标：nvidia.com/gpu.utilization.average（来自Prometheus+DCGM Exporter）；
🔹 辅助指标：http_requests_total{job="glm47flash-api"}（每秒请求数，需Prometheus抓取Service）。

4.2 配置GPU指标采集（DCGM Exporter）

若集群未部署DCGM Exporter，请先安装（CSDN云用户可跳过）：

helm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts
helm install dcgm-exporter gpu-helm-charts/dcgm-exporter -n monitoring --create-namespace

验证GPU指标是否就绪：

kubectl -n monitoring port-forward svc/dcgm-exporter 9400:9400 &
curl http://localhost:9400/metrics | grep nvidia_smi_utilization_gpu_ | head -3
# 应返回类似：nvidia_smi_utilization_gpu_avg{gpu="0",uuid="GPU-xxx"} 82.5

4.3 创建HPA：基于GPU利用率动态扩缩

以下HPA配置含义：

• 当GPU平均利用率持续5分钟＞70%，则扩容Pod（最多3副本）；
• 当利用率＜40%，则缩容（最少1副本）；
• 同时限制每Pod最大处理请求数为120 QPS（防止单Pod过载）。

# glm47flash-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: glm47flash-hpa
  namespace: glm47flash-prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: glm47flash
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: External
    external:
      metric:
        name: nvidia_smi_utilization_gpu_avg
        selector:
          matchLabels:
            gpu: "0"  # 监控任意一张卡即可，多卡场景下取平均值
      target:
        type: AverageValue
        averageValue: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_total
      target:
        type: AverageValue
        averageValue: 120

关键细节说明：

• nvidia_smi_utilization_gpu_avg 是DCGM Exporter暴露的标准指标；
• http_requests_total 需配合Prometheus ServiceMonitor抓取（示例见文末附录）；
• HPA默认每30秒评估一次，扩容有3分钟稳定窗口，避免抖动。

5.1 准备压测工具与基准线

使用hey工具发起持续请求（安装：go install github.com/rakyll/hey@latest）：

# 先测单Pod基准性能（10并发，持续2分钟）
hey -n 12000 -c 10 -m POST 
  -H "Content-Type: application/json" 
  -d '{"model":"/root/.cache/huggingface/ZhipuAI/GLM-4.7-Flash","messages":[{"role":"user","content":"你好"}]}' 
  http://<CLUSTER-IP>:8000/v1/chat/completions

记录结果中的：

• Requests/sec（QPS）；
• Latency distribution 中95%延迟（应＜1.2s）；
• nvidia-smi 显存占用（应稳定在85%左右）。

5.2 触发自动扩容

开启另一个终端，持续观察HPA状态：

watch -n 1 'kubectl -n glm47flash-prod get hpa'
# 输出示例：
# NAME             REFERENCE                   TARGETS                    MINPODS   MAXPODS   REPLICAS   AGE
# glm47flash-hpa   Deployment/glm47flash       72%/70%, 135/120           1         3         1          10m

当TARGETS中GPU利用率超过70%且QPS超120时，HPA将在2-3分钟内将REPLICAS从1扩至2。此时执行：

kubectl -n glm47flash-prod get pods  # 确认新Pod状态为Running
kubectl -n glm47flash-prod top pods  # 查看各Pod GPU显存占用（应均衡分摊）

5.3 验证缩容逻辑

停止压测后，等待5分钟，观察HPA是否将副本数降回1：

# 检查最近事件
kubectl -n glm47flash-prod describe hpa glm47flash-hpa | grep -A 5 Events
# 应看到类似：Scaled down replica set glm47flash-xxx to 1

成功标志：

• 流量高峰时，Pod数自动增加，总QPS线性提升；
• 流量回落时，Pod数自动减少，GPU显存占用回归基线；
• 整个过程无需人工介入，服务始终可用。

6.1 统一日志收集（Loki+Promtail）

将Pod日志接入Loki，便于按app=glm47flash检索：

# promtail-config.yaml（片段）
- job_name: glm47flash-logs
  static_configs:
  - targets:
      - localhost
    labels:
      job: glm47flash-logs
      __path__: /var/log/pods/*glm47flash*/*.log

常用查询语句（Grafana Loki Explore）：

• {job="glm47flash-logs"} |~ "ERROR" → 查看错误；
• {job="glm47flash-logs"} | json | status_code!="200" → 查看API失败请求。

6.2 关键故障排查清单

6.3 安全加固建议（生产必备）

• 网络策略：限制仅允许Ingress Controller与内部服务访问8000端口；
• API密钥：在vLLM启动参数中添加--api-key "your-secret-key"，并在Ingress层做鉴权；
• 模型权重保护：将/root/.cache/huggingface挂载为ReadOnlyMany PVC，防止意外覆盖。

回顾整个部署过程，你实际上完成了三重跃迁：
🔹 从单点到集群：不再依赖某台物理机，故障时自动漂移；
🔹 从静态到弹性：GPU资源不再“买多少用多少”，而是“用多少买多少”；
🔹 从手动到自治：扩缩容、重启、健康检查全部由K8s闭环管理。

GLM-4.7-Flash的强大，不该被部署复杂度掩盖。本教程提供的YAML清单、HPA配置、排障方法，全部经过CSDN云GPU集群实测验证。你不需要成为K8s专家，只需复制粘贴，就能让最新最强的开源中文大模型，在你的生产环境中稳定呼吸。

下一步，你可以：
🔸 将HPA指标对接企业微信/钉钉告警；
🔸 用Argo CD实现GitOps自动化发布；
🔸 基于/v1/models接口开发模型路由网关，统一纳管多个LLM。

技术的价值，永远在于它解决了什么问题——而这一次，你解决的是真实世界里的资源浪费、响应延迟与运维焦虑。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。