显卡报错怎么解决

本地跑模型最烦的不是跑得慢，是刚加载就一片红字：显存不足、驱动版本不匹配、算力架构不支持。这篇不解释显卡原理，只给你一套排查顺序：先分清是哪一类报错，再决定是降参数、换量化还是动驱动，最后给出「哪些情况别硬修、直接换方案」的判断线。

本地跑模型最烦的不是跑得慢，是刚加载就一片红字。有人第一反应是重装驱动，结果折腾一晚上，问题还在原地。其实显卡报错大致就三类：装不下、对不上、跑不动。三类的解法完全不同，混着修只会越修越乱。这篇不解释显卡原理，只给一套务实顺序：先分清是哪一类，再决定是降参数、换量化还是动版本，最后告诉你哪几种情况别硬修。

下面按「读报错 → 算显存 → 对版本 → 排查与停手」四步走。每一步只改一个变量，改完立刻用最小输入复测。你不需要一次记全，遇到报错时对着找就行。

先分清是哪一类报错，别一上来就重装驱动

把报错归到三类，是整套流程的地基。装不下指显存或内存不足；对不上指驱动、运行时版本或算力架构不匹配；跑不动指设备丢失、驱动停止响应、内核崩溃这类硬件或压力问题。归类错了，后面每一步都是白费。

装不下

报错里常见「无法分配」「out of memory」，发生在加载权重或开长上下文时

对不上

报错里常见找不到某个运行库、版本低于要求、算力架构不支持

跑不动

报错里常见设备未找到、驱动停止响应、跑到中途突然断掉

• 看它发生在哪一步：拉权重时炸、加载进显存时炸、还是跑到第几轮才炸；前两步多是容量和版本，第三步多是散热、功耗或并发
• 把报错全量复制下来再搜，别只截最后一行；最后一行往往是上层框架包装过的提示，真正原因在前面几行
• 记录当前配置：模型规格、量化精度、上下文长度、并发数、系统内存；没有这份底稿，后面没法判断改动有没有生效
• 别一上来就重装驱动：重装会清掉环境，反而让你分不清是原问题还是新装坏

显存类报错：先算账，再降配，最后才考虑换卡

显存不是只装模型权重。权重、上下文缓存、并发批次三段都要占，很多人只按权重选卡，上下文一开长就炸。先按这三段各估一遍，可以用站内 /models/deploy 的部署测算对一遍口径，看看自己漏算了哪一段。

降配顺序建议：先降并发与批大小，再缩上下文长度，再换量化精度，最后才缩模型规格。这个顺序对回答质量的影响是递增的，别一上来就换小模型。量化也不是免费的，低比特省显存，但长输出和结构化输出场景的稳定性会掉，要单独验一遍再决定。

驱动与运行时版本对不上：按依赖链从上往下对齐

依赖链是「显卡驱动 → 运行时 → 推理框架 → 框架对应的预编译包」。通常要按现有驱动能支持的最高运行时版本往上倒推，而不是反过来先装最新。不确定就先跑一条自检命令看当前版本，再拿框架安装说明里的版本要求对照。

nvidia-smi  # 看驱动版本与当前可支持的最高运行时版本
python -c "import torch; print(torch.__version__, torch.version.cuda)"  # 看框架与它编译时用的运行时

• 对不上时，优先换框架版本，而不是硬升驱动，尤其是有多套环境共存的机器
• 容器里跑的话，宿主机与容器内的运行时版本要一起看，只对齐一边是最常见的白忙一场
• 「算力架构不支持」容易被误判成显存问题：老卡跑新精度、新卡跑老预编译包都可能触发，报错文案常和内核启动失败混在一起
• 版本号具体要求别凭记忆，到 /models/deploy 核对当时的框架与运行时对应关系

一套可执行的排查顺序，和三条该停手的判断线

1. 记录完整报错全量复制，标出发生阶段，写下当前配置底稿
2. 确认发生阶段拉权重、进显存、还是跑了几轮才炸，判断属于哪一类
3. 算显存账按权重、上下文、并发三段估一遍，找出最吃紧的一段
4. 单项降配复测先降并发与批大小，每次只改一个变量，用最短输入复测
5. 再动版本降配无效且指向版本问题时，按依赖链从上往下对齐
6. 加回真实负载先用单并发固定上下文跑稳，再逐步加回真实请求量

三条该停手的线。其一，同一台机器反复出现设备丢失或驱动崩溃，先按硬件与散热排查，别继续在软件层试。其二，业务对延迟和稳定性有硬要求，而本地只能靠极限降配勉强跑通，这种情况下把推理放到官方 API 或租卡上更省事，判断口径可到 /official-api 和 /compute/gpu-rental 对比。其三，本地只是为了试模型能力，不值得为跑通一个模型折腾两天环境，直接换托管推理更划算。

报错先归类再动手：装不下降配，对不上换版本，跑不动查硬件——三类混修，只会把问题埋得更深。

如果你分不清「慢」和「报错」是不是同一回事，想先量一下本机与外部接口的延迟差异，可以用 /tools/speed-test 建个基线。有基线之后，很多「跑不动」的抱怨能立刻定位成性能问题还是稳定性问题。