摘要：实测 Qwen3.8 27B（27.3B 参数、混合注意力、262144 上下文、Apache 2.0）在 Mac Studio M3 Ultra 经 Ollama 以 Q4_K_M 量化（17GB）运行，生成速度约 14 tokens/s。
这类实测文章的价值不在结论，在参数披露得够不够全。这篇够全，所以值得拆一遍。
被测模型：Qwen3.8 27B，27.3B 参数，混合注意力架构，262,144 token 上下文窗口，Apache 2.0 许可。
硬件：Mac Studio M3 Ultra。
推理栈：Ollama。
量化：Q4_K_M，模型文件 17GB。
结果：生成速度约 14 tokens/s。
先解释 14 tokens/s 是个什么体感。中文一个汉字大致对应 1–2 个 token，14 tokens/s 相当于每秒吐 7–14 个字，比正常人的阅读速度略慢一点。用来做对话交互，能接受但不算流畅；用来生成长文档，等待感明显；用来做批量后台处理，效率偏低。
再解释为什么是这个数。Apple Silicon 的统一内存架构是本地大模型的独特优势——M3 Ultra 的内存带宽让 27B 级别模型能整个装进内存，不用像消费级独显那样在显存和内存之间反复搬运。但 GPU 算力密度和 CUDA 生态的成熟度仍是短板，所以结果是“能跑、够用、不快”。这和 M 系列 Mac 在本地推理场景的一贯口碑一致。
Q4_K_M 这个量化档位选得很实际。27.3B 参数在 FP16 下大约需要 55GB，Q4 压到 17GB，是精度损失与内存占用的常用平衡点。K_M 表示对关键层（注意力等）保留更高精度。经验上 Q4_K_M 相对 FP16 的能力损失在多数任务上可感知但可接受，编码和数学推理这类对精度敏感的任务掉得多一些。
262,144 token 的上下文窗口需要泼一点冷水。声明的窗口长度和实际可用长度不是一回事。KV cache 的内存占用随上下文线性增长，在 17GB 模型的基础上再叠 26 万 token 的 cache，内存很可能吃不住；即便装得下，长上下文下的推理速度会显著下降，检索准确率也会衰减。所以这个数字应该理解为架构上限，不是日常工作点。
谁该考虑这条路径：数据不能出内网的场景、需要长期高频调用而 API 成本累积明显的场景、以及需要离线可用的场景。一台 M3 Ultra Mac Studio 的采购成本，对照高频 API 账单大约一到两年能打平，这个账要按自己的实际调用量算。
谁不该：追求响应速度的线上服务、需要多用户并发的场景、以及调用量本来就不大的团队——后者用 API 更划算，也少了运维负担。
再补几条实测层面的方法论提醒，这类数据自己复现时容易踩坑。
区分 prefill 和 decode。14 tokens/s 说的是生成速度（decode），但用户实际体感里还有一个首 token 延迟（prefill），它取决于输入长度。喂 200 字的问题和喂 2 万字的文档，首字出来的等待时间差很远。只报生成速度的评测是不完整的，自己测的时候两个都要记。
注意热节流。Mac Studio 的散热在长时间满载下会降频，跑 30 秒和跑 30 分钟的平均速度不是一个数。做选型验证时至少连续跑十分钟以上取稳定段的数据。
Ollama 不是最快的选项。它的优势是开箱即用，代价是抽象层带来的开销。同样硬件上换 llama.cpp 直接调、或者用 MLX 这类针对 Apple Silicon 优化的框架，通常还能再快一截。如果 14 tokens/s 差一点点就够用，值得试试换栈。
混合注意力架构的收益要单独验证。Qwen3.8 27B 用了混合注意力，理论上长上下文下的效率优于纯全注意力。但这个收益在量化后、在特定推理框架实现下能保留多少，是个实证问题。如果你的场景确实要用长上下文，务必自己在目标长度上测一遍，不要拿短上下文的读数外推。
