阿里云ACK部署大模型推理：GPU配置优化指南

推理部署的隐性成本往往藏在 GPU 利用率里——大量团队守着独占 GPU 跑推理，SM 利用率却常年不到 30%，账单却按整卡付费。ACK 部署大模型推理 GPU 优化的意义不在于“能跑起来”，而在于让每一卡的钱花在产生实际吞吐的地方。下面从场景选择和架构收益两个维度拆解，什么情况下把推理工作负载搬到 ACK 才有明显回报。

一、ACK部署大模型推理的适用场景与优势

1. 多模型混部与波峰波谷明显的业务

如果只跑一个固定流量的模型，裸金属或简单 ECS 挂载 GPU 也能对付。但一旦线上同时服务多个中小参数量模型（如 7B/13B 的开源模型），或者推理 QPS 有明显的早晚高峰，ACK 的 GPU 共享和弹性能力就变得不可替代。cgpu 方案支持显存硬隔离和算力权重分配，能把一颗 A10 或 L40S 拆成多个 vGPU 给不同模型实例，而不是让一张卡被一个低负载服务霸占。配合 HPA 按 GPU 利用率或请求排队长度自动扩缩，夜间回收节点，单卡日均有效吞吐可以做到自建集群的 2-3 倍。

2. 推理成本需要被精算的团队

当推理要从实验演示走向生产、开始关注单次推理的美元成本时，ACK 带来的就不仅是资源池化，还有成本可观测性。通过 DCGM + Prometheus + 自定义标签，可以把 GPU 功耗、显存带宽、SM 利用率关联到具体业务的 QPS 和时延，不再只能看一个模糊的“使用率”。在此基础上，vLLM 等推理引擎配合 gpu-memory-utilization、批量大小等参数调优，通常能将单卡吞吐再拉升 3-5 倍，折算下来的单次推理成本显著低于直接跑原生 PyTorch 推理的模式。对于以成本优化为硬指标的场景（比如 API 订阅型产品、内部工具链），这种可度量、可优化的架构比自建 GPU 集群手动调度更有说服力。

二、GPU资源配置策略

为大模型推理服务选配GPU，本质上是一道“在显存、算力、成本之间找平衡点”的应用数学题。配高了资源闲置，配低了请求排队超时。根据过去一年在ACK上部署数十个推理服务的实际踩坑经验，两个判断值得重提：第一，推理场景的GPU选型逻辑与训练截然不同；第二，共享GPU的价值被严重低估了。

1. GPU型号如何选择？

推理负载对GPU的需求，核心看三项：模型参数量、量化精度、目标吞吐。选型的第一性原理不是“越新越好”，而是“显存先达标，再看带宽和算力”。

以当前主流的开源模型为例，显存需求可按下述公式快速估算：

模型权重显存 = 参数量 × 每个参数的字节数
推理总显存 ≈ 模型权重显存 × 1.2（预留KV缓存和计算中间层开销）

FP16精度下，70B模型的权重占用约140GB，加上KV缓存，单卡H800（80GB）根本装不下，至少需要2卡做张量并行。如果对模型做4-bit量化（如AWQ），同一模型的权重占用压缩到约35GB，单块A100-80G就能跑起来。这意味着对大量中小规模线上推理场景，量化可直接节省一半以上的GPU成本。

具体选型路径可以参考这个决策框架：

• 7B及以下模型（如Qwen-7B、Llama-3-8B）： FP16部署，T4（16GB显存）是个性价比不错的起点，单卡可承载中等并发。如果对首包时延敏感，直接上A10（24GB），SM利用率和显存带宽明显优于T4。实测下来，A10推理8B模型的token生成速度比T4快约2-3倍。

• 13B-34B模型（如Baichuan2-13B、Qwen-32B）： 4-bit量化后通常需要16-24GB显存。A10是最低门槛选择，L40S（48GB）或A100-40G可提供更大batch size余量。不建议用T4上这个量级的模型，即便量化后显存勉强够，PCIe带宽瓶颈会严重拖慢decode阶段。

• 70B+模型（如Llama-3-70B、Qwen-72B）： 量化后也需要约40GB显存。单卡A100-80G可部署，但实际吞吐受限。多卡A100或H800是生产环境的现实选择。这类部署通常需要张量并行（TP），ACK上可通过Kubernete Device Plugin声明多卡资源，vLLM会自行处理分布式推理的通信。

一个被多次验证过的经验判断：对于推理延迟不极敏感的批量离线推理（如夜间数据标注、语料评估），L40S的成本优势明显；而对于需要保证P99延迟在200ms内的实时对话场景，多花30%-50%成本上A100是划算的，因为它的HBM带宽在高batch下能稳定维持token生成速度。

ACK节点池支持异构GPU混部，可以单独创建一个A100节点池给70B模型，另一个L40S节点池跑13B模型的多个副本，标签选择器做调度分流。这种架构让“大模型吃好卡、小模型吃够卡”的策略落地得很干净。

2. 共享GPU还是独占GPU？

一个多数团队都会踩的坑：为了让一个7B模型的QPS从50提到200，直接上了两块A10并采取独占模式。结果GPU SM利用率长期在15%-25%徘徊，显存倒是占着8GB不动，资源成本翻了倍而吞吐提升远不成比例。问题出在推理负载的瓶颈通常不在算力，而在显存带宽和KV缓存容量——单卡显存没打满，加卡的意义有限。

这引出GPU共享的核心价值。在ACK上，通过cgpu方案可以把一块物理GPU按显存和算力两个维度切分：

# cgpu资源声明示例（YAML片段）
resources:
  limits:
    aliyun.com/gpu-mem: 8    # 申请8GB显存
    aliyun.com/gpu-count: 1  # 显存隔离的虚拟GPU数量

这个方案的实际效果是：显存层面做硬隔离，一个容器超分显存只会OOM自身，不会挤占邻居；算力层面按权重分配，高优容器拿70%的SM利用率，低优容器拿30%。对于“一个集群里同时跑线上实时推理和离线评估任务”这类混部场景，共享GPU能把单卡利用率从25%拉到70%以上。

但共享GPU并非万能药。两类场景更适合独占模式：一是超大模型已打满单卡显存（如70B模型占满80GB），此时无资源可共享；二是极致延迟敏感场景，共享GPU的算力争抢仍会引入尾延迟波动，对于P99延迟要求低于100ms的服务，独占更稳妥。

实操上可以这样分层：线上生产推理服采用独占或高权重共享GPU，保证SLO；开发测试、A/B实验、离线评估全部扔到共享GPU资源池。在ACK上通过Namespace级别ResourceQuota和Pod上的NodeSelector，能把这两类负载严格物理隔离，管理成本比想象中低得多。

三、大模型推理服务部署流程

如果把模型选型和镜像打包比作“造子弹”，那部署环节就是装填和击发。前面的优化做得再好，部署配置写错一行参数，推理吞吐可能直接腰斩。我们见过不少团队在ACK上用默认参数启动容器就跑压测，结果A100跑到一半显存就OOM重启——不是模型太大，是批处理参数没设上限，推理引擎把显存当无底洞了。

下面这三步，覆盖从镜像准备到服务验证的核心动作。每个步骤都踩过生产环境的坑，应该能帮你少绕些路。

1. 构建高效推理镜像

不要把模型文件打包进镜像。这是第一个容易犯的错。一个大模型动辄几十GB，塞进镜像会让拉取时间从几十秒变成十几分钟，弹性扩缩时根本来不及响应。

正确的做法是：镜像只装推理引擎和依赖，模型文件通过NAS或CPFS共享存储挂载。Dockerfile的核心部分大概是这样：

FROM nvidia/cuda:12.1-runtime-ubuntu22.04

RUN pip install vllm==0.3.3 transformers

# 这里只放启动脚本，不放模型权重
COPY serve.sh /workspace/
RUN chmod +x /workspace/serve.sh

ENTRYPOINT ["/workspace/serve.sh"]

如果确实需要在镜像内预装模型——比如边缘部署场景不挂载共享存储——那就在打包前先跑一次4-bit量化。以Llama-2-13B为例，原始FP16需要约26GB显存，INT4量化后降到8GB左右，单张T4甚至L4就能跑起来。量化后的模型权重、tokenizer、config.json一并打入镜像，镜像体积也就膨胀十几GB，还在可接受范围内。

启动脚本serve.sh里写清楚vLLM的启动参数：

python -m vllm.entrypoints.api_server \
    --model /models/Llama-2-13b-awq \
    --quantization awq \
    --max-num-batched-tokens 4096 \
    --gpu-memory-utilization 0.9 \
    --tensor-parallel-size 1

这里有三个关键参数值得说道：max-num-batched-tokens控制单批次最大token数，直接决定显存消耗和吞吐天花板。设太小，GPU SM利用率上不去；设太大，碰上长序列请求容易OOM。4096是个经验起点，建议压测后再微调。gpu-memory-utilization设为0.9，给KV缓存池留足空间但并不占满显存，剩下10%给CUDA context和临时张量当缓冲。tensor-parallel-size是张量并行数，单卡部署就写1，多卡做张量并行时才调大。

效果：基于共享存储挂载模型的方案，容器冷启动时间通常控制在30秒内（镜像拉取5~10秒+模型加载15~20秒）；即使用量化镜像方案，首次拉取也能在3~5分钟内完成，后续节点缓存命中后秒级启动。

2. 编写面向GPU优化的部署清单

镜像就绪，下一步是写ACK的Deployment YAML。很多人习惯把Kubernetes部署文件当流水账填，规规矩矩写上镜像地址、端口、资源请求就完事了。但对大模型推理，YAML里少写几行配置，直接影响GPU利用率和服务稳定性。

一份生产级部署清单需要重点处理这四块：GPU资源声明、探针、优雅终止、反亲和。

先看资源定义部分：

resources:
  requests:
    nvidia.com/gpu: 1
  limits:
    nvidia.com/gpu: 1

这是独占一整块物理GPU的写法。如果要用共享GPU，ACK的cgpu方案支持这样声明：

resources:
  requests:
    aliyun.com/gpu-core-percent: 30
    aliyun.com/gpu-mem: 12
  limits:
    aliyun.com/gpu-core-percent: 30
    aliyun.com/gpu-mem: 12

这里按算力百分比和显存GB两个维度切分，requests和limits一致，禁止超卖保证隔离。实测下来，把一个A100 80G切成三个12G显存+30%算力的虚拟GPU，同时跑三套不同的小模型推理服务，单卡总吞吐反而比独占时高——因为独占时GPU大部分时间在等数据搬运，SM利用率不到40%；共享后三路并发把SM利用率顶到了70%以上。

接下来是探针配置。推理服务不像普通HTTP接口启动即就绪，模型加载可能持续十几二十秒。如果把readinessProbe的initialDelaySeconds设太短，Pod还没加载完就被Kubernetes判定为NotReady，导致滚动更新时流量中断。

readinessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3

livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 60
  periodSeconds: 30

优雅终止同样重要。推理服务处理长连接或批处理请求时，容器突然被SIGTERM杀掉会导致请求中断、客户端超时。Deployment里配好terminationGracePeriodSeconds: 90，给Pod足够时间排空当前队列。vLLM收到SIGTERM后会自动等待max-num-batched-tokens窗口内所有请求完成再退出，这个过程通常不超过30秒。

最后别忘了Pod反亲和。同一Service下的推理Pod如果全调度到同一台GPU节点，单点故障会瞬间放大；如果多个Service混部在同一节点且没做反亲和，可能争抢NVLink带宽导致性能抖动。

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - llama-inference
          topologyKey: kubernetes.io/hostname

效果：按这套配置部署，一个推理Pod从提交YAML到健康检查通过，冷启动在60~90秒；滚动更新时旧Pod优雅退出、新Pod就绪后流量切换，客户端几乎无感。共享GPU模式下，同等硬件成本可支撑的推理实例数提升2~3倍。

3. 服务发布与快速验证

到了最后关头——把Service暴露出来，跑一轮验证看服务是否真的按预期工作。

ACK上建Service时，推理场景建议直接用ClusterIP然后配合Ingress做七层路由，避免NodePort直连增加网络跳数。vLLM默认在8000端口暴露HTTP接口，兼容OpenAI API格式，这意味着可以用市面上大多数LLM评测工具直接对接。

发布后先别急着跑压测，用curl做一次功能探活：

curl http://:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{ "model": "Llama-2-13b-awq", "prompt": "你好", "max_tokens": 50 }'

返回200且包含choices字段，说明模型加载正常、推理通路打通。

接下来是吞吐摸底。不习惯用专业压测工具的话，vLLM自带benchmark脚本能快速给出单机吞吐上限：

python benchmarks/benchmark_serving.py \
    --model Llama-2-13b-awq \
    --dataset ShareGPT \
    --num-prompts 500 \
    --request-rate 10

关注两个指标：首字延迟（TTFT)和每秒生成token数（Token/s）。13B模型在A10上跑INT4量化，TTFT一般在200ms以内，生成速度30~50 token/s视为正常。如果TTFT飙升到1秒以上，检查max-num-batched-tokens是否设太大导致排队；如果Token/s不足20，排查是否有其他容器争抢GPU算力，或者模型加载时忘了启用AWQ量化标记。

验证通过后，建议顺手给Pod打上business-unit、model-name等标签。这步看似和性能无关，但在之后的监控和成本核算环节会派上大用场——ACK的容器成本分析功能可以按标签聚合GPU用量和费用，哪个业务消耗最多算力一目了然。

效果：标准化验证流程能在10分钟内完成功能、延迟、吞吐三项检测，快速暴露配置错误或硬件瓶颈。加上标签体系后，GPU成本核算从“一团糊涂账”变成按团队和模型维度的精细报表。

四、推理性能优化核心技术

在ACK上完成模型部署只是第一步，生产环境的瓶颈往往出现在看似“能跑通”的推理服务开始承接真实流量时。我们在多个项目中观察到，同一份模型权重、同样的GPU型号，推理吞吐可以相差3～5倍，首token延迟则可能从200ms恶化到2s以上。差异的根源就在于是否对推理链路做了体系化的性能调优。下面三个方向是实践中成本收益最高的优化手段。

1. 模型量化与剪枝——先让权重复合硬件

量化不是简单地“压缩模型”，而是让模型的计算访存比与GPU显存带宽对齐。以目前最普遍的4-bit量化为例，AWQ和GPTQ两种算法在ACK上都有成熟实践：

• 操作说明：在镜像构建阶段，使用autoawq或llm-quantizer工具对原始FP16权重进行量化，并将量化后的模型、tokenizer和配置文件一起打包进容器。如果模型较大，推荐使用阿里云CPFS并行文件系统挂载模型，避免镜像体积膨胀。以Qwen-14B为例，一条典型的量化命令如下：

python -m awq.entry --model_path /models/Qwen-14B-Chat \
    --w_bit 4 --q_group_size 128 \
    --dump_awq /quantized_models/Qwen-14B-Chat-AWQ

• 效果说明：14B模型FP16约需28GB显存，量化后仅需约8GB，单张A10（24GB）即可部署，同时留有足够空间给KV cache和批处理。重要的是，显存节省并没有换来吞吐下降——在vLLM推理引擎上，AWQ量化模型的decoding吞吐通常能达到FP16的90%以上，首token延迟因为反量化开销会增加约10%，但在高QPS场景下完全可接受。

• 剪枝的客观边界：结构化剪枝在视觉模型上效果显著，但在Transformer类大模型上，非结构化稀疏对V100/A100等GPU的张量核利用率反而有害。目前的行业共识是：推理优先走4-bit/8-bit量化，剪枝仅在特定低精度目标（如边缘端）才启用，ACK线上服务普遍不推荐盲目剪枝。

2. 批处理与并发调优——用足SM算力

相当多的团队在ACK上部署推理时，直接沿用训练脚本里batch_size=1的串行方式，GPU SM利用率长期在15%以下。推理场景的并行性来源于多请求的连续批处理，而不是一个请求内部的数据并行。

• 操作说明：使用vLLM或TGI等推理引擎后，核心调整参数有两个：

• max-num-batched-tokens：允许同时处理的token总数。这个值直接影响GPU显存中KV cache的预分配大小。以A100 80G部署Llama-2-70B为例，可通过压测找到最佳点。先在ACK中启动一个压测Job，逐步提升该值，直到显存占用达到gpu-memory-utilization设定的上限（建议设为0.92左右）为止。

• gpu-memory-utilization：控制vLLM用于模型权重和KV cache的显存比例。不要设置成1.0，需为CUDA context和临时缓冲区保留约5%～8%余量。

压测命令示例（使用ghz等gRPC压测工具）：  bash  ghz --insecure --proto=service.proto \      --call=inference.v1.InferenceService/Predict \      -d '{"prompt":"Explain AI in 50 words"}' \      -c 32 --rps 100 --total 10000 \      http://ack-inference-service.default.svc.cluster.local:8500

• 效果说明：通过调整上述参数，同一张A10 GPU在部署Qwen-7B时，从默认配置下的约20 QPS提升至85 QPS，同时首token延迟中位数从1.8s降至0.6s。原因是连续批处理将多个请求的计算复用为矩阵乘，大幅提升了Tensor Core使用率。一个容易被忽视的细节是：max-num-batched-tokens设为4096和8192时，在短文本场景下吞吐可能只差15%，但长文本场景会差60%以上，因此必须基于生产真实请求长度分布来定，而不是用固定基准压测。

3. CUDA与驱动层优化——消除隐性抖动

应用层调优完成后，仍有约20%的性能损耗可能来自CUDA runtime和驱动配置。ACK GPU节点默认的NVIDIA驱动（例如525系列）与vLLM推荐的535以上版本在并发场景下存在明显差异，主要体现在CUDA graph捕获和统一内存管理上。

• 操作说明：

• 升级驱动与CUDA版本：在ACK节点池的“自定义镜像”或“节点升级”选项中，选用基于535.129.03以上驱动版本制作的自定义镜像。或通过DaemonSet在每个GPU节点上执行nvidia-driver-installer完成原地升级。

• 锁定GPU时钟频率：推理负载对时钟频率抖动敏感，可通过设置nvidia-smi -ac 1215,1410（针对A10）锁定应用时钟，避免动态调整引入的延迟毛刺。

• 启用CUDA MPS（多进程服务）：当需要在一张GPU上运行多个vLLM实例（如多个小模型）时，通过export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mps启动MPS守护进程，能将多进程的kernel launch开销合并，对SM利用率的提升可达10%～15%。

• 效果说明：在某金融客户的实际评测中，仅将驱动从525升级到535并启用CUDA graph，vLLM的token生成延迟P99从320ms降至240ms，消除了周期性出现的100ms级抖动。锁频后，同一批请求的latency分布更集中，P999与平均延迟的差距缩小至2倍以内。需要注意的是，MPS在部分旧卡（如T4）上存在无限制显存争抢的问题，生产环境建议仅在经过隔离验证的cgpu方案下开启。

综合来看，这三项优化并非各自独立：量化降低了显存门槛，让更多请求可以并发进入批处理，驱动层优化则保证这些并发请求不会因底层抖动而拖慢整体SLA。在ACK上落地时，建议先在灰度环境基于真实流量录制回放完成一轮压测基线，再逐项叠加优化，最终将最佳参数固化到ACK的ConfigMap或Helm values中，避免每次发布重新调优。

五、监控与成本控制

GPU 集群跑起来之后，最容易掉进的坑不是性能调优，而是“盲跑”——GPU 一直在烧钱，但没人说得清这些算力到底转化成了多少有效的推理吞吐。我们在多个生产集群里看到过同一类问题：监控大屏上 GPU 使用率漂亮地维持在 85% 以上，实际一查 QPS，发现大量请求在排队超时，SM 利用率虚高是因为 CUDA 内核在反复处理已经被丢弃的请求上下文。监控需要同时看硬件指标和业务指标，二者断开会直接导致成本误判。

1. 实时监控 GPU 指标：把 DCGM 数据用对

NVIDIA DCGM（Data Center GPU Manager）是 GPU 监控的事实标准，但默认暴露的 200 多个指标里，真正对推理场景有诊断价值的只有少数几个。部署在 ACK 上时，推荐使用阿里云容器洞察或自建 Prometheus + DCGM Exporter 的组合，重点盯住以下四个指标：

一个实际的经验是：对于 7B 模型的 FP16 推理，A10 卡上 SM 利用率 60%、显存带宽利用率 90% 是完全正常的，这时候去加批处理大小反而可能因为 KvCache 抢占导致延迟抖动。正确的做法是设置一个“显存带宽利用率 > 85% 且请求 P99 延迟 > 目标值”的组合告警，而不是单独盯 SM 利用率。

Prometheus 抓取 DCGM 指标的配置示例：

# DCGM Exporter ServiceMonitor 配置片段
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: dcgm-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: dcgm-exporter
  endpoints:
  - port: metrics
    interval: 15s
    relabelings:
    - sourceLabels: [__meta_kubernetes_pod_node_name]
      targetLabel: node

把 GPU 指标接入 Grafana 后，建议为每个推理服务建一张独立的 Dashboard，层叠展示 SM 利用率、显存带宽、请求 QPS 和 P99 延迟。当流量上涨时，如果 QPS 停滞但 SM 利用率略微下降、显存带宽拉满，基本可以判定遇到了显存墙——需要调整 gpu-memory-utilization 参数或启用量化。

2. 成本优化策略：从“提高利用率”到“降低单次推理成本”

行业里有个常见误区：GPU 利用率越高，成本就越低。但在推理场景中，高利用率如果建立在响应延迟恶化的基础上，实际单位成本可能不降反升。成本优化应该锚定一个核心指标：单次推理成本，即（GPU 实例单价 × 占用时长）/ 有效推理次数。

据此拆解出三个可操作的优化方向：

方向一：GPU 共享精细化调度

阿里云 ACK 的 cGPU 方案支持单卡切分为多个显存和算力隔离的虚拟 GPU。实测数据：一张 A100-80G 物理卡部署 4 个 7B 模型推理实例（每个分配 18GB 显存，算力权重各 25%），相比 4 张独享 T4 卡方案，整体推理吞吐提升约 1.8 倍，单次推理成本下降 40% 以上。关键在于为每个实例设置合理的 gpu-core-utilization 权重，高优先级服务配更高算力占比，开发测试环境压到 10% 即可。

# Pod 级别 GPU 共享配置（cGPU）
apiVersion: v1
kind: Pod
metadata:
  name: inference-service-dev
spec:
  containers:
  - name: llm-server
    resources:
      limits:
        aliyun.com/gpu-mem: 18   # 分配 18GB 显存
        aliyun.com/gpu-core: 10  # 算力权重 10%

方向二：基于推理 QPS 的弹性伸缩

GPU 利用率做 HPA 的缺陷是滞后性太强——当利用率飙上来时，排队可能已经堆积了 30 秒。改为基于推理引擎暴露的 QPS 指标或请求排队长度做 HPA，响应更快。推荐配置两级扩缩策略：

• 快速扩容：当排队请求数 > 5 且持续 30 秒，立即增加 Pod；

• 慢速缩容：当排队请求数 < 2 且持续 10 分钟，逐步减少 Pod，避免频繁波动引发冷启动。

需要注意冷启动时间。一个 7B 模型的容器从拉取镜像到完成模型加载，即使模型权重已预置在镜像中，通常仍需 40-60 秒。可以为每个 GPU 节点配置一个“预热 Pod”，在低峰期保持最小副本数，确保扩容时新 Pod 能从本地缓存加载。

方向三：闲置资源回收与混部

我们在实际生产中观察到：大部分推理业务的流量曲线有明显的昼夜波谷，凌晨 2-5 点 GPU 利用率可能掉到 10% 以下。如果这个时段仍按峰值维持 Pod 数量，相当于每月浪费约 20% 的 GPU 费用。借助 ACK 的定时 HPA 或 CronHPA，在低峰期将推理 Pod 缩减至最小副本，释放的 GPU 节点交由弹性实例池回收。对于不能完全停服的业务，可以保留一个低配共享 GPU 实例兜底，延迟适当放宽容忍度。

最后一步是成本可视化：给每个推理服务的 Pod 打上 team、project、env 标签，通过阿里云费用中心的标签分账功能，将 GPU 实例费用、网络流量费、存储费精确分摊到业务线。只有当每个团队都能看到自己跑一趟推理的成本是多少钱，优化才不再是运维团队的单方面诉求。

六、生产环境最佳实践

从技术验证到生产落地，中间横着一条不少团队容易低估的鸿沟。模型能跑通推理是一回事，能够在流量波动下稳定服务、在预算范围内扛住成本，是另一回事。下面这几项实践来自多个业务团队在ACK上长期运行大模型推理服务的经验总结，未必适用于所有场景，但背后的取舍逻辑值得参考。

1. 高可用部署设计

大模型推理服务的高可用，核心矛盾在于容器冷启动时间与业务可用性要求之间的错配。一个7B模型的容器启动到ready状态通常需要60-120秒，70B模型如果从远端拉取权重，这个时间可能拉长到5分钟以上。当流量突然涌进来，HPA触发扩容，但新Pod迟迟不就绪，请求堆积在已有Pod上又触发新一轮扩容——这是典型的扩容雪崩。

解决思路分三条线并行。

第一条线，镜像预热与模型本地化。不要把几十GB的模型权重放在镜像启动后再下载。直接在构建镜像时把量化后的权重、分词器、配置文件全部打进镜像，或者挂载阿里云CPFS文件系统——后者对70B以上超大模型效果更明显，因为节点本地磁盘可能吃紧。CPFS的吞吐可以做到数百GB/s级别，冷启动时模型加载环节能压到30秒以内。代价是CPFS按容量和吞吐付费，需要纳入成本核算。

第二条线，跨可用区反亲和部署。ACK节点池建议覆盖同一Region的两个可用区，Pod配置podAntiAffinity规则，避免同一推理服务的所有副本落在同一可用区或同一台物理机。一个典型配置如下：

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values:
                - llm-inference
        topologyKey: topology.kubernetes.io/zone

这样做不是为了追求极致的SLA数字，而是防止单点故障——某个可用区GPU实例售罄或出现故障时，至少还有一半capacity在跑。

第三条线，多GPU类型备选池。以A10实例作为主力推理节点，成本相对可控；但可以在集群中保留少量A100节点，配置更低优先级的节点亲和性。平时A100跑离线评测或压测任务，一旦A10资源紧张，通过Kubernetes的优先级调度将A100临时征用给生产推理服务。这比单纯扩容A10更灵活，因为GPU实例在部分region偶尔会出现短期库存紧张。

2. 安全加固措施

容器环境下的推理服务安全，容易被“模型跑在内部集群里”这种假设麻痹。实际上，推理API直接对业务侧暴露，请求内容不可控，容器逃逸和模型盗用的风险都需要正视。

网络侧，Ingress层面启用WAF防护，对推理API做请求速率限制和payload大小校验。一个容易被忽视的点是，vLLM和TGI的API端口通常会暴露/metrics端点，这些指标数据包含请求延迟分布、批处理大小等信息，暴露出去相当于给攻击者提供了推断服务负载和内部分布的能力。建议在Ingress规则中加一条路径过滤，只放行/infer和/health接口，/metrics仅对Prometheus内网IP开放。

运行时侧，容器以非root用户运行，并在Pod安全上下文中设置readOnlyRootFilesystem为true。GPU推理服务不需要写本地磁盘的持久化数据，只读文件系统可以阻断大部分通过写入/tmp或/dev/shm的提权路径。同时配置seccompProfile为RuntimeDefault，进一步限制系统调用范围。

密钥管理，如果推理服务需要访问对象存储拉取模型、或调用外部API，不要把AccessKey硬编码在镜像或环境变量里。ACK支持通过CSI驱动将阿里云KMS中的密钥以文件形式挂载到Pod内，容器启动时读取，用完即销毁，避免秘钥泄露后连锁扩散。如果团队已经在用HashiCorp Vault，也可以通过Sidecar方式注入，选择权在团队自身基础设施的成熟度。

3. 典型案例经验总结

某电商客服团队在ACK上部署Qwen-14B对话模型，支撑日均200万次推理请求。他们的经验值得拆解。

选型阶段，他们最早在T4单卡上跑FP16原始模型，单卡吞吐只有12 tokens/s，高峰期需要12-15个Pod才能兜住流量，月成本轻松破万。后来做了两件事：一是用AWQ将模型量化到4-bit，显存占用从28GB压到8GB，单卡batch size从4提升到16；二是把推理引擎从原生PyTorch换成vLLM，启用continuous batching。最终单卡A10能跑到85 tokens/s，Pod数量压缩到3-4个，综合成本下降了62%。

冷启动优化值得单独拿出来说。他们把模型权重打进镜像，同时利用ACK的容器预热功能——在低峰期预先拉取镜像到一批闲置节点上，HPA触发扩容时直接调度到已预热的节点，Pod就绪时间从90秒压到15秒。这个方案需要闲置一些节点容量，但他们估算后发现，预留两台A10节点的成本远低于因扩容延迟导致的超时重试和用户投诉成本。成本和质量间的交换，要用数据说话而不是凭感觉。

监控层面，他们最初只看GPU平均利用率，30%看起来很低，但用户反馈高峰期延迟抖动严重。接入DCGM细粒度指标后发现，问题是GPU显存带宽打满导致的排队——利用率不高，但带宽已经到顶了。这个场景下，加卡解决不了问题，真正有效的是降低max-num-batched-tokens参数，减少单次推理的batch规模，牺牲一点吞吐换稳定的P99延迟。团队的结论是：GPU利用率这个单指标，对推理服务的诊断价值有限，必须同时看SM利用率、显存带宽利用率和请求排队深度这三个维度。

这些经验背后有一个共同的判断：大模型推理上生产，不是一个纯技术问题，而是资源规划、成本核算和稳定性保障的持续平衡。每一项优化都在某个维度带来收益，也会在另一个维度产生新的成本——提前量化这些得失，是在ACK上跑稳推理服务的前提。