Mac 上跑大模型早就不稀奇了。稀奇的是让它像一台真正的推理服务器那样干活：多个请求同时进来，排队、调度、共享缓存、按 token 流式吐字，一个都不能乱。vLLM 官方发布的 vllm-metal v0.28.0，第一次把这套骨架完整搬到 Apple Silicon——V1 调度器、paged KV cache、OpenAI 兼容服务器一应俱全，底层交给 MLX 和 Metal 执行模型，版本号直接与上游 vLLM 对齐。
Mac 做推理服务，卡在哪一步
统一内存是礼物，但它不是显存
M 系列芯片的统一内存架构，让 GPU 能直接访问一整块共享内存，Mac Studio 顶配能堆到 512GB。这意味着 70B 甚至更大的模型塞进一台桌面设备，早就不是幻想。麻烦在于，容量从来不等同于吞吐。M3 Max 的内存带宽大约 400GB/s，M2 Ultra 到 800GB/s，而数据中心那张 H100 是 3.35TB/s。decode 阶段每输出一个 token，都要把模型权重和 KV 重新过一遍，这是典型的 memory-bound 负载，带宽直接决定每秒能吐几个字。
分水岭在于十个请求同时进来
单请求跑个 demo，谁都做得到。真正的考验是十个用户同时提问，而且长度各不相同。传统做法按最大上下文预分配 KV cache，短请求白白霸占长请求的空间，几个并发的长对话就能把内存吃干净。请求一多，要么排队排到超时，要么直接 OOM 崩掉。llama.cpp 的 server 用 continuous batching 缓解了一部分压力，可缺少分页机制，碎片化在长上下文场景下依然会咬人——一个用户丢进来三万字的合同，整批请求的响应时间都得跟着遭殃。
搬过去的不是模型，是整套服务骨架
排队规则，比算得快更重要
vLLM 的 V1 架构把请求调度、KV 块管理、模型执行拆成了独立的三层。搬过来之后，Mac 上的请求也走同一套逻辑：谁先进入 prefill、谁被抢占、长 prompt 怎么切片注入，全都有明确规则。chunked prefill 的存在尤其关键，一个超长 prompt 不会独占整批算力，排在后面的短请求不用干等。版本号跟上游对齐这件事本身也有信息量：vllm-metal 显然没打算做从主干分叉出去、自成一派的实验分支，它跟着主线走。对使用者来说，这意味着上游修掉的调度 bug、新增的优化，大概率能顺着版本号找回来。
paged KV cache 落到 Metal，等于重写一遍
Paged attention 的思路不复杂：把 KV cache 切成固定大小的块，按需分配，用一张 block table 记录映射关系。共享前缀还能靠 copy-on-write 复用，多个请求问同一份文档时省下的内存相当可观。麻烦出在落地环节。Metal 没有 CUDA 那样成熟的分配器和算子库，MLX 虽然提供了统一内存下的数组抽象，但分页结构本身、块表的维护、attention kernel 对非连续块的寻址，全都得重写一遍。这部分工程量不小，也正是 vllm-metal 这个项目存在的理由——它不是给某个脚本加个后端开关那么轻巧。
被低估的 OpenAI 兼容层
很多人把 OpenAI 兼容接口当成顺手加的装饰品。恰恰相反，它决定了迁移成本。现有的客户端 SDK、LangChain、各种评测脚本、公司内部那堆已经写好的调用代码，只要 base_url 换一下就能跑起来。少了这一层，前面那些调度和分页做得再漂亮，也只是一套需要重新适配的自娱自乐。服务端和客户端的接口约定，往往比内核性能更早决定一个项目能不能被真正用起来。
官方基准摆上桌，怎么读
MLX 管算子，Metal 管落地
这套栈里，MLX 负责提供张量抽象和一批优化过的算子，Metal 负责把这些算子真正压到 Apple GPU 上执行。两者分工有点像 PyTorch 之于 CUDA：上层写逻辑，下层榨性能。所以基准里看到的数字，本质上是 MLX kernel 质量、Metal 编译优化、内存带宽三者叠出来的结果。换一颗 M 系列芯片，曲线形状就会变，别把某一台机器的成绩当成整个平台的天花板，更别拿它去推 M4 或者下一代的性能。
可复现的脚本，比漂亮的曲线值钱
官方这次给出了可复现的并发基准，这一点比数字本身更值得注意。端侧推理的评测历来混乱：有人拿 batch=1 的 token/s 当卖点，有人用完全不同的上下文长度比吞吐，最后谁也说不清到底谁快。把并发数、序列长度分布、prompt 规模、模型规格全部摊开写清楚，再附上能跑起来的脚本，横向对比才成立。想评估 Mac 能不能扛住自己的业务，照着跑一遍，比读十篇评测文章都靠谱。
现在该不该把 Mac 塞进机架
马上能受益的场景
小团队内部的知识库问答、本地代码助手、要求数据不出内网的文档处理流程，这些场景有个共同点：并发不算高、上下文偏长、对首 token 延迟的容忍度比云端稍宽。Mac Studio 这类设备一次采购、长期在线、功耗可控，配上 vLLM 那套调度逻辑，撑起内部几个人到十几个人的日常使用问题不大。对预算有限又不想把数据交出去的小团队来说，这是一条少见的性价比路径。
先别急着把独显工作站挂到二手平台
但如果你是面向公众的服务，或者业务量有明显波峰，Mac 还不是省钱的答案。decode 阶段的带宽劣势属于硬件层面，调度器写得再好也补不回来。更现实的做法是把它放在离用户和数据最近的地方——本地开发、边缘节点、隐私敏感的内网环境——而不是硬塞进主力机架去跟 A100、H100 拼吞吐。认清边界，这套东西才用得舒服。
