一台 Mac Studio（M5 Ultra / 256GB）跑本地大模型做长上下文开发负载，能到什么水平？
我用约 200 发合成基准把答案给到你：8 路并发、131K 上下文、热缓存每步 1.1–1.9 秒、零崩溃——并拿 11 天里 10,025 次真实模型调用做了对账验证。
本文给出完整设置（可参考自测）、全部实测数据、生产数据对账、外部权威榜单对照，以及复现方法。

一、测试环境

说明：全部测试使用合成数据（构造长文档 + 埋点探针），不涉任何真实内容；温度、深度、题型、样本数在下文逐项标注。

二、设置：抄作业区

mlx-serve（MLX Core 应用）内共动了 6 项设置。改前 / 改后对照：

崩溃根因：内存账面超卖

改前的组合（256K 上下文 × 3 模型驻留 × 高并发）在账面上允许约 270GB 超过 256GB 物理内存的分配。实测后果：200K 级长上下文负载直接打崩服务（进程自愈重启）。

改后 192K 成为硬边界：越界请求明确返回 400 错误，不再崩溃。压力测试佐证：32 路并发 × 131K 上下文复测，零失败。

一句话结论："能配多大上下文"和"该配多大上下文"是两回事。配置容量要以内存账面为准，而不是模型标称上限。

三、单请求速率

单请求、温度 0、冷缓存（每发全新前缀，杜绝缓存命中），105K–200K 上下文区间：

• prefill 约 5K tok/s 且随深度平坦——它是算力项，长上下文不衰减。
• decode 约 143–173 tok/s——它是带宽项，贴着 1.2TB/s 内存带宽的顶，深度增加只有轻微下滑。
• 短上下文（50K/80K）样本受冷启动影响明显偏低，不列入上表（诚实口径）。

热缓存：多轮对话的真正体验来源

多轮负载（每步新增约 4K token）下，前缀缓存命中后每步只计算新增部分：

实测缓存命中量 121K–191K token，32GB 缓存下零逐出。这就是"长任务每步一两秒"的全部秘密：不是模型变快了，是每步只算 4K 新 token。

四、并发账：8 路是甜点

131K 上下文、每请求输出约 70 token、每路独立填充前缀（杜绝并发路之间缓存互蹭）、温度 0：

三个硬结论：

1. 8 路是拐点：每请求 23.8s，约为单线（44.8s）的一半；端到端产能 0.042 req/s 为全场最高。
2. 超过 8 路反而下降：16/32 路端到端产能跌回 0.036 req/s，排队成本开始吃掉批处理收益。
3. prefill 串行是硬顶：131K 一发 prefill 约 26 秒，16 路和 32 路的整轮墙钟几乎线性翻倍——批处理救不了 prefill 排队。

180K 深度下 8 路整轮 266.1s（每请求 33.3s，0.030 req/s）——深度越高，prefill 硬顶越明显。

口径提醒：并发收益只认端到端（墙钟 ÷ 请求数）。decode 窗口的瞬时总吞吐会被排队结构放大，拿它宣传"32 路千余 tok/s"没有意义——用户等的是整轮墙钟。

五、质量实测：哪里满配，哪里塌方

检索类（5 题型 × 多深度 × 多并发，温度 0）

题型：语义检索 / 变量追踪 / 调用链追踪 / 跨文档聚合 / 首中尾位置探针。

代码类（4 题型 × 50K–200K，温度 0，共 38 发）

两个诚实的发现：

• 多步算术链与代码编辑是该模型的稳定短板，50K 短上下文就挂——这不是长上下文问题，是模型能力问题。对策：重要计算一律交给代码执行，不要让模型口算。
• 跨文件引用从 50K 的 6/6 掉到 105K 的 2/11——这类题对深度敏感。

采样稳定性（温度 0.7 × 5 遍 × 三水位）

105K / 131K / 160K 三个深度的得分均值分别为 0.55 / 0.60 / 0.55，持平：输出抖动与上下文深度无关。深度不增加随机性，只改变命中率。

六、生产数据对账：10,025 次真实调用的上下文洞察

合成基准之外，我把这台机器 11 天里 52 个会话、10,025 次真实模型调用的 usage 记录全部提取做了对账（只取 token 计数与时间戳字段，零文本内容）。合成实验说"应该如此"，生产数据说"确实如此"——这一节是全文最有说服力的部分。

真实负载长什么样

10,025 次调用的上下文深度（输入 + 缓存读取）分布：

• 深度中位数 92.6K、P90 129.2K——超过 4 成的真实调用跑在 100K 以上。本地 agent 负载不是"偶尔长文"，而是长期贴着窗口上限运行。
• 单会话最长跨度 91.5 小时、256 次调用、峰值深度 261K（旧设置期）——长时任务的深度是单调爬升的：实测某会话轨迹 24K → 68K → 101K → 134K → 197K → 258K，中途不回头。

缓存命中率的两级分化（关键洞察）

全局 46% 看着寒酸，真相是：浅调用（会话开头、压缩后首步）拉低了平均，深调用几乎全命中。深调用 95.1% 的实测命中率，与合成基准热缓存实验的 94% 命中互相印证——第三节"每步只算新增 token"的机制，在生产环境原样成立。这也解释了为什么前缀缓存从 2GB 加到 32GB 是本次调优收益最大的一项：真实负载就是 121K–191K 的缓存体量。

压缩行为实测

11 天里共 50 次上下文压缩（深度骤降 >40% 判定），压缩前深度中位数 130,880——即会话实际是爬到约 131K 满窗附近才被压缩回收，76% 的压缩事件落在 100–135K 区间。压缩后深度回落、缓存重建、继续爬升，循环往复。这验证了"131K 窗口 + 自动压缩"作为长时任务的续航机制在生产中稳定工作。

设置收敛的前后对照（生产侧证据）

旧设置（256K 窗口）放任了近 5% 的调用跑进第五节实测的"质量塌方区"（>160K，聚合类任务开始丢分）；新设置把深度压回满配区内，131–160K 占比上升说明负载被引导到窗口上限而非放任越界。样本量提示：新设置期仅 267 次调用（约 1 天），此对照为初步证据，持续观察中。

七、外部权威数据对照

同机型（M5 Ultra 256GB）公开榜单，供横向参考：

mlx-serve 官方基准（benchmarks.md，llmprobe 测法：预热丢弃、3 次取中位、代码补全 prompt、投机解码标注在旁）：

来源：ddalcu/mlx-serve benchmarks.md；官方 README 另载 v26.11.1 同机 Flash-Next 4.7bit 为 180 tok/s（README）。

第三方栈参考（llama.cpp，非同引擎，仅作量级对照）：Qwen3.8 27B 空上下文 46.3 tok/s、128K 上下文 30.1 tok/s（getneotiler 实测）；社区汇编给 Flash-Next 长上下文 60–85 tok/s 区间（presenc 汇编，转引 Context Studios）。

本文自测 vs 官方榜单：本文单线 decode 143–173 tok/s（105K–200K、无投机解码、长上下文），与官方 168 tok/s（短 prompt + MTP 投机解码）同量级、口径可解释——长上下文吃带宽，投机解码提短 prompt 表现。

八、使用场景建议

上下文窗口设置建议 131K（如果客户端可配）：质量满配区之内、距 192K 服务硬限有安全余量、压缩触发线（约 0.8×）也落在满配区内。三重约束，131K 是综合最优解——第六节的生产数据佐证了这一点：真实负载 4 成跑在 100K+，压缩事件中位触发深度 130,880，正好贴着这个窗口。

九、复现方法与测量教训

想在自己机器上复跑，方法如下（判据先于数据）：

1. 合成埋点：程序生成长文档，按 token 深度均匀埋入探针（数字对、变量名、代码片段），题面与校验点同源生成。
2. 五题型：语义检索 / 变量追踪 / 调用链 / 跨文档聚合 / 首中尾位置——位置探针专打 lost-in-the-middle。
3. 温度纪律：质量测温度 0（确定性，重跑零方差）；稳定性测必须温度 >0，否则测不到抖动。
4. 并发防污染：每路并发用不同随机种子独立填充前缀，否则后发路蹭前发路的缓存，数据全废。
5. 判分器先单测：判分 bug 会把满分判成零分（我们踩过空格匹配和变量名漂移各一轮）。
6. 吞吐只认端到端：墙钟 ÷ 请求数；decode 窗口瞬时和会被排队结构放大。
7. macOS 采样小坑：BSD awk 没有 strftime，内存采样脚本用 Python 写。
8. 生产对账口径（第六节）：从 agent 会话日志的 usage 字段提取 inputTokens / cacheReadTokens / outputTokens 与时间戳；命中率 = cacheRead ÷ (input + cacheRead)；压缩事件判定 = 相邻调用间隔 <10 分钟内深度骤降 >40%（间隔阈值排除"重启恢复首调"的假压缩——实测 52 个候选里 2 个是恢复、50 个是真压缩）。全程零文本读取。

数据窗口与免责

• 实测窗口：合成基准 2026-11-08，mlx-serve 26.11.2，macOS 27.2，全部数据可在评论区按上述方法复现核对；生产对账窗口 2026-10-29 至 11-09（52 会话 / 10,025 次调用），仅提取 token 计数与时间戳，不含任何会话文本。
• 样本量说明：合成基准约 200 发/配置组合，低于学术基准（如 RULER 的 1000 题/配置）口径，关键结论均经多轮交叉验证；个别短上下文样本受冷启动影响已剔除并注明。生产对账中新旧设置对照的新期样本仅约 1 天（267 次），标注为初步证据。
• 换模型、换量化档、换 mlx-serve 大版本后，本文数字会失效，需重跑。

*欢迎交流设置与复现结果。希望能帮到大家，肝测试挺费人费机器。