为什么本地部署大模型输出特别慢？GPU显存卸载与 Token 生成速度优化

模型已经跑起来了，但吐字像挤牙膏：一句回答要等半天，长文更是没法用。这时候最容易乱调参数，越调越慢。这篇不讲怎么选卡、怎么挑模型，只解决「已经在跑、但嫌慢」这一件事：先分清是显存不够导致的卸载还是算力不够，再按顺序一项项排，最后给一套能反复用的验收方法。

模型已经跑起来了，但吐字像挤牙膏：一句回答要等半天，长文更是没法用。这时候最容易乱调参数，越调越慢。这篇不讲怎么选卡、怎么挑模型，只解决「已经在跑、但嫌慢」这一件事：先分清是显存不够导致的卸载还是算力不够，再按顺序一项项排，最后给一套能反复用的验收方法。

先说结论：本地推理慢只有两大类原因，一是显存装不下、被迫把权重丢到内存或硬盘上，二是卡本身算力就到顶了。前者是设置问题，能救；后者是硬件门槛，只能降档。搞混这两类，你会把大量时间花在改根本没用的参数上。

先分清卡在哪：是显存不够，还是算力不够

打开任务管理器或 nvidia-smi，同时盯两个数就够了：显存占用率，和生成时的 GPU 利用率。显存顶格、利用率却上不去，八成是卸载在拖后腿；显存没占满、利用率一直贴着高位，那就是纯算力问题，调参数基本无效。

还要区分「首字慢」和「吐字慢」。首字慢偏输入处理和模型加载，吐字慢偏解码速度，两者解法完全不同。别指望一个参数同时治好两个症状，先判断你的抱怨具体是哪一个。

1. 量一条基线固定同一段提示词，用站内 /tools/speed-test 跑一次，记下首字延迟和吐字速度两个数。后面每次改动都拿它对比，别靠感觉。
2. 盯两个数生成过程中看显存占用和 GPU 利用率，判断属于卸载瓶颈还是算力瓶颈。
3. 做减法先砍上下文长度和并发数，再考虑降量化档。顺序错了会白忙活。

显存卸载怎么设：留多少在卡上，留多少给内存

卸载的核心取舍很简单：放在显卡上的层越多越快，放不下的层丢给内存或硬盘就越慢。所以它不是「越多越好」，而是「刚好不爆」最好。留一点显存余量给上下文和临时张量，比把显存填满更稳。

层卸载

把部分模型层留在显卡、其余放内存，逐层调度，通常还能用于交互式对话。

整模型卸载

权重几乎全在内存或硬盘，每次推理都要搬运，基本没法用于实时对话。

上下文抢占

上下文长度、并发数、批大小和模型权重抢同一块显存，单独调到刚好会在长对话时崩。

内存交换

内存不够时系统把数据写到硬盘，速度断崖式下跌，比卸载本身更致命。

判断标准很直接：如果卸载层数已经很少、显存仍然吃紧，问题多半不在卸载设置，而是上下文或并发开太大。先把并发降到 1、上下文砍到能覆盖你真实对话的长度，再看显存是否松动。

• 先查是逐层卸载还是整模型卸载，后者基本没法用于交互式对话
• 把上下文长度、并发数、批大小一起算进显存预算，别只盯模型权重
• 留出一定显存余量，避免长对话时突然爆显存
• 内存本身不宽裕时，卸载到内存只会更慢，优先减上下文而不是加卸载

真正能提速的几根杠杆，按性价比排序

按性价比从高到低排，大致是这个顺序：换更低的量化档位、缩短上下文、降低并发、换更快的推理后端或开启批处理。前两项当天就能见效，后两项要看你的部署方式支不支持。

上下文是最容易被忽略的一项。聊天越久越慢，往往不是卡的问题，是每轮都要重算一长串历史。定期新开会话、只带必要的历史，效果立竿见影。

量化档位怎么挑，别只信别人嘴里的经验，到站内 /models/deploy 的部署测算看你这张卡对应的档位建议，再结合自己的质量要求定。

改完怎么验收：三次对照，别改一堆再一起看

调优最忌讳一次改五个参数，然后凭感觉说「好像快了」。正确做法是固定同一段提示词，一次只动一个变量，跑三遍取稳定值，记录首字延迟和吐字速度两个数。

1. 固定变量同一段提示词、同一会话状态、同一时间段，排除后台任务干扰。
2. 跑三遍取稳定值单次结果波动大，三遍都稳定才能下结论。用站内 /tools/speed-test 的基线做前后对比。
3. 记录下来的设置量化档、上下文上限、并发数、卸载层数，写成一个固定组合，下次换模型或升级驱动时直接复用。
4. 回到基线复查每改一项就回到基线重测，确认这一项真的有效再改下一项。

调完之后，把稳定组合记下来，比记住任何单一参数都值钱。下次换模型或者升级驱动，直接拿这套配置重跑一遍基线，就能快速判断是环境变了还是设置被覆盖了。