[实测]m5 ultra 256G ds v4.1 flash oq3.5 97toks | qwen3.8 flash next oq6 143toks
-
论坛第一帖，初来乍到，希望能和各位大佬多多分享、交流学习！
新人发帖，难免有不足之处，还请大家多多包涵，轻喷轻喷！
10天前拿到mac studio m5 ultra 256G 64GPU 几乎搜遍了现在全网所有m5的优化方案, 推理引擎选择omlx ,主要是因为底子好,缓存优化,算子开箱即用,基本上也是最优了. 起点高了后期优化更加游刃有余, 不用重复造轮子.
优化过程总结:
qwen3.8 flash next 优化方案很多, 权重全部驻留内存, 开箱成绩已经很好了, 稍微优化一下缓存, 成绩持平并且小幅领先网上公布的 m5 ultra 80GPU 的成绩.deepseek v4.1 flash 的优化过程就多了一点点曲折, 主要优化工作都花在内存的管理. 得益于这代mac studio 挤破牙膏的SSD 升级, 磁盘读写性能达到13GB/s , v4.1 的engram 全部使用SSD卸载+异步预读, 对性能的影响可以忽略不计. 模型权重元数据无损压缩又减少7.9G, 这样内存常驻优化到了216G, 注意这是平均q3.5级别的权重! 552B总参数, 完整保留dspark和视觉, 跑这个模型我想不出比m5ultra更具性价比的方案了.
最后是测试总结. 稍后我还想开贴详细描述一下优化过程, 我也会把代码放上github.
以下按 2026-10-08 已完成的最终验收记录整理。
模型权重卡片
项目 DeepSeek V4.1 Flash LSQ Qwen3.8 Flash Next oQ6e MTP 权重 本地 DeepSeek-V4.1-Flash-LSQ3-G128-MLX，从官方固定版本重建mlx-community/oQ6e-mtp 权重卡 参数口径 552B 主干＋196B Engram；预填充激活约 8B，解码约 16B 125B 主干＋51B n-gram＋4B MTP，完整包约 180B；激活约 6B。官方卡 量化 主专家 LSQ 3-bit/G128，其他模块混合精度；完整保留 DSpark 和视觉 oQe imatrix，默认 6-bit/G64；部分模块采用 8-bit 或其他分组，保留 MTP 本地权重体积 412.61 GiB，含 Engram；优化后非 Engram 常驻权重 215.58 GiB 140.11 GiB，28 个 safetensors 分片 DeepSeek 的体积和转换口径见权重证据。
推理框架与关键配置
共同测试机器为 Apple M5 Ultra，30 核 CPU、64 核 GPU、256 GiB 统一内存，macOS 27.0.1。
配置 DeepSeek Qwen 框架 oMLX 0.7.0.dev4＋tacos8me 补丁；MLX 0.32.3 dev；核心提交 78a5a474oMLX 0.7.0＋社区补丁；MLX 0.32.2；核心提交 d542b0daMTP DSpark 开启，每轮草稿 4 tokens，异步执行 fixed depth 3＋P2 prompt lookup 权重驻留 主模型、DSpark、视觉驻留；Engram 大表在 SSD 专家、PLE/ngram 全部驻留 预填充分块 8192 tokens 8192 tokens，缓存边界可能进一步切分 服务上下文上限 1,048,576 tokens 262,144 tokens 最新服务 并发上限 8；3 GiB 精确前缀缓存，支持重启恢复 并发上限 8；8K 快照＋尾部/公共前缀缓存，SSD 缓存预算 50GB 内存保护 进程与 wired 上限 240 GiB 进程保护 232 GiB，wired 上限 240 GiB 正式性能计时使用 temperature=0；Qwen 关闭 thinking，当前日常服务默认 temperature=1。
定制优化的简单概况
- **DeepSeek：**无损压缩量化元数据，并在 Metal 内核中直接恢复计算；配合 CED、异步 DSpark 和精确前缀缓存。常驻权重减少 7.90 GiB，最后一轮预填充优化提升约 4.21%。
- **Qwen：**采用 QSA/NAX、固定深度 MTP 和提示词匹配，再保存真实 GDN 尾部及公共前缀状态，减少重复预填充。最终选择 PLE 全驻留方案。
最终性能数据
下面是预热后、无前缀命中、单请求、每次生成 512 tokens的结果。DeepSeek 使用几何平均，Qwen 使用中位数；提示词不同，不构成严格的模型间对照。
模型及测试口径 输入长度 Prefill tokens/s Decode tokens/s 首 token 延迟 DeepSeek，三场景综合 8K 2196.22 76.07 3.774 s DeepSeek，代码场景 16K 2203.40 94.40 7.495 s DeepSeek，代码场景 32K 2194.11 97.23 15.022 s Qwen，完整串行矩阵 2K 2812.28 143.45 0.736 s Qwen，完整串行矩阵 8K 3884.35 134.54 2.128 s Qwen，完整串行矩阵 32K 3910.28 124.63 8.443 s Qwen，最终前缀版本复核 32K 3807.32 129.06 8.671 s DeepSeek 的 8K 三场景分别为代码 91.22、营销文本 71.59、视频/computer-use 计划文本 67.40 tokens/s。最终 A/B 共 32 次正式请求，另有 10 次热身。
Qwen 完整矩阵每组 5 次，采用 MTP＋lookup 配置，测于前缀优化前；最终前缀版本的 32K 冷请求复核为 3 次。
缓存命中后的最终表现：
场景 冷请求 缓存命中后 实际复用 DeepSeek，65,520-token 请求总耗时 43.682 s 5.751 s；重启恢复后 4.588 s 57,344 tokens Qwen，7792-token 重复提示词 TTFT 2.132 s 0.160 s 7785 tokens Qwen，32K 重复提示词 TTFT 8.671 s 0.281 s 32,761 tokens Qwen 最终缓存命中时，约 8K/32K 的解码速度分别为 146.18/138.11 tokens/s。
其他完成的测试：- **内存：**DeepSeek 最终单请求 A/B 采样峰值最高 225.73 GiB；Qwen 前缀优化前完整运行峰值 158.83 GiB，最终前缀版本未重新采集峰值。
- **真实代码 Agent：**DeepSeek 的 Hermes/DSH 单项功能任务耗时分别为 158.37/302.99 秒，各自独立隐藏测试均 5/5 通过。
- **并发：**两组最新服务均通过 8 路请求及缓存回归；这些属于短请求正确性验收，尚无最终版本的持续 8 路吞吐基准。
更新 2026-10-10
Deepseek v4.1 flash 的量化权重上传至 huggingface
https://huggingface.co/gnahzhang/DeepSeek-V4.1-Flash-LSQ3-G128-MLX本仓库发布已有的混合 LSQ3-G128 MLX 权重，并附加 120 个路由专家投影的精确元数据字典。原始量化有损；本次压缩对既有权重的 BF16 scale/bias 位模式逐位无损，整数权重编码不变。常驻模型张量从 223.481 降至 215.581 GiB，节省 7.900 GiB。发布包保留原始分片、SSD Engram 表及回退原件，因此下载总量为 420.53 GiB，不等于常驻内存大小。
Deepseek v4.1 flash 与 Qwen3.8 flash next oQ6 的复现代码也上传到了 github
https://github.com/gnahz/omlx-flash-optimizations -
论坛第一帖，初来乍到，希望能和各位大佬多多分享、交流学习！
新人发帖，难免有不足之处，还请大家多多包涵，轻喷轻喷！10天前拿到mac studio m5 ultra 256G 64GPU 几乎搜遍了现在全网所有m5的优化方案, 推理引擎选择omlx ,主要是因为底子好,缓存优化,算子开箱即用,基本上也是最优了. 起点高了后期优化更加游刃有余, 不用重复造轮子.
优化过程总结:
qwen3.8 flash next 优化方案很多, 权重全部驻留内存, 开箱成绩已经很好了, 稍微优化一下缓存, 成绩持平并且小幅领先网上公布的 m5 ultra 80GPU 的成绩.deepseek v4.1 flash 的优化过程就多了一点点曲折, 主要优化工作都花在内存的管理. 得益于这代mac studio 挤破牙膏的SSD 升级, 磁盘读写性能达到13GB/s , v4.1 的engram 全部使用SSD卸载+异步预读, 对性能的影响可以忽略不计. 模型权重元数据无损压缩又减少7.9G, 这样内存常驻优化到了216G, 注意这是平均q3.5级别的权重! 552B总参数, 完整保留dspark和视觉, 跑这个模型我想不出比m5ultra更具性价比的方案了.
最后是测试总结. 稍后我还想开贴详细描述一下优化过程, 我也会把代码放上github.
以下按 2026-10-08 已完成的最终验收记录整理。
模型权重卡片
项目 DeepSeek V4.1 Flash LSQ Qwen3.8 Flash Next oQ6e MTP 权重 本地 DeepSeek-V4.1-Flash-LSQ3-G128-MLX，从官方固定版本重建mlx-community/oQ6e-mtp 权重卡 参数口径 552B 主干＋196B Engram；预填充激活约 8B，解码约 16B 125B 主干＋51B n-gram＋4B MTP，完整包约 180B；激活约 6B。官方卡 量化 主专家 LSQ 3-bit/G128，其他模块混合精度；完整保留 DSpark 和视觉 oQe imatrix，默认 6-bit/G64；部分模块采用 8-bit 或其他分组，保留 MTP 本地权重体积 412.61 GiB，含 Engram；优化后非 Engram 常驻权重 215.58 GiB 140.11 GiB，28 个 safetensors 分片 DeepSeek 的体积和转换口径见权重证据。
推理框架与关键配置
共同测试机器为 Apple M5 Ultra，30 核 CPU、64 核 GPU、256 GiB 统一内存，macOS 27.0.1。
配置 DeepSeek Qwen 框架 oMLX 0.7.0.dev4＋tacos8me 补丁；MLX 0.32.3 dev；核心提交 78a5a474oMLX 0.7.0＋社区补丁；MLX 0.32.2；核心提交 d542b0daMTP DSpark 开启，每轮草稿 4 tokens，异步执行 fixed depth 3＋P2 prompt lookup 权重驻留 主模型、DSpark、视觉驻留；Engram 大表在 SSD 专家、PLE/ngram 全部驻留 预填充分块 8192 tokens 8192 tokens，缓存边界可能进一步切分 服务上下文上限 1,048,576 tokens 262,144 tokens 最新服务 并发上限 8；3 GiB 精确前缀缓存，支持重启恢复 并发上限 8；8K 快照＋尾部/公共前缀缓存，SSD 缓存预算 50GB 内存保护 进程与 wired 上限 240 GiB 进程保护 232 GiB，wired 上限 240 GiB 正式性能计时使用 temperature=0；Qwen 关闭 thinking，当前日常服务默认 temperature=1。
定制优化的简单概况
- **DeepSeek：**无损压缩量化元数据，并在 Metal 内核中直接恢复计算；配合 CED、异步 DSpark 和精确前缀缓存。常驻权重减少 7.90 GiB，最后一轮预填充优化提升约 4.21%。
- **Qwen：**采用 QSA/NAX、固定深度 MTP 和提示词匹配，再保存真实 GDN 尾部及公共前缀状态，减少重复预填充。最终选择 PLE 全驻留方案。
最终性能数据
下面是预热后、无前缀命中、单请求、每次生成 512 tokens的结果。DeepSeek 使用几何平均，Qwen 使用中位数；提示词不同，不构成严格的模型间对照。
模型及测试口径 输入长度 Prefill tokens/s Decode tokens/s 首 token 延迟 DeepSeek，三场景综合 8K 2196.22 76.07 3.774 s DeepSeek，代码场景 16K 2203.40 94.40 7.495 s DeepSeek，代码场景 32K 2194.11 97.23 15.022 s Qwen，完整串行矩阵 2K 2812.28 143.45 0.736 s Qwen，完整串行矩阵 8K 3884.35 134.54 2.128 s Qwen，完整串行矩阵 32K 3910.28 124.63 8.443 s Qwen，最终前缀版本复核 32K 3807.32 129.06 8.671 s DeepSeek 的 8K 三场景分别为代码 91.22、营销文本 71.59、视频/computer-use 计划文本 67.40 tokens/s。最终 A/B 共 32 次正式请求，另有 10 次热身。
Qwen 完整矩阵每组 5 次，采用 MTP＋lookup 配置，测于前缀优化前；最终前缀版本的 32K 冷请求复核为 3 次。
缓存命中后的最终表现：
场景 冷请求 缓存命中后 实际复用 DeepSeek，65,520-token 请求总耗时 43.682 s 5.751 s；重启恢复后 4.588 s 57,344 tokens Qwen，7792-token 重复提示词 TTFT 2.132 s 0.160 s 7785 tokens Qwen，32K 重复提示词 TTFT 8.671 s 0.281 s 32,761 tokens Qwen 最终缓存命中时，约 8K/32K 的解码速度分别为 146.18/138.11 tokens/s。
其他完成的测试：- **内存：**DeepSeek 最终单请求 A/B 采样峰值最高 225.73 GiB；Qwen 前缀优化前完整运行峰值 158.83 GiB，最终前缀版本未重新采集峰值。
- **真实代码 Agent：**DeepSeek 的 Hermes/DSH 单项功能任务耗时分别为 158.37/302.99 秒，各自独立隐藏测试均 5/5 通过。
- **并发：**两组最新服务均通过 8 路请求及缓存回归；这些属于短请求正确性验收，尚无最终版本的持续 8 路吞吐基准。
更新 2026-10-10
Deepseek v4.1 flash 的量化权重上传至 huggingface
https://huggingface.co/gnahzhang/DeepSeek-V4.1-Flash-LSQ3-G128-MLX本仓库发布已有的混合 LSQ3-G128 MLX 权重，并附加 120 个路由专家投影的精确元数据字典。原始量化有损；本次压缩对既有权重的 BF16 scale/bias 位模式逐位无损，整数权重编码不变。常驻模型张量从 223.481 降至 215.581 GiB，节省 7.900 GiB。发布包保留原始分片、SSD Engram 表及回退原件，因此下载总量为 420.53 GiB，不等于常驻内存大小。
Deepseek v4.1 flash 与 Qwen3.8 flash next oQ6 的复现代码也上传到了 github
https://github.com/gnahz/omlx-flash-optimizations -
-
Qwen3.8 Flash Next oQ6e MTP , Q6 品質應該蠻好的, 看能不能和 DeepSeek V4.1 Flash LSQ 相對測試 分享一下體感經驗 或者實例比較下 很好奇哪一個輸出品質比較好
-
画一个3D的 鹈鹕在海边公路骑自行车动画，用HTML5及必要的技术来展示，要求细节拉满，有美感，比例正确60帧不卡顿，默认从左后方向45度视角，有日夜切换按钮，太阳和月亮会随时间变化 运动（大概是20倍于现实中的时间流逝）,鹈鹕左侧的路面增加一些花花草草，海里增加一些小鱼时不时的跃出水面，沙滩上有螃蟹及海螺，岸边有人散步，海里有些人游泳，远处有一些渔船，海上有一些海鸥随机飞翔。 夜晚天上加一些星星，保存为pelican.html（本机默认下载好three.js，如果没有也可以自动从中国CDN快速加载）。游戏要有server.py，启动后随机寻找一个本机的空闲端口作为服务器，并自动从默认浏览器打开让用户试玩.可以试试3D鹈鹕提示词，看多久可以完成，效果如何。
-
，
T terry 固定了此主题
-
-
-
画一个3D的 鹈鹕在海边公路骑自行车动画，用HTML5及必要的技术来展示，要求细节拉满，有美感，比例正确60帧不卡顿，默认从左后方向45度视角，有日夜切换按钮，太阳和月亮会随时间变化 运动（大概是20倍于现实中的时间流逝）,鹈鹕左侧的路面增加一些花花草草，海里增加一些小鱼时不时的跃出水面，沙滩上有螃蟹及海螺，岸边有人散步，海里有些人游泳，远处有一些渔船，海上有一些海鸥随机飞翔。 夜晚天上加一些星星，保存为pelican.html（本机默认下载好three.js，如果没有也可以自动从中国CDN快速加载）。游戏要有server.py，启动后随机寻找一个本机的空闲端口作为服务器，并自动从默认浏览器打开让用户试玩.可以试试3D鹈鹕提示词，看多久可以完成，效果如何。
画一个3D的 鹈鹕在海边公路骑自行车动画，用HTML5及必要的技术来展示，要求细节拉满，有美感，比例正确60帧不卡顿，默认从左后方向45度视角，有日夜切换按钮，太阳和月亮会随时间变化 运动（大概是20倍于现实中的时间流逝）,鹈鹕左侧的路面增加一些花花草草，海里增加一些小鱼时不时的跃出水面，沙滩上有螃蟹及海螺，岸边有人散步，海里有些人游泳，远处有一些渔船，海上有一些海鸥随机飞翔。 夜晚天上加一些星星，保存为pelican.html（本机默认下载好three.js，如果没有也可以自动从中国CDN快速加载）。游戏要有server.py，启动后随机寻找一个本机的空闲端口作为服务器，并自动从默认浏览器打开让用户试玩.可以试试3D鹈鹕提示词，看多久可以完成，效果如何。
双7900XTX 35分钟
-
，
M Marck Wong 引用了 此主题
-
@terry 谢谢版主置顶的支持
更新晚了一天. 因为整理这个补丁和文档还是需要花些时间的,特别是需要审核检查错误,花了一些时间才把补丁和复现过程整理好. 上传到hf 又花了一些时间, 修改那个模型卡片的参数也折腾了一下才弄明白用法.下一步的优化方向, 我还是想从减少内存方面出发, 因为统一内存还是很宝贵的, 当前版本节省的8G可以多做很多事情, 用来开harness, 缓存都能换来实际的生产力. 所以下一步还是看看能不能再压榨一点出来.
大家有什么好的优化方向, 或者对于量化质量的测试想法都发出来, 大家一起讨论, 让mac的ai生态可以活跃一些.
3D鹈鹕 这个测试我稍后就更新一下模型表现, blender 我也想稍后测试一下效果. 等完成了就更新出来. coming
soonslowly -
-
-
确实忘记提功耗了，因为吐字时的功耗才 60w 预填充阶段瞬时 120w 所以我现在已经不考虑功耗问题了。
算力的选择我现在确实有点后悔没有选择 80GPU 的型号，实测感觉 64GPU 填不满 1.2T 带宽。这只是体感并没有测试，如果有 80GPU 型号的坛友也测试一下我的猜测。后续我可能考虑入一台 80GPU 的型号
价格确实是贵的，但是从性价比讲，对我个人来说 mac studio 比 dgx spark x2 要有用一些
-
@Jw-Zhang 你覺得作為LLM server+工作站( coding+3D+媒體), m5 ultra 256G是否高性價比? 因為看著網友各種GPU+高系統RAM的配置strata跑qwen3.8 flash next, 雖然入門價格低, 速度也快, 但只能跑1-2個模型, 配上linux/ubuntu也很多軟體跑不了/要折騰, 還要算上全速跑的600W起跳耗電, 每月電費至少多500-600塊, 還有噪音+熱量, 想想看其實mac studio挺值得, 而且omlx/vllm生態會一路優化進步.
@Henry-Chiu-0 我觉需要规划好内存的使用，多少给 LLM，多少留给生产力工具，harness 工具也要留充足的内存，是无头服务器还是主力机工作站。如果主力模型是 deepseek 4.1 可能留给生产力工具的内存就不太多了，后续如果有 320G 统一内存型号，我觉得可选，512G 我觉得没有性价比了，我能想到的需求是大型 3D 视频工作站本地模型+建模渲染工具，可能需要 512G
关于这个 1.2T 的带宽，它是整块SoC的峰值带宽。在Ultra芯片上跑单路解码流，基本无法把带宽跑满，根据我的测试结果推测，通常只能达到峰值的70%-80%。MoE模型会进一步降低带宽利用率：每个token需要读取分散分布的不同专家权重，内存读取并非连续访问。
-
，系统 取消固定了此主题
-
-
-
，T terry 固定了此主题
-
-
-
-
-
如果跑comfyui速度能跟上N卡, 真是神機了, 期望社区生态能開發出來
@Henry-Chiu-0 ComfyUI对N卡的优化一直事最顶级的。但无法突破物理限制。
️
版主审定：本帖设为精华，作者 +5 积分奖励，希望再接再厉！