适用设备　40 核 GPU、128GB 统一内存、546GB/s 内存带宽的 M4 Max MacBook Pro 或 Mac Studio
适用目标　在单台 Mac 上稳定运行 Qwen3.8-27B，并通过 OpenAI 兼容 API 提供给少量用户共享
基准日期　2026-08-30。Qwen3.8、DeepSeek V4 Flash 和 oMLX 仍在快速迭代，升级前应重新跑本机基准。

一、先给结论

如果目标是兼顾速度、质量、多人共享和维护成本，推荐采用下面的架构。

用户客户端
   │
   │  HTTPS + 独立 API Key
   ▼
Tailscale 私有共享层
   │
   ▼
oMLX（127.0.0.1:8000）
   │
   ├── 默认配置：Qwen3.8-27B-oQ4e-mtp
   ├── 高质量配置：Qwen3.8-27B-oQ8e-mtp
   ├── 重型配置：DeepSeek-V4-Flash-0731-2.4bit-mixed
   ├── 连续批处理
   ├── Prefix/KV Cache
   └── Lightning MTP 或 DFlash2（二选一）

默认生产配置建议如下。

项目	推荐值
推理引擎	oMLX 官方 DMG
默认模型	`Jundot/Qwen3.8-27B-oQ4e-mtp`
高质量模型	`Jundot/Qwen3.8-27B-oQ8e-mtp`
重型 Agent 模型	`mlx-community/DeepSeek-V4-Flash-0731-2.4bit-mixed`
上下文上限	64K 起步
最大并发	4 起步，根据实测决定是否升到 8
投机解码	Lightning MTP，draft depth 3
ANE Prefill	开启后运行本机 Tuner，不照抄其他机器的比例
TurboQuant KV	默认关闭
SpecPrefill	默认关闭，只放在有损实验配置中
对外访问	Tailscale 私网共享，不做公网端口转发

量化选择可以这样理解。

Q4e 是速度和多人共享档。
Q8e 是质量优先档。
BF16 是对照评估档，不适合作为共享服务默认值。
DeepSeek V4 Flash 2.4-bit 是单用户高难 Agent 档，不与 Qwen 同时常驻。

二、理解 M4 Max 的真实物理上限

2.1 内存容量决定“能不能装下”

M4 Max 的 128GB 是 CPU、GPU、操作系统共同使用的统一内存，不是 128GB 独立显存。模型服务还需要容纳下面这些内容。

模型权重
+ 每个会话独立的 KV Cache
+ Prompt Prefill 临时空间
+ ANE 编译与运行缓冲
+ Prefix/Hot Cache
+ macOS 和其他应用

Qwen3.8-27B 的大致权重占用如下。

精度	权重占用约	是否适合 128GB M4 Max	推荐用途
oQ4e 4-bit	17GB	很宽松	默认多人服务
oQ8e 8-bit	29～34GB	宽松	高质量服务
BF16	55～60GB	能运行	单用户对照测试

不要把 128GB 全部交给推理进程。共享服务至少应给 macOS 和日常应用保留 20～24GB；如果启用 ANE/CPU Sharing、多个长上下文会话或大 Hot Cache，还要继续增加余量。

2.2 内存带宽决定“每秒能生成多少 token”

稠密模型逐 token 解码时，需要反复读取大部分权重，因此单流解码通常接近内存带宽约束。

朴素解码上限 ≈ 有效内存带宽 ÷ 每轮需要读取的权重体积

M4 Max 标称带宽为 546GB/s，但实际还要扣除内核效率、缓存、算子开销、功耗和热限制。粗略预期如下。

模型精度	理论量级	无投机解码的现实量级
Q4e	约 30～34 tok/s	约 21～30 tok/s
Q8e	约 16～18 tok/s	约 13～16 tok/s
BF16	约 9～10 tok/s	约 7～10 tok/s

这解释了为什么 128GB 虽然装得下 Q8/BF16，Q4 仍然更适合低延迟服务。量化能节省容量，也能减少每个 token 必须搬运的数据量。

图 1　左栏看「装得下」，右栏看「跑得快」。BF16 在左栏最长（最占内存），在右栏最短（最慢），Q4e 恰好相反。同一次量化选择同时决定了这两件事。

2.3 投机解码为什么能突破朴素 roofline

Qwen3.8-27B 带有 MTP（Multi-Token Prediction）头。MTP 或 DFlash2 会先提出多个候选 token，再让目标模型一次验证多个 token。只要草稿接受率足够高，一轮权重读取就可能确认多个 token，从而突破“每轮只能生成一个 token”的朴素带宽上限。

需要牢记下面几件事。

MTP 与 DFlash2 都属于投机解码路径，必须二选一。
加速幅度取决于草稿接受率；代码通常比开放式对话更容易获得高接受率。
多请求批次位置不对齐时，oMLX 可能回退到普通解码。
社区峰值不能视为稳定服务承诺。

2.4 Qwen3.8 的 KV Cache 为什么相对友好

Qwen3.8-27B 的 64 层中，只有 16 层保留随 token 增长的全注意力 KV；其余 48 层是 Gated DeltaNet 固定状态。按 BF16 KV 粗算如下。

16 层 × 2（K/V）× 4 KV heads × 256 head_dim × 2 bytes
= 64 KiB/token

纯 KV 理论值如下。

上下文长度	单会话纯 KV 理论值
64K	约 4GiB
128K	约 8GiB
256K	约 16GiB

实际运行还会加入分页、块对齐、GDN 状态、元数据和临时缓冲，所以监控值会更高。模型权重可以共享，每个并发会话仍有自己的动态状态。

三、为什么选择 oMLX

oMLX 的单用户峰值未必最高。它的优势在于把共享服务所需的能力放进同一套运行栈。

Apple Silicon 原生 MLX 推理；
OpenAI Chat Completions、Responses 和 Anthropic Messages 兼容接口；
连续批处理；
Lightning MTP 与 DFlash2；
Qwen 专用 ANE Prompt Processing；
Prefix、内存热层和 SSD 缓存；
API Key 与子密钥；
模型常驻、自动装卸和 Web 管理面板；
内置吞吐、上下文、并发和质量基准。

如果只追求单用户短上下文峰值，其他实验引擎可能更快；如果要同时满足共享、缓存、鉴权、监控和维护，oMLX 更完整。

四、版本策略与升级方法

截至 2026-08-30，建议使用下面的版本策略。

路线	建议	适用场景
稳定生产	oMLX 正式版 0.6.4	Qwen3.8、DeepSeek V4 Flash 与 Lightning MTP
版本锁定	保留当前 DMG 和配置快照	新版出现性能或缓存回归时快速回退

0.6.4 已在 2026-08-29 发布，修复了连续批处理、前缀缓存恢复和 Lightning MTP 状态管理等问题。生产服务仍不应盲目自动更新，应按下面的顺序操作。

保存当前版本号和配置；
跑升级前基准；
安装新版本；
用完全相同的模型、提示和采样重跑；
出现超过 10% 的退化或稳定性问题就回退。

五、系统准备

5.1 检查设备

sw_vers
sysctl -n machdep.cpu.brand_string
system_profiler SPHardwareDataType

建议环境如下。

macOS 15.0 或更高；
40 核 GPU 的 M4 Max；
128GB 统一内存；
如果同时保留 Q4、Q8、DeepSeek 2.4-bit 和 SSD Cache，建议至少预留 280～350GB 磁盘空间；
MacBook Pro 接电使用。

5.2 电源与散热

MacBook Pro 可按下面设置。

系统设置 → 电池；
接电时能源模式设为“高功率”；
打开“显示器关闭时防止自动睡眠”；
保证底部和出风口通风。

Mac Studio 可按下面设置。

系统设置 → 节能；
打开“显示器关闭时防止自动睡眠”；
根据需要打开“网络访问唤醒”；
不要开启低功耗模式。

连续长 Prefill 会造成热浸泡。评测不同配置时，应交替测试并留出冷却时间，否则后测配置可能因降频被误判为更慢。

六、安装 oMLX

6.1 推荐使用官方 DMG

从 oMLX GitHub Releases 下载目标版本 DMG；
拖入 Applications；
启动后选择模型目录；
启动本地服务；
打开 http://127.0.0.1:8000/admin。

官方 DMG 会随应用携带经过验证的依赖和原生内核，是最少踩坑的安装方式。

6.2 为什么不推荐普通 pip 安装

普通 pip install -e . 不会自动构建 oMLX 的原生自定义内核，相关模型会回退到较慢路径。源码安装可以使用，但需要完整 Xcode，并显式执行下面的命令。

OMLX_WITH_CUSTOM_KERNEL=1 pip install -e .

本教程不建议把源码构建作为共享服务的首选维护方式。

6.3 验证服务与内核

curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/api/status

检查管理面板或状态输出中的 Qwen 原生内核、ANE 尝试状态、实际编译层数和 procedure 数量。设置显示为“开启”不等于优化路径真的执行。

七、下载模型

7.1 默认速度模型

在 oMLX Models → Download 中输入下面的仓库 ID。

Jundot/Qwen3.8-27B-oQ4e-mtp

这是默认推荐模型，约 17GB，适合 MTP、ANE Prefill 和多人共享。

7.2 高质量模型

Jundot/Qwen3.8-27B-oQ8e-mtp

Q8e 适合质量敏感任务，但在相同加速条件下通常慢于 Q4e。不要用“Q8 + 投机解码超过 Q4 朴素解码”来推断 Q8 比同样开启投机解码的 Q4 更快。

7.3 DFlash2 草稿模型（实验）

z-lab/Qwen3.8-27B-DFlash2

只有建立 DFlash2 实验配置时才下载。启用 DFlash2 后必须关闭 Lightning MTP。

7.4 FP16 克隆版（0.6.3rc2 实验）

名称含 -fp16-mtp 的变体用于 ANE、CPU 和 GPU 联合 Prefill，并非 M1/M2 专用模型。它可能增加约 4～6% Prefill 性能，也会增加约 7GB 峰值内存；是否使用应由本机 Tuner 决定。

7.5 DeepSeek V4 Flash 2.4-bit 混合量化版

mlx-community/DeepSeek-V4-Flash-0731-2.4bit-mixed

这个仓库的平均量化精度为 2.44 bpw，磁盘占用约 92.8GB。它面向 128GB Apple Silicon，保留了三个 MTP 块，并把注意力、共享专家、词嵌入和输出层保留在更高精度。它适合高难代码和 Agent 任务，暂不适合作为多人共享的默认模型。

八、全局服务配置

建议先在 Web 管理面板设置并持久化，而不是把密钥写进启动脚本。

配置项	起步值	说明
Host	`127.0.0.1`	使用 Tailscale 反向代理时不对局域网裸暴露
Port	`8000`	默认端口
Max concurrent requests	`4`	先保证交互体验，再压测 8
Chunked prefill	开	多人同时发长 Prompt 时降低阻塞
Prefill priority	`speed`	优先低延迟；超长上下文场景可改 `context`
Burst decode	`balanced`	峰值速度与流式平滑的折中
Hot cache	16～24GB	先从 16GB 起步
SSD cache	50～100GB	适合重复长会话，不提升首次冷 Prompt
Memory guard	100～104GB	给 macOS、ANE 和临时缓冲留余量
Default model	Q4e	无 model 参数时走默认配置
Pinned model	Q4e	避免首请求重新加载

不建议一开始使用 112GB memory guard。它只给系统留下约 16GB，在长 Prefill、ANE 编译或其他应用活跃时容易进入内存压力。

API 密钥

在管理面板中完成下面的操作。

设置一个只由管理员持有的主密钥；
为每个使用者创建独立 sub-key；
不在聊天、文档或仓库中保存真实密钥；
不把密钥写进 WHData、桌面、下载目录或 .env 文件；
人员退出时只撤销对应 sub-key。

九、建立四个模型配置档

9.1 `fast-shared` 默认多人配置

Model: Qwen3.8-27B-oQ4e-mtp
Max context: 65536
Max output: 8192

MTP: ON
MTP draft depth: 3
DFlash2: OFF
SpecPrefill: OFF
TurboQuant KV: OFF

ANE Prefill: ON
ANE sequence length: 2048
ANE split: 运行本机 Tuner 后应用
GDN acceleration: 由 Tuner 决定

Reasoning effort: medium

这是默认生产配置。

9.2 `quality` 质量优先配置

Model: Qwen3.8-27B-oQ8e-mtp
Max context: 65536
Max output: 8192

MTP: ON
MTP draft depth: 3
DFlash2: OFF
SpecPrefill: OFF
TurboQuant KV: OFF

ANE Prefill: 仅在 oMLX 0.6.3rc1+ 开启并验证
Reasoning effort: medium 或 xhigh

Q8 的 ANE 支持是新功能，必须通过 Tuner 和 /api/status 确认实际执行。

9.3 `dflash-experiment` DFlash2 实验配置

Target: Q4e 或 Q8e
MTP: OFF
DFlash2: ON
Draft model: z-lab/Qwen3.8-27B-DFlash2
SpecPrefill: OFF

对代码、中文说明、工具调用分别压测，不要根据单一英文代码 Prompt 决定生产配置。

9.4 `deepseek-heavy` DeepSeek 重型配置

Model: DeepSeek-V4-Flash-0731-2.4bit-mixed
Alias: deepseek-flash-local
Max context: 16384
Max output: 8192

Lightning MTP: ON
MTP draft depth: 3
DFlash2: OFF
SpecPrefill: OFF
TurboQuant KV: OFF
ANE Prefill: OFF

Max concurrent requests: 1
Pinned: OFF
TTL: 15 minutes
Reasoning effort: high

先用单并发和 16K 上下文跑通。完成内存与长时稳定性测试后，可以把并发提高到 2，并将上下文试探到 32K。不要直接照搬模型标称的 1M 上下文。

十、DeepSeek V4 Flash 2.4-bit 本地安装与对比

10.1 先认清 2.4-bit 的含义

DeepSeek-V4-Flash-0731 官方模型包含约 284B 主模型参数，连同 MTP 约为 304B，每个 token 激活约 13.8B 参数。它采用 MoE 架构，全部专家权重必须留在内存里，每一步只激活其中一部分。

MLX Community 的 2.4-bit 混合量化占用 92.8GB 十进制磁盘空间，约合 86.5GiB，平均精度为 2.44 bpw。主要路由专家使用 2-bit，注意力使用 6-bit，共享专家、词嵌入和输出层使用 8-bit，MTP 路由专家使用 3-bit。这个配方把容易受损的部分留在较高精度，同时让完整模型进入 128GB 统一内存。

它仍属于激进量化。模型仓库用 600 道 MMLU-Pro 样本做过一次同条件测试，2.4-bit 得分为 57.3%，托管全精度版本为 64.7%，相差 7.3 个百分点。这个结果只能说明精度损失真实存在，不能代替代码、中文、工具调用和长上下文任务的本机回归测试。

10.2 安装前准备

把 oMLX 更新到 0.6.4 或更高正式版。
确认模型盘至少有 120GB 可用空间。还要保留 SSD Cache 时，建议留出 180GB 以上。
退出占内存较多的浏览器、虚拟机、视频软件和本地开发容器。
在 oMLX 中卸载已加载的 Qwen Q8 或 BF16 模型。
暂时取消 Qwen Q4 的 Pin。DeepSeek 验证完成后再决定哪个模型常驻。

无需先修改 iogpu.wired_limit_mb。oMLX 在 M4 Max 基准中的模型峰值约为 88GB，128GB 机器通常可以直接加载。只有日志明确出现 Metal 分配失败，并且官方当前版本文档要求修改时，才调整系统级 GPU 有线内存限制。

10.3 在 oMLX 中下载

打开 http://127.0.0.1:8000/admin，进入 Models 和 Download，粘贴下面的仓库 ID。

mlx-community/DeepSeek-V4-Flash-0731-2.4bit-mixed

下载完成后回到模型列表。oMLX 会从 Hugging Face 缓存识别模型，API 中通常显示为下面的 ID。

deepseek-v4-flash-0731-2-4bit-mixed

给它设置别名 deepseek-flash-local，随后按 deepseek-heavy 配置档启动。首次加载要读取接近 93GB 权重，耗时明显长于 Qwen。加载期间不要同时启动另一个大模型。

10.4 验证模型与接口

先检查模型是否进入 API 列表。

curl http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer <测试sub-key>" | grep deepseek

再发送一个短请求。

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Authorization: Bearer <测试sub-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-flash-local",
    "messages": [
      {"role": "user", "content": "写一个带测试的 Python LRU 缓存，并解释时间复杂度。"}
    ],
    "reasoning_effort": "high",
    "temperature": 1.0,
    "top_p": 0.95,
    "stream": true
  }'

DeepSeek V4 Flash 0731 接受 low、high 和 max 三档 reasoning effort。Qwen 配置里的 medium 与 xhigh 不应原样复制过来。

10.5 M4 Max 实测怎样理解

oMLX 社区基准使用 40 核 GPU、128GB 内存的 M4 Max，运行 oMLX 0.6.3rc2，并开启 Lightning MTP。结果如下。

Prompt 长度	PP tok/s	TG tok/s	模型峰值内存
1K	339.4	32.6	87.8GB
4K	356.7	35.8	88.3GB
8K	349.5	35.7	88.3GB
16K	342.6	36.8	88.4GB

8K 测试的 TTFT 约为 23.4 秒，系统已用内存峰值约为 106.5GB。这个数字说明它确实能在 128GB M4 Max 上工作，也说明余量已经不宽。oMLX 0.6.4 已成为正式版，安装后仍应在同一机器上重新跑一遍，因为内核、缓存状态、温度和采样都会改变结果。

10.6 与 Qwen3.8-27B 的关键差别

项目	Qwen3.8-27B Q4e	Qwen3.8-27B Q8e	DeepSeek V4 Flash 2.4-bit
架构	27B 稠密	27B 稠密	284B MoE，约 13.8B 激活
权重或磁盘占用	约 17GB	约 29～34GB	92.8GB，约 86.5GiB
M4 Max 生成速度	常见 30～50 tok/s，开启 MTP	依接受率实测	约 33～37 tok/s，开启 MTP
建议起步上下文	64K	64K	16K，验证后试 32K
建议并发	3～4	2～3	1，验证后试 2
模型常驻	推荐 Pin	按需加载	不 Pin，设置短 TTL
主要优势	速度、余量、多人共享	质量与资源较平衡	高难代码和 Agent 能力潜力
主要代价	4-bit 质量损失	速度下降	内存占用高，2.44 bpw 精度损失明显

两者的生成速度可能很接近，原因却不同。Qwen Q4 读取的是较小的稠密权重，DeepSeek 依靠 MoE 路由和 MTP，每一步只计算少量专家。DeepSeek 的 284B 总参数仍要常驻内存，因此它的并发余量远小于 Qwen。表中的速度来自不同测试条件，最终选择应以同一台机器、同一组提示和同一采样参数的结果为准。

这台机器作为共享服务时，Qwen Q4e 继续承担默认入口。DeepSeek 适合通过模型别名提供给少数高难任务，空闲 15 分钟后卸载。不要同时 Pin Qwen Q8 与 DeepSeek，也不要承诺 1M 本地上下文。

十一、采样与思考模式

11.1 Thinking 日常档

enable_thinking: true
reasoning_effort: medium
temperature: 1.0
top_p: 0.95
top_k: 20

降低 reasoning_effort 不会提高 tok/s，但会减少思考 token，从而显著缩短总耗时。

11.2 高难任务档

enable_thinking: true
reasoning_effort: xhigh
temperature: 1.0
top_p: 0.95
top_k: 20

只在复杂推理、难代码和高价值任务中使用。不要把 xhigh 设为所有用户的无条件默认值。

11.3 非 Thinking 档

enable_thinking: false
temperature: 0.7
top_p: 0.80
presence_penalty: 1.5

适合提取、改写、结构化输出和简单问答。不同客户端可能会覆盖服务端参数，应在请求日志中确认最终生效值。

十二、通过 Tailscale 共享

本节假设本机共享层已经安装完成。

12.1 推荐使用 Tailscale Serve 反向代理

保持 oMLX 只监听 127.0.0.1:8000。

tailscale serve --bg http://127.0.0.1:8000
tailscale serve status

Tailscale 会返回一个私有 HTTPS 地址，例如下面这样。

https://your-mac.example.ts.net

客户端配置如下。

Base URL: https://your-mac.example.ts.net/v1
API Key: 该用户自己的 sub-key
Model: 以 /v1/models 实际返回的 ID 为准

不要使用 Tailscale Funnel，也不要在路由器上把 8000 端口转发到公网。

12.2 如果使用节点共享直接访问

如果现有方案要求用户直接访问 Tailscale 节点 IP，优先让 oMLX 绑定具体的 Tailscale 100.x.x.x 地址，而不是 0.0.0.0。后者还会同时暴露到局域网的所有网卡。

12.3 API 测试

先查询模型 ID。

curl https://your-mac.example.ts.net/v1/models \
  -H "Authorization: Bearer <用户自己的sub-key>"

再发送流式请求。

curl https://your-mac.example.ts.net/v1/chat/completions \
  -H "Authorization: Bearer <用户自己的sub-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<从/v1/models复制的模型ID>",
    "messages": [
      {"role": "user", "content": "请用一句话说明服务是否正常。"}
    ],
    "stream": true
  }'

十三、上线前必须做的基准测试

13.1 测试矩阵

至少测试以下组合。

配置	4K	16K	64K	单路	4 并发
Q4e，无 MTP	✓	✓	✓	✓	✓
Q4e，MTP depth 3	✓	✓	✓	✓	✓
Q8e，MTP depth 3	✓	✓	✓	✓	✓
Q8e，DFlash2	✓	✓	✓	✓	✓
Q4e，ANE 开/关	✓	✓	✓	✓	不适用
DeepSeek 2.4-bit，MTP	✓	✓	验证后再测	✓	先测 2 并发

13.2 记录指标

不能只看 TG tok/s。至少记录下面这些指标。

PP tok/s 表示 Prompt 预填充速度；
TG tok/s 表示输出速度；
TTFT 表示首 token 延迟；
E2E 表示完整请求耗时；
4 并发聚合吞吐；
每用户平均吞吐和 P95 延迟；
MTP/DFlash 接受率；
峰值内存；
ANE 实际执行层数；
Prefix Cache 命中量；
30 分钟持续负载后的热降频。

13.3 使用真实任务做质量回归

准备 30～50 个自己的真实 Prompt，至少覆盖下面这些任务。

中文长文理解；
代码生成与修复；
JSON/工具调用；
长上下文信息检索；
需要多步推理的问题；
拒答、安全和边界案例。

对比 Q4e、Q8e、DeepSeek 2.4-bit 和必要时的 BF16。只有当 Q8 或 DeepSeek 在真实任务上稳定改善到值得牺牲速度与内存时，才扩大它的使用范围。

十四、性能预期与席位规划

以下是合理区间，不是服务等级承诺。

场景	合理预期
Q4e 普通单路	约 21～30 tok/s
Q4e + MTP	常见约 30～50 tok/s；高接受率代码可能更高
Q8e 普通单路	约 13～16 tok/s
Q8e + 投机解码	依接受率而定，必须本机实测
DeepSeek 2.4-bit + MTP	M4 Max 已测约 33～37 tok/s，建议单并发起步
冷 20K Agent Prompt	可能需要数十秒 Prefill
前缀缓存命中的后续轮次	可从分钟级降到秒级，但仍取决于变化尾部

席位建议如下。

2～3 个长 Prompt、Agentic Coding 用户的体验较可靠；
4 个普通交互用户适合作为默认并发上限；
8 个短对话用户可以压测，但单用户延迟会明显上升；
DeepSeek 2.4-bit 先服务 1 个重型用户，验证稳定后最多尝试 2 个轻量用户；
团队级高频 Agent 服务应考虑 GPU 服务器或本地与云端混合路由。

连续批处理提高的是聚合吞吐，不等于每个用户都获得单路峰值。Prefill 很长时，用户之间仍会互相影响。

十五、运维与监控

15.1 健康检查

curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer <测试sub-key>"

15.2 日志位置

~/.omlx/logs/server.log

重点搜索下面这些关键词。

rg -i "error|warning|memory|evict|mtp|dflash|ane|cache" ~/.omlx/logs/server.log

15.3 每周检查

是否发生模型自动卸载或重复加载；
是否出现内存硬限制和请求中止；
MTP 接受率是否长期过低；
Prefix Cache 是否实际命中；
用户是否频繁发送超长上下文；
SSD Cache 是否异常增长；
P95 TTFT 是否持续恶化；
macOS 是否在负载期间进入睡眠或低功耗模式。

十六、常见故障排查

症状	常见原因	处理
Q8 只有 13～16 tok/s	正常带宽约束	开 MTP/DFlash2，或改用 Q4e
开启 ANE 后没有变化	内核缺失、量化不兼容、ANE 没实际执行	查 `/api/status` 和日志，运行 Tuner
MTP 开启但速度不升	模型缺 MTP 张量、draft depth 未生效、接受率低、并发回退	确认模型 ID、depth=3、日志中的接受率
请求中途停顿	TurboQuant 与 MTP 组合、SSD Cache、热降频	先关 TurboQuant，再对比冷/热机结果
400 reasoning effort	客户端传了不支持的 `high`	改为 `xhigh`、`medium` 或 `low`
长 Prompt 被拒绝或模型被卸载	Memory guard 太紧、并发/上下文过大	降并发或上下文，减少 Hot Cache，留更多系统余量
第二轮仍完整 Prefill	Prompt 前缀发生变化、缓存未命中、客户端注入动态系统字段	比较请求前缀，检查缓存命中日志
远端访问失败	Host 绑定方式与 Tailscale 模式不匹配	Serve 模式用 127.0.0.1；直连模式绑定具体节点 IP
多人时 MTP 消失	批次位置不对齐，运行时回退	观察日志；以并发实测而非单路结果规划容量
DeepSeek 下载后不出现在模型列表	oMLX 版本过旧、下载未完成、缓存目录未被扫描	升级到 0.6.4，确认 18 个分片完整，重启服务
DeepSeek 加载时 Metal OOM	Qwen 仍在常驻、Hot Cache 太大、其他应用占内存	卸载其他模型，清理 Hot Cache，退出大内存应用后重试
DeepSeek 返回 reasoning effort 错误	复制了 Qwen 的 `medium` 或 `xhigh`	改用 `low`、`high` 或 `max`
DeepSeek 声称支持 1M 却跑不动	标称上下文超出 128GB 机器的现实内存余量	从 16K 起步，只在基准通过后提高到 32K

十七、最终上线检查单

安装

使用官方 oMLX DMG
记录当前 oMLX、MLX 和 macOS 版本
验证 Qwen 原生内核状态
模型和缓存位于本机高速 SSD

模型

Q4e 作为默认模型
Q8e 作为质量配置，而非无条件默认
DeepSeek 2.4-bit 按需加载，不与 Qwen Q8 同时 Pin
MTP 与 DFlash2 没有同时开启
SpecPrefill 默认关闭
TurboQuant KV 默认关闭
ANE Tuner 在本机运行并验证实际执行
DeepSeek 使用 low、high 或 max reasoning effort

服务

最大并发从 4 起步
单用户上下文上限为 64K
给 macOS 保留至少 20～24GB
Q4e 模型 Pin 常驻
Prefix Cache 开启并确认命中
日志和健康检查可访问
DeepSeek 从单并发、16K 上下文起步

安全

oMLX 默认只监听 127.0.0.1
通过 Tailscale 私网共享
不做公网端口转发
每个用户一个 sub-key
管理员主密钥不共享
知识库和脚本中没有真实密钥

验收

完成 4K、16K、64K 单路测试
完成 4 并发测试
完成 30 分钟持续负载测试
完成 Q4/Q8 真实任务质量对比
完成 DeepSeek 2.4-bit 与 Qwen 的同题质量回归
完成远端客户端端到端测试
记录上线基线，供升级后对照

十八、参考资料

版本记录

版本	日期	说明
1.1	2026-08-30	增加 DeepSeek V4 Flash 0731 2.4-bit 混合量化版的安装、配置、实测与 Qwen 对比
1.0	2026-08-24	首版覆盖选型、安装、调优、共享、基准、运维与排障