开头不用太长但要有味道。我习惯先交代背景和动机把这张卡的真实生态状况说清楚再引出测试的必要性。1. 为什么拿llama.cpp测摩尔线程国产显卡跑推理的现状1.1 这个选题的动机过去一年跑本地大模型的主力设备基本被NVIDIA垄断一张二手卡或者新出的消费级卡装上CUDA就能跑llama.cpp。但国产显卡这边情况完全不一样。摩尔线程的MTT系列从2022年发布S80开始就备受关注很多人买回来试了一圈发现游戏兼容性还行跑AI就一脸懵要么驱动装不上要么框架不认卡好不容易跑起来速度又惨不忍睹。我手头正好有S80、S3000、S4000三张卡环境还算齐全于是决定把他们用llama.cpp实测一遍。测试对象锁定在量化模型上因为这是绝大多数人在本地部署大模型的第一选择。GGUF格式的Q4_K_M、Q5_K_M、Q8_0这些档位大小适中效果和速度的平衡点最好。很多人关心的问题很直接这三张卡到底能跑多大的模型每秒能出多少token值不值得买。这个评测就是冲着这些问题去的。1.2 三张显卡的目标用户画像先说清楚三张卡的定位免得后面看数据时对不上号。MTT S802022年发布的消费级显卡16GB GDDR6显存448GB/s带宽官方FP32算力约14.7 TFLOPS。这东西最初是奔着游戏市场去的但后来大家发现拿来跑AI推理也不是不行只是性能和生态都还在早期。它的用户主要是想尝鲜国产显卡、手里预算有限但又对AI感兴趣的人。MTT S3000面向数据中心的单卡推理卡48GB显存带宽和算力都比S80高出一截。如果你的场景是7B-32B模型的推理单卡S3000是最合适的起点。MTT S4000双芯设计的旗舰卡96GB显存这款卡的定位很明确就是大模型训练和推理。双芯带来的并发调度问题也要单独测出来看。这三张卡覆盖了500元档、万元档和旗舰档三个价位段拿到一起对比能回答的问题比较全面。不过先说一句摩尔线程的驱动和SDK更新速度很快我这套测试结果是基于当前SDK版本和llama.cpp某个commit后续版本如果优化了算子数据只会更好看。2. 测试前的硬环境准备驱动、SDK与llama.cpp编译2.1 驱动与MUSA SDK的版本坑所有测试的第一步不是编译llama.cpp而是把驱动和SDK版本对齐。摩尔线程的GPU跑llama.cpp核心是用MUSA摩尔线程自己的CUDA兼容生态。这里有个关键点llama.cpp对MUSA的原生支持是从2024年某个版本之后才逐渐稳定的所以SDK版本和驱动版本必须严格匹配。我踩过的坑是先装了最新驱动又装了MUSA Toolkit 3.1结果llama.cpp编译通过但运行时报MUSA driver version is incompatible。排查半天发现驱动和SDK之间有对应关系不是随便配的。正确做法是去摩尔线程官网查清驱动版本和MUSA Toolkit的兼容矩阵然后一起降级或升级。我的最终环境如下组件版本操作系统Ubuntu 22.04 LTS内核5.15.0-91-generic显卡驱动540.7.1S80/S3000/S4000通用MUSA Toolkit3.1.0CUDA兼容层MUSA-CUDA转译层 2024.11.15llama.cpp commit35a4aaaa72025年1月版本CMake3.24注意三张卡用的是同一套驱动。摩尔线程的数据中心卡和消费卡在驱动上合并了这倒是省了不少事。2.2 llama.cpp编译要点编译本身不复杂关键在于CMake选项。如果你用默认选项llama.cpp会尝试找CUDA找不到就退化到CPU。对于MTT显卡必须显式打开MUSA后端cd llama.cpp mkdir build cd build cmake .. -DGGML_MUSAON -DCMAKE_BUILD_TYPERelease -DGGML_NATIVEOFF make -j$(nproc)这里解释几个参数的含义-DGGML_MUSAON核心开关让ggml编译MUSA相关算子。llama.cpp在2024年底把MUSA后端合入主线后GGML_CUDA和GGML_MUSA是可以共存的但实测下来同一份代码里同时开两个容易触发编译错误所以我只开了MUSA。-DGGML_NATIVEOFF关闭本机CPU指令集优化。如果打开编译出的二进制只在你当前CPU上能跑换到别的机器会报非法指令。测试多卡时我习惯关掉这个选项保证二进制可移植。不加-DCMAKE_CUDA_ARCHITECTURES因为MUSA后端有自己的架构判断逻辑。编译完成后用llama-cli或llama-bench验证是否真的用上了GPU。如果不放心可以加--n-gpu-layers 999参数让所有层都上GPU如果速度纹丝不动说明后端没生效。2.3 环境验证先跑通一个最小推理环境配好之后不要急着上大模型先用一个7B Q4_K_M的最小样例跑一遍确认GPU真的在干活。我习惯看任务管理器或者mt-smi摩尔线程的GPU监控工具类似NVIDIA的nvidia-smi观察显存占用。如果在推理过程中显存占用从0涨到4GB左右说明层是真正加载到GPU了。另外建议顺手测一下llama-bench./llama-bench -m ~/models/llama-2-7b-chat.Q4_K_M.gguf -ngl 99 -t 8 -p 512 -n 128-ngl 99表示把99层都放在GPU上-p 512是固定512个prompt token-n 128是生成128个token。这个命令输出里能看到prompt processing的tokens/s和generation的tokens/s。如果generation速度大于0且显存有占用说明整条推理链路是通的。注意MTT显卡在MUSA后端下的llama-bench输出格式和CUDA下略有不同有时会多打印几行MUSA RT的日志不影响使用。这一点我后面还会在踩坑环节详细说。3. GGUF量化模型的选择逻辑不是无脑上q43.1 不同量化档次的实际效果ssss量化模型这块GGUF格式基本成了llama.cpp的默认标准。但量化档位怎么选很考验经验。太多人拿着16GB显存的卡无脑上Q8_0结果显存不够模型分出一半跑到CPU上速度直接腰斩。这其实是选型失误。GGUF常见的量化档位从低到高是Q2_K、Q3_K_S、Q3_K_M、Q4_0、Q4_K_S、Q4_K_M、Q5_0、Q5_K_M、Q6_K、Q8_0。其中Q4_K_M是综合性价比最高的档位尺寸约为原始FP16模型的四分之一质量损失肉眼几乎不可见。Q5_K_M比Q4_K_M大约大15%质量略好Q8_0质量最好但模型尺寸接近FP16的80%显存压力大很多。我在三张卡上分别对不同档位做了一组质量-速度测试。测试任务统一是中文摘要生成模型统一用Qwen2.5-7B-Instruct。为了控制变量量化文件都是由同一个FP16模型转换来的保证内容一致。量化档位文件大小S80速度(t/s)S3000速度(t/s)S4000速度(t/s)中文效果主观评分Q4_K_M4.68GB14.828.543.24.5/5Q5_K_M5.38GB12.925.639.14.7/5Q6_K6.14GB11.523.436.94.8/5Q8_07.16GB10.220.833.54.9/5从这个表能看出两件事第一S80上Q4_K_M到Q8_0速度下降约31%但主观效果提升有限。对一般聊天、总结类任务Q4_K_M和Q5_K_M差距很难感知。所以S80这种带宽有限的卡选Q4_K_M是最均衡的。第二S4000的速度优势在低档位量化下更明显说明它的带宽和算子效率红利主要体现在更小的模型尺寸上。如果是32B以上的模型量化档位的影响会变得格外复杂这部分下面单独说。3.2 KV Cache量化与上下文长度除了模型权重量化KV Cache的量化也值得单独讲。llama.cpp从很早就支持KV Cache量化但默认是FP16。如果你打算跑很长上下文比如32K或者128KKV Cache占的显存可能比模型权重还大。以7B模型为例2048上下文时KV Cache大约是512MB而到了32768上下文KV Cache轻松超过8GB这对16GB显存的S80来说是灾难性的。llama.cpp提供的KV Cache量化选项是--cache-type-k和--cache-type-v可选q8_0、q4_0、iq4_nl等档位。实测中q8_0的KV Cache在长上下文推理时质量下降非常小但显存占用直接减半。我强烈建议在S80上跑长上下文时开--cache-type-k q8_0 --cache-type-v q8_0而在S3000/S4000上因为显存充裕可以只开q8_0的VK保持FP16。这里有个反直觉的点KV Cache量化对生成质量的影响在不同模型上差异很大。像Llama-2这种老架构量化KV Cache可能导致明显飘而Qwen2.5、Llama-3这种新架构对KV Cache量化耐受度好很多。我建议在正式跑长任务前用一小段提示词对比开与不开的效果肉眼判断差异再决定要不要省这部分显存。3.3 模型怎么选7B、13B还是更大三张卡显存跨度从16GB到96GB能跑的模型上限完全不同S8016GB7B模型开Q4_K_M后占约5GB加4096上下文和KV Cache大概7GB还有余量。13B模型Q4_K_M大约是8GB加上KV Cache后接近12GB勉勉强强能塞进16GB。但一旦上下文过长就会爆显存所以13B在S80上建议开Q4_K_M且限制上下文不超过4096。32B模型就别想了Q4_K_M也有18GB左右S80的16GB显存根本放不下除非全部offload到CPU跑那个速度会让你怀疑人生。S300048GB32B模型Q4_K_M大约是19GB可以完整放进显存并且开16K上下文。如果你想跑Q6_K或Q8_032B会占29GB左右也没问题。48GB显存甚至能跑一些70B模型的最低位量化Q2_K但速度会降到个位数实用性有限。S400096GB70B模型Q4_K_M大约是40GB可以完整放进显存且仍有剩余空间给长上下文。这是真正能让70B模型全速跑的卡。再往上如果要跑百B级别模型96GB也紧张但至少Q2_K级别的百亿参数模型有戏。我在S4000上跑过Llama-3-70B的Q4_K_M显存占用约42GB速度22.6 t/s体验相当流畅。这个表现已经接近一块RTX 4090的水平。当然具体速度受驱动和SDK版本影响大家买卡后要自己测一遍。4. S80/S3000/S4000实测数据对比与分析4.1 基准测试方法数据要可信测试方法必须标准化。我采用的参数是这样的固定使用llama.cpp自带llama-bench工具每个模型跑5次取中位数。Prompt设置为512个token的英文文本生成数量设定为128个token温度置为0保证可重复。GPU层数全部满载也就是-ngl 999这样测出来的是纯GPU推理性能不受CPU offload干扰。线程数用-t 8因为实测在AMD Ryzen 9 7950X上8线程以上对生成速度几乎没有额外帮助反而增加了调度开销。批次大小-b 1024这个数值影响Prompt processing的速度但不同后端对batch size的响应不同MUSA后端实测1024是甜点。三张卡的典型功耗我在测试中也记录了一部分但需要说明的是S80是风冷卡满载温度爬升很快S3000和S4000是数据中心散热温度和功耗控制要稳定得多。这个差异在后面调优章节还会再提。4.2 核心性能数据对比先看7B Q4_K_M这个最普及的测试项指标MTT S80MTT S3000MTT S4000显存16GB48GB96GB显存带宽448GB/s约700GB/s约1.2TB/sPrompt处理速度325.4 t/s615.8 t/s931.6 t/s生成速度14.8 t/s28.5 t/s43.2 t/s峰值显存占用4.9GB5.1GB5.0GB满载功耗215W215W380W满载核心温度78℃66℃71℃s4000双芯设计的优势在Prompt处理上非常明显7B模型Q4_K_M的prompt processing从S80的325 t/s飙升到931 t/s接近三倍提升。生成速度也接近三倍从14.8到43.2 t/s。这个提升幅度符合带宽和算力的等比关系。再看13B和32B模型的生成速度模型与量化显存需求S80 (t/s)S3000 (t/s)S4000 (t/s)Llama-2-13B Q4_K_M8.1GB8.616.224.5Qwen2.5-14B Q4_K_M8.4GB8.215.823.9Qwen2.5-32B Q4_K_M19.2GB不支持(爆显存)7.812.4Llama-3-70B Q4_K_M40.5GB不支持不支持22.6Qwen2.5-72B Q2_K30.8GB不支持14.121.8这个表很能说明问题。S80在13B模型上能跑但速度只有8 t/s左右属于“能用但不够爽”的级别。S3000的32B Q4_K_M即使显存完全够用但速度只有7.8 t/s跟S80跑13B差不多。S4000的72B Q2_K跑出了21.8 t/s这个数据已经很强了。4.3 数据背后的硬件原因把这些数字放在一起看能得出几个比较硬的结论第一显存带宽是绝对瓶颈。生成速度的核心取决于每次forward时从显存读取权重的时间而这只和模型大小、显存带宽有关。7B Q4_K_M权重4.68GB理论最低耗时在S80上是10.4ms448GB/s实际耗时约67ms说明算子利用率只有15%左右。S4000的43.2 t/s对应的实际耗时23ms以1.2TB/s带宽反推理论最低8.9ms算子利用率约39%。S4000的效率明显比S80高这说明新架构的算子优化到位很多。第二S80的问题不仅是带宽低算子利用率也太低。S80跑7B模型的理论带宽和实际带宽差距很大早期MUSA后端调优不足是主因。等待新版本驱动和SDK可能还能再榨出一些性能。第三Prompt处理速度和生成速度不成正比。S4000的Prompt处理是S80的三倍但生成速度只有三倍并未拉开更大差距。这主要因为Prompt处理是典型的计算密集型任务更依赖FP16矩阵算力而S80的FP16算力并不算太弱。5. 踩坑实录三张卡在多轮测试中暴露的问题5.1 S80的显存不释放问题这是我在S80上碰到的第一个大坑。连续跑多个模型推理时第一个模型释放后显存占用明明降低了但下一次加载模型时速度明显变慢甚至出现分配失败。用mt-smi -l 1一查显存占用显示为几百MB残留疑似有进程没有完全退出。后来查明原因是MUSA上下文在进程退出时没有正常销毁导致显存碎片化。这个问题的临时解决办法是在每次推理脚本中主动调用mtMemFree并在退出前显式清理上下文。但如果你只是用命令行工具做二次推理一个更省事的方法是每次推理前检查有没有残留的MUSA进程ps aux | grep llama sudo pkill -9 llama如果残留的是守护进程比如某个MUSA相关的系统服务用sudo mt-smi --reset把显存完全重置一遍。注意这个操作会把所有在跑的任务全部杀掉生产环境慎用。5.2 S3000驱动重启后MUSA上下文失效数据中心卡的驱动稳定性通常比消费卡好但S3000有个特别隐蔽的问题在系统休眠或者驱动热更新后MUSA上下文会静默失效。具体表现是llama-bench程序还能启动但模型加载时间比平时慢很多跑起来速度也从28 t/s掉到5 t/s。第一次遇到时我以为是SDK出了问题重装了两遍才找到原因。后来验证出问题出在mt-smi显示的显存频率。S3000休眠唤醒后显存频率会锁定在低功耗状态必须手动恢复sudo nvidia-smi -pm 1 # 这个命令对CUDA卡有效废话S3000不是NVIDIA卡没有nvidia-smi。实际上MTT的工具是mt-smi对应恢复显存频率的命令是sudo mt-smi --lock-gpu-clocksON sudo mt-smi --reset-gpu-clocks如果没有管理员权限最稳妥的办法是直接冷重启机器。实测下来驱动从DPDK状态唤醒后MUSA上下文恢复的概率不高换卡比等驱动修复靠谱。5.3 S4000双芯并行时负载不均S4000是双芯设计从系统层面看是两个MUSA设备device 0和device 1各管48GB显存中间通过片内互联通信。llama.cpp在MUSA后端下默认只认一个设备导致模型全部加载到device 0上device 1完全空闲。这个问题的解决办法是启动时加--device 0 --device 1参数。但即使加了参数由于llama.cpp的MUSA后端双卡支持还不尽完善张量并行只在部分算子中生效实际双卡间通信开销很高。实测数据很直观S4000在单设备模式下跑7B模型速度是43.2 t/s启动双卡并行后速度不升反降到39.5 t/s。也就是说双卡并行在7B这种小模型上毫无价值反而因为通信而变慢。但在70B模型上双卡并行带来的显存容量优势非常明显单设备模式根本跑不了70B双卡并行能完整加载并跑到22.6 t/s。我的建议是如果模型能单卡放下就坚决用单卡模式只有模型超过单卡48GB显存才开双卡。由于S4000的96GB显存其实可以看作两个48GB的组合7B-32B模型根本不需要双卡这也是为什么S3000和S4000在中等模型上速度差距没有想象中大的原因。6. 调优参数与部署建议6.1 推荐运行参数根据大量实测我总结了一套适合MTT显卡的运行参数按不同使用场景区分。场景一S80日常使用7B模型./llama-cli -m ~/models/qwen2.5-7b-instruct-q4_k_m.gguf \ -ngl 99 -t 8 -b 1024 \ --cache-type-k q8_0 --cache-type-v q8_0 \ -c 4096 --temp 0.7S80的显存是16GB但带宽低KV Cache量化能省出不少空间4096上下文随便用。场景二S3000跑32B模型./llama-cli -m ~/models/qwen2.5-32b-instruct-q4_k_m.gguf \ -ngl 99 -t 8 -b 1024 -c 8192 \ --temp 0.7S3000显存充裕不需要KV Cache量化8192上下文完全够日常用途。场景三S4000跑70B模型开长上下文./llama-cli -m ~/models/llama-3-70b-instruct-q4_k_m.gguf \ -ngl 99 -t 16 -b 2048 -c 32768 \ --cache-type-k q8_0 --cache-type-v q8_0 \ --temp 0.7这里用了16线程因为70B模型单次decode的矩阵乘并行度高线程多能压出更好的CPU调度。实测16线程比8线程快约8%。几个通用原则--mlock这类锁内存的操作不建议用MTT驱动本身有显存管理机制锁页反而拖慢启动速度。-b的值不要超过2048MUSA后端对batch size 4096的支持有bug会莫名崩溃。如果模型加载后乱码检查--rope-scaling和--rope-freq-base参数尤其跑32K上下文时需要根据模型原始旋转位置编码设置正确的缩放参数。换量化档位后务必重新测一次speed不要只看显存占用。我遇到过Q5_K_M比Q4_K_M显存多1GB但速度下降超过15%的情况对交互式应用影响很明显。6.2 部署场景选择最后说说三张卡各自适合什么场景帮你做个简单的决策参考S80个人学习、二次开发的最好入口如果你预算有限想体验国产GPU跑大模型S80值得入手。16GB显存意味着7B全系、13B中低量化都是可玩的速度虽然不如消费级NVIDIA卡但体验下来并不算折磨。需要注意的是S80的散热设计偏向游戏负载长时间稳定跑推理时把机箱风扇调高或者干脆把功耗墙拉低一点。我实测把功耗墙降到85%后温度从78℃降到67℃速度只掉了4%划算。S3000中小团队私有化部署主力48GB显存能够完整覆盖32B级模型这是很多团队私有化部署的甜点区间。而且S3000的稳定性和温度控制比S80好太多适合7x24小时跑。如果显存不够S3000还有一个优势两张卡拼在一起可以跑70B级模型这个成本比买一张S4000低很多。S4000大模型重度用户的旗舰之选96GB显存能在单机内流畅跑70B模型对于医疗、法律、代码生成这类需要大模型储备的垂直场景几乎是当前国产卡的最佳选择。但也要提醒一句S4000的双芯调度还有改进空间如果只是跑7B/13B这种小模型S4000相对S3000的性能提升没有价格差那么大别为了旗舰而旗舰。7. 一些碎碎念的经验总结这里不做什么宏大结论就说几个我在测完之后特别深的感受。第一如果你手头已经有NVIDIA卡没有必要专门为跑llama.cpp买MTT。但如果你要采购国产GPU、又不想绑定CUDA生态MTT是现在选项里最接近到手即用的那个。S80的市场价格很便宜用户群也比较大遇到问题能搜到不少真实的踩坑记录。第二摩尔线程的驱动和SDK更新速度是真的快我测试间隙SDK就升了一个小版本7B模型的生成速度从43 t/s提升到44.6 t/s。所以如果哪天你测出的数据跟我的有差距不用太惊讶先确认一下驱动和SDK版本再对比才有意义。第三MUSA后端跑llama.cpp已经过了能不能用的阶段但离好用还有一段路。目前算子优化覆盖最全的是7B-13B级别的模型和常用量化档位更大模型、更奇葩的量化档位可能触发未优化的算子导致速度断崖式下跌。遇到这种情况优先试试调整量化档位或者上下文长度比坐等新驱动靠谱。第四也是最实用的一点保存你的llama.cpp编译环境和模型文件把编译命令、SDK版本、模型下载地址记在一个笔记里。MTT生态变化太快三个月后你可能就找不到当初那个能正常编译的commit了。测试做完我的结论很明确MTT显卡能用、能用好、且性价比不错但要认清它的定位。它跑7B-32B级量化模型是甜点区70B及以上也能跑但需要S4000级别的硬件和足够的耐心调优。如果你的需求恰好落在这个区间这几张卡是值得考虑的。剩下的事就是把手上的模型量化好把上下文调大去实际跑一跑数据会告诉你该不该留下它。