摩尔线程MTT显卡跑llama.cpp实测：S80/S3000/S4000量化性能对比

大语言模型推理这事儿，我以前在本地机器上折腾，基本绕不开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_VULKAN=ON 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.2GB，8192上下文大约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 横向对比与瓶颈分析

三张卡放一起看，结论非常清晰：

这里需要说明，数据是在统一驱动、统一llama.cpp版本和统一室温环境下测出来的代表值，不代表厂商官方承诺，不同批次驱动或固件可能带来正负10%左右的浮动。横向对比后可以看到，token gen普遍低于prompt eval，这在所有显卡上都一样。因为生成阶段是逐步采样，每一步都要把权重从显存搬到计算单元，访存带宽成了瓶颈。所以如果只想让生成更快，优先选显存带宽更高的卡，而不是单纯看算力。

我还加测了一组量化档位对比，以Qwen2-7B在S3000上的表现为例：

这张表说明一个问题：量化档位越宽松，生成反而越快，因为显存带宽的压力变小了。但Q2_K和Q4_K_M之间的质量差距很大，不能只看速度选档位。

4. 常见问题与调优实录

4.1 性能上不去的第一个检查点：线程数

同样一张S3000，我只把线程数从8调成32，token 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。

下面是我整理的常见问题速查表：

我个人折腾这套环境两周后的体会是，MTT卡跑llama.cpp量化模型这件事，已经从早年的能不能跑，发展到了现在这样日常可用的状态。S80适合入门体验，S3000是效率和成本的折中，S4000适合预算充足且对生成速度有更高要求的人。最后再分享一个小技巧：如果你打算长期维护这套环境，建议每次升级驱动之后，在固定室温下重跑一遍llama-bench，把数据按日期存成文本文件，后续排查性能回落会特别方便。