微软 NVIDIA 为 vLLM 打通 Azure Blob 双通道：权重进、KV 出，加载快 7.3 倍

8 月 12 日 14:13（UTC），，vLLM 的模型加载器与 KV Connector 双双新增 Azure Blob 路径：权重从 Blob 加载进 GPU，KV 缓存输出到 Blob，微软与 NVIDIA 各配了一份部署配方。加载侧，Dynamo ModelExpress 接入 vLLM 的模型加载器；KV 侧，lmcache 借 Dynamo 的 NIXL 把 KV 块存进 Blob，命中时直接取回而不是重算。

微软前一天在 Azure Storage 博客公布了这组测量：；经 NIXL 把 KV 缓存卸载到 Blob 后，首 token 延迟（TTFT）比重算 KV 低最多 2.8 倍。

权重不进 HBM，服务就起不来

vLLM 推文把加载这条线的逻辑说死了：“Nothing serves until weights land in HBM”，即权重不落进 HBM，服务就无法开始。ModelExpress 的做法是把权重从加载、缓存到分发复用的整个生命周期交给 Dynamo 集群统一调度，核心是与 Run:ai Model Streamer 的原生集成：并行传输加预取，把权重从 Azure Blob 直接流进 GPU 显存，用满 Azure VM 网卡带宽。

博客图一对比了四款模型：Qwen3.5-27B、Nemotron-3 Super-120B、Qwen3.5-122B、Kimi-K2.5。权重加载时间的提速标注从 5.4 倍到 7.3 倍，就绪时间从 1.9 倍到 4.6 倍。

vLLM 官方账号把这组 7.3 倍数字标注为 H100/A100 上的结果，博客只写测试覆盖 Azure 的多种节点类型。配方的入口是一行参数：vLLM 0.18.0 及以上版本用 --load-format modelexpress 加 az:// URI 启动，日志里出现“Registered model loader ... MxModelLoader”。这条路不需要模型 PVC，pod 启动时直接从 Blob 流式加载，用的是 az://models/models/deepseek-ai/DeepSeek-V3。

一次命中是一次取回，不是一次重算

讲的是服务起来之后的事：KV 计算贵，还和你想留给 batch size 的 HBM 抢空间；“一次命中就是一次取回，不是一次重算”，差距随提示词长度拉大。路径是 vLLM 的 KV Connector：借 NVIDIA Dynamo 的 NIXL 把 KV 块存进 Azure Blob。

微软工程师 Kyle Knapp 的把这条路测到最细：单台 Standard_ND96isr_H100_v5（8×H100 80GB，80 Gbps 网卡），三种模型各扫 20k 到 120k token 的提示词，基线关掉 prefix caching、每次从零重算 prefill。120k token 处，Mistral Medium 3.5-128B 的 TTFT 从约 13.0 秒降到约 4.7 秒，快 2.79 倍；MiniMax M2.7 从 7.8 秒降到 3.8 秒，快 2.07 倍；gpt-oss-120b 从 2.8 秒降到 1.6 秒，快 1.79 倍。

取回为什么快：gist 记录到 KV 读取的入向吞吐在多数长度上打满 80 Gbps 网卡；本地 CPU 缓存层被显式关掉，CPU 只作 50 GiB 暂存缓冲，nixl_async_put 在后台异步上传。入口是 vLLM 的 --kv-transfer-config，kv_connector 填 LMCacheConnectorV1，kv_role 为 kv_both。gist 也注明，Mistral 模型的权重当时改从 Hugging Face 加载（vllm-project/vllm#40765），只影响权重来源，不影响 KV 卸载的结论。

配方落在 ai-dynamo 仓库和一个 gist 里

加载侧配方的先决条件：Premium 块 Blob 存储账户、pod 经 DefaultAzureCredential 拿到 Azure 身份、该身份持 Storage Blob Data Reader 权限、装有 ModelExpress 与 vLLM 0.18.0+ 的镜像。张量并行大于 1 时保持 MX_MS_DISTRIBUTED=1，ModelExpress 会把分布式流式加载交给 vLLM 原生的 RunAI ModelStreamer 加载器；mx 作为旧加载格式的别名保留。

KV 侧配方用 lmcache/vllm-openai 镜像并装上 runai-model-streamer[azure]，权重同样从 Blob 加载（--load-format runai_streamer），lmcache 配置里 nixl_backend 设 AZURE_BLOB。基准环境是南非北部区域的 Premium LRS 块 Blob 账户，与 H100 虚拟机同区域。

这条 KV 通路的底层更早就位：2 月 18 日发布的就包含 Azure Blob Storage 插件的首个实现，基于 Azure SDK for C++、用 Microsoft Entra ID 做 OAuth 认证，作为 S3 后端之外的云对象存储选项。博客致谢写明这项工作是微软与 NVIDIA 工程团队的紧密协作：微软侧署名 Vishnu Charan TJ 与 Kyle Knapp，NVIDIA 侧列出七名工程师。基准 gist 创建于 5 月 19 日，8 月 11 日随博客发布被列为 KV 卸载配方，vLLM 官方账号次日宣布。

为什么是现在：单 token 成本要一层层压下来

微软博客把动机放在开头：智能体生成的 token 更多、上下文窗口更长，平台必须在推理栈每一层压低单 token 成本。博客的对比还显示，这套优化随模型变大而更值钱：权重文件越大，Blob 直连流式加载对完整启动路径的影响越大。前沿模型参数普遍超过 1 万亿，权重文件常超 1 TB，加载正是冷启动延迟里最大的一块。

落地到 AKS 上的部署，博客列了三个具体好处：权重集中放在 Blob，用 Entra ID 与 Azure RBAC 控制跨集群访问；Blob 的生命周期管理与高耐久性；弹性扩缩容时直接从 Blob 流式取权重。KV 侧同理：Blob 的可扩展性让缓存层能留住更多可复用 KV 块，块被再次命中的概率随之提高。

短提示词上，重算比取回更快

gpt-oss-120b 与 MiniMax M2.7 两款 MoE 模型要到 40k token 左右，走 Blob 的 lmcache 方案才开始超过基线；更短的提示词上，H100 重算 prefill 够快，从 Blob 取 KV 块的固定开销还没摊平，重算反而便宜。20k token 时，这两款模型走 Blob 的 TTFT 分别慢 1.21 倍和 1.30 倍。

X 用户在回复里把这笔账写成一句话：KV 进 Blob 的反转，是用网络往返换取不把缓存放进你手里最贵的显存；只有复用率高的负载才划算——共享前缀、多轮会话——所以这是个工作负载决策。也在这条推文下回了一个火焰表情。

gist 的结论还留了一句边界：在 prefill 更慢的硬件上，这个交叉点会向更短的输入长度移动。基准本身也只测了命中场景：每次记录前先做一轮不记录的预热，把 KV 写进 Blob，所以 2.79 倍是缓存已命中时的取回收益，不是冷缓存下的数字。