vllm 缓存对模型启动时间的影响

你的观察基本符合 vLLM 的实际启动流程。几个缓存影响的阶段不同,所以影响启动时间差异很大。

先区分一下:

缓存 主要内容 影响阶段 对 vLLM 启动时间影响
/tmp/torchinductor_root/ PyTorch Inductor 编译缓存 模型运行时图优化、kernel fusion 通常较小
~/.triton/cache/ Triton kernel 编译缓存 Triton 自定义 kernel 编译 通常较小
~/.cache/vllm/ vLLM 自身缓存(含部分编译产物) vLLM backend 初始化 中等
flashinfer/ FlashInfer kernel autotune / JIT 编译缓存 attention、MoE、量化 kernel 非常大

为什么 FlashInfer 缓存影响最大?

你的模型:

复制代码
unsloth/Qwen3.6-27B-NVFP4

启动参数:

复制代码
--moe-backend flashinfer_b12x

这类模型启动时会大量依赖 FlashInfer。

启动流程大概:

复制代码
vLLM serve
 |
 |-- load model weights
 |
 |-- initialize attention backend
 |
 |-- initialize MoE backend
 |
 |-- FlashInfer kernel selection
       |
       |-- 查找已有 kernel cache
       |
       |-- 没有:
             编译 CUDA kernel
             autotune
             保存 cache
 |
 |-- engine ready

第一次启动:

复制代码
没有 flashinfer cache
        |
        v
nvcc / nvrtc 编译大量 kernel
        |
        v
几十秒甚至几分钟

第二次:

复制代码
读取 ~/.cache/vllm/flashinfer
        |
        v
直接加载
        |
        v
快速启动

为什么 Triton cache 不明显?

因为现在 vLLM 的核心路径不一定大量依赖 Triton。

例如:

以前:

复制代码
vLLM
 |
 |-- Triton attention
 |-- Triton fused kernel

现在很多情况:

复制代码
vLLM
 |
 |-- FlashAttention
 |
 |-- FlashInfer
 |
 |-- CUTLASS
 |
 |-- CUDA kernel

尤其 Blackwell:

复制代码
RTX5090
SM120
NVFP4

大量走:

复制代码
FlashInfer
+
CUTLASS
+
Tensor Core kernel

不是 Triton。

所以:

复制代码
~/.triton/cache

可能只有少量 kernel。


/tmp/torchinductor_root 为什么影响小?

PyTorch Inductor主要影响:

  • torch.compile

  • graph capture

  • operator fusion

例如:

复制代码
torch.compile(model)
        |
        v
Inductor
        |
        v
生成优化后的 kernel

但是 vLLM 推理:

不是传统:

复制代码
PyTorch eager
+
torch.compile

更多是:

复制代码
CUDA Graph
+
custom kernel
+
FlashInfer

所以 Inductor 贡献有限。


你可以验证

第一次启动:

复制代码
rm -rf ~/.cache/vllm/flashinfer
time vllm serve ...

观察:

复制代码
Compiling ...
Generating kernels...
Autotuning...

第二次:

复制代码
time vllm serve ...

通常会明显减少。


你的环境建议持久化

你之前设置:

复制代码
export HF_HOME=/hyperai/input/input0/hub
export VLLM_CACHE_ROOT=/local_nvme/vllm_cache
export FLASHINFER_CACHE_DIR=/local_nvme/flashinfer_cache
export TORCHINDUCTOR_CACHE_DIR=/local_nvme/torch_cache
export TRITON_CACHE_DIR=/local_nvme/triton_cache

其中最关键:

第一优先级

复制代码
FLASHINFER_CACHE_DIR

一定要持久化。

第二优先级

复制代码
VLLM_CACHE_ROOT

保存 vLLM 相关编译结果。

第三

复制代码
TRITON_CACHE_DIR
TORCHINDUCTOR_CACHE_DIR

保存也没坏处,但收益明显低。


对你的 RTX5090 + NVFP4 环境还有一个特殊点

Blackwell 的 NVFP4 kernel 比传统 FP16 kernel 更依赖:

复制代码
CUTLASS
+
FlashInfer
+
architecture specific compilation

例如:

复制代码
sm_120
sm_121

这些 kernel 不是通用二进制。

所以:

同一个 cache:

复制代码
RTX5090(sm120)

换到:

复制代码
B200(sm100)

通常不能复用。

甚至:

复制代码
RTX5090 A机器
RTX5090 B机器

如果 CUDA / driver / flashinfer 版本不同,也可能重新编译。


所以你的实验结果可以总结为:

复制代码
启动耗时主要 =
模型权重加载
+
FlashInfer kernel 编译/autotune

不是 =
PyTorch Inductor
+
Triton cache

对于你现在这个 Qwen3.6-27B-NVFP4 + RTX5090 + vLLM FlashInfer MoE backend 场景,flashinfer cache 是最值得持久化的。

相关推荐
MC皮蛋侠客1 天前
Redis 系列(八):缓存设计模式与一致性——从 Cache Aside 到防雪崩
redis·缓存·设计模式
2401_894915531 天前
部署 GEO 优化源码常见报错排查:端口、伪静态、缓存问题解决
java·运维·服务器·后端·缓存·开源
MC皮蛋侠客1 天前
Redis 系列(三):底层实现(一)——对象系统、SDS 与 dict
数据库·redis·缓存
LitchiCheng2 天前
vllm运行在DGX Spark的启动参数及小问题
人工智能·python·vllm
范什么特西2 天前
回答知识总结04(redis)
数据库·redis·缓存
HyperAI超神经2 天前
【vLLM 学习】Disaggregated Prefill
人工智能·深度学习·学习·vllm
math_hongfan3 天前
鸿蒙离线数据缓存高级架构:弱网预加载/离线数据优先级/同步冲突解决/上线后数据合并策略
学习·缓存·华为·架构·harmonyos·鸿蒙
海上小飞龙3 天前
Redis 持久化:RDB 与 AOF
数据库·redis·缓存
math_hongfan3 天前
鸿蒙存储碎片高级清理机制:数据库Vacuum/文件碎片整理/缓存过期清理/主动空间回收策略
jvm·数据库·学习·缓存·华为·harmonyos·鸿蒙
范什么特西3 天前
知识总结04(redis)
数据库·redis·缓存