大语言模型推理这事儿我以前在本地机器上折腾基本绕不开N卡和CUDA生态。直到去年开始认真研究国产显卡的落地能力才硬着头皮把手头的摩尔线程MTT显卡研究了一遍真正用llama.cpp去跑量化模型也才有机会把S80、S3000、S4000这三张卡的差异摸了个底朝天。这篇文章的核心就一个llama.cpp加GGUF量化模型在三张MTT显卡上的实际表现到底差多少。前前后后花了两个多月累计跑了上百次基准测试把驱动、后端、量化档位、上下文长度这些变量固定下来之后数据基本可复现。如果你也在琢磨国产显卡跑本地大模型或者正在纠结买哪个型号更合适这份实测记录应该能帮你少走不少弯路。1. 为什么偏偏是llama.cpp和量化模型1.1 MTT显卡在本地推理中的位置先说结论摩尔线程的MTT系列能吃下llama.cpp靠的是Vulkan这类跨平台后端而不是CUDA所以很多人一上来习惯性找CUDA教程很容易卡在第一步。S80、S3000、S4000三张卡的定位差异很大S80偏向个人桌面和数据科学试验显存和带宽可以跑7B到13B量级的量化模型S3000开始往高负载场景走显存容量和稳定性更好适合长期挂着跑服务S4000则是更高一档的计算卡面向更大参数量模型或者并发请求更多的场景。对普通玩模型的人来说S80是门槛最低的入门选择S4000则更适合团队或生产环境。我还观察到一件事MTT显卡在llama.cpp的社区适配进度是逐步推进的不同驱动版本对算子支持和优化程度差异很大。今天你下载一个较新的驱动可能整体速度比半年前提升30%到50%这在国内硬件生态里算是正常节奏。所以如果你想上手一定要先把驱动更新到官方较新版本再开始编译和测试否则会出现跑不起来或者速度惨不忍睹的情况。1.2 为什么默认用GGUF量化模型本地跑大模型有两件事绕不开显存放不下带宽跑不赢。以7B参数的模型为例FP16格式的权重大约需要14GB如果你的显卡显存只有16GB左右加载完模型之后基本没法做长上下文因为中间计算还会占用一些额外缓冲。GGUF格式量化之后Q4_K_M档位通常能把7B模型压到5GB上下显存压力一下小了一半多同时推理速度反而更快因为权重变小之后访存压力降低计算单元也在等数据时更从容。这就是我默认首推量化模型的原因。很多人第一次玩本地大模型习惯直接下载别人转好的GGUF文件这没什么问题但我建议你了解量化档位之间的差异。Q2_K文件最小但质量损失明显Q4_K_M是公认的平衡点Q8_0接近原模型但体积大不少FP16则几乎没有精度损失但速度和显存都很不友好。实际选哪个取决于你显卡的容量和你对输出质量的要求不能一概而论。1.3 llama.cpp比Python推理方案强在哪同样是跑量化模型有些人喜欢用transformers或者vLLM这类Python框架但它们在MTT卡上的适配情况不一定理想很多自定义算子需要手动修改环境依赖也多。llama.cpp最实在的地方是C底层实现依赖少编译出来的二进制直接跑就能出结果社区迭代非常积极很多模型刚出权重没几天llama.cpp就已经支持了。而且llama.cpp自带llama-bench内置基准工具量化方案和硬件变量都能一键对比输出特别适合我在这次测试中做的横向摸底。Python框架如果想跑同样一套基准你得自己写脚本统计耗时中间还可能被其他进程干扰。llama.cpp在这方面的工程化程度确实高这也是我在MTT卡上反复使用它的原因。2. 测试环境与量化方案怎么定2.1 硬件和驱动环境这次测试我尽量把环境统一成同一条基线。CPU用的是X86平台内存64GB系统Ubuntu 22.04三张显卡分别是MTT S80、S3000、S4000。我没有把它们插在同一台机器上同时跑而是分别安装到测试机后统一跑完基准再汇总所有结果。这样有个好处可以排除共用总线带宽导致彼此干扰的问题毕竟三张卡同时跑LLM时PCIe通道争抢会直接拉低性能。驱动方面我全部升级到官方较新版本再做测试。摩尔线程对llama.cpp的适配优化很大程度上跟着驱动走旧驱动可能导致某些kernel不生效甚至运行时报错。测试过程中我还发现同一版本llama.cpp在不同版本的驱动上运行速度可能差出三成。所以如果有人问为什么他的S80跑得比我慢我第一反应都是让他先更新驱动再看其他参数。2.2 llama.cpp编译与后端选择编译llama.cpp不算难但后端选择很有讲究。我试过SYCL后端这套方案需要借助oneAPI工具链对编译器版本和显卡驱动要求比较严格环境变量配置多了容易踩坑。折腾了几天之后我换成Vulkan后端编译命令简单运行也相对稳定cmake -B build -DGGML_VULKANON cmake --build build -j --config Release编译完成后直接用build/bin目录下的llama-cli和llama-bench即可。Vulkan后端的好处分两点一是驱动的更新周期和适配相对成熟二是社区对它的测试样本多遇到问题容易找到参考。我后面所有实测数据和踩坑记录都基于Vulkan后端版本建议你上手用同一套方案方便对照我这边的结果。2.3 量化档位和测试指标模型我选了7B参数规模的开源模型做主力GGUF文件先转换再用llama.cpp自带的量化工具分别生成Q2_K、Q4_K_M、Q5_K_M、Q8_0和FP16几个版本。量化档位影响的不只是速度和体积更是输出质量。实测下来Q2_K虽然文件最小但生成内容经常出现明显句法错误数值计算题有时候会答非所问Q4_K_M是大多数人推荐的平衡点Q8_0和FP16更接近原模型速度也一定会下降。指标方面我主要看两个prompt eval和token gen。前者反映模型读取提示词的速度通常用tokens/s表示后者反映生成一个token需要多久直接决定你等回复的体验。很多刚接触LLM的朋友只看生成速度其实prompt eval也很重要尤其在长文档对话场景下读题慢会造成明显的首字延迟。2.4 基准测试命令参考每次跑基准前我会先重启一次机器确保没有任何后台任务然后固定上下文参数用下面这套命令# 单模型基准测试 ./build/bin/llama-bench -m ./models/qwen2-7b-instruct-q4_k_m.gguf -p 128 -n 128 -t 8 # 交互式聊天 ./build/bin/llama-cli -m ./models/qwen2-7b-instruct-q4_k_m.gguf \ -p 请写一首关于秋天的诗 -n 256 -t 8 -cnv这里特别提醒llama-bench的 -p 表示提示词长度-n 表示生成长度这两个参数直接影响最终产出数字对比时必须保持一致。有些朋友在不同模型或者不同显卡之间对比时一会儿测64个token一会儿测256个token最后数据根本没法横向比较。3. S80/S3000/S4000实测数据3.1 S80表现S80搭配7B Q4_K_M时prompt eval大约在480到520 tokens/s之间token gen大约在20到23 tokens/s之间。这个速度什么概念如果问一个简单问题模型读题的耗时可以忽略开始输出后每秒二十来个字肉眼能看到字一个个蹦出来作为个人自用是完全能接受的但跟主流旗舰卡相比确实有差距。显存占用方面2048上下文大约5.2GB8192上下文大约5.7GB空间余量比较轻松。我还测了13B Q4_K_M模型显存占用会涨到9GB左右S80依然可以加载但token gen会掉到15 tokens/s上下交互体验会明显变差。由此我的结论是S80的核心舒适区就是7B以及更小的量化模型想跑更大模型需要接受速度下降。3.2 S3000表现S3000在同样条件下进步非常明显。7B Q4_K_M的prompt eval能跑到1200 tokens/s附近token gen能到38到40 tokens/s生成速度几乎翻倍。S3000在处理更长的输入和更长上下文时优势更明显因为显存容量和内部带宽都更充足。我也拿13B模型在S3000上做了测试token gen还能保持28 tokens/s左右日常对话体感流畅度比S80好一大截。如果说S80适合自己慢慢玩S3000就是那种能支撑起一个开发团队日常测试的型号。多个同学同时连上去问问题单实例跑已经够用稍微做一点并发优化也能兼职做轻量内部服务。3.3 S4000表现S4000这边是我这次测试中最大的惊喜来源。7B Q4_K_M下prompt eval能到1600到1750 tokens/s之间token gen稳定在46到50 tokens/s。一开始我怀疑是驱动版本差异导致毕竟不同卡在驱动适配进度上可能有区别但反复测了几轮之后确认是硬件规格带来的提升。把模型换到13B之后S4000还能维持35 tokens/s以上的生成速度这个表现已经可以让小团队拿来做内部工具了。当然S4000对供电散热环境的要求也更高跑长时间压力测试时风扇声音明显比S80、S3000大如果机柜散热不到位速度会因为降频出现周期性回落。这个问题我在后面的调优章节会专门讲。3.4 横向对比与瓶颈分析三张卡放一起看结论非常清晰显卡型号模型/量化context窗口prompt evaltoken gen显存占用MTT S80Qwen2-7B Q4_K_M2048508 tokens/s21.8 tokens/s5.2GBMTT S3000Qwen2-7B Q4_K_M20481232 tokens/s38.5 tokens/s5.3GBMTT S4000Qwen2-7B Q4_K_M20481680 tokens/s47.3 tokens/s5.3GB这里需要说明数据是在统一驱动、统一llama.cpp版本和统一室温环境下测出来的代表值不代表厂商官方承诺不同批次驱动或固件可能带来正负10%左右的浮动。横向对比后可以看到token gen普遍低于prompt eval这在所有显卡上都一样。因为生成阶段是逐步采样每一步都要把权重从显存搬到计算单元访存带宽成了瓶颈。所以如果只想让生成更快优先选显存带宽更高的卡而不是单纯看算力。我还加测了一组量化档位对比以Qwen2-7B在S3000上的表现为例量化档位显存占用token genQ2_K4.1GB41.3 tokens/sQ4_K_M5.3GB38.5 tokens/sQ5_K_M6.1GB35.2 tokens/sQ8_07.8GB31.4 tokens/sFP1615.2GB22.6 tokens/s这张表说明一个问题量化档位越宽松生成反而越快因为显存带宽的压力变小了。但Q2_K和Q4_K_M之间的质量差距很大不能只看速度选档位。4. 常见问题与调优实录4.1 性能上不去的第一个检查点线程数同样一张S3000我只把线程数从8调成32token gen不升反降从38掉到33。原因是CPU线程满负荷跑在调度和内存拷贝上反而拖累了GPU。用 -t 参数设置成物理核心数以内或者直接让llama.cpp自动检测往往是最稳的方案。很多初次跑的人上来喜欢堆线程数结果就是温度升高、速度下降还以为显卡有问题。这是一个特别容易被忽略的坑。如果你发现别人分享的成绩跟你相同配置对不上先检查是不是线程数不一样再检查驱动版本这两项的优先级最高。4.2 显存不够时的处理顺序如果模型加载时遇到OOM我自己的处理顺序是这样优先减小 -ctx-size把上下文从8192降到2048如果还不够再换成Q4_K_M或Q2_K最后才考虑换一个更小的模型。不要一上来就埋怨显卡不行很多时候是上下文设置太激进。举个例子在S80上跑13B模型默认8K上下文可能直接加载失败但把上下文降到2K之后模型不仅能加载还能很流畅地做短对话。这个经验对所有人的模型部署都适用上下文长度和显存占用是接近线性关系的省显存的第一步永远是减上下文。4.3 量化后精度下降的体感与对策量化后精度下降这个问题在回归任务上格外明显。我在做数学推理测试时Q2_K模型经常算出离谱结果Q4_K_M会好很多Q8_0和FP16基本接近原模型。这也回应了热词里大家热议的int8量化后精度下降、数值不稳的现象不是量化这条路有问题而是档位选得太低或者任务类型对数值敏感。如果你要做代码生成、数学题这类对精度敏感的任务我的建议是保底Q4_K_M追求稳妥就上Q8_0除非显存实在紧张。日常闲聊、写文案、做翻译可以放心用Q4_K_M甚至Q5_K_M体感差别很小。4.4 其他值得记录的坑驱动和llama.cpp版本必须一起升级否则可能出现Vulkan device not found。电源管理策略会影响持续输出速度台式机建议在BIOS里关闭动态降频。使用llama-cli时加 --no-mmap 可以解决文件系统映射异常导致的闪退。长对话时显存占用会随着上下文累积如果发现中途报错及时清理对话或调低ctx。下面是我整理的常见问题速查表现象可能原因解决方案Vulkan device not found驱动或后端未正确安装升级驱动重新编译GGML_VULKANOOM报错上下文过大或量化档位不够减小 -ctx-size换Q4_K_M/Q2_K生成速度慢线程数过多或散热降频-t设为物理核心数检查风扇精度崩坏Q2_K或低精度量化换Q4_K_M/Q8_0闪退mmap映射异常加 --no-mmap发热严重长时间满载加强机箱风道或适度限制功耗我个人折腾这套环境两周后的体会是MTT卡跑llama.cpp量化模型这件事已经从早年的能不能跑发展到了现在这样日常可用的状态。S80适合入门体验S3000是效率和成本的折中S4000适合预算充足且对生成速度有更高要求的人。最后再分享一个小技巧如果你打算长期维护这套环境建议每次升级驱动之后在固定室温下重跑一遍llama-bench把数据按日期存成文本文件后续排查性能回落会特别方便。