ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

RTX 5090本地部署大模型:sm_120环境配置与排障全记录

RTX 5090本地部署大模型:sm_120环境配置与排障全记录 RTX 5090 到手那一刻我本以为是愉快的开箱即用结果装完驱动、配好 PyTorch一跑测试直接甩给我一句CUDA error: no kernel image is available for execution on the device。新卡在 PyTorch 眼里就是个“不认识的设备”这就是 Blackwell 架构里sm_120带来的第一个下马威。后面又折腾 FlashAttention 的编译前前后后踩了一堆坑才把 Qwen 系列大模型在本地顺畅跑起来。这篇文章就把完整的配置过程、版本匹配逻辑和排障记录整理出来给同样入手了 RTX 5090、想在本地部署大模型的朋友一个可以直接照着做的参考。1. 为什么 RTX 5090 让老环境一夜之间“全废”1.1 sm_120 是什么Blackwell 架构到底改了什么先说结论RTX 5090 的计算能力compute capability是 12.0也就是 CUDA 术语里的sm_120。上一代 RTX 4090 是sm_89专业卡 H100 是sm_90这三者之间完全是不同的架构代际。Blackwell 架构相比 Ada Lovelace 和 Hopper有几个关键变化直接影响软件生态张量核心全面升级支持 FP4/FP8 等低精度计算这也是 Blackwell 主打 AI 推理的核心卖点引入新一代线程块集群thread block clusters和 TMATensor Memory Accelerator对 kernel 的编写方式有影响内存子系统、SM 内部调度单元都做了重新设计这些改动带来的直接后果是用旧的 CUDA 版本编译出来的二进制 kernel在黑维尔 GPU 上根本没法执行。sm_120和sm_89的指令集不兼容GPU 驱动不会做指令翻译没有兜底机制没有 kernel image 就是没有。所以你会看到很多人在论坛上问“为什么我装好驱动、PyTorch 也能识别显卡一跑模型就报错”——本质上就是某个组件还是老版本编译产物里没有 Blackwell 对应的 SASS 代码。1.2 驱动、CUDA、PyTorch、FlashAttention 的版本链条这里要理清一个概念大模型跑起来的依赖链条远比想象中长。最底层是 GPU 驱动上面是 CUDA Toolkit再往上是 PyTorch 这类深度学习框架最后才是 FlashAttention 这种第三方加速库。每一层都得能识别和生成sm_120的代码这条链才算通。我整理了一份当时可用的版本对应关系供参考组件最低可用版本推荐版本说明GPU 驱动570.x575.x 或更新Blackwell 需要 R570 驱动CUDA Toolkit12.812.8 / 12.912.8 起正式支持 sm_120PyTorch2.72.8需要 cu128 或更新的 wheel 包FlashAttention2.7.x2.7.3需要从源码编译或用新预编译包vLLM0.8.x0.8.50.8 系列才完整支持 Blackwell这几个版本号不是随便选的是有因果关系的。PyTorch 要支持sm_120底层得链接到新版的 CUDA runtimeFlashAttention 要支持sm_120得自己用新版 nvcc 重新编译 kernelvLLM 同理它内部集成了大量自定义 CUDA kernel老版本编译产物根本跑不起来。所以如果你还在用 PyTorch 2.5 CUDA 12.4 的组合在 RTX 5090 上跑大模型报错是必然的跟你代码写没写对没关系纯粹是环境版本落后了。2. 环境准备把依赖链条一次装对2.1 硬件确认与驱动安装装驱动这一步看似简单其实很容易踩坑。我拿到卡之后第一件事是在系统里装上了从官网下载的最新驱动然后确认驱动版本。注意不要只看nvidia-smi显示的驱动日期要重点看右上角的 CUDA Version那个数字表示这个驱动最高支持到什么 CUDA 版本。我当时装的是 575.x 驱动nvidia-smi输出的最高 CUDA 版本是 13.0这就意味着向下兼容 CUDA 12.8 完全没问题。如果你看到驱动版本还在 550 或者更老那必须先升级驱动否则后面都会被“no kernel image”卡住。驱动确认之后还要检查一下 GPU 是否真的被系统识别到nvidia-smi重点关注GPU 型号显示为 NVIDIA GeForce RTX 5090显存显示为 32GB注意 5090 是 32GB GDDR7比 4090 的 24GB 大了不少这对跑大模型很关键驱动版本不低于 570如果是刚装好驱动建议重启一次系统确保驱动模块完全加载。有时候不重启nvidia-smi能显示但 CUDA 程序会诡异报错这种问题排查起来很浪费时间。2.2 创建 Python 环境与安装 PyTorch驱动准备好之后接下来是 Python 环境。我推荐用 conda 或 venv 创建独立环境避免把系统 Python 搞乱。我的操作是conda create -n llm python3.11 -y conda activate llmPython 版本我用的是 3.11这是因为 PyTorch 对 3.11 的支持最成熟而且 FlashAttention 编译时的兼容性也最好。3.12 和 3.13 不是不行只是可能遇到一些第三方依赖还没适配的情况。接下来安装 PyTorch。这一步非常关键一定要安装带 CUDA 12.8 支持的版本。我当时用的命令是pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128如果你直接pip install torch默认安装的很可能是 CPU 版本或者是不带 Blackwell 支持的 CUDA 版本那样后面就白折腾了。装完之后必须立刻验证import torch print(torch.__version__) print(torch.version.cuda) print(torch.cuda.is_available()) print(torch.cuda.get_device_capability(0))我当时看到(12, 0)这个输出时心里才踏实了一半。get_device_capability返回(12, 0)意味着 PyTorch 确实把这块卡识别成了sm_120设备。如果你这里返回的不是(12, 0)或者直接False那说明 PyTorch 版本不对停下来重新装不要继续往下走。注意get_device_capability返回(12, 0)不代表所有组件都能用。这只是 PyTorch 层面识别到了 GPU真正跑模型时用的 FlashAttention、vLLM 里的 kernel 是另外编译的它们同样需要支持sm_120。2.3 从源码编译 FlashAttention 的完整流程FlashAttention 是这次配置里最折腾的一步也是收获最大的一步。很多大模型的前向推理和训练都会用到它尤其是长上下文场景有没有 FlashAttention速度和显存占用完全是两个量级。先说为什么需要从源码编译。FlashAttention 的 PyPI 预编译包长期以来只覆盖主流的 CUDA 版本和 GPU 架构对于刚发布的新卡预编译包往往还没有跟上。我当时在 RTX 5090 上直接pip install flash-attn装是装上了但一调用就报错错误信息大概是“no kernel image available”或者直接段错误。所以只能老老实实从源码编译。编译前先安装 CUDA Toolkit。如果你只是想编译 FlashAttention不一定要装完整的 NVIDIA 官方 CUDA Toolkit但 nvcc 编译器必须有。我建议直接用 conda 安装conda install -c nvidia cuda-toolkit12.8这里有个坑conda 安装的 cuda-toolkit 和系统级的 CUDA 可能会冲突所以最好在激活的 conda 环境里先确认 nvcc 的版本nvcc --version输出应该是 12.8 或更高。如果显示的还是老版本或者提示找不到 nvcc需要检查环境变量CUDA_HOME和PATH。编译 FlashAttention 前还需要设置一个关键环境变量告诉它目标 GPU 架构export TORCH_CUDA_ARCH_LIST12.0PTX这个变量的含义是为sm_120生成 SASS 代码同时生成 PTX 代码做向前兼容。加PTX的好处是未来如果驱动更新支持了更多特性PTX 可以即时编译成更优的 SASS不用重新编译。然后开始拉代码编译git clone https://github.com/Dao-AILab/flash-attention.git cd flash-attention git checkout v2.7.3 # 选择支持 Blackwell 的版本 pip install -e .这里要注意几点GCC 版本不能太老建议 GCC 11 或 12。太老的 GCC 在处理新版 CUDA 的某些特性时会报错编译时间比较长大概要 20-40 分钟取决于机器性能如果编译中途报显存不足OOM可以降低编译并行度编译成功的标志是最后没有红色错误信息并且能正常import flash_attnimport flash_attn print(flash_attn.__version__) print(flash_attn.__file__)如果能正常输出说明 FlashAttention 已经编译成了支持sm_120的版本。我还建议跑一下自带测试来进一步确认python -m py_compile $(python -c import flash_attn; print(flash_attn.__file__))其实更直接的办法是跑一个真实的 attention 计算来验证结果是否正确。我当时用两个随机的张量做 scale-dot-product attention对比 FlashAttention 和普通 attention 的输出确认数值在误差范围内一致才算真正放心。3. 跑通大模型从 transformers 到 vLLM3.1 用 transformers 验证 FlashAttention 生效环境配好之后就该让大模型真正跑起来了。我选的第一个模型是 Qwen2.5-7B-Instruct因为 7B 模型在 32GB 显存下跑起来非常宽裕而且 Qwen 系列的中文能力很好适合本地部署验证。用 transformers 加载模型时可以显式指定 FlashAttentionfrom transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, attn_implementationflash_attention_2, device_mapcuda ) tokenizer AutoTokenizer.from_pretrained(model_name)这里的关键参数是attn_implementationflash_attention_2它会让模型内部的 attention 层使用 FlashAttention 的 kernel。如果 FlashAttention 装得有问题这一步就会直接报错如果一切正常加载完成后就能看到显存被占用了大概 15-16GB这是 7B 模型在 bf16 精度下的正常水平。然后测试推理messages [{role: user, content: RTX 5090 的 sm_120 计算能力有什么特点}] text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer(text, return_tensorspt).to(cuda) outputs model.generate(**inputs, max_new_tokens256) print(tokenizer.decode(outputs[0]))跑通之后我对比了开不开 FlashAttention 的差异。在 7B 模型、2048 token 上下文、生成长度 256 的设置下开启 FlashAttention 后生成长度 256 大约需要 6-8 秒不开则要慢 30%-50%而且长上下文下的显存占用差距更大。FlashAttention 的核心优势是内存效率和计算效率双重优化在大模型推理和训练场景下收益非常明显。指定torch_dtypetorch.bfloat16也很重要。Blackwell 架构对 bf16 的支持非常完善相比 fp16 在数值稳定性上更好而且速度也不慢。如果你在 5090 上用 fp32 加载 7B 模型显存直接翻倍完全没有必要。3.2 用 vLLM 做更高吞吐的部署如果只是单次推理验证transformers 就够用了。但如果你想把这个模型当服务用或者想同时处理多个并发请求就需要上 vLLM。vLLM 有非常成熟的 PagedAttention 和 continuous batching 机制吞吐量比 transformers 高一个数量级。vLLM 的版本选择很重要。老版本的 vLLM 不认识sm_120装了也是白装。我当时用的是 0.8.5这个版本已经能比较好地支持 Blackwell 架构。安装pip install vllm启动服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --dtype bfloat16这里解释一下参数--tensor-parallel-size 1单卡部署不用张量并行--gpu-memory-utilization 0.9允许 vLLM 占用 90% 的显存--max-model-len 32768最大上下文长度设为 32K--dtype bfloat16用 bf16 加载模型启动成功的标志是日志里能看到 GPU 显存信息并且没有报错。之后就能用标准的 OpenAI API 格式来请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好介绍一下你自己}], max_tokens: 256 }5120 个 token 的并发压力测试下vLLM 的吞吐量大概能达到每秒 1000 token这个表现已经能和不少云服务比肩了32GB 显存跑 7B 模型非常富余。实测下来单张 5090 跑 7B 模型、32K 上下文显存大概吃 18-20GB剩下的空间足够给 KV cache 分配多路并发毫无压力。如果你想挑战更大的模型比如 32B 甚至 70B在 32GB 显存下就需要上量化了。常见方案是 AWQ 或 GPTQ 量化4bit 精度下 32B 模型大约占 16-18GB 显存也能流畅跑起来。不过量化之后模型质量会有小幅下降需要根据实际场景权衡。4. 常见问题与排查技巧实录4.1 报错信息速查表我把这次配置过程中遇到的所有报错和排查方法整理成了表格方便大家直接搜索对照报错信息可能原因解决办法CUDA error: no kernel image is availablePyTorch 或 CUDA 版本太老不认识 sm_120升级到 PyTorch 2.7cu128、CUDA 12.8flash_attn 导入成功但调用时报段错误FlashAttention 不支持 sm_120用TORCH_CUDA_ARCH_LIST12.0PTX从源码重新编译编译 FlashAttention 时报 GCC 版本错误GCC 太老安装 GCC 11 或 12RuntimeError: CUDA out of memory模型太大或上下文太长降低max-model-len开启量化或换更小的模型vLLM 启动时报 “Unsupported GPU”vLLM 版本太老升级到 vLLM 0.8.x 或更高torch.cuda.get_device_capability返回(0, 0)驱动没装好或 PyTorch 版本不对重新安装匹配的驱动和 PyTorch4.2 最容易踩的 5 个坑第一个坑是忽略 GCC 版本。我当时编译 FlashAttention 时用系统自带的 GCC 9编译到一半直接报错信息是关于 CUDA 特性和编译器不兼容。后来装了 GCC 12才顺利编过。建议编译前先检查一下 GCC 版本不够就直接升级别浪费时间试旧版本。第二个坑是TORCH_CUDA_ARCH_LIST设置方式不对。有些人图省事写的是12.0没有加PTX。这样也能编过但只生成 SASS 代码兼容性差一些。加上PTX之后如果未来驱动更新PTX 还能重新 JIT 编译成更优的 SASS不会浪费新卡的潜力。第三个坑是用 pip 直接装预编译版 FlashAttention 后以为成功了。pip install flash-attn装的是最新 release 的预编译包理论上预编译包会包含主流架构但新卡的架构往往不在其中。当时我验证发现 import 不报错但一调用就段错误白白排查了很久。所以对于新卡不要相信 pip 能直接装从源码编译最稳妥。第四个坑是下载模型权重时网络不稳定。Hugging Face 直接下载经常断流大文件重下很痛苦。我当时用环境变量切到了国内镜像站或者直接用 ModelScope 下载速度快很多。具体的做法是# 方法一设置 HF 镜像 export HF_ENDPOINThttps://hf-mirror.com # 方法二用 ModelScope from modelscope import snapshot_download snapshot_download(Qwen/Qwen2.5-7B-Instruct)第五个坑是跑大模型时没设好模型路径导致一次性把权重全部加载到内存再拷到显存速度很慢。用 transformers 时指定device_mapcuda或者device_mapauto可以避免这个问题模型会按层分配到显存和内存中加载速度会有明显提升。4.3 显存优化的小技巧RTX 5090 有 32GB 显存这个容量对大多数开源模型来说已经相当宽裕了但也不是无限大。跑 32B 模型、长上下文时还是需要精打细算。有几个实用技巧尽量用bfloat16而不是float16两者占用一样但 bf16 数值更稳定Blackwell 对 bf16 的支持更好用gradient_checkpointing可以在训练/微调时大幅降低显存代价是变慢推理场景下用 KV cache 量化比如 KV cache 用 8bit可以节省不少显存对长上下文效果显著考虑用FlashAttention的window_size参数做滑窗注意力可以控制 KV cache 大小特别适合超长上下文的场景如果想在 32GB 显存上跑更大的模型可以用 AWQ 或 GPTQ 量化。就我实测来看4bit 量化的 32B 模型在多轮对话的流畅度上和原模型差距并不明显但显存占用只有原来的不到一半。这个方案非常适合本地部署场景。5. 跑通之后还能做什么环境配好、模型跑通之后能做的事情就很多了。如果你对微调感兴趣可以试试用 LLaMA-Factory 这类工具在 5090 上做 LoRA 微调。32GB 显存做 7B 模型的 LoRA 微调完全够用甚至 32B 模型的 QLoRA 也能跑。Blackwell 架构的 FP8 能力在训练场景下也有收益只是相关支持还在持续完善中。如果你有编程需求可以部署 CodeQwen 或者 DeepSeek-Coder 这类代码模型配合 Continue 或 Cline 这类 IDE 插件用本地 API写代码时的补全和问答响应速度非常快还不用担心代码上传到第三方服务。多模态方向也可以尝试比如 Qwen2-VL 系列或者用更轻量的多模态模型接入家庭服务器。5090 的 32GB 显存对这些任务来说都是很好的起步配置。我个人比较推荐的做法是先用 transformers 跑通一个 7B 模型做功能验证然后用 vLLM 部署成服务最后按需求再加 LoRA 微调或换更大的模型。这个路径最平滑每个阶段的成果都能快速用起来不会在配置环境上反复折腾。如果你也刚拿到 RTX 5090 正准备部署大模型建议按照这篇文章的顺序来配置环境。核心就一句话驱动上 570、CUDA 上 12.8、PyTorch 上 2.7、FlashAttention 源码编译加TORCH_CUDA_ARCH_LIST12.0PTXvLLM 最低 0.8。这几件事做对了后面就顺了。
返回列表