【实测】Mac Studio M5 Max 64GB 跑 Strata + Qwen3.8-Flash-Next Q2_0：安装、配置与 256K 上下文阶梯实测

fsclsnow

结论先说：64GB 的 M5 Max 能跑 125B 的 Qwen3.8-Flash-Next（Q2_0 量化），262K 上下文完整跑通，512K 卡在时间预算而不是模型本身。
实测 prefill 吞吐约 1,870–2,077 tok/s，生成吞吐约 79–89 tok/s；512K 请求引擎侧实际跑了 310.5 s 才被客户端中止。

一、测试机器

项目	配置
机型	Mac Studio（Mac17,14，型号 MHQJ4LL/A）
芯片	Apple M5 Max
CPU	18 核（6 超级核 + 12 性能核）
统一内存	64 GB
GPU	内置，40 核，Metal 4
系统	macOS 27.0.1（Build 26A434），arm64

引擎自报的 CPU 配置（启动日志）：

CPU pool: 16 workers by default (18 physical cores, 18 logical processors;
bounded by physical cores, one kept free)
host thread on core 0 (draining too)
this CPU has no AVX-512: the expert kernels run on ggml-cpu vec_dot

二、软件与模型

项目	内容
推理框架	Strata（开源，MIT）—— 版本 0.2.1，Metal 引擎 0.1.46.2（日志显示 `engine 0.1.46-metal`）
模型	Qwen3.8-Flash-Next，125B 参数 MoE（48 层，每层 512 专家）
量化版本	ISTA-DASLab 的 GSQ-RCO Q2_0（分 2 个 shard）
模型体积	shard1 37.6 GB + shard2（PLE n-gram 表） 28.8 GB = 66.4 GB
视觉编码器	`mmproj-Qwen3.8-Flash-Next-BF16.gguf`，0.91 GB
MTP 草稿层	`mtp-q2_0.gguf`，0.89 GB（draft 词表 106,299 tokens）
本地 pack	`packs/q2_0/dense.bin`，1.49 GB（1,079 个张量）
磁盘总占用	`Strata-data/` 约 70 GB
服务地址	OpenAI 兼容 API：`http://127.0.0.1:8080/v1`；聊天页：`http://127.0.0.1:8080/`

/v1/health 返回：

{"status":"ok","max_context":524288,"model":"qwen3.8-flash-next-q2_0",
 "images":true,"api_key":false,"loaded":true,"service":"strata"}

三、安装过程（Mac 源码路线）

Strata 在 Mac 上有两条路：.dmg 应用 / Terminal 版（预编译引擎），或源码 ./setup.sh（自己编译 Metal 引擎）。本机走的是源码路线。

git clone https://github.com/Niko1221/Strata && cd Strata
./setup.sh          # 问模型尺寸；--yes 走推荐答案

setup.sh 依次做 7 件事（已完成的步骤会自动跳过）：

Python：需要 3.10+，macOS 自带 3.9 时会下载一个 25 MB 的独立 Python 3.12（SHA-256 校验），不需要 sudo/Homebrew。本机已有 Homebrew Python 3.14，直接建 .venv。
体检：芯片、内存、macOS 版本、Command Line Tools、磁盘空间。
Python 依赖装进 .venv，CMake 与 Ninja 也来自 pip。
编译引擎 build-metal/strata（Apple metal-cpp 头文件 + llama.cpp 的 ggml，本机 AppleClang 21）。
下载模型（断点续传；已有 GGUF 可用 --gguf-dir）。
准备模型：生成 pack（几秒）+ MTP 草稿层（约 5 GB 原始 checkpoint）。
写 strata-<model>.json 与 run-<model>.sh，然后启动服务。

本机实际时间线（2026-10-20）

时间	事件
14:02	创建 `.venv`（Python 3.14.7）
14:03	Metal 引擎编译完成（`build-metal/strata`，4.7 MB）
14:17	模型 shard 1 下载完成（37.6 GB）
14:27	模型 shard 2 下载完成（28.8 GB）
14:28	视觉编码器 + pack（`dense.bin` 1.49 GB）就绪；`strata-vision` 编译完成
14:31	MTP 草稿层（0.89 GB）生成；写入 `run-q2_0.sh`
14:31:43	引擎首次启动，`--max-context 32768`
15:24 / 15:32 / 16:52	上下文依次调到 131072 → 262144 → 262144
20:19 / 20:56	上下文调到 524288，跑阶梯实测

四、配置信息

strata-q2_0.json（由 run-q2_0.sh 调用）：

{
  "exe": ".../build-metal/strata",
  "args": [
    "--pack",        ".../Strata-data/packs/q2_0",
    "--native",      ".../Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf",
    "--ple-gguf",    ".../Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00002-of-00002.gguf",
    "--expert-profile", ".../Strata/data/expert-profile.bin",
    "--expert-cache", "64",
    "--prefill",     "auto",
    "--spec",        "2",
    "--mtp",         ".../Strata-data/mtp/rt",
    "--max-context", "524288",
    "--mmap-experts",
    "--vision"
  ],
  "tokenizer": ".../packs/q2_0/tokenizer",
  "model_name": "qwen3.8-flash-next-q2_0",
  "port": 8080,
  "backend": "metal",
  "env": { "STRATA_METAL_STREAM": "0" },
  "vision": {
    "exe": ".../build-vision/bin/strata-vision",
    "mmproj": ".../mmproj-Qwen3.8-Flash-Next-BF16.gguf",
    "gpu": true,
    "max_tokens": 1024
  }
}

参数含义（按本机实测理解）：

参数	作用
`--native`	37.6 GB 主文件被 Metal 直接映射进统一内存（"wrapped"），专家权重不复制
`--ple-gguf`	28.8 GB 的 n-gram PLE 表，从 SSD 逐行读，不计入显存
`--expert-cache 64`	常驻 GPU 的专家槽位 64 个，仅 0.08 GiB；按路由频率排序，不淘汰
`--expert-profile`	24,576 个专家配对的排序表，决定哪些专家常驻
`--spec 2`	MTP 投机解码窗口 2（Mac 默认值）
`--mtp`	草稿层，实测 `drafts accepted 7 of 8`
`--max-context`	上下文窗口，本机从 32768 逐步调到 524288
`--vision`	图片输入开启（默认开）

️ 524K 上下文时引擎的警告：

serve: 0 MiB of VRAM free with everything loaded - LOW: requests may stall;
  add --vram-reserve-mib 1212 to the config's args (or lower --max-context)

另外 memory guard: the available RAM cannot be read; parking and session save/restore are refused —— 所以 Strata 侧没有 oMLX 那样的 /admin/api/stats，测试脚本无法采集内存峰值（报告里 peak GiB 为 -）。

五、测试工具

自写脚本 scripts/local-test/context_capacity_probe.py：

扫描本机 OpenAI 兼容端口（8000 / 8080），列出在线模型供选择；
先做校准（测 chat 模板开销与 tokens/字符比例，本次模板开销 72 tokens，filler 47 tokens/行）；
然后按 16K → 32K → 64K → 128K → 256K → 512K 阶梯上升；
每步 max_tokens=16，记录真实 prompt_tokens / completion_tokens / prefill_ms / total_time / 墙钟时间；
任一步失败（OOM、memory guard、超时、上下文超限、服务端截断）立即停止，不再试更高阶梯；
每次运行独立目录，不覆盖旧结果。

本次运行参数：--mode ladder，--gen-tokens 16，--time-budget 480，--max-requests 20，--request-timeout 360。

六、实测结果（run-20261020-201926-074430ec）

目标模型：qwen3.8-flash-next-q2_0 @ http://127.0.0.1:8080/v1
状态：ladder_stopped_timeout，总耗时 479.61 s，请求 10 条（9 成功 / 1 失败）

阶梯上下文	目标 prompt	实际 prompt	prompt 字符	gen tokens	prefill(ms)	prefill tok/s	total(s)	状态
16,384	16,304	16,286	60,408	16	7,840.0	2,077	8.14	OK
32,768	32,688	32,689	121,483	16	16,048.3	2,037	16.26	OK
65,536	65,456	65,448	243,458	16	32,262.5	2,029	32.49	OK
131,072	130,992	131,013	487,583	16	66,416.4	1,973	66.69	OK
262,144	262,064	262,049	975,483	16	140,141.4	1,870	140.48	OK
524,288	524,208	—	1,951,633	—	—	—	210.54	timeout

关键指标：

指标	值
最高完成阶梯	262,144 tokens
实测最大 prompt tokens	≥ 262,049
上下文可信区间	`[262,049, 524,208]`
prefill 吞吐中位数 / P95	2,029 / 2,077 tok/s
生成吞吐中位数	78.7 tok/s
最大单请求耗时	210.54 s
请求体总字节	3,853,524 B
缓存命中 token	0（每阶梯都是新会话）

引擎侧对应日志（同一请求）：

prompt 262049 tokens = 0 reused + 262049 read in 140141 ms (1869.9 tok/s),
  16 generated in 203 ms (78.7 tok/s), drafts accepted 7 of 8, 6 checkpoints
prompt 524215 tokens = 0 reused + 524210 of 524215 read in 310525 ms (1688.1 tok/s),
  0 generated in 2 ms (0.0 tok/s) (cancelled)

七、结果解读

1. 262K 是真跑通的，不是"声明支持"。
服务端 /health 声明 max_context: 524288，但声明不等于可用。实测 262K 完整 prefill + 生成 16 token，没有任何截断或报错。

2. 512K 失败是"时间预算"问题，不是模型拒绝。
失败类型是 Timeout: TimeoutError，HTTP 状态 -1（客户端侧），而不是服务端返回 400/500。整轮运行耗时 479.61 s，正好撞上 --time-budget 480 的全局预算，所以这条请求在 210.5 s 处被客户端看门狗中止；引擎日志显示该请求的 prefill 推进到 524,210 / 524,215 tokens，累计 310.5 s（1,688 tok/s） 后才被标记为 cancelled。
→ 把 --time-budget 提到 900 s、--request-timeout 提到 600 s，512K 大概率能跑通。

3. prefill 吞吐随上下文下降约 10%。
2,077 → 2,037 → 2,029 → 1,973 → 1,870 tok/s。16K 到 262K 只降 10%，说明长上下文没有明显的平方级恶化（MoE + PLE 的读取走 SSD，专家命中走 GPU）。

4. 真正的瓶颈是显存余量。
32K 上下文时 10273 MiB of VRAM free；524K 时 0 MiB of VRAM free，引擎直接提示"requests may stall"。64 GB 统一内存跑 Q2_0（官方建议 64 GB 起）在 512K 上是刚好卡在边界。

5. KV 缓存复用效果非常明显。
同一会话重复请求时，日志出现：

prompt 262132 tokens = 262127 reused + 5 read in 25 ms (197.0 tok/s)

262K 上下文从 140 s 降到 25 ms。阶梯测试每步都是新会话，所以 cached_tokens = 0；日常多轮对话的实际体验远好于阶梯数字。

6. 生成速度稳定。
带 MTP（--spec 2）实测 79–89 tok/s，草稿接受率约 7/8。

八、复现命令

# 1) 启动服务
cd /Users/snow/local-ai/Strata/Strata
./run-q2_0.sh

# 2) 健康检查
curl http://127.0.0.1:8080/v1/health

# 3) 阶梯实测
cd /Users/snow/Documents/workspace
python3 scripts/local-test/context_capacity_probe.py --list
python3 scripts/local-test/context_capacity_probe.py --select 2

# 4) 想跑满 512K，把预算放宽
python3 scripts/local-test/context_capacity_probe.py \
  --select 2 --time-budget 900 --request-timeout 600 --max-requests 12

九、给同样配置的人的建议

场景	建议
64 GB M5 Max，日常使用	`--max-context 262144`，稳；实测 262K 无压力
想试 512K	保留 `--vram-reserve-mib 1212`，并把客户端超时/预算放宽到 600–900 s
磁盘	至少预留 80 GB。本机模型放在内置 SSD（剩余 618 GB），外接 4 TB SSD 存放 oMLX 的模型
多轮长对话	开启缓存复用，实际首 token 延迟远低于阶梯测试值
想要更高质量	官方文档：64 GB 内存 Q2_0 / IQ2_XS / IQ3_XXS 都能装，但 IQ3_XXS 需要关闭浏览器并把上下文控制在 128K 以内；IQ3_S 建议 96 GB 起

附：数据来源

硬件：system_profiler SPHardwareDataType / sysctl / diskutil
服务元数据：/v1/health、/v1/models、strata-q2_0.json、build-metal/BUILD.json
引擎日志：Strata/strata-q2_0.log
测试报告：scripts/local-test/results/run-20261020-201926-074430ec/summary.md（另有 result.json / probes.csv / probes.jsonl / meta.json）
复现性：20:27 的第二轮（run-20261020-202748-1342eaf6）得到同样的结论——256K 成功、更高阶梯超时。

抡锤者