Azure自托管大模型实战：vLLM+AKS+GPU部署完整指南

为什么选择自托管大模型

随着大语言模型（LLM）在企业应用中的普及，越来越多的团队开始面临一个关键抉择：是继续依赖 OpenAI、Anthropic 等第三方 API，还是将模型部署在自己可控的基础设施上？对于有数据合规要求、追求成本可预测性、或需要深度定制推理服务的团队而言，自托管（self-hosting）正在成为一个越来越有吸引力的选项。

2024 年以来，自托管 LLM 的趋势明显加速，这背后有几个关键驱动力：开源模型能力的快速追赶（如 LLaMA 3、Mistral、Qwen 2.5 等在多项基准上接近 GPT-4 水平）、推理框架的成熟降低了部署门槛、以及企业对 AI 供应链安全的担忧（避免对单一 API 提供商的过度依赖）。这些开源模型之所以能快速追赶商业闭源模型，得益于多项关键技术突破：训练数据质量的大幅提升（如 LLaMA 3 使用了超过 15 万亿 token 的高质量训练数据）、DPO 等低成本对齐技术的普及、以及 GQA（Grouped Query Attention）等架构优化在保持性能的同时显著降低了推理资源需求。在 MMLU、HumanEval、GSM8K 等主流基准测试上，这些开源模型已达到 GPT-4 早期版本 85-95% 的水平，对于绝大多数企业应用场景已经完全够用。

Gartner 预测到 2025 年将有超过 50% 的企业在生产环境中使用开源基础模型，这一比例在 2023 年仅为约 15%。对于中国市场，DeepSeek、通义千问等国产模型的开源更是为自托管提供了更贴近本地场景的选择。

近期，一位开发者（GitHub 用户 shiqs90）在 Reddit 上分享了一个完整的端到端项目，演示如何在 Azure 上使用 Kubernetes 自托管 LLM。项目地址为 vllm-serving-aks，涵盖了从 GPU 调度到成本控制的全套工程实践，对于想要落地私有化推理服务的团队具有很高的参考价值。

技术栈解析：vLLM 与 AKS 的组合

该项目的核心技术选型体现了当前 LLM 服务化的主流思路，将高性能推理引擎与云原生编排能力相结合。

vLLM：高吞吐量推理引擎

项目采用 vLLM 作为推理引擎，这是当前开源社区最受欢迎的 LLM serving 框架之一。vLLM 由加州大学伯克利分校的 Sky Computing Lab 于 2023 年开源发布，迅速成为 LLM serving 领域的标杆项目。在此之前，开源社区的推理方案主要包括 HuggingFace 的 Text Generation Inference（TGI）、NVIDIA 的 Triton Inference Server 以及各类基于 FastAPI 的轻量封装。vLLM 的独特价值在于它从底层重新设计了显存管理和请求调度机制，而非在已有框架上做增量优化。截至 2024 年，vLLM 已支持包括 LLaMA、Mistral、Qwen、Yi 等主流开源模型架构，并提供了与 OpenAI API 格式兼容的服务端点，使得迁移成本极低。

在当前 LLM 推理框架的竞争格局中，vLLM 的主要竞品各有侧重：HuggingFace TGI 侧重于易用性和 HuggingFace 生态的无缝集成；NVIDIA TensorRT-LLM 通过算子融合和 FP8 量化提供最极致的单卡推理性能，但编译流程复杂且强绑定 NVIDIA 硬件；斯坦福团队的 SGLang 则创新性地引入 RadixAttention 实现更高效的前缀共享，在多轮对话和 agent 场景下表现出色。vLLM 凭借活跃的社区、快速的模型支持迭代以及在易用性和性能之间的良好平衡，成为大多数团队的默认选择。

vLLM 的核心优势在于其 PagedAttention 机制，能够显著提升 GPU 显存的利用率，并通过连续批处理（continuous batching）大幅提高推理吞吐量。相比直接用 Transformers 库或简单的 Flask 封装，vLLM 在生产环境下的并发性能往往能提升数倍。

PagedAttention 机制深度解析

PagedAttention 是 vLLM 团队在 2023 年 SOSP 会议上发表的核心创新。要理解其价值，首先需要理解 KV Cache 为何是 LLM 推理的核心瓶颈。Transformer 模型在自回归生成时，每产生一个新 token 都需要对之前所有 token 计算注意力。KV Cache 通过缓存已计算的 Key 和 Value 向量避免重复计算，将每步推理的复杂度从二次方降为线性。但其代价是巨大的内存开销——一个 13B 参数模型、2048 序列长度的单个请求 KV Cache 就需要约 1.7GB 显存。当并发请求达到数十个时，KV Cache 的显存占用往往超过模型参数本身，成为限制吞吐量的首要因素。

传统 LLM 推理中，每个请求的 KV Cache 需要预先分配连续的 GPU 显存块。由于生成文本的长度不可预知，系统往往需要按最大长度预留显存，导致实际利用率通常不到 30%。PagedAttention 借鉴了操作系统中虚拟内存的分页机制，将 KV Cache 切分为固定大小的块（blocks），这些块不需要在物理显存中连续存放，通过一张块表（block table）进行映射管理。这种设计使得显存碎片化问题大幅缓解，多个请求可以共享相同的前缀缓存块（prefix caching），显存利用率可提升至接近 100%，从而在相同硬件条件下支持更高的并发请求数。

连续批处理与静态批处理的区别

传统的静态批处理（static batching）要求一个批次中所有请求同时开始、同时结束。由于 LLM 生成文本是逐 token 进行的，较短的回复完成后必须等待批次中最长的回复结束才能释放资源，造成严重的 GPU 空闲浪费。连续批处理（continuous batching，也称为 iteration-level batching）则允许在每个解码步骤（iteration）对批次进行动态调整：当某个请求完成生成后，立即将新的等待请求插入批次中。这意味着 GPU 在任何时刻都尽可能满载运行。Orca（2022 年提出的调度系统）最早实现了这一思想，vLLM 在此基础上结合 PagedAttention 进一步优化了调度效率，实测吞吐量相比 HuggingFace Transformers 的朴素推理可提升 14-24 倍。

AKS：托管 Kubernetes 的弹性调度能力

项目使用 Azure Kubernetes Service（AKS） 作为编排层。选择 Kubernetes 而非单机部署，主要是为了获得弹性伸缩、故障恢复以及标准化运维的能力。对于需要长期运行、并可能面临流量波动的推理服务而言，K8s 提供的声明式管理和水平扩展能力是不可或缺的。

Kubernetes 最初设计用于无状态微服务的编排，但随着 AI/ML 工作负载的爆发式增长，社区在 GPU 调度、大规模分布式训练和推理服务方面做了大量扩展。2024 年 Kubernetes 生态中涌现了多个专门面向 AI 推理的项目，如 KServe（提供 serverless 推理能力）、LeaderWorkerSet（管理多节点分布式推理）以及 NVIDIA 的 NIM（NVIDIA Inference Microservices）。AKS 作为 Azure 的托管 Kubernetes 服务，相比自建 K8s 集群省去了控制面运维，并提供了与 Azure 生态（如 Azure Monitor、Azure Policy、Microsoft Entra ID）的深度集成，特别适合已在 Azure 云上有业务部署的企业。

Azure Kubernetes Service 的 GPU 节点池架构

AKS 通过节点池（node pool）的概念来管理不同类型的计算资源。在 LLM 推理场景中，通常会创建至少两个节点池：一个使用标准 CPU 实例承载系统组件（如 Kubernetes 控制面代理、监控 DaemonSet 等），另一个使用 GPU 实例专门运行推理工作负载。

Azure 提供多个系列的 GPU 虚拟机以适配不同需求：NCas_T4_v3 系列配备 NVIDIA T4（16GB 显存），性价比较高，适合 7B 以下小模型推理；NC_A100_v4 配备单块或多块 A100（80GB 显存），是当前主流的大模型推理选择；ND 系列（如 ND96asr_v4 配备 8x A100 通过 NVSwitch 全互联，NDm_H100_v5 配备 8x H100）面向超大模型推理和分布式场景，节点内 GPU 通过 NVSwitch 全互联，节点间通过 InfiniBand 400Gb/s 高速网络连接。

这种分离设计的好处在于：CPU 节点池可以设置为低成本的 B 系列或 D 系列实例，而 GPU 节点池可以配置独立的自动伸缩策略，在无推理请求时缩容至零节点，从根本上消除空闲 GPU 的成本浪费。AKS 还支持通过 Cluster Autoscaler 与 Azure 的虚拟机规模集（VMSS）集成，实现从零到多节点的自动扩展，典型的冷启动时间约为 3-8 分钟（取决于 GPU 实例类型的可用性和镜像大小）。

NVIDIA GPU Operator：GPU 资源的标准化管理

在 Kubernetes 上使用 GPU 并非开箱即用。项目引入了 NVIDIA GPU Operator，它负责自动化部署 GPU 驱动、容器运行时（container toolkit）、设备插件（device plugin）以及监控组件。这套工具链让 GPU 节点的初始化从繁琐的手动配置变成了声明式的自动化流程，是 K8s 上运行 GPU 工作负载的关键基础设施。

NVIDIA GPU Operator 的组件架构

NVIDIA GPU Operator 是一个 Kubernetes Operator——一种将运维知识编码为软件的设计模式，通过自定义资源（CRD）和自定义控制器实现对复杂有状态应用的自动化管理。控制器持续监控资源的期望状态与实际状态之间的差异，并执行调谐（reconciliation）操作使其趋于一致。在 GPU 节点频繁伸缩的云环境中，这种自动化能力尤为关键——当新节点加入集群时，Operator 会自动检测节点状态并按序部署所有必要组件，无需人工干预。

具体而言，GPU Operator 将 GPU 节点所需的整个软件栈封装为一组协调部署的容器化组件：（1）GPU Driver Container——在容器内编译并加载与宿主内核匹配的 NVIDIA 驱动，避免直接修改节点操作系统；（2）NVIDIA Container Toolkit——配置容器运行时（如 containerd）使其能够将 GPU 设备透传给容器；（3）NVIDIA Device Plugin——向 Kubernetes 的资源调度器注册 nvidia.com/gpu 资源类型，使 Pod 可以通过 resources.limits 声明 GPU 需求；（4）DCGM Exporter——收集 GPU 利用率、显存使用、温度等指标并暴露为 Prometheus 格式，便于监控告警；（5）GPU Feature Discovery——自动为节点打上 GPU 型号、驱动版本、CUDA 版本等标签，方便通过 nodeSelector 进行精确调度。整套组件通过 ClusterPolicy CRD 统一声明和管理，大幅降低了 GPU 集群的初始化和升级复杂度。

生产化部署中的关键挑战与解决思路

从项目内容来看，真正的难点并不在于跑通一个 demo，而在于处理生产化过程中的各种工程细节。

GPU 调度配置

在 Kubernetes 中，GPU 是一种不可切分的稀缺资源（默认情况下）。如何让 Pod 正确请求到 GPU、如何避免多个 workload 争抢同一块显卡、如何配置节点亲和性（node affinity）和污点容忍（taints/tolerations）确保 GPU 节点被合理利用，都是需要精心设计的环节。项目专门覆盖了 GPU scheduling 这一主题，说明作者在实践中确实踩过相关的坑。

Kubernetes 中 GPU 调度的技术细节

Kubernetes 将 GPU 视为扩展资源（extended resource），默认不可分割——一个 Pod 请求 1 块 GPU，就独占该 GPU 的全部算力和显存。这与 CPU（可按毫核切分）和内存（可按字节切分）截然不同。在实际部署中需要注意几个关键配置：第一，通过 taints 和 tolerations 确保只有 GPU 工作负载才会被调度到昂贵的 GPU 节点上，防止普通 Pod 浪费 GPU 资源；第二，使用 nodeAffinity 指定模型部署到特定 GPU 型号的节点（例如大模型需要 A100 80GB 而非 T4 16GB）；第三，对于多 GPU 推理（tensor parallelism），需要确保所有 GPU 分配在同一节点上，可通过 topology 约束实现。此外，NVIDIA 近年推出的 MIG（Multi-Instance GPU）和 GPU Time-Slicing 技术允许在一定程度上对 GPU 进行逻辑切分，适用于小模型复用同一块 GPU 的场景，但对于 7B+ 参数的 LLM 推理通常仍需独占整卡。

Tensor Parallelism 与多 GPU 推理

对于超过单卡显存容量的大模型（如 70B 参数模型在 FP16 下需要约 140GB 显存），必须采用模型并行策略将模型分布在多块 GPU 上。最常用的方式是张量并行（Tensor Parallelism，TP），即将 Transformer 每一层的权重矩阵按列或行切分到不同 GPU 上，各 GPU 分别计算后通过 NVLink 或 PCIe 进行 All-Reduce 通信汇总结果。vLLM 原生支持 TP 配置，只需设置 tensor-parallel-size 参数即可自动完成切分。在 Kubernetes 环境中，这要求所有 GPU 位于同一节点（通过 nodeAffinity 约束）且节点内 GPU 间具备高带宽互联（NVLink 可提供 600-900 GB/s 带宽，远优于 PCIe 的 64 GB/s）。Azure 的 ND 系列实例（如 ND96asr_v4 配备 8x A100 通过 NVSwitch 全互联）特别适合此类多卡推理场景。

部署问题排查

作者提到项目包含了「deployment issues」的内容。在真实部署中，常见的问题包括：镜像体积过大导致拉取超时、模型权重下载缓慢、显存不足（OOM）导致 Pod 崩溃、以及驱动版本与 CUDA 版本不匹配等。这类经验往往是官方文档中不会详述、但工程师最需要的实战知识。

模型权重加载与镜像优化策略

LLM 模型权重通常在数 GB 到数十 GB 之间（如 LLaMA 2 7B 约 13GB，70B 约 130GB），这给容器化部署带来了独特挑战。常见的模型加载策略有三种：（1）将模型烘焙（bake）进容器镜像——简单直接但导致镜像巨大，每次更新模型需重新构建推送；（2）Pod 启动时从对象存储（如 Azure Blob Storage）下载——灵活但冷启动慢，取决于网络带宽；（3）使用持久卷（PersistentVolume）预挂载模型文件——通过 Azure Files 或 Azure NetApp Files 提供共享存储，多个 Pod 可同时只读挂载同一份模型数据，既避免镜像膨胀又减少重复下载。在 AKS 环境中，还可以利用 Ephemeral OS Disk 和镜像缓存（通过 Azure Container Registry 的 artifact streaming 功能）加速大镜像的拉取速度，将原本需要 10-15 分钟的镜像拉取缩短至 2-3 分钟。

云上 GPU 成本控制策略

这可能是自托管 LLM 最容易被低估的部分。GPU 实例（尤其是 A100、H100 这类高端卡）的云上单价极高，如果集群 7×24 小时空转，成本会迅速失控。项目覆盖了 cost controls，可能涉及的策略包括：使用 Azure Spot 实例降低计算成本、配置集群自动伸缩（Cluster Autoscaler）在低峰期缩容、以及通过合理的 batch 配置提高单卡吞吐从而减少所需 GPU 数量。

Azure Spot 实例与 GPU 成本优化

Azure Spot 虚拟机利用 Azure 数据中心的闲置计算容量，以最高可达常规价格 90% 的折扣提供 GPU 实例。其代价是 Azure 可能在任何时候以 30 秒通知收回实例（eviction）。对于 LLM 推理服务，这带来了独特的工程挑战：推理请求是无状态的短时任务，一次收回只会影响正在处理的几个请求，通过多副本部署和负载均衡可以有效应对。典型的混合策略是：保留 1-2 个按需（on-demand）GPU 节点作为基线容量保证 SLA，同时使用 Spot 节点池处理突发流量。AKS 原生支持 Spot 节点池配置，结合 Pod Disruption Budget（PDB）可以控制同时被收回的 Pod 数量，确保服务不会完全中断。在实际案例中，NC_A100_v4 系列 Spot 实例的价格可从按需价格的约 $3.67/小时降至 $0.37-1.10/小时，成本节省非常显著。

自托管 LLM 的决策评估要点

虽然这类项目为技术落地提供了清晰的路径，但团队在决策前仍需理性评估以下几个维度。

成本临界点：自托管并不总是更便宜。只有当调用量足够大、GPU 利用率足够高时，自建才可能优于按量付费的 API。对于零星调用的场景，第三方 API 往往更经济。一个粗略的经验法则是：当团队每月的 API 开支持续超过一台 GPU 实例的月度成本（包含运维人力折算）时，就值得认真评估自托管方案。以 GPT-4 级别的模型为例，如果每月 API 费用超过 $5,000-10,000，自托管一台 A100 实例（按需约 $2,600/月，Spot 可能低至 $800/月）配合开源模型可能已经具备经济性。

运维复杂度：从这个项目涉及的技术点——vLLM、GPU Operator、K8s 调度、成本优化——就能看出，自托管的运维门槛并不低。团队需要具备 Kubernetes 和 GPU 运维的相关能力，否则容易陷入长期的维护泥潭。

数据合规与主权价值：对于金融、医疗、政务等对数据主权有严格要求的行业，自托管带来的数据可控性往往是决定性因素，此时成本反而是次要考量。在欧盟 GDPR、中国《数据安全法》等法规框架下，将用户对话数据发送至第三方 API 可能面临合规风险，而自托管模型可以确保数据完全不出组织边界，审计追踪也更加清晰可控。

模型能力与灵活性：自托管开源模型还带来了第三方 API 所不具备的深度定制能力。团队可以对模型进行领域微调（fine-tuning）、调整推理参数（如温度、top-p、重复惩罚等的精细控制）、实施自定义的安全过滤策略，甚至修改模型的 tokenizer 以适应特定领域术语。此外，不存在第三方 API 的速率限制（rate limiting）和上下文窗口限制变更等不可控因素，服务的可用性和性能完全由自己掌控。

总结

shiqs90 分享的 vllm-serving-aks 项目是一份务实的 LLM 自托管工程参考。它没有停留在「Hello World」层面，而是完整覆盖了 vLLM 推理引擎配置、NVIDIA GPU Operator 部署、K8s GPU 调度策略、部署排错经验和成本控制方案等生产化必备环节。对于正在评估私有化部署路线的团队，这类开源实践既能提供技术蓝图，也能帮助提前识别落地过程中的关键风险点。在大模型推理服务日益走向企业私有化部署的趋势下，掌握这套 vLLM + Kubernetes + GPU 的技能栈将越来越重要。