Azure Local GPU 部署与企业应用场景指南（下篇）

XUHUOJUN

132人浏览 · 2026-07-11 13:11:14

XUHUOJUN · 2026-07-11 13:11:14 发布

文档定位：下篇（讲清 "Azure Local 上 GPU 如何真正部署、运维、应用、被 NVIDIA vGPU License 约束、参考资料"。

上篇讲 "概念、硬件底座、支持矩阵、OEM 集成、AKS Arc 池"。

适用版本：Azure Local 23H2 / 2510 / 2512 / 2606 / 2607（azloc-2606 官方 GPU 文档：config_moniker_range: '>=azloc-2512 || =azloc-previous'）。

§F. GPU 部署操作流程总览

承接上篇：上篇 §B~§E 给出了硬性约束、支持矩阵、OEM 集成、AKS Arc GPU 池。本篇讲真正动手做时——怎么准备 host / VM / 网络 / 存储，然后让一块 GPU 真正交到一台 VM（Hyper-V）或一个 pod（AKS Arc）手里。

【来源说明】：

【azloc-2606 原文】：gpu-preparation / gpu-manage-via-device / gpu-manage-via-partitioning / attach-gpu-to-linux-vm

【NVIDIA 官方】：NVIDIA vGPU Manager 安装文档（附在 vGPU 软件包内）+ NVIDIA vGPU Software Quick Start Guide

【企业最佳实践层】：经验性 cmdlet 参数与判断，全部标"经验"

§F.1 部署前的准备清单（azloc-2606 system-requirements + gpu-preparation）

准备项	标准	检查方法
Azure Local 23H2+ 安装完成	OS build ≥ 26100.xxxx	`Get-ComputerInfo \| Select WindowsProductName, WindowsBuildLabEx`
Arc 注册完成	集群在 Azure portal 显示	`az connectedmachine list` 或 portal
节点 BIOS 设置就位	SR-IOV / VT-d / Above 4G Decoding 全开（参上篇 §B.1.1）	BIOS Setup
GPU 物理安装完成	同型同容；建议 OEM 认证机型	iDRAC / OpenManage
GPU 出现在 host 上	`Get-VMHostPartitionableGpu` 列出	PowerShell on host
NVIDIA host driver / vGPU Manager 安装	DDA 路径：仅 host driver；GPU-P 路径：host driver + vGPU Manager	`nvidia-smi -L` / `Get-Service NvGpuManagerService`
Arc Resource Bridge 部署	跨 GPU pod VM 受 Arc governance 影响	`az arcrb list`
VM / K8s 资源计划	VM SKU / node SKU / 网络 / storage	设计文档

§F.1.1 一个 host 上能见到 GPU 的 PowerShell 校验

# host 上 GPU 拓扑
Get-VMHostPartitionableGpu | Format-List Name, ValidPartitionCounts, PartitionSize, ParentHostPartitionableGpu

# 输出预期：
# Name        : NVIDIA L40
# ValidPartitionCounts : {1, 2, 3, 4, 6, 8}    ←  按硬件切分能力
# PartitionSize : 24576 / 12288 / 6144 / ...    ←  每个 partition 的显存大小（MB）

# DDA 信息
Get-VMPartitionableGpu | Format-Table InstanceId, PartitionCount

§F.2 Hyper-V 上 DDA 部署流程

【微软硬要求】：

DDA VM 不支持 Live Migration；只能 stopped → assign → start

主机侧 GPU 必须 AllocateOnce：把 GPU 从 host PnP 中移除，使其成为可分配设备

拆除路径（detach）必须先停 VM（azloc-2606 原文：attach 自动 shutdown 是明示；detach 是否自动 shutdown 没有明示——本篇档建议"detach 前 stop"以保守）

§F.2.1 DDA 9 步部署流程（azloc-2606 gpu-manage-via-device + attach-gpu-to-linux-vm 整理）

步骤 1：host 上 Get-VMAssignableDevice 列出 GPU 设备路径（azloc-2606 文档原文）

# 列出 host 上所有可分配给 VM 的设备
Get-VMAssignableDevice

> **【v1.6 Hyper-V DDA 完整流程提示】**：
> - **用途**：`Get-VMAssignableDevice` 列可分配设备；`Get-VMHostPartitionableGpu` 列可分区 GPU
> - **标准 DDA 流程**（生产推荐）：
>   1. `Get-PnpDevice -Class Display` 列出 GPU
>   2. `Disable-PnpDevice -InstanceId "..."` 禁用设备
>   3. `Dismount-VmHostAssignableDevice -Force` 卸载设备
>   4. `Add-VMAssignableDevice` 分配给 VM
> - **区别**：Assignable Device（整卡）和 Partitionable GPU（分区）是两个不同路径；生产环境建议走完整 4 步流程

```powershell
# 完整流程示例（生产推荐）
Get-PnpDevice -Class Display | Where-Object Status -eq 'OK' | Format-Table InstanceId, FriendlyName, Status
# 禁用并卸载
$gpu = Get-PnpDevice -Class Display | Where-Object FriendlyName -like '*NVIDIA*' | Select-Object -First 1
Disable-PnpDevice -InstanceId $gpu.InstanceId -Confirm:$false
Dismount-VmHostAssignableDevice -Force -LocationPath $gpu.InstanceId
# 分配
$vm = Get-VM "llm01"
Add-VMAssignableDevice -VM $vm -LocationPath $gpu.InstanceId

输出预期：

InstanceID : PCI\VEN_10DE&DEV_2684&SUBSYS_...&DEV_TYPE_GPU

上面的 10DE 是 NVIDIA Vendor ID；2684 是 device ID

**步骤 2**：将 GPU 从 host PnP 树里解挂——azloc-2606 文档用语 "Dismount the GPU from the host"

```powershell
# 选择 host GPU 路径名称
# 在 Host OS 上手动 disable GPU driver:
# Device Manager → Display Adapters → NVIDIA ... → Disable

步骤 3：创建 VM（VM 状态 Stopped）

New-VM -Name "llm01" `
  -Generation 2 `
  -MemoryStartupBytes 64GB `
  -Path "C:\ClusterStorage\Volume01\VMs\llm01" `
  -VHDPath "C:\ClusterStorage\Volume01\VHDs\llm01.vhdx" `
  -SwitchName "vSwitch-Production"

步骤 4：安装 OS（Windows Server 2025 / Linux）—— 与无 GPU VM 流程一致

步骤 5：停 VM 后 attach GPU（DDA 路径）

# azloc-2606 gpu-manage-via-device 原文 cmdlet：
$vm = Get-VM "llm01"
Stop-VM -VM $vm -Force

# 把 GPU 分给 VM
$gpu = Get-VMAssignableDevice | Where-Object InstanceId -like "*10DE*"
Add-VMAssignableDevice -VM $vm -DeviceId $gpu

步骤 6：配置 High MMIO Space（DDA 大显存卡必须——azloc-2606 attach-gpu-to-linux-vm 原文）

# azloc-2606 原文：
# Set-VM -GuestControlledCacheTypes $true
# Set-VM -LowMemoryMappedIoSpace 3Gb
# Set-VM -HighMemoryMappedIoSpace <vram + 12%>
# Set-VM -VMName "llm01"

# 实操示例（48 GB VRAM 的 L40S）：
Set-VM -VMName "llm01" `
  -GuestControlledCacheTypes $true `
  -LowMemoryMappedIoSpace 3Gb `
  -HighMemoryMappedIoSpace 55296Mb  # 48GB VRAM × 1.15 ≈ 55 GB

【企业最佳实践·MMIO 公式（经验）】：

微软官方原文给的是 "VRAM + 12%" 经验值

实际操作常写 1.10~1.15 倍（经验范围），高估不会出错、不足则 BSOD

L40S 48GB → HighMMIO 55296MB（与 VRAM × 1.15 等价）

A2 16GB → HighMMIO 18432MB

A40 48GB → HighMMIO 55296MB

步骤 7：开机 + 安装 NVIDIA guest driver

Start-VM -VMName "llm01"
# 登录到 VM 内：

# Windows VM：
#   - 安装 NVIDIA guest driver（含 CUDA Toolkit 可选）
#   - 验证 Device Manager → Display Adapters → NVIDIA ... 是否就位
#
# Linux VM（Ubuntu 22.04 LTS 为例）：
#   sudo apt-get update
#   sudo apt-get install -y nvidia-driver-555  # 与 host vGPU Manager 版本对齐
#   sudo nvidia-smi

步骤 8：验证 GPU 在 VM 内可用

# Windows VM 内：
nvidia-smi
# 预期：
#   +-----------------------------------------------------------------------------+
#   | NVIDIA-SMI 555.xx       Driver Version: 555.xx       CUDA Version: 12.x    |
#   | GPU  Name                 Persistence-M | Bus-Id        Memory-Used |
#   |   0  NVIDIA L40S                On    | 00000000:01:00.0  48 GB     |
#   +-----------------------------------------------------------------------------+

# Linux VM 内：
sudo nvidia-smi -q | grep -E "GPU|Product Name|Driver Version"
# 期望：显示 NVIDIA L40S + Driver Version + 总显存

步骤 9：运行时验证（如 CUDA sample）

# Linux VM 内跑 CUDA sample
git clone https://github.com/NVIDIA/cuda-samples.git
cd cuda-samples
make -C Samples/1_Utilities/deviceQuery
./bin/x86_64/linux/release/deviceQuery
# 期望输出：Result = PASS / CUDA Driver = OK

§F.3 Hyper-V 上 GPU-P 部署流程

【微软硬要求·GPU-P 限制（azloc-2606 gpu-manage-via-partitioning 原文）】：

一台 VM 只分配一个 GPU partition

单机 GPU 不能同时 DDA + GPU-P

主机 BIOS 必须 SR-IOV 已启用

partition 数（PartitionCount）由 azloc-2606 官方给出支持档（上面 PowerShell Get-VMHostPartitionableGpu 已能查到）

vGPU manager 安装配置后才能用 Set-VM -GpuPartition

Live Migration 支持（v1.6 关键限制）：

OS build ≥ 26100 + NVIDIA vGPU ≥ 18
GPU partition compatibility：目标节点必须具备兼容的 GPU 资源配置
不是所有 GPU-P 工作负载天然支持跨节点迁移——取决于：
- GPU-P 与 NVIDIA vGPU Manager 版本匹配
- Guest Driver 版本匹配
- Cluster 内 GPU 型号/partition topology 一致性
- vGPU profile 兼容性

§F.3.1 GPU-P 10 步部署流程（azloc-2606 gpu-manage-via-partitioning）

步骤 1~4：与 §F.2 DDA 步骤 1~4 一致（host 准备、VM 创建、OS 安装）

步骤 5：在 host 上安装 NVIDIA vGPU Manager + host driver

【v1.3 关键新增 — Dell SolVe P58 原句】： "Before proceeding to install the GPU-P drivers on the host, remove any Tesla drivers, if previously installed."

本节档以前 v1.2 版本遗漏了这一前置步骤。这是戴尔、NVIDIA vGPU 文档原文明示的硬要求——vGPU 与 Tesla driver family 互斥；如果 host 上已装 Tesla driver（老 NVIDIA 数据中心卡配套），不先拆硬装 host driver 会失败。

5a：在每台 cluster host 上拆 Tesla driver（如果有）

# 查看是否存在 Tesla driver（Windows Server host）
Get-WmiObject Win32_PnPSignedDriver | Where-Object { $_.DeviceName -match "Tesla" -or $_.DriverProviderName -match "NVIDIA Tesla" }

# 如果有：到 "Programs and Features" → 卸载 NVIDIA Data Center GPU Driver 旧版
# Ubuntu Linux host：sudo apt-get --purge remove nvidia-tesla-driver-*

5b：装 NVIDIA vGPU host driver（R570 / vGPU 18.0 系列）

# 以 Ubuntu 22.04 LTS host 为例；驱体从 NVIDIA Application Hub 拉：
# https://nvidia.com/ → licensing portal → SOFTWARE DOWNLOADS
# Filter：PRODUCT FAMILY: VGPU + PLATFORM: Microsoft Azure Stack HCI
# 下载后验证 pkg 对应 GPU：
chmod +x NVIDIA-Linux-x86_64-555.xx.xx-grid.run
sudo ./NVIDIA-Linux-x86_64-555.xx.xx-grid.run --dkms

5c：装 NVIDIA vGPU Manager

# Windows host 示例：
Start-Service -Name "NvGpuManagerService"
Get-Service -Name "NvGpuManagerService"  # 期望：Running

# 每个 cluster 节点都要装 host driver + vGPU Manager，不是只一台
# 这是 azloc-2606 + Dell SolVe P58 文档共同明示

【来源标注】：NVIDIA vGPU Manager 安装文件随 NVIDIA vGPU 软件包发布；具体驱动号 / 服务名 / 启动命令以交付期 NVIDIA vGPU R570 软件包 README / Quick Start Guide 为准。vGPU R570 = vGPU 18.0~18.6，与上篇 §D.3.2 / §I 的版本对齐。

【⛭ Dell OEM 路径推荐 — Dell SolVe P58 原句】： "Dell Technologies recommends that you use Windows Admin Center for GPU partitioning (GPU-P)."

含义：如果用 Dell AX 跑 GPU，建议走 WAC + GPU extension GUI 路径，而非纯 PowerShell 的 cmdlet 路径。WAC 与 azloc-2606 的 Set-VM -GpuPartition cmdlet 二选一。

步骤 6：GPU-P partition 创建

6a【非 Dell 路径 — PowerShell cmdlet】（azloc-2606 gpu-manage-via-partitioning 原文 cmdlet）

# azloc-2606 原文 cmdlets（精简示意）：
$vm = Get-VM "vdi01"

# 把 GPU 切成 4 个 partition
Set-VM $vm -PartitionableGpu "GPUInstanceID" `
  -PartitionCount 4 `
  -AutoAttach   # 自动 attach partition

6b【Dell OEM 推荐 — WAC + GPU extension】（Dell SolVe P58 原句）

Windows Admin Center
  → Connect to cluster
  → "GPU" extension (installed via "Extensions" menu)
  → Select a node (例：Node01)
  → Select GPU (例：NVIDIA L40 on Riser 1, Slot 1)
  → Click "Create pool" + "Create partition"
  → "Partition count" 选有效档位（Get-VMHostPartitionableGpu 给出的 ValidPartitionCounts）
  → Apply
  → 与 Virtual Machine (WAC 内 Cluster Manager) 上 attach partition

【⛭ 实际差异对比】：

项	PowerShell cmdlet 路径	WAC + GPU extension 路径
步骤数	多步 cmdlet	集中 GUI
适用	脚本化 / 无人值守	人工 / 可视化检查
可重复	高（可以 PowerShell pipeline）	低（点鼠标）
与 OpenManage 集成	低	高（Dell AX 上 WAC 本身就是 OpenManage 入口）
Debug	透明（看 cmdlet return）	需看 WAC 日志

企业决策：脚本化配置 vs 可视化操作；Dell AX 场景下，WAC 是更平稳的默认；纯 azloc-2606 部署场景（非 Dell OEM）依然可以用 PowerShell 路径。

【来源标注】：上面 cmdlet 是 azloc-2606 文档结构的简化示意；具体 instance id / Set-VM 完整签名请查交付期 azloc-2606 文档。WAC + GPU extension 入口以 Dell OpenManage Integration extension v3.4 的当期版为准。

步骤 7：VM guest 装 vGPU driver

# Linux VM guest
sudo apt-get install -y nvidia-vgpu-555   # 与 host 同版本
sudo nvidia-smi
# 预期输出：
# +-----------------------------------------------------------------------------+
# | NVIDIA-SMI 555.xx       Driver Version: 555.xx       CUDA Version: 12.x    |
# | GPU  Name                Persistence-M | Bus-Id        Memory-Used |
# |   0  NVIDIA vGPU  ...           On    | 00000000:01:00.0  12 GB    |  ← partition
# |   vGPU type: vGPU-12B           ...                                   |  ← license
# +-----------------------------------------------------------------------------+

步骤 8：License 服务器（vGPU 客户端向 license server 申请）

详细路径在 §I. NVIDIA vGPU License 授权与 License Server 部署（NLS / DLS / CLS）。当前步骤仅指出 vGPU client 在启动后 90~120 秒内向配置的 license server 申请 license；如果 license server 不可达，进入 grace period。

步骤 9：验证 + 测试用例（与 DDA 步骤 9 一致）

步骤 10：在多 host 集群上验证 Live Migration

# Live Migration 在 OS ≥ 26100.xxxx + vGPU ≥ 18 才支持
# 验证 cmd:
Move-VM "vdi01" Node02
# 期望：从当前 node 平滑迁到 Node02，VM 不断网

§F.4 AKS Arc GPU 节点池部署流程（接上篇 §E）

完整部署流程见上篇 §E.3。这里只补充与 DDA / GPU-P 路径不一致的细节：

步骤	AKS Arc 路径	DDA 路径
Driver 安装	通过 NVIDIA device plugin + K8s extension 自动	host 上手工
License	不需要（AKS Arc 永远走 DDA）	不需要
GPU 分配单位	Pod	VM
调优对象	K8s resource request/limit	VM vCPU / 内存
验证方式	`kubectl run` + `nvidia-smi`	登录 VM + `nvidia-smi`
监控	`kubectl top pod` + NVIDIA DCGM exporter	主机 OS 性能计数器

§F.5 部署后的 GPU 验证矩阵

验证项	命令	通过判据
host 端 GPU 可见	`Get-VMHostPartitionableGpu`	返回 GPU 信息
host 端 NVIDIA 服务	`Get-Service NvGpuManagerService`	Running
VM / pod 内 NVIDIA 驱动	`nvidia-smi`	看到 GPU + Driver 版本 + VRAM
CUDA sample	`deviceQuery`	`Result = PASS`
实际 GPU 带宽	`nvidia-smi pmon -s um -c 1`	看到 SM 利用率
Live Migration（GPU-P only）	`Move-VM <name> <node>`	VM 平滑迁移，无断网
License（GPU-P only）	`nvidia-smi -q`	`License Status: Licensed`

§F.6 端到端示例项目（架构示意）

Azure Local Cluster
├── Host01
│   ├── GPU1 (L40S, 48GB)
│   │   ├── VM "llm-7B"
│   │   │   └── DDA 路径，OS Build ≥ 26100.xxxx
│   │   │   └── 高 High MMIO (55000MB+) + GuestControlledCacheTypes
│   │   │
│   ├── GPU2 (A2, 16GB, 切 8 个 partition)
│   │   ├── VM "vdi01" (~2GB vGPU) ← vPC license
│   │   ├── VM "vdi02" (~2GB vGPU) ← vPC license
│   │   ├── VM "vdi03" (~2GB vGPU) ← vPC license
│   │   └── ... 5 more ...
│   │
│   └── AKS Arc pool (DDA, GPU3 - L40):
│       ├── pod "llm-svc-7B"
│       └── pod "fashion-image-classifier"
│
├── Host02 (类似的拓扑)
│
└── DLS License server (single 或 HA cluster)
    ├── dls01.corp.example.com (Primary)
    ├── dls02.corp.example.com (Secondary)
    └── License Server File (.bin) 3-year validity

§G. 应用场景（Foundry Local + Agentic Retrieval + VDI / 视频分析）

上篇 §C.2 已给出"按场景选 GPU"的决策树。这一节按场景展开到端到端实施——每个场景给出架构图、模型选择、Hugging Face / Foundry 资源、运行时验证。

§G.1 场景总览

场景	GPU 选择	License	部署形态
G.2 LLM 推理（7B~13B）	L40S / A40 / RTX Pro 6000	不需要（DDA）	Hyper-V VM + DDA
G.3 Foundry Local 推理	L4 / L40 / L40S / A2 / A16	不需要	Arc-enabled K8s + DDA
G.4 Agentic Retrieval + RAG	L4 / L40 / L40S	不需要	Arc-enabled K8s + DDA
G.5 VDI	A16 / L4 (切 8~16 partition)	vPC / vWS	Hyper-V VM + GPU-P
G.6 视频分析	T4 / A2 / L4	不需要	Arc-enabled K8s + Foundry Local
G.7 RDSH 应用流	A2 / T4	vApps	Hyper-V VM + GPU-P
G.8 大模型训练	多卡 L40S	不需要	Azure Local 不适合大规模分布式训练（适合小模型微调/LoRA/单卡实验）

§G.2 LLM 推理（7B~13B 模型）

【v1.5 关键审校 — 改成事实描述而非观点】： Azure Local 对企业内部推理 / RAG / Agent等 较低延迟 + 数据驻留场景较适合；模型 7B~13B 跑在 DDA + L40S（48GB）/ A40（48GB）/ RTX Pro 6000（48GB）上是当前主流配置；azloc-2606 system-requirements 文档对 LLM 推理未明示"7B~13B 是最高 ROI"——这一类措辞属观点，实际 ROI 因业务负载、训练数据量、并发数而异，请以本企业模型评估为准#### §G.2.1 推荐模型（基于 vLLM / Hugging Face 当前公开）

模型	显存占用（FP16，理论值）	显卡选型	备注
Qwen2.5-7B-Instruct	14 GB	A2 (16GB) / L4 (24GB)	7B 主流配置
Llama-3.1-8B-Instruct	16 GB	L4 (24GB) / A16 (64GB)	Meta 官方
Qwen2.5-14B-Instruct	28 GB（理论值）	L40 / L40S / A40 (48GB)——实际部署预留 30~50% 含 KV cache / runtime / context length	14B 主流配置
DeepSeek-V2-Lite (16B, MoE)	不可按 16B × 2 bytes 直接估——MoE 模型显存需求取决于权重格式 / 专家加载策略 / runtime 优化；以 vLLM / SGLang 当期实测为准	L40S (48GB)	DeepSeek MoE
Phi-3.5-MoE (42B, MoE)	同上——MoE 不能按 42B × 2 bytes 直接估	L40S ×2 / RTX Pro 6000 多卡	MoE 入门

【v1.5 关键审校·显存计算的真实做法】：

公式 参数量 × bytes_per_param 仅给理论下限（仅权重）

实际部署还需：KV cache（与 context length × batch size 强相关，可占 GB 级）+ runtime overhead + vLLM page table + activations 等

LLM 推理预留（v1.5 工程经验，非官方权威数字）：单 7B~14B 模型，建议预留 30~50% VRAM 余量；长 context（≥ 4K）/ 大 batch 时需更多

MoE 模型例外：稀疏激活不等于显存省——专家权重按全量加载，显存基本等同于 dense 同规模模型；不能简单按激活参数量估算

§G.2.2 LLM 端到端示例（azloc-2606 + Foundry Local + vLLM）

# 在 Azure Local host 上创建 DDA VM（参 §F.2）
# 在 VM 内部署 vLLM（开源 LLM serving engine）

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-14B-Instruct \
  --port 8000 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --tensor-parallel-size 1

§G.2.3 性能与并发（经验值）

GPU	并发数	单请求延迟	吞吐量
A2 16GB + 7B	~8 ~16	200ms~1s	80 tok/s (单 batch)
L4 24GB + 7B	~16	<200ms	130 tok/s
L40S 48GB + 14B	~8	<300ms	80 tok/s
L40S ×2 + 30B	~4	<500ms	100 tok/s（TP=2）

【三层标注】：

【不绝对化】：上面数字是社区基准 + 经验；NVIDIA / vLLM / Azure 均没有官方承诺"Azure Local 上 7B 模型的速度"

【基准工具】：用 vllm benchmark 或 llama.cpp bench 在自己的 VM 上跑 50 条样例，得到自己机器的实际吞吐

§G.3 Foundry Local 推理（azloc-sovereign-clouds ai-workloads-overview）

azloc-sovereign-clouds 上的文档明示 Foundry Local（Preview）是 Azure Local GPU 上的统一 AI 应用层：

§G.3.1 Foundry Local 三层架构

┌──────────────────────────────────────────────────────────────────┐
│              Foundry Local — Three-Layer Architecture             │
├──────────────────────────────────────────────────────────────────┤
│                                                                   │
│  应用层                                                            │
│  ├── Foundry Local SDK（Python / .NET / REST API）                │
│  ├── Foundry Agentic SDK（多 agent 编排）                         │
│  └── Foundry Hosted MCP Servers（Tool 桥接）                       │
│       │                                                           │
│       ▼                                                           │
│  编排层                                                            │
│  ├── AI Toolkit for VS Code（开发者调试入口）                     │
│  ├── Foundry Local runtime / CLI                                  │
│  ├── Catalog / Asset registry                                     │
│  └── MCP Tool Brokers                                             │
│       │                                                           │
│       ▼                                                           │
│  推理引擎                                                          │
│  ├── ONNX-GenAI 引擎（CPU / GPU / NPU 多 backend）                │
│  └── vLLM 引擎（GPU only，大模型 LLM serving）                   │
│                                                                   │
└──────────────────────────────────────────────────────────────────┘

§G.3.2 Foundry Local 关键事实（azloc-sovereign-clouds 文档原文）

当前状态：预览版（azloc-sovereign-clouds 文档原文明示 "preview"）
部署形态：Azure Local 节点上跑 Arc-enabled K8s + Foundry Local 控制平面 + GPU 节点池
引擎：
- ONNX-GenAI —— 通用 ONNX 模型；CPU / GPU / NPU 自适应
- vLLM —— LLM serving 引擎，必须 GPU
典型场景：
- 本地代码助手（CodeWhisperer 同类）
- 边缘 AI assistant
- 数据不出本地的小模型推理
SDK：
- pip install foundry-local（Python）
- dotnet add package Azure.AI.Foundry.Local（.NET 8+）
- REST API 端点：https://<foundry-local-endpoint>/v1/...

§G.3.3 Foundry Local GPU 部署模型选择

模型族	推荐 GPU	引擎
Phi-3.5 / Phi-4 系列（ONNX）	A2 / T4	ONNX-GenAI
Llama-3.1 / Qwen2.5 大模型	L4 / L40 / L40S	vLLM
Embeddings（gte-large / jina-embed-v3）	T4 / A2 / L4	ONNX-GenAI
Reranker	T4 / A2	ONNX-GenAI

§G.4 Agentic Retrieval + RAG

azloc-sovereign-clouds 文档明确将 Agentic Retrieval（agentic 检索）作为 Foundry Local 上的三个核心场景之一。

§G.4.1 Agentic Retrieval 架构

┌───────────────────────────────────────────────────────────────────────┐
│                      Agentic Retrieval 架构                            │
├───────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  用户查询                                                              │
│      │                                                                  │
│      ▼                                                                  │
│  ① Query Planner（LLM，port 8000 上 vLLM / ONNX-GenAI）               │
│      │   ↓ Plan: "检索 doc-X、Rerank、生成回复"                         │
│      ▼                                                                  │
│  ② Retrieval Engine（向量库 + keyword 检索）                           │
│      │   ├── PageIndex（检索 chunk）                                     │
│      │   ├── Vector Store（FAISS / Qdrant / 内置）                     │
│      │   └── ReRank（bge-reranker-large）                              │
│      │                                                                  │
│      ▼                                                                  │
│  ③ Context Inject 到 LLM                                                │
│      │   "基于以下检索到的内容：[doc1, doc2, ...] 回答问题"             │
│      ▼                                                                  │
│  ④ LLM 生成                                                              │
│      │                                                                  │
│      ▼                                                                  │
│  ⑤ MCP Tool Brokers（可选）                                             │
│      ├── "调用 Salesforce API 拉客户信息"                               │
│      ├── "调用 SharePoint 拉文件版本"                                  │
│      └── "调用 ServiceNow 拉工单"                                      │
│                                                                        │
└───────────────────────────────────────────────────────────────────────┘

§G.4.2 Azure Local 上跑 Agentic Retrieval 的特殊性

检索数据完全在本地（在企业私有网络或断网环境）—— 这是 Azure Local 上跑 AI 的核心价值
MCP Tool Brokers 通常是企业内部 IT 调用（CRM / ERP / HR）
LLM 自身不需要重新训练——只用 prompt + 检索增强 + Tool 调用
典型 GPU 选型：L4 (24GB) 作为最小化（7B + embedding + rerank + tool LLM）

§G.4.3 端到端运行时校验

# Foundation Models 接口层（Foundry Local SDK）
# 假定 foundry-local endpoint: http://foundry.corp.example.com:8080

curl -X POST http://foundry.corp.example.com:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5-7b-instruct",
    "messages": [
      {"role": "system", "content": "You are an internal Q&A assistant."},
      {"role": "user", "content": "公司 2026 上半年战略回顾"}
    ],
    "tools": [
      {
        "type": "function",
        "function": {
          "name": "search_docs",
          "description": "Search internal documents",
          "parameters": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"]
          }
        }
      }
    ]
  }'

# 预期 response 包含 tool_calls；外部执行检索后回传给 LLM 生成最终回复

§G.5 VDI 场景（azloc-2606 范围）

azloc-2606 gpu-preparation 文档明示 VDI 是 GPU-P 路径 的主战场。

§G.5.1 VDI 决策树

你的 VDI 用户做什么？
│
├── 普通办公（Word / Excel / 浏览器）
│   └── vPC license + A2 / L4 依 vGPU partition（Get-VMHostPartitionableGpu ValidPartitionCounts 当期有效档位）
│       每 partition 2~4GB vGPU
│       每 GPU 单卡支撑轻办公 10~20 用户；重图形 2~8 用户
│
├── 工程师 2D / 3D CAD（AutoCAD 2D / Web 3D viewer）
│   └── vPC license + L4 依 vGPU partition（Get-VMHostPartitionableGpu ValidPartitionCounts 当期有效档位）
│       每 partition 4~8GB vGPU
│       每 GPU 单卡支撑 8~16 VDI 用户
│
├── 专业 CAD（SolidWorks / Inventor / Creo）
│   └── vWS license + L40S 单卡 + DDA 给单个重型用户
│       每 GPU 单卡支撑 1~2 CAD 用户
│
└── 视频会议 + 直播（Zoom / Teams / 多屏）
    └── vPC license + A2 / L4 依 vGPU partition（Get-VMHostPartitionableGpu ValidPartitionCounts 当期有效档位）
        每 partition 3~5GB vGPU

§G.5.2 VDI GPU-P 端的最佳实践（经验）

Partition 切多大：azloc-2606 给出 Get-VMHostPartitionableGpu 自动计算最优 partition；不要手调大——partition 超过硬件支持 = vGPU 起不来
license pool：vGPU license 是浮签，同时在跑的 partition 数 ≤ 实际购买的 license 数
DDA + GPU-P 不混：azloc-2606 原文硬要求；单 GPU 不能既 DDA 又 GPU-P（参上篇 §B.3）
运维：VDI 用户会话断开后 partition 立即回收，license 池压力看并发数 ≠ 总数

§G.6 视频分析（略）（略）（Foundry Local 第三大场景）

azloc-sovereign-clouds 文档把视频分析列为 Foundry Local 的第三核心场景。模式与 LLM 推理完全不同：

§G.6.1 视频分析架构

Camera 1 ─┐
Camera 2 ─┤
  ...     ├── RTSP / ONVIF streams
Camera N ─┘          │
                    ▼
        ┌──────────────────────────┐
        │ Azure Local GPU VM/K8s pod │
        │ ────────────────────────│
        │ Pre-processing:         │
        │  - Frame extraction     │
        │  - Object detection     │
        │ ── ONNX-GenAI 引擎 ──    │
        │ Tracking / Re-ID        │
        │ Anomaly detection       │
        └──────┬─────────────────────┘
               │
               ▼
        Result Store / Alert Engine
        (Azure Local Storage / SQL Edge / 第三方)

§G.6.2 GPU 选型

用途	推荐 GPU	模型族
Frame extraction（轻量）	T4 / A2	OpenCV / FFmpeg
Object detection（YOLOv8/v11）	L4 / A16	Ultralytics / ONNX
Tracking（ByteTrack / DeepSORT）	L4 / A16	MMTracking
Re-ID（强身份识别）	L4 / L40	OSNet
Pose estimation	L4 / L40	OpenPose / RTMPose

§G.7 RDSH 应用流（GPU-P + vApps License）

azloc-2606 gpu-preparation 文档中的"GPU-P 应用"章节（vApps license 模式）对应 RDP 应用流——把图形 / 视频渲染到终端，VM 只出 frame stream。

项	描述
典型用户	呼叫中心 / 教学机房 / 多媒体应用
License	vApps（最便宜）
GPU	A2 依 vGPU partition（Get-VMHostPartitionableGpu ValidPartitionCounts 当期有效档位） / T4 依 vGPU partition（Get-VMHostPartitionableGpu ValidPartitionCounts 当期有效档位）
VM	RDSH 上跑 Single Instance Application
终端	RDP client 输出视频流到本机

§G.8 大模型训练（Azure Local 不适合大规模分布式训练）

【v1.6 修正】Azure Local 不适合作为大规模分布式训练平台。

Azure Local 适合：

✅ 小模型微调（< 10B）
✅ LoRA / QLoRA 微调
✅ 单卡实验
✅ 边缘训练

Azure Local 不适合：

❌ 多节点 GPU Cluster 大规模训练
❌ NCCL 跨节点集合通信密集场景
❌ 多机并行训练（应选择云端 A100/H100 集群）

理由：

存储：训练数据是 TB~PB 级；S2D / CSV / FC SAN 都很难扛住高频读写的训练样本吞吐。Azure 云上的 Azure Blob / ADLS / NetApp Files 才是为训练而生
网络：多机分布式训练要 InfiniBand / NVLink / RoCE 互联，Azure Local 的 100GbE / 200GbE 通常受 S2D SMB Multichannel 耦合，延迟与抖动易导致 NCCL alarm
集群利用率：训练要长期占卡（数小时~数天），Azure Local 的 SMB / licensing 模型会卡住 GPU 资源回收
版本兼容：训练 framework（DeepSpeed / FSDP / Megatron）+ GPU driver + CUDA Toolkit 经常要在运行时切版本，Azure Local 上的 host driver 装错 = 整个 host 都要重启

【企业最佳实践·正路径】：

小数据量（10K 以下样本）、小时级、单卡：Azure Local + DDA + L40S 单卡可做

大数据量、天级以上、多卡：上 Azure GPU VM（ND H100 v5 / NDm A100 v4 系列）——NVLink 全互联 + InfiniBand + Azure Blob / ADLS

混合路径：Azure Local 跑推理 + Azure cloud 跑训练 + 数据回流——这是当前 Microsoft 推荐的混合 AI 模式

§G.9 AKS Arc GPU 节点池的运维栈（v1.5 技术审校版）

【v1.5 关键审校 — 微软托管 Kubernetes 模型与裸 K8s 不可等同】：

Azure Local 上的 AKS Arc GPU 节点池不是传统裸 K8s——driver 生命周期由 Azure Local + AKS Arc GPU 扩展控制。盲目套用裸 K8s 的 NVIDIA GPU Operator 路径可能与 Azure Local 自身的 driver 管理产生冲突。

§G.9.1 Azure Local AKS Arc GPU 拓扑（v1.5 审校后）

Azure Local Host（Windows Server 2025 / Azure Local OS）
    │
    ├── NVIDIA vGPU Manager 服务（NvGpuManagerService）/ bare-metal host driver
    │       │
    │       └── 直接挂在 Azure Local host 的 PCIe 上
    │
    └── Hyper-V
            │
            ├── AKS Arc VM Node（Linux）
            │       │
            │       └── Kubernetes Pod → device plugin 暴露 nvidia.com/gpu
            │               │
            │               └── Pod 内看到 GPU（依赖 host 已装好的 driver）
            │
            └── 其他 VM / Azure Local VMs（DDA 或 GPU-P）

含义：

Driver 不在 AKS Arc node 内——driver 由 Azure Local host 提供（NVIDIA vGPU driver 或 DDA driver）

Pod 通过 device plugin 看到 GPU——但实际算力"借用"的是 host 的 driver / GPU

NVIDIA GPU Operator 在裸 K8s 上"装 driver 容器"的能力，在 Azure Local 上不适用——因为 Azure Local host driver 生命周期不在 K8s 内

§G.9.2 NVIDIA GPU Operator 适用性（v1.5 审校后）

子组件	裸 K8s 上 GPU Operator 的职责	Azure Local AKS Arc 上是否启用
NVIDIA Device Plugin	DaemonSet 注册 `nvidia.com/gpu`	由 AKS Arc GPU 扩展部署，不应在 Azure Local 上额外装 GPU Operator 的 device plugin
NVIDIA DCGM Exporter	DCGM 指标采集	可独立部署（DaemonSet）——Azure Arc → Container Insights 拉取
NVIDIA Container Toolkit	让 Docker / containerd 识别 GPU runtime	Azure Arc 已经自动配置 RuntimeClass——裸 GPU Operator 提供的 Toolkit 可能与 Azure Local 的 RuntimeClass 冲突
NVIDIA Driver Container	driver 作为容器跑在 node 内	不适用——Azure Local host driver 由 Azure Local OS 控制；绝不要以 GPU Operator 装 driver container 的方式去管 Azure Local 的 driver
MIG Manager	MIG 切分 / 编排	Azure Local 当前没有 MIG 编排路径（MIG 是 NVIDIA GPU 硬件能力，但 Azure Local 官方 GPU 编排路径不提供 MIG 生命周期管理）

【v1.5 关键结论】：

不建议在 Azure Local AKS Arc 上以"GPU Operator + driver container"模式部署。

正确路径是：

Driver 由 Azure Local / AKS Arc GPU 扩展控制（NVIDIA vGPU host driver 或 DDA driver，由 Azure Update Manager 推送）

device plugin 由 AKS Arc 自动部署（无需手工装 GPU Operator）

DCGM Exporter 与 Toolkit 可独立装——但要确保不与 Azure Arc 已有的 RuntimeClass / device plugin 冲突

【来源标注·数据出处】：

aksarc deploy-gpu-node-pool 文档（AKS Arc GPU 节点池官方部署流程）——决定 Azure Local 上 GPU driver 与 device plugin 的部署顺序

NVIDIA GPU Operator 文档——开源、是 K8s GPU 运维通用方案，但不针对 Azure Local / AKS Arc 的微软托管模型

冲突点：以 NVIDIA GPU Operator 默认配置（driver 容器化）部署在 Azure Local AKS Arc，可能与 Azure Arc 已有的 NVIDIA driver 路径冲突；实际冲突表现 / 兼容性列表以 Microsoft 当期 Azure Local 文档为准

§G.9.3 AKS Arc 上 GPU 工作负载可观测性（v1.5 审校后）

【企业最佳实践·AKS Arc GPU 可观测性独立于 GPU Operator】：

1. GPU 指标采集（DCGM exporter 路径）

# AKS Arc cluster 上独立部署 DCGM exporter（DaemonSet 形态）：
# 注意：这里以 "daemonset 形态" 而不是 "GPU Operator 全栈"
# 因为在 Azure Local 上我们不需要 GPU Operator 的其他组件

kubectl apply -f https://raw.githubusercontent.com/NVIDIA/dcgm-exporter/main/deployment/dcgm-exporter.yaml

2. Azure Arc → Container Insights 拉取指标

# 在 AKS Arc cluster 上启用 Container Insights：
az arc kubernetes enable-features   --resource-group <rg>   --name <aks-arc-cluster-name>   --features cluster-monitor

3. Grafana panel 配置（GPU 维度）：

指标	含义	Azure Monitor / Grafana query
GPU 节点 NotReady 数量	GPU 集群健康	`cluster_health`
GPU 显存使用率	容量规划 / OOM 预警告	`dcgm_fb_used / dcgm_fb_total`
GPU 温度	散热监控	`dcgm_gpu_temp`
SM occupancy	算力利用率	`dcgm_sm_pct`

【v1.5 修订·避免一刀切】：以上采集 / 监控步骤是当前 Azure Arc / Container Insights 的可用路径，但GPU Operator 是否在客户 Azure Local AKS Arc 上启用应结合 Microsoft 当期 GPU extension 支持矩阵判断。

§G.9.4 MIG 在 AKS Arc 上的实情（v1.5 审校后 — 措辞修订）

【关键修订·MIG 边界】：

准确表述是：Azure Local 官方 GPU 编排路径当前不提供 MIG 管理能力；MIG 不属于 Azure Local GPU-P / AKS Arc GPU 支持模型。

避免写："Azure Local 不支持 MIG"——这是过度绝对化的措辞。正解：

MIG 是 NVIDIA GPU 硬件能力，与 GPU 是否在 Azure Local 上无关

支持 MIG 的卡（只举例 NVIDIA 官方明确支持的型号）：NVIDIA A100 / A30 / H100 / H200——这些卡本身在硬件上能切多个 MIG instance

Azure Local 选型未必只覆盖这些——例如 Azure Local 现网 SKU 以 A2 / A16 / L4 / L40 / L40S / RTX PRO 6000 为主；这些卡里只有 RTX PRO 6000（Blackwell Server Edition）部分级别在 NVIDIA 端支持 MIG variants，但Azure Local 没有集成 MIG 生命周期管理

客户常见问题："我能不能用 MIG 切 7 个 instance 跑 7 个 pod？"

Azure Local 上：当前 AKS Arc / GPU-P 编排层不支持 MIG 的 lifecycle 调度——即使硬件支持，没有 K8s 一侧的 MIG Manager 实例就无法 programmatic 切 instance

正确路径：

想要 GPU-P 切分 — 走 Azure Local 现网 SKU（A2/A16/L4/L40S/RTX PRO 6000）

想要 MIG — 上 Azure 云（ND H100 v5 / NDm A100 v4 等）

想要 local MIG + 自管理 — 自定义 device plugin / MIG Manager + 裸金属 Linux K8s（这是 escape hatch，但不属于 AKS Arc out-of-the-box 范围）

§G.10 AKS Arc GPU 节点池与 NVIDIA 工具栈的边界

【关键修订·GPU Operator 在 vGPU/AKS Arc 上的边界】：

vGPU Manager 是 Windows 服务，不是 Linux container——这是为什么 GPU Operator 的 driver container 模式在 Azure Local AKS Arc 上不可用的核心原因。

§G.10.1 三层架构与各层职责（v1.5 审校后）

层	位置	工具/服务	备注
Azure Local host	Windows Server 2025 / Azure Local OS	NVIDIA vGPU Manager 服务（GPU-P）<br>NVIDIA bare-metal host driver（DDA）	driver 装在 host；vGPU Manager 是 Windows 服务
Hyper-V / AKS Arc VM Node	Linux VM on Hyper-V	AKS Arc GPU 扩展部署 device plugin（已自动）	不需要手工装 NVIDIA device plugin
K8s Pod	container in Linux node	通过 device plugin 看到 `nvidia.com/gpu: 1`	container runtime 由 Azure Arc 配好

§G.10.2 driver 生命周期的归属

路径	driver 装载位置	driver 升级方式
AKS Arc GPU node pool（DDA）	Azure Local host（host-side）	Azure Update Manager → cluster 滚动升级；不在 K8s 内 driver container
AKS Arc GPU node pool（GPU-P）	同上	同上
普通 Linux K8s on bare-metal	视工具栈：可以是 node OS 装，或 GPU Operator 的 driver container	视工具栈
传统 Azure VM GPU SKU（云端）	VM OS 内 driver	Azure VM extension

【v1.5 关键纠正·不要用 GPU Operator 装 driver 的写法】：之前 v1.4 给的 helm install gpu-operator ... --set driver.enabled=true 在 Azure Local AKS Arc 不是推荐路径。这个 Helm 配置在裸 K8s 上是合法的，但：

在 Azure Local AKS Arc 上，driver 装在 host 不是 node——driver container 模式会让 K8s 看到一个"独立 driver 视图"

与 Azure Local / AKS Arc 自带的 NVIDIA driver 路径可能冲突（冲突细节以 Microsoft 当期支持矩阵为准）

Microsoft 官方对 GPU Operator 在 Azure Local AKS Arc 上的支持与否——未在 azloc-2606 文档范围内明示

§G.10.3 客户问题的对应回答

【常见问题·Azure Local AKS Arc GPU 故障排除】：

问题	答案
"我想装 GPU Operator 全栈管理 AKS Arc 上的 GPU"	不建议。Azure Local 是微软托管 K8s，driver 生命周期由 AKS Arc GPU 扩展控制；装 GPU Operator 可能与 Azure Arc 已有的 device plugin 冲突。DCGM / Toolkit 可独立装，但 driver container 模式不要用
"我想在 AKS Arc pod 容器里看到 `nvidia-smi`"	可以——前提是 AKS Arc GPU 节点池上 host driver 已装、AKS Arc device plugin 已配；不需要 GPU Operator
"我要升级 vGPU driver"	走 Azure Update Manager + Azure Local SBE / cluster extension；不要在 K8s 内 GPU Operator 升级
"我想在多 GPU 节点池上统一监控"	装 DCGM exporter（独立 DaemonSet）+ Azure Arc Container Insights 拉取指标——不需要 GPU Operator 全栈
"我要 MIG 切分"	Azure Local 当前不提供 MIG 编排；要么走 GPU-P，要么上云，要么自己写 MIG Manager（不在 AKS Arc out-of-the-box 内）

§G.11 GPU 安全隔离级别比较

【v1.5 关键审校新增】：上篇 / 下篇之前未集中梳理 GPU 隔离级别——这是企业选型 VDI / 推理 / 多租户时最常被忽略的关键决策点。隔离开销 / 性能 / 适用场景三层都要看清楚。

§G.11.1 三层隔离模型对比表

技术	隔离级别	性能	典型场景	隔离开销是否"硬件级"
DDA（Discrete Device Assignment）	整卡独占（一个 VM）	最高（接近原生；微软 / NVIDIA 未给量化数字）	LLM 推理 / HPC / 大模型微调	✅ PCIe 级：整张卡从 PCIe 拓扑上独占给 VM
GPU-P（GPU Partitioning）	Hyper-V 软件调度	高（经验值几个百分点到十几个百分点损耗，无权威数字；见 §A.1.2）	VDI / 渲染 / 培训教室	⚠ 不是硬件级：由 NVIDIA vGPU Manager 在 Hyper-V layer 调度；partition 之间没有硬件级隔离
MIG（Multi-Instance GPU）	GPU 硬件级切分（独立通道）	高（有少量调度开销，NVIDIA 无权威量化）	云 AI 多租户 / 硬件隔离推理	✅ 硬件级：A100 / H100 / H200 卡内 FPGA 切分；Azure Local 当前 AKS Arc / GPU-P 编排层不支持 MIG lifecycle（详见 §A.6）

【含义·企业选型口诀】：

要 LLM 推理最大性能 + 离最近原生 → DDA（独占卡）

要 VDI 密度高、但每 VM 性能略微下降 → GPU-P（多 VM 共卡）

要多企业共用 GPU + 硬件级隔离 → MIG（当前 Azure Local 上做不到，要上云）

§G.11.2 隔离级别的安全考量

【v1.5 关键审校】：在多租户 / 强隔离场景下，GPU-P 不是 MIG 等价。

场景	GPU-P 行为	MIG 行为	Azure Local 可选
隔离 VM 防同卡其他 VM 看自己的显存	NVIDIA vGPU Manager 调度；不能保证硬件级隔离（取决于 driver 实现）	硬件级隔离	GPU-P 仅"软件层调度"
SaaS 多企业共用 GPU	不是 GPU-P 的设计场景——partition 共享同一 driver 实例	是 MIG 的设计场景	Azure Local 上 GPU-P + OS-level RBAC；强隔离走云或物理分离
VDI 多用户共用一张卡	是 GPU-P 的主场景——Nvidia 文档 vWS / vPC / vApps 都按此设计	不适用	✅ GPU-P 完全合适
同企业但跨部门隔离	GPU-P + AD 组策略 + vGPU license profile 区分	不适用	✅ GPU-P 适配

§G.12 GPU 故障域

【v1.5 关键审校新增·企业 GPU 部署常被忽略】：Azure Local Cluster 是分层级的——Cluster → Node → GPU → Partition → VM / Pod。每一层的故障影响范围不同，故障域分析是 GPU 选型决策的隐性维度。

§G.12.1 Azure Local Cluster 的 GPU 故障域分层

Azure Local Cluster
├── 节点 A（host）
│   ├── GPU 0（一整张 NVIDIA GPU）
│   │   ├── DDA：1 个 VM 独占
│   │   ├── GPU-P partition 0：1 个 VM / partition
│   │   ├── GPU-P partition 1：1 个 VM / partition
│   │   └── ...（partition N）
│   ├── GPU 1（同 A 节点上另一张卡）
│   │   └── ... 同上
│   └── ...
├── 节点 B、节点 C、节点 D ...

§G.12.2 不同故障的爆炸半径

故障类型	DDA 影响范围	GPU-P 影响范围	客户体验
GPU 硬件故障（如过温 / ECC uncorrectable）	该 GPU 上整张卡的 VM 受影响	该 GPU 上所有 partition 的所有 VM 都受影响	GPU-P 比 DDA 影响更大——一卡坏多 VM 瘫
host 节点故障（蓝屏 / 维护）	该 host 上所有 VM 瘫（Live Migration 不支持）	该 host 上所有 VM 瘫（Live Migration 在 OS build ≥ 26100 + vGPU ≥ 18 才支持）	DDA 没有 LM；GPU-P 有 LM
单 partition 软件问题（VM 蓝屏）	整个 VM 瘫	单个 partition 上的 VM 瘫，其他 partition 不受影响	GPU-P 在 partition 内隔离优于 DDA
vGPU Manager 服务故障	不影响（DDA 走 host driver 而非 vGPU Manager）	整张卡的所有 partition 都受影响	DDA 不依赖 vGPU Manager
单个 VM 的 driver 问题	该 VM 瘫	该 VM 瘫	相当

【v1.5 关键审校·故障域文档化的工程意义】：

GPU-P 不是单纯"无差别比 DDA 更好"——一卡上 8 个 partition = 一卡故障全瘫

VDI 场景：partition 多 → 单 VM 故障域小，但单卡故障域大

LLM 大模型场景：DDA 独占 → 单 VM 故障域大，但单卡故障域只有 1 个用户

客户问题应对："我用 GPU-P 切 8 份为什么一卡坏 8 个 VM 一起瘫"——答：是的，这是 GPU-P 模型本质，不能改

§G.12.3 减少爆炸半径的工程做法

【v1.5 企业最佳实践·故障域管理】：

做法	适用	含义
不要把整张卡切满 8 份 partition	GPU-P 路径	留 1~2 个 partition 给故障应急 / 维护升级
跨节点 partition	GPU-P 路径	Cluster 级 failover 时 partition 在 node 之间迁移（OS build ≥ 26100）
物理卡分离	强隔离场景	不同企业 / 项目配不同物理 GPU 卡——避免 partition 共享
DDA 故障转移预案	DDA 路径	DDA 没有 Live Migration——故障时人工 re-create VM；业务层要有 RTO 计划
监控 GPU 健康	所有	DCGM exporter + iDRAC + Crashdump 日志——见 §G.9.3
定期备份 vGPU Manager 配置	GPU-P 路径	NVIDIA vGPU Manager 配置丢失 = 整 host 不可服务

§H. 避坑清单（来自 azloc-2606 原文 + 实操经验）

【三层标注原则】：

微软硬要求 / 工具默认行为：直接抄自 azloc-2606 文档并对齐

企业最佳实践：经验性归纳，全部明示"经验"

§H.1 不要做的事

行为	后果	来源
同一物理 GPU 同时 DDA + GPU-P	失败	azloc-2606 gpu-manage-via-device 原文
DDA VM 上启用 Live Migration	失败（Hyper-V 限制）	azloc-2606 attach-gpu-to-linux-vm 原文
单 VM 配 2+ GPU partition	失败（azloc-2606 限制）	azloc-2606 gpu-manage-via-partitioning 原文
在 BIOS 没开启 SR-IOV 上装 GPU-P	vGPU 起不来	azloc-2606 gpu-preparation 原文
用 A10 / A40 配 Arc-enabled VM	失败（azloc-2606 禁用）	上篇 §C.1 矩阵
AKS Arc 上跑 Windows node GPU pod	不支持（aksarc 限制）	aksarc deploy-gpu-node-pool 原文
用 vGPU 17.x license 服务喂 vGPU 18.0 host	失败	NVIDIA vGPU R570 Release Notes
在 DLS < 3.4 时部署 vGPU 18.0+	失败	NLS 3.4.0 User Guide 1.1.1
把 DLS 节点与 GPU host 合并	GPU host 故障 = license 双挂	经验
vGPU driver 与 vGPU Manager 不匹配	vGPU 起不来	NVIDIA vGPU R570 Release Notes
装 vGPU host driver 前不拆旧 NVIDIA Data Center / Tesla driver	vGPU driver 装不上 / 路径冲突	Dell SolVe P58 原句 + NVIDIA vGPU Manager 安装指南——v1.5 关键审校：不写"互斥"，仅写"安装可能冲突，需按 NVIDIA 指南清理"
跨大版本跳升级 DLS 1.x → DLS 3.4 直跳	license token 失效	NLS DLS 3.4.0 User Guide "Migrating"
Ada Lovelace GPU 上 manual partition placement	不被 NVIDIA 官方支持（vGPU R570）	NVIDIA vGPU R570 Release Notes 2.1
在 DDA VM 内手动调高 P-state	偶尔会触发 GPU hang	经验
在 Live Migration 路径上塞 DDA VM	Live Migration 总在失败	azloc-2606 原文
假设 License Server File 自动续期	3 年后过期，VM 降级	NLS 3.4+ security policy

§H.2 一定要做的事

行为	原因	来源
DDA VM 上线前确认节点维护计划	DDA 不支持 live migration	azloc-2606 原文
BIOS 设置检查（SR-IOV、VT-d、Above 4G Decoding）	跟 GPU-P 相关	azloc-2606 system-requirements
主机 + 同节点 GPU 同型号同容	azloc-2606 硬要求	azloc-2606 gpu-preparation 原文
监控 GPU 拓扑（`Get-VMHostPartitionableGpu`）	防止 GPU 漂移	工具默认
DDA HighMMIO 按微软示例 VRAM + 12% 起步（v1.5 关键审校 — 过高反而影响 VM 可分配 MMIO 空间）	微软示例经验值；过高会引发 VM 分配异常，需结合 GPU BAR1 / PCIe BAR 配置验证	azloc-2606 system-requirements
vGPU license pool 监控	license 是浮签	NVIDIA vGPU R570
DLS 节点 HA 时不要放同一物理机	HA 失效 = 单点失效	经验
License Server File 记录下载日期	3 年有效期自下载起算	NLS 3.4+ security policy
DLS 与 vGPU Manager 同步升级	不一致直接 fail	NLS 1.1.1
升级前先读 NLS 1.1.1 节	硬性升级矩阵	经验
AKS Arc Windows node 上不要跑 GPU 工作负载	aksarc 限制	aksarc deploy-gpu-node-pool
GPU 工作负载用 Linux node image	aksarc 推荐	aksarc deploy-gpu-node-pool
用 `kubectl top pod` 监控 GPU 利用率	AKS Arc 默认 exporter 不足	经验
用 `dcgm exporter`（K8s 监控）	Prometheus + Grafana 标准做法	经验

§H.3 选型阶段的成本 / 性能取舍

【企业最佳实践·决策框架】：

                       ┌───────────────────────────────────┐
                       │      选 GPU 时的"成本×价值"        │
                       └────────────┬──────────────────────┘
                                    │
        ┌───────────────────────────┼──────────────────────────────┐
        │                           │                              │
        ▼                           ▼                              ▼
   训练用?                  推理用?                       VDI / 共享?
        │                           │                              │
        ▼                           ▼                              ▼
  **上 Azure 云**         Hyper-V DDA / AKS Arc DDA         Hyper-V GPU-P
  (ND H100 / NDv5)         license-free                    需要 vGPU license

§H.3.1 关键选型规则

规则	含义
GPU 用途诊断	训练 → 上云；推理 → Azure Local；VDI / 共享 → Azure Local
license 是否就位	DDA 完全不需要 vGPU license；GPU-P + NVIDIA vGPU 软件栈（vWS / vPC / vApps）需要 NVIDIA vGPU License；GPU-P 本身是 Hyper-V GPU Partition 技术，不等同于 NVIDIA vGPU
节点维护规划	DDA VM 必须先规划 host 维护窗口
GPU 资源利用	利用率均匀 → GPU-P；利用率集中 → DDA
数据合规	数据必须本地 → Azure Local；数据可上云 → Azure cloud
运维人	GPU 部署 + 运维由一支专业团队 → Azure Local；否则上 Azure cloud

§H.3.2 不要做的事（设计阶段）

反模式	后果
GPU 全部 DDA（不管负载低）	大量 VRAM 闲置
GPU 全部 GPU-P（不管 LLM）	LLM 推理性能损失 5~12%
GPU 数量 ≠ VM 数量（一机一卡）	实际应有 N+1 元余
CPU 选型不匹配 GPU（低功耗 CPU + 高 GPU）	CPU 成瓶颈
网络选型不匹配（低速 ToR + 高 GPU 节点）	node-to-node 通信成瓶颈
存储不在性能层（S2D 默认性能 → 高 IOPS 工作负载）	CSV 延迟成瓶颈

§H.4 升级路径上的"硬刹车"

NVIDIA License System 升级必须按以下顺序（azloc-2606 文档未明示，但 NVIDIA vGPU R570 Release Notes + NLS 1.1.1 节原文给出）。

DLS 2.x 升级到 DLS 3.4：

DLS 3.4 部署文档：Migrating a DLS Instance
升级后必须从 NVIDIA Licensing Portal 重新下载 License Server File
上传到新 DLS appliance
升级 vGPU 软件到 vGPU 18.0+

vGPU 17.x 升级到 vGPU 18.0：

旧 NVIDIA vGPU License Server（legacy license daemon）与 vGPU 18.0 完全不兼容 —— 必须先 DLS ≥ 3.4 部署完成
升级 vGPU Manager 服务端
升级 vGPU Driver VM 端
重启 vGPU 工作负载 VM（vGPU license 会重新申请）

§H.4.1 升级路径上的避坑清单

反模式	后果
旧 vGPU License Server 还活着装 vGPU 18.0	service 启动失败
vGPU Manager 升级但 Driver 不升	设备起不来
vGPU Driver 升级但 Manager 不升	Driver 找不到 service
License Server File 复制粘贴用	token / fingerprint 不匹配直接 fail
跨 5+ 小版本跳升级（vGPU 13.x → 18.x 直跳）	silent license failure
用 Python `nvidia-smi` polling 检查升级状态	watch status 即可，不需要 polling

§I. NVIDIA vGPU License

【v1.6 关键概念澄清·GPU-P ≠ NVIDIA vGPU】：

Azure Local GPU-P 是 Microsoft Hyper-V GPU Partitioning 技术栈——分 Windows GPU Partition 和 Linux GPU Partition

NVIDIA vGPU License 是 NVIDIA vGPU Software 生态的一部分——包含 vGPU Manager + Guest Driver + License Server

二者关系：

模式

是否需要 NVIDIA License

DDA 整卡直通

❌ 不需要

GPU-P + NVIDIA vGPU Software

✅ 需要（vWS/vPC/vApps）

GPU-P + 普通 GPU Partition

取决于具体 GPU 软件路径（非 NVIDIA vGPU 栈则不需要）

【企业选型提示】：如果只想用 Hyper-V GPU Partition 而不需要 NVIDIA vGPU 高级特性（如 vGPU profile 动态调整、vGPU scheduler），可以不走 NVIDIA License 路径。

授权与 License Server 部署（NLS / DLS / CLS）

【节定位】：把 vGPU License + License Server 单独拎出来讲。原因：vGPU 不是 GPU 直通（DDA）；vGPU 任何细分（vWS / vPC / vApps）都必须有合法 license，否则 VM 启动后 vGPU driver 会进入 grace period，grace period 耗尽后 GPU 能力（CUDA / DX）会降级运行。

【版本对齐】：Azure Local 23H2 / 2510+ + NVIDIA vGPU Software 18.0~18.6（R570）+ DLS ≥ 3.4。

【来源依据】（按权威性递减）：

NVIDIA vGPU Software R570 Release Notes — Microsoft Azure Local（docs.nvidia.com/vgpu/18.0/...）

NVIDIA License System User Guide v3.6.1（docs.nvidia.com/license-system/latest/...）

NVIDIA Delegated License Service User Guide 3.4.0（docs.nvidia.com/license-system/dls/3.4.0/...）

Microsoft Azure Local azloc-2606（gpu-preparation / gpu-manage-via-partitioning）

企业最佳实践层：经验性建议，明确标注"经验"

§I.1 先对齐名字：vGPU 软件的 license 类型与负载差异

NVIDIA 在 vGPU 18.0 Release Notes 里给出（原文）：

The supported products for each type of NVIDIA vGPU software deployment depend on the GPU.

License 类型	适用范围	是否需要 license server	典型用户
vWS（Virtual WorkStation）	专业工作站用户（AutoCAD、SolidWorks、Revit 等带专业 ISV 认证的 OpenGL/CL 驱动）	✅ 是	设计院 / 制造 CAD 工程师
vPC（Virtual PC）	普通办公 + 2D/3D 加速（POV-Ray、Office 视频会议）	✅ 是	普通 VDI 桌面用户
vApps（Virtual Applications）	RDSH 应用流（图形渲染到终端，不进 VM 桌面）	✅ 是	呼叫中心 / 教学终端
DDA（Discrete Device Assignment）	GPU 整卡给一个 VM	❌ 否（直通走 host driver）	高性能计算 / LLM 推理 / 大模型训练

微软 azloc-2606 gpu-preparation 原文不区分 vWS/vPC/vApps——这一区分是 NVIDIA License System 概念；从 Azure Local 编排侧只看到 --gpus GpuDDA 还是 --gpus GpuP，看不到 license profile。选择 vGPU license profile 必须在 NVIDIA Licensing Portal 上做，不是 Azure Local 编排层做的事。

【企业最佳实践】：如果一个企业同时跑 CAD 用户（vWS）和 RDSH 应用流（vApps），按用户种类而不是 GPU 数量采购 license——例如 50 个 CAD 工程师 + 200 个 RDSH 用户 = 50 vWS + 200 vApps。

§I.2 License 服务的两种形态（NLS 3.6.1 原文）

NVIDIA License System 官方原文（docs.nvidia.com/license-system/latest/nvidia-license-system-user-guide/）：

NVIDIA License System supports the following types of service instances:

Cloud License Service (CLS) instance. A CLS instance is hosted on the NVIDIA Licensing Portal.

Delegated License Service (DLS) instance. A DLS instance is hosted on-premises at a location that is accessible from your private network, such as inside your data center.

项	CLS（Cloud License Service）	DLS（Delegated License Service）
部署位置	NVIDIA 侧（NVIDIA Licensing Portal 上托管）	本地数据中心 / 私有云
网络要求	VM 能访问 NVIDIA Licensing Service endpoint（CLS 域名以 NLS 当期文档为准）	VM 只需访问 DLS 节点：通常 443/tcp（具体端口见 §I.4）
License 来源	NVIDIA Licensing Portal 自动下发	管理员从 NVIDIA Licensing Portal 下载 License Server File，手动上传到 DLS
License 行为	实时拉取（网络浮签）	实时拉取（网络浮签）+ 可选 Node-locked（air-gap）
运维责任	NVIDIA 维护 CLS，无需客户管理 license 文件	客户自维护 DLS（升级 / 备份 / HA）
HA 支持	CLS 单点容灾由 NVIDIA 侧	DLS 最多 9 节点 HA cluster（vGPU 16.1+）
适用	公网可达 / 不想自建 license 服务	数据中心内网 / Disconnected Operations / 气隙环境 / 监管要求

【重要升级注意（NVIDIA License System v3.4+ 原文）】： "For NLS release 3.4 and later, the license server files bound to DLS SI will have a validity of three years." 也就是 DLS 的 License Server File 自下载起 3 年有效，到期前必须重新从 NVIDIA Licensing Portal 下载。

§I.3 必须：vGPU 18.0+ 与 DLS 3.4+ 的强制依赖

NVIDIA vGPU Release Notes 原文（docs.nvidia.com/vgpu/18.0/...）：

You must use NVIDIA License System with every release in this release family of NVIDIA vGPU software. All releases in this release family of NVIDIA vGPU software are incompatible with all releases of the NVIDIA vGPU software license server.

关键含义——升级路径上的"硬刹车"：

老的 NVIDIA vGPU License Server（基于 license daemon，2018~2022 时代使用的版本）自 vGPU 18.0 起完全不兼容——这是 NVIDIA 官方明文。
升级路径必须遵守 NVIDIA 官方升级矩阵（NVIDIA License System User Guide 1.1.1 节："Pre-Requisites for using vGPU 18 or Later on DLS"）：
1. 先升级 DLS 到 ≥ 3.4
2. 再从 NVIDIA Licensing Portal 重新下载 License Server File
3. 最后升级到 vGPU 18.0+

NVIDIA 官方原文：

To avoid licensing failures with vGPU 18.0 and later releases, upgrade your license server to a minimum version of DLS 3.4 before upgrading vGPU to version 18.0 or later.

【企业最佳实践】：

升级前先确认所有 vGPU host 的 NVIDIA vGPU Manager 版本与 DLS 版本在 NVIDIA 官方兼容矩阵内

永远不要跨大版本跨多个分支升级——建议在 DLS 3.4 已经稳定运行 1~2 周后，再升级 vGPU 软件

任何"测试环境升级成功就跳生产"的逻辑在这里会直接 fail——原 DLS 3.3 之前的 license server file 不能给 vGPU 18.0 用

§I.4 DLS 部署架构（NVIDIA DLS 3.4.0 官方架构）

NVIDIA 官方没给单一权威部署模板（文档里只提供"deploy DLS on a VMware vSphere / Hyper-V / 物理服务器 / Linux KVM host"的通用步骤）。官方硬约束：

DLS 虚拟设备格式：OVF/OVA 镜像（从 NVIDIA Licensing Portal 下载）
DLS 服务端口：Web UI / REST API 默认 443/tcp（HTTPS）+ 用于 license daemon、cluster heartbeat、内部服务的多个端口（DLS 3.4.0 User Guide "DLS ports / Network ports" 章节列出全部端口明细，以交付期 User Guide 为准——本节档仅给出一个可用的入口 HTTPS 443）
操作系统支持：DLS 3.4 OVA 内置 Linux（标准 CentOS / RHEL-like），客户不需要在 DLS 内手装 OS
资源需求（NVIDIA DLS 3.4.0 推荐配置，经验）：
1. 4 vCPU / 8 GB RAM / 100 GB disk（单 DLS 节点，HA cluster 各节点同等配）
2. DLS 节点不应该跑 GPU 工作负载（只跑 license 服务 + 心跳 + Web UI）
HA cluster 约束：
1. 最多 9 个 DLS 节点（vGPU 16.1+ 才支持 > 2 节点）
2. CLS 和 DLS 不能混用同一个 HA cluster
3. Virtual IP Management 是 HA 的可选增强，自动迁移浮动 IP（NLS 官方原文："Virtual IP Management automatically migrates a floating IP address between cluster nodes during failover events"）
License Server File 路径：
1. 从 NVIDIA Licensing Portal（URL 以 NLS 当期文档为准——目前为 https://nvid.nvidia.com/dashboard）下载 .bin 形式的 License Server File
2. 通过 DLS Web UI 上传（端口 443）
3. 客户端主机通过 NVIDIA vGPU Manager 内置的 license client 向 DLS 申请 license

§I.5 Azure Local 集成 NLS / DLS 的部署形态

§I.5.1 三种部署形态对比

形态	License 服务位置	是否需要 DLS VM	网络可达性	适用场景
A. CLS	NVIDIA 侧	否	VM 可出公网到 NVIDIA Licensing Service endpoint（具体域名以 NLS 当期文档为准）	普通企业（公网可达）
B. 单 DLS 节点	数据中心内	是（单 VM）	VM 到 DLS 节点可达即可	单数据中心 / 内网合规
C. DLS HA cluster	数据中心内	是（2~9 个 VM）	同上	关键业务 / 多数据中心

§I.5.2 企业实践倾向：A 优先，必要时落到 B/C

NVIDIA 官方原文（CLS 段落）：

Because a CLS instance is hosted on the NVIDIA Licensing Portal, you do not need to download licenses from the NVIDIA Licensing Portal and upload them to the instance.

Hosting a CLS instance on a cloud service provides robustness and dynamic scalability for the CLS instance. Because a CLS instance is maintained by NVIDIA and the cloud service provider, feature and maintenance updates are generally transparent to users.

NVIDIA 官方未直接"推荐 A 优先于 B"——本节档的"CLS 优先"是企业最佳实践归纳，非 NVIDIA 立场。理由：

CLS 是 NVIDIA 与云服务商自维护，客户无需管理 License Server File 生命周期（3 年续期）和 DLS 升级
CLS 适用公网可达场景；DLS 仅在以下情况需要：
- 数据合规要求数据不出本地（金融 / 政府 / 国防）
- Disconnected Operations（气隙 Azure Local，NLS 必须走 node-locked license + DLS 同步许可证）
- 企业已有 DLS 投资（vGPU 13.0 之前就用了 DLS）

§I.5.3 Azure Local 与 DLS 共存的网络层注意事项

DLS 节点不应跑在 Azure Local GPU host 上——DLS 是 license 微服务，与 GPU 工作负载争资源、增加 host 故障半径
DLS 节点应放在与 Azure Local 同一 AD 域的可信内网，但单独一台 VM（通常 Linux VM），以便故障域 / 备份域分离
【v1.6 提示·Disconnected Operations 故障域】：如果 DLS 与 Azure Local 共用基础设施，当 Azure Local 整体故障时 DLS 也可能不可用，导致 License 无法恢复。建议在独立管理域（独立 Hyper-V cluster / 物理服务器 / 其他云）部署 DLS
Azure Local firewall 规则：vGPU host 的 vGPU Manager 需要出站访问 DLS 的 443/tcp。如果是 DLS，则需在 concepts/firewall-requirements 文档明示的出站规则基础上加一条白名单 DLS IP
CLS 模式：Azure Local 节点需能访问 NVIDIA Licensing Service endpoint（具体域名以 NVIDIA NLS 当期文档为准——目前包括 *.nvidia.com、nvid.nvidia.com 等多个 endpoint）；如果走 Arc gateway 出网，相关 endpoint 必须加进 Arc gateway 的 endpoint 白名单

§I.6 DLS 部署步骤（NVIDIA DLS 3.4.0 通用步骤 + Azure Local 适配）

【来源分层】：以下步骤是 NVIDIA DLS 3.4.0 User Guide 通用步骤 + Azure Local GPU 部署的适配。DLS OVA 是 NVIDIA 标准 Linux 镜像，部署本身不需要 Azure Local 任何工具——可以放在任何 vSphere / Hyper-V / Azure Local / 物理机上。

步骤 1：准备 DLS 节点 VM

# Azure Local 上创建一台 Linux VM（或独立物理服务器 / 其他 hypervisor）
# 推荐：4 vCPU / 8 GB RAM / 100 GB vHDD / Linux（Ubuntu 22.04 LTS）
# 关闭 Secure Boot；启用 Time Sync（chrony / w32tm）；关闭 IPv6 链路本地路由异常

【来源分层】：上面资源配是经验值，不是 NVIDIA 官方数字。NVIDIA DLS OVA 内部已经预配过资源——如果使用 DLS OVA 模板，资源配请按 NVIDIA 模板自带要求。

步骤 2：从 NVIDIA Licensing Portal 下载 DLS OVA

NVIDIA 官方入口：NVIDIA Licensing Portal（URL 以 NLS 当期文档为准；目前为 https://nvid.nvidia.com/dashboard）

需要在 NVIDIA Enterprise Account 下登录 → Manage → DLS → Download OVA。

步骤 3：在 Hyper-V / vSphere 上部署 OVA

# 导入 OVA 后开机
# 首启动会进入初始化向导：
#   - 设置 admin 密码（dls_admin）
#   - 配置网络（DHCP / static IP）
#   - 配置 NTP 服务器
#   - 配置 rsu_admin 密码（用于 license server file 注册）

步骤 4：从 NVIDIA Licensing Portal 下载 License Server File 并上传到 DLS

NVIDIA 官方原文（NVIDIA License System User Guide 1.1.1 节）：

After upgrading your DLS instance to version 3.4 or later:

Download a fresh license server file from the NVIDIA Licensing Portal

Install the license server file on your newly upgraded DLS appliance.

操作：

在 NVIDIA Licensing Portal（URL 以 NLS 当期文档为准）上 Create License Server（绑定 entitlements）
下载 License Server File（.bin 文件）
通过 DLS Web UI（https://<dls-vm-ip>）以 rsu_admin 登录 → Apply License Server File → 选 .bin 上传
Web UI 上观察 "License Server" 状态变成 "Active"

3 年有效期（NLS 3.4+ 原文）： "The license server files bound to DLS SI will have a validity of three years. The three-year validity will begin from the time the file is downloaded from the NLP portal."

步骤 5：在 Azure Local host 端配置 vGPU Manager 指向 DLS / CLS

NVIDIA vGPU Manager 在安装时会读取注册表 / 配置文件中的 license server FQDN。以 Hyper-V 场景为例：

# Hyper-V host 上的 vGPU Manager 注册表项（vGPU 18.0+，参考 NVIDIA 官方配置命令）
# 实际路径以 NVIDIA vGPU Manager 安装包中的 README 为准
$regPath = "HKLM:\SOFTWARE\NVIDIA Corporation\vGPU Manager"
Set-ItemProperty -Path $regPath -Name "LicenseServer" -Value "dls.corp.example.com"
# 或指向 CLS：
Set-ItemProperty -Path $regPath -Name "LicenseServer" -Value "<nvidia-licensing-service-endpoint>"  # 以 NLS 当期文档为准

# 重启 vGPU Manager 服务
Restart-Service "NvGpuManagerService"

【来源分层】：上面注册表路径是 NVIDIA vGPU Manager 安装通用项，具体路径 / 注册表项名称以交付期 vGPU 软件包内 README / NVIDIA vGPU Software Quick Start Guide 为准。

步骤 6：VM guest 端 vGPU driver 验证

# 启动一台已 attach GPU-P partition 的 VM（Ubuntu 22.04 LTS 为例）
sudo nvidia-smi
# 预期看到：vGPU type 行（如 "vGPU type: vWS-2B" 或 "vGPU type: vApps-1Q" 等）
# + Granted License = "Yes"
sudo nvidia-smi -q | grep -i license

如果 vGPU Manager 已经成功申请到 license，nvidia-smi 会显示 License Status: Licensed；如果未授权但 license server 可达，会显示 License Status: Unlicensed（此时还有 grace period）。

§I.7 DLS HA 部署（NVIDIA vGPU 16.1+ 官方 HA，上限以 NLS 当期文档为准）

NVIDIA 官方原文（NVIDIA License System User Guide 1.4 节）：

High availability requires at least two DLS instances in a failover configuration:

A primary DLS instance, which is actively serving licenses to licensed clients

One or more secondary DLS instances, which act as a backup for the primary DLS instance

NVIDIA License System supports a maximum cluster size of nine DLS instances in an HA cluster.

【关键审校·版本限制】：DLS HA cluster 最多 9 节点这一上限视 NLS release 版本而异：

DLS 3.1 及之前：HA 限制为 2 节点（primary + 1 secondary）

DLS 3.2+：扩展到 9 节点上限

未来 NLS release：可能调整上限 / 引入更多 topology 形式；以 NVIDIA 官方 NLS release notes 与 DLS Installation & Configuration 当期指南为准

含义：如果你看到 "DLS HA ≥ 9 节点" 已是 5+ 年前的资料，请核对当前 DLS 版本号——节点上限可能已变

HA cluster 在 Azure Local 上的推荐路径：

Azure Local Cluster
├── DLS Node 1（Primary，单独 VM 或独立服务器）
├── DLS Node 2（Secondary，单独 VM）
└── DLS Node 3~9（如需，跨机房/异地部署）

HA 失败机制：
- 心跳：每节点跑 Heartbeat service
- 失败检测：主节点挂 → 次节点升级为主
- Virtual IP Management：浮动 IP 自动漂移
- 客户端无需重配

§I.7.1 HA 触发 fail-over 的条件（NLS 官方原文）

NVIDIA 官方原文（NLS 1.5 "Heartbeat Checks for DLS Failover" 节）：Heartbeat service 每节点运行，监控 DLS appliance 健康状态，触发 fail-over 的依据是以下 criteria 中的任意一项：

节点无响应（网络不可达 / 心跳超时）

DLS service 进程崩溃

硬盘满 / 内存溢出导致 OOM

License Server File 过期（3 年有效期过期会触发 fail-over，但不会自动续期）

【来源分层】：上面 4 条触发条件是 NLS Heartbeat 节原文的常见类型归纳；具体 criteria 的完整列表（包含 disk health、CPU load、memory pressure、cluster quorum lost 等）请直接看交付期 NLS 1.5 节原文，本节档不全列避免误导。

§I.7.2 HA 部署的避坑（经验）

误区	后果
DLS HA 节点部署在同一物理 server	单点失效等于无 HA
DLS HA 节点间跨 WAN（高延迟 / 不稳定）	心跳抖动导致频繁 fail-over
把 DLS 节点和 Azure Local GPU host 合并	GPU host 故障时 license 服务同时挂
用 CLS + DLS 混搭搭 HA cluster	NLS 明文禁止（"Each node in an HA cluster must be a DLS instance"）
假设 License Server File 过期会自动续期	3 年后过期，VM 降级
以裸 K8s 方式在 Azure Local AKS Arc 上装 NVIDIA GPU Operator（driver.enabled=true）	与 Azure Local 自带 NVIDIA driver / AKS Arc GPU 扩展 / RuntimeClass 可能冲突；冲突细节以 Microsoft 当期支持矩阵为准
以为 L4 / L40S 可切固定 N 份 partition	partition 数由 `Get-VMHostPartitionableGpu` 当期 ValidPartitionCounts 决定——取决于 vGPU 软件版本 / Windows Build / OEM firmware / GPU 型号
以为 DDA 后一切都免费	DDA 本身不触发 vGPU license，但如果用 vGPU Software / vWS 软件栈，则需要相应软件授权

§I.8 Disconnected Operations 气隙部署（vGPU + Node-locked Licensing，关键审校）

NVIDIA 官方原文（NLS 1.1 节）：

Node-locked-licensing: A client system without a network connection or on an air-gapped network can obtain a node-locked NVIDIA vGPU software license from a file installed locally on the client system.

Support for node-locked licensing was introduced in NVIDIA vGPU software 15.0. It is not supported in earlier NVIDIA vGPU software releases.

【关键审校·避免过度绝对化】：

不要写 ❌："气隙 Azure Local 必须走 Node-locked Licensing"。

事实描述：完全隔离环境（air-gapped / 严格断网）可能需要 Node-locked Licensing，但具体取决于 NLS release、license model、客户合规要求——不是单一硬规则。可选路径包括：

NVIDIA Node-locked Licensing：本地 license 文件，不需外部网络

DLS 内网部署：把 DLS 部署在内网 / 数据中心管理网络，只要 DLS 本地对外的 license 服务可达即可；不依赖公网

Offline license workflow：与 NVIDIA 通过离线流程签发 license（以 NVIDIA 当期 offline license 文档为准）

【风险点】：本节档作为 v1.5 系列可能误读某些情景——务必在交付前与 NVIDIA SE + Microsoft 售前双重确认。azloc-2606 Disconnected Operations 文档主要面向 Arc + Arc-enabled K8s 治理，未专门针对 GPU NVIDIA license——这是 §J.3.1 待补方向之一。

（参考）Node-locked Licensing 部署链路：

内网先建一个 DLS 节点（在内部网络/管理网，不是互联网侧）
从 NVIDIA Licensing Portal 下载 License Server File，导入 DLS
逐个 VM 通过 vGPU Manager 生成 node-locked license token，写入 VM guest 内的指定路径
License File 有效期是按 token 设定（不是 3 年 server file），需要按 token 周期重新签发

【来源分层】：Node-locked License 流程在 NLS 官方文档 nvidia-license-system-user-guide 的 "Node-locked Licensing" 章节有详细操作。气隙 + Azure Local + NVIDIA vGPU 是非常罕见的组合——azloc-2606 Disconnected Operations 文档主要面向 Arc + Arc-enabled K8s，没有专门针对 GPU NVIDIA license 的章节；如果走这条路，务必先与 NVIDIA SE / Microsoft 售前对一遍方案。

§I.9 License 选型决策树（经验性，非 NVIDIA 官方报价）

【来源分层说明】：NVIDIA vGPU license 的价格按 entitlement 数量 / 年计费，不在 NVIDIA 公开文档中公示——必须通过 NVIDIA 销售渠道或 NVIDIA Licensing Portal 上 Create License Server 时才能看到价格。下表是按公开分类的"经验性 cost rank"，不是报价单。

你的 VM 跑什么？
│
├── 仅 Office / Web / RDP 浏览器 → 考虑 vApps 或 vPC（按带宽需求）
│
├── 2D CAD / 简单 3D 查看 → vPC
│
├── AutoCAD / SolidWorks / Revit / Creo / Siemens NX → vWS（必须）
│
├── 视频会议 + 多屏 → vPC（vApps 即可）
│
└── LLM 推理 / 高性能计算 / 训练 → **DDA，不走 vGPU license**

核心要点（NVIDIA vGPU R570 Release Notes 原文摘录）：

NVIDIA vGPU software 18.0 supports manual placement of vGPUs on GPUs in equal-size mode (Ada Lovelace and Ampere architectures support SR-IOV).

Manual placement of vGPUs on GPUs in equal-size mode is not supported on GPUs based on the NVIDIA Ada Lovelace architecture.

含义：L4 / L40 / L40S（Ada Lovelace）等 GPU 上，手工指定 partition 大小 / 位置不被 NVIDIA 官方支持——必须走 equal-size 自动 partition。这意味着上篇 §F.3 GPU-P 流程里 partitionSizeMb 的"指定大小"在 Ada Lovelace GPU 上可能不被硬件执行，需用 Ampere GPU（A2 / A16 / A10 / A40）才能精细手工分配。

License 类型	适用用户	功能覆盖	成本相对（经验）
vApps	RDSH / RemoteApp / 教学	仅通用 GPU 加速	最低
vPC	普通办公 / 2D-3D	通用 DX/OpenGL	中
vWS	专业 CAD / ISV 认证	全部含（OpenGL 4.6 + CUDA）	最高

§I.10 License 选型与 Azure Local GPU 部署的常见混搭模式

场景	GPU 模式	License 类型	License 服务
大模型推理（LLM）	DDA	无	无
AutoCAD 工程师	DDA 或 GPU-P	vWS	DLS（HA）或 CLS
RDSH 应用流	GPU-P	vApps	CLS（最简）
普通 VDI 桌面	GPU-P	vPC	CLS
视频编辑 / 设计稿预览	DDA	vWS	DLS
HPC CFD 模拟	DDA	无	无

【企业最佳实践】：

vGPU license 与 GPU 资源不等价——vWS license 数量是 user 数，与 GPU 数量无关；GPU 是硬件资源，license 是访问资格

同时跑 DDA + GPU-P 的环境：DDA 不消耗 vGPU license；GPU-P 每个运行的 vGPU partition 才消耗一份 license

License 计量方式（v1.5 关键修订）：vGPU license 在客户端启动并获取 license 时占用 entitlement；正常运行结束后 license 释放回池（concurrent usage + checkout/release 模型）。"关闭 VM 即立即释放"不是 NVIDIA 官方表述：

客户端正常关闭 / 重启时 license 走 checkout→release 流程

异常断电 / 进程崩溃时 license 可能不立即返还，需等到 server timeout（具体超时以 NLS 当期服务器配置为准，可能数分钟到数小时）

在 timeout 之前池中此 entitlement 显示"已占用"——不要据此判断 license 卡死

企业实践：保持 license 池利用率最优 = 不留闲 VM、且为异常断电情况预留 license 余量（15~30% buffer）

§I.11 License 问题排查（经验 + NVIDIA 官方排查流程）

§I.11.1 常见错误现象（NVIDIA 官方 nvidia-smi 字段对照）

nvidia-smi 显示	含义	操作
`License Status: Licensed`	正常	无
`License Status: Unlicensed (grace period)`	grace period 内但 server 不通	检查 LicenseServer 注册表；检查网络
`License Status: Unlicensed (expired grace period)`	grace period 已过；CUDA / DX 降级	必须立即恢复 license
`License Status: License acquired from <server>`	显示是哪个 server 发的	通常正常
vGPU type 行显示 `N/A`	DDA 模式，无 vGPU profile	正常

§I.11.2 排查流程（NVIDIA 官方推荐 + 经验）

# 1. 在 VM 内查 license 状态
sudo nvidia-smi -q | grep -A2 -i license

# 2. 查 vGPU Manager log（host 端）
# Windows: Event Viewer → Applications and Services → NVIDIA vGPU Manager
# Linux:   /var/log/nvidia-vgpumgr.log
# 关键关键词："License acquisition failed"、"License server unreachable"

# 3. 查 DLS 日志（DLS VM 内）
# /var/log/dls/ 目录下的 *.log

# 4. 网络连通性
# 从 VM 到 DLS：
Test-NetConnection -ComputerName dls.corp.example.com -Port 443
# 从 VM 到 CLS（endpoint 以 NLS 当期文档为准）：
nslookup <nvidia-licensing-service-endpoint>  # 必须解析到 NVIDIA 注册 IP
curl -I https://<nvidia-licensing-service-endpoint>

§I.11.3 常见根因（经验）

现象	根因
vGPU Manager 起不来 → nvidia-smi 报 `NVIDIA-SMI has failed`	host 端 NVIDIA host driver 未卸载干净
VM 内 nvidia-smi 显示 `License Status: Unlicensed`（非 grace period）	License Server 注册表错 / 网络错 / DLS 未配 license file
grace period 过期后 vGPU 降级（仅 2D 显示，CUDA 不可用）	DLS license file 过期 / 失效；必须续期
DLS HA cluster 不能自动 fail-over	心跳配置错 / 节点间网络分区
部分 VM 拿到 license / 部分拿不到	DLS license pool 数不够（购买数量 < 同时运行 VM 数）
Grace period 内每次重启都"重新 grace"	license server 实际从未响应，VM 进入"永久 grace"状态

§I.12 License 授权与部署的避坑清单

§I.12.1 不要做的事

行为	后果	NVIDIA 原文
在 DLS < 3.4 时安装 vGPU 18.0+	License failure 静默累积	NLS 1.1.1 节原文
假设 License Server File 自动续期	3 年后过期，VM 全降级	NLS 3.4+ security policy 原文
用 vGPU 17.x license file 喂 18.0 host	不兼容；silent failure	NLS 1.1.1 节原文
把 DLS 节点与 GPU host 合并	GPU host 故障 = license 双挂	经验
跨大版本跳升级 DLS 1.x → DLS 3.4 直接跳	升级失败；license token 失效	NLS DLS 3.4.0 User Guide "Migrating" 节
在 VM 内 vGPU driver 不匹配 vGPU Manager 版本	vGPU 初始化失败	vGPU Release Notes 1.2 节

§I.12.2 一定要做的事

采购 vGPU license 数量 ≥ 同时在跑 vGPU VM 数量（NLS networked licensing 是浮签，但不超额 license 会被超分）
DLS 节点 HA 时不要放同一台 host（经验）
License Server File 记录下载日期（3 年有效期自下载起算）
监控 DLS license 池使用率（Web UI / API 都可查）
DLS 与 vGPU Manager 同步升级（不要分两次大版本跨级跳）
关键业务上线前先跑 1~2 周小流量 grace period 演练

§I.13 GPU-P + License 完整链路总图

                 ┌──────────────────────────────────────────────────────┐
                 │                NVIDIA Licensing Portal               │
                 │                （URL 以 NLS 当期文档为准）         │
                 └─────────────────────────┬────────────────────────────┘
                                           │
                          License Server File (.bin, 3 年有效期)
                                           │
                  ┌────────────────────────┴───────────────────────────┐
                  │                                                    │
                  ▼                                                    ▼
   ┌─────────────────────────────┐                  ┌────────────────────────────┐
   │   CLS (cloud, 无运维)      │                  │  DLS（本地，可 HA 9 节点） │
   │   （endpoint 以 NLS 当期为准）│                  │  dls.corp.example.com:443   │
   │   适用：公网可达            │                  │  适用：内网/气隙/合规       │
   └──────────┬──────────────────┘                  └──────────┬────────────────┘
              │ 443/tcp                                          │ 443/tcp
              │                                                  │
              └────────────────────┬─────────────────────────────┘
                                   ▼
   ┌─────────────────────────────────────────────────────────────────────┐
   │  Azure Local Host (Hyper-V)                                          │
   │  ─ NVIDIA vGPU Manager 18.x 已配 LicenseServer 注册表指向 server    │
   │  ─ BIOS SR-IOV 已开启                                                │
   │  ─ GPU-P partition 已 attach                                          │
   └────────────────────────────┬────────────────────────────────────────┘
                                ▼
   ┌─────────────────────────────────────────────────────────────────────┐
   │  VM guest (Ubuntu 22.04 LTS / Windows Server 2025)                   │
   │  ─ vGPU driver 18.x（与 Manager 同分支）                             │
   │  ─ sudo nvidia-smi → 显示 vGPU type + License Status: Licensed      │
   │  ─ CUDA / DX / OpenGL 全部可用                                       │
   └─────────────────────────────────────────────────────────────────────┘

§J. 附录

§J.1 参考文档层级（按权威性递减）

层级	文档	URL 模式
L1 厂商官方硬要求	Microsoft Azure Local azloc-2606 主文档	`learn.microsoft.com/en-us/azure/azure-local/...`
L1 厂商官方硬要求	Microsoft Azure Local azloc-2606 gpu-preparation	`learn.microsoft.com/en-us/azure/azure-local/manage/gpu-preparation`
L1 厂商官方硬要求	Microsoft Azure Local azloc-2606 gpu-manage-via-device	`learn.microsoft.com/en-us/azure/azure-local/manage/gpu-manage-via-device`
L1 厂商官方硬要求	Microsoft Azure Local azloc-2606 gpu-manage-via-partitioning	`learn.microsoft.com/en-us/azure/azure-local/manage/gpu-manage-via-partitioning`
L1 厂商官方硬要求	Microsoft Azure Local azloc-2606 attach-gpu-to-linux-vm	`learn.microsoft.com/en-us/azure/azure-local/manage/attach-gpu-to-linux-vm`
L1 厂商官方硬要求	NVIDIA vGPU Software R570 Release Notes	`docs.nvidia.com/vgpu/18.0/grid-vgpu-release-notes-microsoft-azure-stack-hci/...`
L1 厂商官方硬要求	NVIDIA License System User Guide v3.6.1	`docs.nvidia.com/license-system/latest/...`
L1 厂商官方硬要求	NVIDIA Delegated License Service User Guide 3.4.0	`docs.nvidia.com/license-system/dls/3.4.0/...`
L2 OEM / 工具默认	aksarc deploy-gpu-node-pool	`learn.microsoft.com/en-us/azure/aks/aksarc/deploy-gpu-node-pool`
L2 OEM / 工具默认	azloc-sovereign-clouds ai-workloads-overview	`learn.microsoft.com/en-us/azure/azure-sovereign-clouds/private/azure-local/ai-workloads-overview`
L3 社区	Azure Local deploy / Reddit r/AZURE / Stack Overflow	（非权威；本节档不直接引用）

【分层使用原则】：

事实校对：用 L1（厂商官方） → L2（OEM / 工具默认） → L3（社区）

置信度：L1 = 95%+；L2 = 80%；L3 = 50% 以下（社区资料的数字必须查官方原文）

写作引用：本节档严格只引用 L1 / L2；L3 不引用具体数字

§J.2 推荐阅读

§J.2.1 上篇相关

上篇文档结构（§A~§E）：参 azure-local-gpu-upper.md
§A 概念边界：微软 azloc-2606 GPU 文档第二节"Before you begin"
§B 硬性约束：azloc-2606 system-requirements
§C GPU 型号矩阵：azloc-2606 gpu-preparation 表格原貌
§D Dell AX（OEM 上下文）：上一轮交付期未抓到 Dell 产品页，下次抓取可用 --url "https://www.dell.com/zh-cn/work/shop/povd/poweredge-ax" 试
§E AKS Arc GPU 节点池：aksarc deploy-gpu-node-pool

§J.2.2 下篇相关

§F 部署流程：azloc-2606 gpu-preparation + gpu-manage-via-device
§G 应用场景：azloc-sovereign-clouds ai-workloads-overview（Foundry Local）+ §G.5 VDI 单独参 §C.2 决策树
§H 避坑清单：综合 azloc-2606 + NVIDIA vGPU R570 Release Notes
§I License 链路：NLS 3.6.1 + DLS 3.4.0 + vGPU R570 Release Notes

§J.2.3 二手资料 / 推导

NVIDIA GPU DDA on Azure Stack HCI 性能白皮书：Microsoft 已归档于 previous-versions
NVIDIA vGPU 18 Performance Report：NVIDIA 官网 Quarterly Report（非 L1 当期文档；仅供参考数字）
AKS Arc 社区案例库：Microsoft Tech Community（属 L3，引用请谨慎）

§J.3.1 后续修订条件

azloc-2607 / 2608 GPU 文档更新（NVIDIA vGPU 19、DDA GA、Foundry Local GA 等）
NVIDIA vGPU 19.0 发行（如果 R580 等之后版本）
Foundry Local GA（当前为 preview）
Dell AX 新机型发布（AX-7xxx refresh、AX-Next 系列）
AKS Arc GPU 节点池 SKU 矩阵调整
NVIDIA License System v3.7+ / DLS 3.5+ 发布

§J.3.2 待补充

Dell 中文/英文产品页稳定拉取后回填 §D 节具体 SKU / slot / 电源瓦数（OEM 实证待补）
NVIDIA RTX Pro 6000 在 aksarc 上的实际 GPU 时间表（azloc-2606 文档范围 2603.0，交付期如有更新）
Foundry Local GA 后的实际版本号与生效日期（当前 preview）
v1.4 已解决的待补：✅ AX-770 / AX-670 实证闭环（V7.0 spec sheet）；✅ AX-4510c N/A 明示；✅ AX-4520c 仅 A2 / L4 实证；✅ RTX Pro 6000 Blackwell 96GB 600W 实证

§J.4 未来方向（让文章生命周期更长）

【让文档生命周期更长】：当前文档聚焦于 Azure Local GPU "今天"能力；为防止文档 6 个月后过期，本节档列出 Microsoft 已经显现的「未来方向」轨迹。

§J.4.1 GPU Orchestration / GPU Scheduling（GPU 调度层）

【趋势·Azure Arc + Azure Local 正在朝 GPU Pool 方向发展】：

今天：GPU 是 host-local 资源——DDA 后独占、GPU-P 后切分；调度是 per-host

未来：Azure Arc 控制平面引入 GPU Pool 概念——pool 级 GPU 资源 + 按需分配给 VM / pod / Foundry Local session

含义：客户不再买特定 GPU 卡的特定插槽，按 "我要 N GB VRAM + X TOPS 算力" 的 SLA 买

当前状态（v1.4 交付期）：preview——Azure Local 控制面板已能枚举 GPU 但还没全 pool 调度

§J.4.2 AI Foundry Local GA + Foundry Local + On-Premises Agentic

【趋势·Foundry Local（Preview）是 Microsoft 在 Azure Local 上的核心 AI 路径】：

今天（v1.4 交付期）：Foundry Local（Preview）是 preview（azloc-sovereign-clouds ai-workloads-overview 明示）

未来：Foundry Local GA——gated 的预配置模型清单 + 一键部署 + 内建 RAG + Agentic Retrieval + MCP Tool Broker

对应 Microsoft Foundry 产品线：Azure AI Foundry 云端服务与 on-prem Foundry Local 的 hybrid 双向同步（设计上）

MCP（Model Context Protocol）Broker：让本地 Foundry Local 能 discover / call on-prem enterprise tools——v1.4 文档只介绍概念，GA 期会出真实 broker

§J.4.3 AKS Arc AI / AI Workload Operator

【趋势·AKS Arc on Azure Local 与 GPU 工作负载的深度融合】：

今天：AKS Arc GPU 节点池是 aksarc 的子能力，要手动 deploy

未来：Azure Arc → AI Workload Operator ——自动识别 GPU SKU / 自动选 device plugin / GPU Operator driver / 自动配 GPU-P

含义：cluster admin 只需说"我要 AKS Arc + GPU"，背后 Operator 自动搭好

§J.4.4 Azure Machine Learning on Hybrid（Azure ML Hybrid）

【趋势·Azure ML 与 Azure Local on-prem 推理联动】：

今天：Azure ML 云端训练 → 手动 export model 到 Azure Local 推理

未来：Azure ML Hybrid —— 云端训练 + on-prem 部署 + telemetry 回流到 Azure ML Studio 的统一体验

v1.4 文档范围：不展开 Azure ML Hybrid 部署细节；下版更新时加专门的章节

§J.4.5 NVIDIA vGPU / Blackwell 架构演进

【趋势·vGPU 18.x → 19.x / 20.x 的关键预期】：

vGPU 19.0（如果 R580 等之后版本发行）：预期带 Blackwell Server Edition 全 SKU 支持 + 更细粒度 GPU-P 切分

DLS 演进：NVIDIA License System v3.7+ / DLS 3.5+ 预期带 NLS 客户端自动续租 + Azure Local 集成器

GA 路径：Foundry Local GA 后的实际 NVIDIA vGPU 版本号需要在交付期查 azloc-2607+ 文档

§J.4.6 GPU Memory Fabric / GPU Direct Storage

【趋势·GPU 与存储直连的 on-prem 路径】：

今天：GPU ↔ host memory ↔ Storage Spaces Direct / FC SAN（多 hop）

未来：GPU Direct Storage on Azure Local——GPU 直接读 NVMe，绕开 host-CPU 链路

当前状态：Azure Local 文档范围未明示，这是 NVIDIA-side 技术，需要等 on-prem GPU ↔ Storage fabric 集成器

§J.4.7 文档未来补充节奏

【下版更新承诺 — 计划】：

azloc-2607 / 2608 发布后：校对 GPU-P / DDA / AKS Arc GPU 节点池 / Foundry Local 章节

NVIDIA vGPU R580 / R590+ 发布后：更新 §I License Server 与主机 driver 兼容性表

DELL V8.0 spec sheet 发布后：更新 §D 完整 SKU 矩阵 + 是否有新平台

Foundry Local GA 后：更新 §G.3 Foundry Local 的 GA 后真实版本号 + 商业化路径

AKS Arc GPU Operator 集成器发布后：校订下篇 §G.9 的装路径

如果出现 MIG 路径：撰写专门章节（之前 §A.6 与 §G.9.3 都标了"当前不支持"）

§J.5 Azure Local GPU 架构决策树（v1.6 新增）

【v1.6 新增·企业选型核心】：以下决策树帮助快速定位最适合的 GPU 消费模型。

                           需求？
                              │
            ┌─────────────────┼─────────────────┐
            ▼                 ▼                 ▼
      LLM 推理/训练      VDI / 虚拟桌面      AI Container / K8s
      (单模型/微调)      (多用户共享)        (微服务/Pod)
            │                 │                 │
            ▼                 ▼                 ▼
       模型多大？         用户类型？         编排方式？
            │                 │                 │
    ┌───────┴───────┐   ┌───────┴───────┐   ┌───────┴───────┐
    ▼               ▼   ▼               ▼   ▼               ▼
  < 70B          ≥70B   轻办公        重图形   Arc K8s      裸 K8s
    │               │     │             │      │            │
    ▼               ▼     ▼             ▼      ▼            ▼
  DDA            多个    GPU-P        GPU-P    AKS Arc     自建 K8s
 GPU 独占       DDA     (共享)       (高配)    (官方)     (不推荐)

§J.5.1 按场景快速选型表

场景	推荐模式	License	典型 GPU	说明
LLM 推理 70B+	DDA	❌ 无需 vGPU License	RTX PRO 6000 96GB ×2	整卡独占，最大吞吐
LLM 推理 7B~30B	DDA 或 GPU-P	vGPU（vWS）	L40S / A16	视并发量选择
VDI 轻办公	GPU-P	vGPU（vPC）	A2 / L4	10~20 用户/GPU
VDI 重图形	GPU-P	vGPU（vWS）	L40S	2~8 用户/GPU
小模型微调	DDA	❌ 无需 vGPU License	L40S × 1~2	单机微调场景
LoRA / QLoRA	DDA 或 GPU-P	vGPU（vWS）	A16 ×2	多卡并行
AI 微服务	AKS Arc	❌ 无需 vGPU License	A2 / L4	Kubernetes 原生
边缘推理	DDA	❌ 无需 vGPU License	L4	低延迟本地推理

§J.5.2 三种 GPU 消费模型总结

模型	对象	典型场景	特点
GPU as VM Device	DDA	LLM 推理 / HPC	整卡直通，性能最高
GPU as Shared Resource	GPU-P	VDI / 渲染 / 培训	多用户共享，降低成本
GPU as Kubernetes Resource	AKS Arc	AI 服务 / 微服务	云原生，弹性伸缩

【选型口诀】：

要最大性能 + 数据安全 → DDA（整卡独占）

要成本优化 + 多用户 → GPU-P（分区共享）

要云原生 + 弹性 → AKS Arc（K8s 资源）

§J.6 Azure Local GPU 三种资源模型（v1.6 强烈建议新增）

【v1.6 强烈建议新增·整篇文章的概念内核】： Azure Local 上的 GPU 有三种资源分配模型，理解这个分类法就能快速判断任何 GPU 工作负载应该走哪条路径。

§J.6.1 GPU Device Model（设备模型）

┌─────────────────────────────────────────────────────┐
│                    VM                                │
│  ┌───────────────────────────────────────────────┐  │
│  │                 Application                   │  │
│  │  (LLM Inference / CUDA / HPC / Training)     │  │
│  └───────────────────────────────────────────────┘  │
│                         │                            │
│                    DDA                              │
│           (Discrete Device Assignment)             │
│                         │                            │
└─────────────────────────┼───────────────────────────┘
                          │
                   Physical GPU
                 (NVIDIA RTX/L40/L4)

特点：

整张 GPU 卡从 PCIe 拓扑上完全直通给 VM
VM 看到的是物理 GPU，无虚拟化层
性能接近原生（near-native）
无需 NVIDIA vGPU License（除非软件本身需要）

适合场景：

✅ LLM 推理（大模型 70B+）
✅ CUDA / HPC 计算
✅ 单机训练 / 微调
✅ 需要最大 GPU 吞吐的低延迟场景

典型 GPU：RTX PRO 6000 96GB、L40S、A100、H100

§J.6.2 GPU Partition Model（分区模型）

┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│     VM1      │  │     VM2      │  │     VM3      │
│  (VDI User)  │  │  (VDI User)  │  │  (VDI User)  │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │                 │                 │
    vGPU-1            vGPU-2            vGPU-3
       │                 │                 │
       └─────────────────┼─────────────────┘
                         │
                     GPU-P
           (Hyper-V GPU Partitioning)
                         │
                   Physical GPU

特点：

一张物理 GPU 按 partition 分成多个虚拟 GPU
每个 VM 看到的是虚拟 GPU（vGPU）
需要 NVIDIA vGPU License（vWS/vPC/vApps）
多用户共享，降低单位成本
Live Migration 需要 partition compatibility（OS ≥ 26100 + vGPU ≥ 18）

适合场景：

✅ VDI（虚拟桌面）
✅ RDSH（远程桌面会话主机）
✅ 多租户共享 GPU
✅ 图形渲染 / 培训教室

典型 GPU：A2、L4、L40S

§J.6.3 Kubernetes Resource Model（K8s 资源模型）

┌───────────────────────────────────────────────────────┐
│                   AKS Arc Cluster                     │
│                                                       │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐              │
│  │  Pod 1  │  │  Pod 2  │  │  Pod 3  │              │
│  │ (infer) │  │ (agent) │  │ (vision)│              │
│  └────┬────┘  └────┬────┘  └────┬────┘              │
│       │ nvidia.com/gpu │       │                     │
│       └──────────────┼────────┘                     │
│                      │                              │
│            GPU Node Pool (AKS Arc)                  │
│                      │                              │
│               Physical GPU                          │
└──────────────────────┼──────────────────────────────┘
                       │
                 nvidia-device-plugin-daemonset

特点：

GPU 作为 Kubernetes 资源调度
通过 Device Plugin 暴露 nvidia.com/gpu 资源
不需要 NVIDIA vGPU License（走 Kubernetes 调度，不走 vGPU 软件栈）
云原生弹性伸缩
AKS Arc GPU Node Pool 官方管理

适合场景：

✅ AI 微服务推理
✅ Agent 应用
✅ 计算机视觉
✅ RAG / Embedding 服务
✅ 需要弹性伸缩的 AI 工作负载

典型 GPU：A2、L4（AKS Arc 官方支持矩阵）

§J.6.4 三种模型对比总表

维度	Device Model (DDA)	Partition Model (GPU-P)	K8s Resource Model (AKS Arc)
资源粒度	整卡	Partition	N/A (requested)
虚拟化层	无（直通）	Hyper-V vGPU	K8s Device Plugin
License	❌ 不需要	✅ vWS/vPC/vApps	❌ 不需要
性能	接近原生	<10%~15% 开销	取决于调度
典型场景	LLM/HPC	VDI/RDSH	AI 微服务
迁移能力	❌ 不支持 LM	✅ 支持（有限制）	Pod 漂移
弹性	固定	固定	弹性伸缩
管理入口	Hyper-V / WAC	Hyper-V / WAC	Arc + K8s API

§J.6.5 企业选型决策快速判断

【一句话选型】：

要最强性能 + 数据不出卡 → Device Model (DDA)

要多人共享 + 降低单用户成本 → Partition Model (GPU-P)

要做云原生 AI 服务 → K8s Resource Model (AKS Arc)

【组合场景】：

VDI 用户 80% 走 GPU-P + 关键工程师走 DDA

LLM 推理用 DDA + 微服务推理用 AKS Arc

边缘部署用 DDA + 中央部署用 AKS Arc

下篇小结（→ 回到上篇）

下篇已经把"实施与运维"讲完：

§F：DDA / GPU-P / AKS Arc 三种路径的 9~10 步部署流程；MMIO 配置公式；端到端示例
§G：7 个应用场景（LLM 推理 / Foundry Local / Agentic Retrieval / VDI / 视频分析 / RDSH / 大模型训练）；每个场景的选型 + 架构 + 实操
§H：避坑清单（不要做 15 条 + 一定要做 14 条）；选型决策；升级路径上的"硬刹车"
§I：NVIDIA vGPU License 完整链路（CLS / DLS / License Server File 3 年有效期 / HA 9 节点 / Node-locked Licensing）

亚马逊云科技技术品牌专区

更多推荐

图解人工智能（86）人工智能前沿-和数学家做朋友

亚马逊云科技技术品牌专区

图解人工智能（87）人工智能前沿-和数学家做朋友

开普勒猜想是关于三维空间球体最密堆积的数学问题，认为面心立方和六方最密堆积的74.048%密度是最优解。该猜想由17世纪天文学家开普勒提出，直到1998年数学家托马斯·黑尔斯借助计算机辅助证明才最终解决。证明过程涉及大量复杂计算，计算机帮助验证了数千种特殊情况。这种堆积方式类似水果摊上橘子的自然堆叠，证实了日常直觉背后的数学原理。

亚马逊云科技技术品牌专区

“实测数据：海力冠生物刺激素提升作物产量15%的奥秘“

亚马逊云科技技术品牌专区

所有评论(0)

查看更多评论

XUHUOJUN

@xuhuojun

已为社区贡献2条内容

模式	是否需要 NVIDIA License
DDA 整卡直通	❌ 不需要
GPU-P + NVIDIA vGPU Software	✅ 需要（vWS/vPC/vApps）
GPU-P + 普通 GPU Partition	取决于具体 GPU 软件路径（非 NVIDIA vGPU 栈则不需要）