你的Mac跑大模型时，到底在吃谁的内存？

你有没有遇到过这种情况：本地跑着一个大模型对话，突然发现Chrome标签页开始卡顿，IDE的自动补全也变慢了。你以为是自己电脑老了，其实可能是你选的那个AI推理引擎，正在悄悄把整台机器的内存榨干。

这正是一群研究者盯上的问题。他们做了一件事：把九个跑在苹果芯片上的大模型服务引擎拉出来，放在同一台Mac上，用同样的模型、同样的问题，看谁快、看谁省内存、看谁答得准。结果发现，几乎没有一个引擎能同时做好这三件事。

**这篇论文叫SiliconBench，是第一个把速度、内存、准确性三个维度放在一起考核本地大模型服务引擎的评测体系。**

先说说这事儿的背景。以前大模型都是跑在数据中心的GPU上,用的是显存,和电脑其他部分的内存是分开的,互不干扰。但现在情况变了,苹果的M系列芯片和英伟达新出的DGX Spark这类设备,用的是统一内存架构。

统一内存*：CPU和GPU共用同一块物理内存,不像传统显卡那样有独立显存。好处是容量可以做得很大(消费级设备现在能到512GB),坏处是内存变成了一块必须精打细算分配的公共资源。

这就好比你和室友合租一套房子,厨房是共用的。如果你做饭时把所有锅碗瓢盆全占了还不洗,室友想炒个菜都插不上手。如果只有独立厨房各用各的,谁做饭都不影响别人,但你得多花钱多占地方装两个厨房。统一内存省了钱和空间,代价是你的大模型引擎必须学会"文明用锅",不能吃相太难看。

问题是,现在市面上至少有九个活跃的推理引擎在抢这块"公共厨房"的使用权,包括llama.cpp、ollama、mlx_lm、vllm-metal等等。用户选引擎时,通常只看一个指标:跑得快不快。但研究者发现,这个单一指标严重误导人。

为什么只看速度会被坑

先说结论:研究者在Qwen3-0.6B这个小模型上做测试时发现,一个叫vllm-metal的引擎,把并发请求数从1提到16之后,吞吐量直接翻了一倍还多,不管是聊天场景还是智能体(agent)场景都是这样。

智能体工作负载*：指的是AI助手同时发出多个请求的场景,比如一个编程助手可能同时调用4到16个工具,每个工具调用都要等服务器返回结果。这种负载的特点是上下文长、回复短,对首字延迟特别敏感。

而与它规格相似的hf_transformers引擎,同样支持"打包查询"、"分页KV缓存"这些高级特性,吞吐量却只涨了23%。这说明什么?说明纸面参数一样,不代表实际跑起来一样快。这就像两辆车都写着"涡轮增压",一辆百公里加速5秒,另一辆却要9秒,光看参数表你根本猜不出来。

更麻烦的是内存这块。研究者做了一个特别直观的实验:用mlx_lm这个引擎,同时处理三个长度分别是3万、5千、10个token的提示,先让它们排队一个个处理,再让它们同时挤在一起处理。

结果在32GB内存的M1 Pro上,同时处理的方式直接触发了macOS的内存压缩机制,整个任务耗时暴涨到2.5倍。但换到64GB内存的M1 Max上,同样的代码跑同样的任务,几乎没有性能损失。

**同一套代码,在小内存机器上会悄悄变慢2.5倍,却不会报任何错误。**

这个发现值得琢磨。为什么会这样?因为mlx_lm在批量处理时用的是"padding"(填充)策略,不管每个请求实际有多长,都按最长的那个来分配内存和计算资源。三个请求实际总共只有3.5万个token,但填充之后要按9万个token位置来处理,浪费了61%的计算和内存I/O。

这就像你去自助餐厅打包三份外卖,明明一份小份一份中份一份大份,餐厅却非要给你三个一样大的餐盒,理由是"方便统一装箱"。如果餐盒够多,这么做无非是多浪费点塑料。但如果餐盒本来就紧张(内存不够),多余的餐盒会挤占别的顾客的位置,导致整个后厨都得停下来腾地方(触发内存压缩),原本五分钟能出的菜现在要等十二分钟。

如果不用填充策略,会怎样?论文里提到的vllm-metal和llama.cpp用的是"打包token"的方式,不填充,来多少处理多少。这也是为什么vllm-metal能在小内存机器上依然保持稳定表现的原因之一。

三个必须同时满足的硬指标

研究者提出了三个评价标准,他们管这个叫"desiderata"(期望特性)。

第一个是架构就绪度*：指的是引擎能不能支持新出的模型架构,以及能不能在并发请求下高效运转。

新模型架构这事儿听着抽象,但影响很实际。像Qwen3.5这种模型,用的是一种叫"混合线性注意力"的新机制,把循环神经网络的状态和传统的全注意力缓存结合在一起。要支持这种新架构,推理引擎的底层代码得跟着改。

研究者提到一个关键背景:CUDA生态里有CUTLASS、Triton这些成熟的内核开发工具,而苹果的Metal平台在这方面工具链还不够成熟。这直接导致了一个现象,截至2026年4月,九个引擎里只有llama.cpp和vllm-metal支持了Qwen3.5和Gemma4这两个新模型家族,到了8月份才涨到五个。

这就好比苹果和安卓两个生态里都出现了新款手机配件,但苹果这边配套的第三方工具厂商本来就少,新配件出来后很长一段时间只有官方原装配件能用,第三方要花更久才能跟上适配。不是配件本身有问题,是整个生态的开发效率跟不上。

第二个是内存纪律*：指引擎能不能守住内存边界,给系统和其他应用留出呼吸空间,而不是把内存占满。

这一点最能戳破"完成所有请求=表现好"的假象。研究者发现,sglang和vllm-mlx这两个引擎虽然都能完成全部600个请求,一个都不失败,但代价是内存使用量一路逼近物理内存上限。mistral.rs更夸张,在并发8的时候内存冲到59.3GB,却只成功处理了13个请求,剩下的全部失败或超时。

**声明了"内存上限"这个配置项,不代表引擎真的会遵守它。**

论文里管这种现象叫"declared budget"(声明的预算)和"实际执行"之间的落差。mistral.rs、vllm-mlx、sglang这三个引擎都设置了明确的内存上限参数,但实测下来照样往物理内存天花板上撞。这就像健身房办卡时承诺"每天限流500人",但实际进场根本没人查卡,高峰期照样挤得水泄不通,承诺和执行是两码事。

第三个是多节点扩展性*：指的是能不能把一个模型拆到多台机器上一起跑,突破单机内存容量的限制。

因为苹果的每一台Mac都是一个封闭的单GPU系统,没法像英伟达服务器那样插多张显卡搞NVLink直连,所以要跑更大的模型,唯一的路是联网多台Mac一起干活。研究者测试了两台M4 Pro Mac mini,用Thunderbolt 5高速连接,跑一个350亿参数的混合专家模型。

结果很有意思:用张量并行(把模型的权重切开分给不同机器)加上RDMA远程直接内存访问的方案,两台机器加起来吞吐量能涨30%左右。但用流水线并行(把模型的不同层分给不同机器,像流水线一样依次处理)加TCP网络传输的llama.cpp方案,两台机器反而比单台机器慢了16%到20%。

RDMA*：远程直接内存访问技术,允许一台机器直接读写另一台机器的内存,不用经过CPU中转,速度比传统TCP网络快得多。

这个结果不难理解。流水线并行意味着数据得像接力赛一样,一棒一棒往下传,每一棒之间的等待和网络传输开销会累积。而张量并行加RDMA更像是两个人同时各自处理自己那部分任务,配合上高速直连的"专线",效率自然更高。如果换成普通网线传输流水线数据,相当于接力赛选手之间隔着一条拥堵的马路来回跑,越跑越慢也就不奇怪了。

快和准之间的隐藏博弈

光看速度和内存还不够,论文还测了一个容易被忽略的维度:输出内容到底准不准。

研究者用了一个叫GMRID的供应链事件分类任务,让所有引擎跑同一个模型、同样的提示词,拿英伟达A100上跑vLLM的结果当作参考基准,看各家Mac上跑出来的结果和基准差多少。

这里发现了两个挺扎心的案例。第一个是ollama,它在零样本(不给任何示例直接问)情况下表现和基准差不多,但一旦切换到五样本(先给5个例子再问)模式,准确率反而落后基准整整30个百分点。研究者怀疑是它的对话模板处理多个示例时出了问题,但没有彻底查清楚根本原因。

零样本/五样本*：零样本指直接让模型回答问题不给任何示范;五样本则是先给模型看5个已经答对的例子,再让它回答新问题,通常能提升准确率。

第二个案例更微妙,vllm-mlx这个引擎在没有任何请求失败、没有任何解析错误的情况下,零样本得分依然比参考基准低了整整5个百分点。**这意味着即便一个引擎跑得很稳、从不崩溃,它输出的答案质量也可能悄悄跑偏,而这种偏差从日志和错误率里根本看不出来。**

这就像你雇了两个客服,一个偶尔会挂断电话(失败请求),但接通的每个电话都答得准;另一个从不挂电话、态度也很好,但悄悄地每20个问题里就有1个答错了方向。如果你只看"接通率"这一个指标去考核客服,后一个反而会显得更优秀,但客户满意度其实更差。

谁真正通过了三重考验

论文最后给出了一张关键的成绩单。在九个引擎里,只有llama.cpp、vllm-metal、omlx三家同时满足了三个最低门槛:并发请求下至少90%成功率、输出内容落在参考基准的可信区间内、以及支持全部三个测试模型。

其余六个引擎至少在一项上翻车。sglang在高负载下性能下滑明显;ollama速度虽快但五样本准确率崩了;mlx_lm在并发16时智能体场景直接崩溃;mistral.rs并发8就开始掉队、并发16直接崩溃;vllm-mlx虽然三项硬指标都过了,但准确率是个异常值;hf_transformers则受限于处理速度太慢,一小时的测试时限内都跑不完智能体场景的测试。

研究团队还特别提到一个维护上的插曲,挺能说明这类评测工作的琐碎和重要性。他们用一个AI助手(Claude Code)辅助维护测试代码,结果碰上过两次连锁故障:一次是底层MLX库升级后,三个引擎同时出问题,一个报错、一个编译失败、一个直接返回空结果;另一次是ollama导入模型时漏掉了聊天模板里的分隔符,导致92%的分类任务解析失败,规律是对的答案却读不出来。这两次都是靠AI辅助诊断加人工审核才修复的。这提醒我们,评测软件本身也需要持续验证,不是搭好一次就能一劳永逸。

写在后面

读完这篇论文,我印象最深的不是那些具体的百分比数字,而是那张32GB和64GB内存对比图。同一段代码,同一个任务,只因为内存余量不同,性能差了2.5倍,而且系统不会报任何错误提醒你出问题了。这种"静默降级"比直接崩溃更危险,因为你根本不知道该往哪个方向排查。

另一个让我愣了一下的细节是ollama那个"答得快但准确率会随样本数增加而下滑"的现象。直觉上,给模型看的例子越多,它应该表现得越好才对,这几乎是所有人默认的常识。但实测结果是反过来的,研究者自己也没找到确切原因。这种"你以为给了更多帮助,结果反而帮了倒忙"的情况,在工程系统里其实很常见,只是很少被这么直白地摆到台面上说清楚。

这篇论文没有给出一个"最好的引擎"这样简单的答案,反而是拆解出了一堆互相制约的权衡关系:快和省内存冲突,省内存和答得准之间也未必兼容,支持新模型和整体稳定性之间同样存在张力。或许这就是工程实践的常态,不存在一个全都占优的选择,只有针对具体场景做出的取舍。

那么下一次你选择本地大模型工具时,除了问"它快不快",是不是也该多问一句:它会不会在我不注意的时候,悄悄把我电脑的内存和CPU都占满?

Q&A

Q1：SiliconBench评测了哪些大模型服务引擎？

A：SiliconBench评测了九个苹果芯片上的推理引擎，包括llama.cpp、ollama、mlx_lm、vllm-metal、vllm-mlx、omlx、sglang、hf_transformers和mistral.rs，同时还用英伟达DGX Spark做对照参考。

Q2：为什么一个引擎速度快就不能说明它好？

A：因为速度快可能是靠占用大量内存换来的，比如ollama速度领先但内存逼近物理上限，还在五样本测试中准确率大幅落后参考基准，快不代表内存友好或输出可靠。

Q3：哪些引擎同时通过了速度、内存、准确性三项考核？

A：九个引擎里只有llama.cpp、vllm-metal和omlx同时满足了并发成功率、输出准确性达标、支持全部三个测试模型这三个最低门槛。