很多人第一次在本地把大模型跑起来的时候兴奋感其实撑不了太久。模型确实加载出来了对话也能跑但每回答一个问题屏幕上的字是一个一个往外蹦等得人心烦。我最早在某台老游戏本上跑一个7B模型生成一段两百字的回答能等上一分多钟那种体验基本没法用。后来我做了三件事把Ollama默认参数调了一遍、把模型从FP16量化到4bit、又把上下文长度从32K砍到了8K速度直接翻了两三倍。也就是说本地部署AI慢这件事很多时候并不是“电脑不行”而是硬件和软件根本没对齐。本地部署AIOllama、LM Studio、Dify这类方案这几年越来越火核心卖点就是隐私在自己手里、不按调用量付费、可以随意折腾。但生成速度比云端慢是几乎每个人都会碰到的第一道坎。这篇文章就围绕本地部署AI的推理速度从硬件瓶颈和软件优化两个方向把“为什么慢”和“怎么变快”讲透。不管你手里是老台式机、游戏本、MiniPC还是工作站都可以按这里的思路去定位问题。1. 先搞清楚瓶颈在哪AI推理到底在做什么1.1 生成一个token的过程预填充和解码大模型生成文本本质上是一次次“猜下一个词”。但每个词的生成过程并不像看起来那么简单里面包含两个特点完全不同的阶段理解这两个阶段是后面所有优化动作的基础。第一阶段叫预填充Prefill。输入那段提示词之后模型需要把整段文字一次性读完做完整的矩阵运算把每个词的位置信息、语义关系都算出来。这个阶段的特点是单次计算量非常大所以对算力也就是FLOPS非常敏感。通俗点说预填充像“备课”学生要把整道题先完整读一遍、想清楚思路才真正开始动笔。第二阶段叫解码Decode。模型每生成一个词都要把当前已经算好的“理解结果”再推理一遍每次只产生一个词然后把这个词拼回去再算下一个。这个阶段的特点是单步计算量不大但每一步都需要把模型全部参数从显存里读一遍。所以它最吃的是显存带宽也就是每秒钟能从显存里搬运多少数据。这就是为什么很多人跑本地模型时会发现从输入问题到出现第一个字往往要等很久但后面一个字一个字往外蹦的速度也没快到哪去。前者就是预填充在占用时间后者则是解码阶段被带宽卡住了。对症下药之前先搞清楚自己到底卡在哪一阶段非常重要。预填充慢优先看算力解码慢优先看带宽和量化策略。1.2 三个硬指标算力、显存带宽、显存容量讨论本地部署AI的硬件时绕不开三个数字。很多人只看“显卡有多少G显存”这是最大的误区。真正决定推理体验的是这三者的配合。算力FLOPS决定了模型算得有多快。同代显卡里核心越多、频率越高算力越强预填充阶段就越快。但这不代表解码也快因为解码阶段算力往往用不满。显存带宽GB/s决定了参数能搬得多快。每次生成一个token都要把模型全部权重从显存读一遍所以带宽越高每秒生成的token数就越多。这是影响“一个字一个字往外蹦”速度的核心指标。显存容量GB决定了能放下多大模型。模型本身占空间KV Cache也占空间容量不够就直接加载失败或中途OOM。容量更多是准入门槛不是速度指标。用一张表来看比较直观指标主要影响通俗类比典型参考值算力 TFLOPS预填充速度、长文档处理做题速度约80到100 TFLOPS中高端卡FP16显存带宽 GB/s解码速度、每秒生成词数翻书速度约300到1000 GB/s显存容量 GB能跑的模型规模书桌大小8GB起步24GB舒适这三个指标通常不是独立变化的。比如某些游戏本上的显卡核心算力看起来不差但显存带宽被砍得很严重跑解码速度就会明显拖后腿。反过来一些专业卡显存特别大带宽和算力却一般跑大批量并发合适跑单用户交互式生成反而不一定占优。1.3 参数规模、量化精度与速度的关系我们常说的“7B模型”B是Billion也就是十亿参数。7B代表约70亿个参数。模型每生成一个token大约需要做“2 × 参数量”次浮点运算所以7B模型生成一个token粗算至少要140亿次浮点运算。这个量级并不低。参数在内存或显存里怎么存储同样影响巨大。FP16格式每个参数占2字节FP32占4字节8bit量化后每个参数只要1字节4bit量化后只要0.5字节。量化直接决定了同样数量的参数要占多大空间、每次读取要消耗多少带宽。把模型从FP16换成4bit读取同样参数量的带宽压力直接降为四分之一这就是量化能在很多机器上让速度翻倍的底层原因。这里多提一句很多人以为量化是“牺牲质量换速度”其实在Q4_K_M这种成熟量化方案下大部分任务的质量损失非常小。本地部署时优先选择量化模型是性价比最高的提速手段第三章我会专门展开讲怎么选、怎么用。2. 硬件优化把钱花在刀刃上2.1 CPU和核显能不能跑能跑但别对速度有错觉先说结论如果只是偶尔玩一玩3B、7B这种规模的小模型CPU加核显不是不能跑只是要把预期放低。CPU推理和GPU推理的最大差异在内存带宽。普通双通道DDR4内存带宽只有50GB/s左右而一张中端显卡的显存带宽动辄300到500GB/s差距是数量级的。由于解码阶段每一步都要读取全部参数CPU推理的速度几乎被内存带宽死死压住。我试过在一台很老的台式机上用CPU跑7B模型量化到Q4_K_M之后大概每秒只能出2到4个token稍微把上下文调长一点就开始卡顿。但换个思路如果目标是跑1.5B、3B的小模型CPU反而有优势稳定、不需要独立显卡、内存便宜长凭运行也不怕过热降频。核显则是另一个完全不同的场景。核显通常会借用系统内存当显存速度受制于内存频率和共享带宽跑大模型只能算“能亮”谈不上“能用”。如果你是想认真做本地部署至少准备一张独立显卡是更现实的路。2.2 显存容量怎么算模型、KV Cache和运行时开销显存里要装下的东西不只是模型文件本身那么简单。很多人问过“模型文件才4GB为什么我12GB显存还是爆”答案就藏在KV Cache和运行时开销里。一个7B模型如果以Q4_K_M格式加载权重文件大约4.1到4.7GB。但推理过程中模型会把输入和已生成的文本逐步加工成一种叫KV Cache的中间结构它的大小和上下文长度强相关。上下文越长KV Cache越大。以7B模型为例把上下文长度开到32KKV Cache可能要到2GB以上。再加上计算图、CUDA上下文、并行调度等还要额外占几百MB到1GB。所以评估显存需求可以用这个粗算公式模型权重参数量 × 每个参数字节数 × 1.1冗余开销KV Cache按上下文长度预估一般留1到4GB运行时环境至少预留1GB以7B模型Q4量化为例推理时最少需要大约6到8GB显存12GB会更舒服。14B模型Q4权重约9GB实际推理可能要14到16GB显存。参数量上去之后显存需求是加速上升的这也是为什么本地部署里“显存容量”往往是最先卡脖子的硬指标。2.3 选卡的核心逻辑先看带宽再看容量聊到这里选显卡的思路就很清晰了。如果主要跑大模型显存带宽和技术代际比单纯的核心算力更值得关注。并不是说算力不重要而是在解码阶段带宽才是最常见的短板。举几个例子。RTX 3090有24GB显存带宽约936GB/s二手市场性价比很高跑13B、14B模型很舒服。RTX 4090带宽约1008GB/s算力也强是折腾本地大模型的水桶卡。反过来看一些16GB显存的显卡如果位宽被砍到128bit带宽只有200多GB/s跑大模型解码的速度就会明显拖后腿。如果预算有限又想上大显存可以关注老一代专业卡、游戏卡的二手市场但要注意功耗、散热和驱动支持。另一个值得提的方案是Apple Silicon。M系列芯片采用统一内存架构CPU和GPU共享内存显存容量等于内存容量带宽也很高。M2 Pro/Max级别的机器跑14B模型体验比很多同价位Windows PC更好这也是不少人选Mac做本地部署的原因。最后补一句如果日常只跑1.5B、3B这类小模型中低端卡完全够用没必要为了“账面好看”买高配卡。先确定目标模型规模再反推显存和带宽需求钱才花得准。2.4 内存与SSD两个容易被忽略的隐形瓶颈显卡之外系统内存和硬盘速度也在偷偷影响体验。先讲内存。当模型太大放不进显存时Ollama这类框架会自动把一部分层放到内存里用CPU计算这时系统内存的带宽和容量就直接影响速度。单通道内存比双通道内存带宽少一半CPU推理速度几乎减半。内存不够还会触发swap也就是把数据倒腾到硬盘上一swap就基本卡死。所以玩本地部署内存尽量双通道容量至少16GB32GB更稳。再讲SSD。每次启动模型框架都要把权重文件从硬盘加载到内存或显存模型越大加载越久。用SATA SSD加载一个大模型可能要几十秒NVMe SSD可以把时间压缩到十几秒甚至几秒。生成过程中的历史记录、知识库检索也会持续读写硬盘NVMe的优势更明显。我自己习惯把模型文件放在单独的NVMe盘系统盘和模型盘分开。这样既不会因为模型占用拖慢系统也方便在几台机器之间同步同一个模型目录排查问题时非常省事。3. 软件优化不额外花一分钱的提速方案3.1 量化成本最低、见效最快的提速手段硬件一时半会换不了但软件层面有一个极速方案量化。思路很简单把模型参数从FP16的2字节压缩到8bit的1字节或4bit的0.5字节用一点点精度换大幅度的显存和带宽释放。最常见的量化格式有Q8_0、Q5_K_M、Q4_K_M等。Q4_K_M是社区公认的质量和体积平衡点绝大多数任务下和FP16版差异很小但显存占用降一大截解码速度提升明显。如果显存更紧张还可以选Q3_K_S、Q2_K但质量下降就比较明显实际使用中偶尔会“答非所问”。具体操作上Ollama可以直接在模型名称里带量化标签比如llama3:8b-instruct-q4_K_M就是4bit量化版。LM Studio的模型下载界面也会列出不同量化等级直接对比文件大小和参数说明再选择。一个更贴合场景的做法是结合任务选量化知识库问答、代码补全这类任务Q4_K_M足够创意写作、角色扮演这类对细节要求高的场景可以留在Q5_K_M或更高。不管选哪种量化带来的提速在带宽不足的机器上都非常直观这招不需要换任何硬件当场见效。3.2 Ollama与LM Studio的环境变量和运行参数Ollama虽然用起来简单但默认参数偏向兼容性不是为极限性能调的。想提速就得会用环境变量和运行参数。OLLAMA_GPU_LAYERS控制把模型的多少层放到GPU上跑。显存足够时可以全放GPU显存不够时也可以手动设置分层避免默认策略导致频繁拷贝。OLLAMA_NUM_PARALLEL控制同时处理几个请求默认是1也就是串行。如果同时开多个对话又不开并行后面的请求就会排队体感就是长时间转圈。但并行调高也会增加显存压力需要实测。OLLAMA_MAX_LOADED_MODELS控制同时加载几个模型默认策略有时候会把多个模型常驻显存导致新模型只能去内存里跑反而更慢建议按实际使用频率调低。在Windows上这些环境变量可以写进系统环境变量也可以用命令行临时设置。例如OLLAMA_GPU_LAYERS99 OLLAMA_NUM_PARALLEL4 ollama serveLM Studio则提供了图形化界面加载模型时右侧边栏可以调GPU Offload层数、Context Length、Batch Size等参数。关键提醒Context Length不要盲目开大默认8K很多时候已经够用开得越大KV Cache越膨胀速度反而下降。3.3 推理后端与框架选型llama.cpp、vLLM、llama-server外层框架决定你用什么样的命令或界面启动模型内层推理引擎才决定计算效率。llama.cpp是目前本地部署大模型的事实标准后端Ollama、LM Studio底层都直接或间接用到它。它在CPU和GPU混合推理时优化做得非常好是普通用户最稳妥的选择。对多数人来说不需要直接操作llama.cpp但知道它存在会帮助理解为什么不同工具调度模型时效率差距巨大。vLLM则是服务化部署场景的提速神器核心是PagedAttention和Continuous Batching。它把显存里的KV Cache按页管理并允许同一批请求连续计算而不是一个个排队。跑API服务、同时服务多个用户时vLLM能大幅提升吞吐量但配置门槛更高不适合纯本地方便环境。如果你想自己写代码调模型还可以试试llama-server。它支持精细调度选项比如指定线程数、批量大小、KV Cache量化。把KV Cache量化到8bit可以省不少显存长上下文场景下提速尤其明显。我的建议是先用默认配置让模型跑起来再考虑要不要深入调参不要一开始就钻进参数海洋。3.4 上下文长度、并行请求与吞吐量的平衡本地部署另一个常见误区是“上下文越长越好”。把上下文从8K开到32K表面上似乎能记住更多对话但KV Cache会同步膨胀显存占用上升生成速度下降。判断上下文长度够不够有个笨办法翻一下自己日常对话历史统计平均长度。如果大部分对话就在2K以内开8K上下文绰绰有余没必要为了极小概率的长文档场景牺牲日常速度。遇到真需要长上下文的场景可以单独用长上下文模型或者跑文档拆分检索而不是让所有会话都背着巨大上下文窗口。并行请求方面如果是本地一个人用默认串行反而稳定。如果是团队共用一台服务器并行参数就要按显存余量来压榨。并行越高总吞吐越高但单条回复的延迟也可能上升。延迟和吞吐本来就是跷跷板优化时想清楚自己到底要哪一头。4. 实测数据不同配置能跑到什么速度4.1 常见硬件跑主流模型的token/s参考没有万能的速度表因为不同版本、不同量化、不同上下文下差异很大。下面给的是我在多台机器上实际跑过、以及社区里比较常见的数据单位是token/s也就是每秒生成的词数。数值仅供选型参考不代表所有场景。设备模型规模量化实测速度参考RTX 4090 24GB7BQ4_K_M约90到120 token/sRTX 3090 24GB7BQ4_K_M约60到80 token/sRTX 4070 Ti 12GB7BQ4_K_M约50到70 token/sM2 Pro 32G统一内存7BQ4_K_M约50到70 token/s老台式机 CPU7BQ4_K_M约2到5 token/s注意一个现象中高端显卡跑7B模型速度很容易过百token/s但一换到14B、32B模型速度会明显下降。原因不复杂解码阶段每次要读全部参数参数翻倍相同带宽下的速度就接近减半。所以评估体验时一定要把模型规模绑在一起说脱离模型谈速度没有意义。4.2 同样一台机器优化前后能差多少讲一个我自己的真实例子。有段时间我在一台16GB显存的机器上跑13B模型最开始直接用Ollama默认参数模型是原版非量化的FP16版本速度只有8到10 token/s。体感就是明显卡顿一个长回答要等很久。之后我做了三步优化把模型换成Q4_K_M量化版显存占用从约26GB降到约9GB速度直接到20多token/s手动设置只加载一个模型把KV Cache调成8bit量化长上下文场景下又稳定提升了10%到15%关掉不必要的后台程序避免GPU和内存被争抢。优化完成后同一台机器跑13B模型稳定在25到30 token/s生成质量几乎没变化。这个例子说明不要一觉得慢就盯上新显卡先学会把手里硬件的能力释放出来。4.3 判断自己到底卡在哪三分钟定位瓶颈不知道怎么优化先定位瓶颈。最实用的方法是打开任务管理器或系统监控把GPU利用率、显存占用、内存占用、SSD活动这四项同时显示出来然后跑一次完整的问答。几种典型情况GPU利用率一直很高但速度没有明显提升说明模型计算量偏大优先考虑缩小模型规模或缩短上下文。GPU利用率很低但显存占用很高说明模型没有在GPU上全速跑可能部分层被放到CPU或者显存带宽已经到顶。显存占用没满但内存占用很高同时SSD活动频繁说明模型被部分换到了系统内存甚至硬盘这是最严重的降速场景优先清理内存占用。以上判断完全不需要额外工具系统自带监控就能完成。定位到现象之后回到本章对应的小节找优化手段会精准很多。5. 常见问题与排查技巧实录5.1 GPU占用率不高但还是慢明明显卡没在用全力生成速度却上不去通常有三个原因。第一模型没有完整offload到GPU。Ollama可以用ollama ps命令查看当前模型运行在什么设备上如果显示是CPU/GPU混合说明有一部分层在CPU上跑速度自然会受影响。调大OLLAMA_GPU_LAYERS或者更新显卡驱动后再试。第二解码阶段本来就是低算力高带宽需求。GPU算力再强如果显存带宽不够算力也喂不饱。这种情况换量化模型是性价比最高的手段读取同样参数量的带宽压力直接减半速度自然上来。第三上下文过长导致KV Cache反复读写。把Context Length从32K降到8K很多机器都能立刻感受到变快。5.2 显存没爆却报OOM这种情况很常见尤其是用着用着突然提示显存不足。原因大多出在并行请求开太多、多个模型同时加载、或者KV Cache预留不够。Ollama遇到OOM先执行ollama ps看看当前加载了什么再用ollama stop把不用的模型卸载。然后把OLLAMA_MAX_LOADED_MODELS设为1避免模型被常驻。如果是并行导致把OLLAMA_NUM_PARALLEL降回2或1。LM Studio里则直接设置同时加载模型数为1清空VRAM后再重新加载。还有一个容易忽略的细节Windows上即便模型不占显存浏览器等其他程序也可能占几百MB到1GB显存估算预留空间时要把这部分算进去。5.3 量化之后质量变差怎么平衡量化不是白捡的便宜压缩过头确实会让模型“变笨”。常见表现是输出开始重复、逻辑变弱、记不住细节。遇到这种情况不要一上来就退回FP16可以先试Q5_K_M或Q6_K它们比Q4只大一点点质量却明显更稳。另一个技巧是分任务看。比如模型在中文创意写作上变差但英文能力没受太大影响很可能是量化层级对中文token切分不够友好这时候可以换另一个量化版本试一下或者调整采样参数把温度调低、repeat_penalty调高有时候能弥补不少质量损失。如果对质量极其敏感又不想花太多时间调参那就退回FP16但把它放到更短的上下文里跑。很多情况下质量下降的真正原因并不是量化而是上下文太长导致注意力分散。5.4 多线程、双通道与多卡硬件的最后一点咀嚼空间CPU推理时llama.cpp等后端支持多线程。线程数不是越大越好建议设置在物理核心数附近。同时要确保内存是双通道单通道内存会让CPU推理速度直接减半这个收益比换CPU来得更快。多卡推理则是另一个话题。用多张显卡跑同一个模型时层会被切到不同卡上卡之间要通信速度受PCIe带宽限制。如果不是追求极限显存容量我更建议单卡跑中等规模模型而不是多卡硬拼大模型维护成本和实际提速往往不成正比。最后如果你用的是Windows建议把显卡驱动更新到较新版本同时确认电源计划不是省电模式。很多“突然变慢”的问题和驱动、电源策略关系很大先排除这些再考虑换硬件。我个人在实际折腾中的体会是本地部署AI的提速没有银弹但确有一条清晰的路径先量化再调上下文再调并行最后才考虑换卡。换硬件的前提是你已经通过监控工具确认瓶颈在硬件本身而不是软件没喂饱它。把这条路径走完大多数“慢”的问题都能在花很少钱甚至不花钱的情况下解决掉。希望这篇梳理能帮你少走点弯路。