Mac生态跑文生图视频以有可能了吗？M5 Max 40GPU 64G
-
用oMLX加载MTPLX优化的模型，关闭思考，启用Lightning MTP
Model用的是Qwen3.8-27B-MTPLX-Optimized-Speed （19.5G）
执行简单回话，任务，写个贪吃蛇小游戏
一次成功，图形画面也不错
数据还挺漂亮。
性能测试结果：
智力测试结果：
智能基准对比模式 抽样 Qwen3.8-27B-MTPLX-Optimized-Speed
MMLU 抽样 1000/14042 83.6%
CMMLU 抽样 300/11582 80.7%
HELLASWAG 抽样 200/10042 93.0%
TRUTHFULQA 全量 817 84.8%
ARC_CHALLENGE 抽样 300/1172 96.7%
WINOGRANDE 抽样 300/1267 79.0%
GSM8K 抽样 100/1319 91.0%
HUMANEVAL 全量 164 91.5%
MBPP 抽样 200/500 80.0%
LIVECODEBENCH 抽样 100/1055 60.0%
BBQ 抽样 300/10864 92.7%
SAFETYBENCH 抽样 300/11435 86.3%--- 详情 ---
模型：Qwen3.8-27B-MTPLX-Optimized-Speed
基准测试 准确率 正确 总数 Time(s) 思考MMLU 83.6% 836 1000 856 否
CMMLU 80.7% 242 300 93.5 否
HELLASWAG 93.0% 186 200 82.9 否
TRUTHFULQA 84.8% 693 817 245.3 否
ARC_CHALLENGE 96.7% 290 300 106.8 否
WINOGRANDE 79.0% 237 300 79.7 否
GSM8K 91.0% 91 100 515 否
HUMANEVAL 91.5% 150 164 375.9 否
MBPP 80.0% 160 200 535.2 否
LIVECODEBENCH 60.0% 60 100 2561 否
BBQ 92.7% 278 300 86.2 否
SAFETYBENCH 86.3% 259 300 91 否可能是关闭思考的关系，LiveCodeBench测试只拿到了60%
别的基本都还挺高 -
-
-
-
-
-
-
半实战测试，让Qwen3.8-27B 写了个射击小游戏；反复修一些小bug；调整关卡难度，物品掉落折腾了半天。期间大部分由hermes调配完成。不知道是不是DSH对非自家模型适配的调配机制问题。给了他几个请求发一起，他一通思考然后就爆上下文罢工了。期间还报错在自己workspace内的文件他自己无法修改，最后爆掉了。
还请DSH大神指导。
然后我让Hermes去查，就是可以修改的，没问题。是DSH打开文件，又开了个复件自己修改自己被拒。。。我也是没想明白DSH怎么把自己绕进去的。
然后就让Hermes持续开发完善了小半天。长上下文持续工作下，输出就降到了33 Tok/s。
今天让35B-A3B开发了第四关，很顺利的一把完成。没遇上什么问题。因为上下文压力也比较小，输出在62 Tok/s
也算模拟小规模实际开发时，2个模型大概的能力展示。27B稠密模型这个速度也还算是可以接受，就是心理预期知道，实际能力很难维持50 Tok/s左右的。
-
-
Mac M2 Max测试本地模型Qwen3.8-27B-4bit、Qwen3.8-27B-Uncensored-oQ4e-mtp模型在 oMLX（Mac M2 Max 环境） 下的横向深度对比：oMLX - LLM inference, optimized for your Mac
https://github.com/jundot/omlx
Benchmark Model: Qwen3.8-27B-4bit
Engine: Auto
Context: 代码（Python）
================================================================================
Single Request Results
Test TTFT(ms) TPOT(ms) pp TPS tg TPS E2E(s) Throughput Peak Mem
pp1024/tg128 9048.7 50.86 113.2 tok/s 19.8 tok/s 15.531 74.2 tok/s 15.85 GB
pp4096/tg128 34039.8 52.03 120.3 tok/s 19.4 tok/s 40.670 103.9 tok/s 17.10 GB
Continuous Batching
预处理1024 / 生成128
Batch tg TPS Speedup pp TPS pp TPS/req TTFT(ms) E2E(s)
1x 19.8 tok/s 1.00x 113.2 tok/s 113.2 tok/s 9048.7 15.531
2x 33.6 tok/s 1.70x 90.6 tok/s 45.3 tok/s 17273.3 30.233
4x 62.8 tok/s 3.17x 78.3 tok/s 19.6 tok/s 31000.7 60.467
oMLX - LLM inference, optimized for your Mac
https://github.com/jundot/omlx
Benchmark Model: Qwen3.8-27B-Uncensored-oQ4e-mtp
Engine: Auto
Context: 代码（Python）Single Request Results
Test TTFT(ms) TPOT(ms) pp TPS tg TPS E2E(s) Throughput Peak Mem
pp1024/tg128 8955.1 50.04 114.3 tok/s 20.1 tok/s 15.330 75.1 tok/s 22.34 GB
pp4096/tg128 33851.1 57.56 121.0 tok/s 17.5 tok/s 41.180 102.6 tok/s 23.70 GBContinuous Batching
预处理1024 / 生成128Batch tg TPS Speedup pp TPS pp TPS/req TTFT(ms) E2E(s)
1x 20.1 tok/s 1.00x 114.3 tok/s 114.3 tok/s 8955.1 15.330
2x 28.8 tok/s 1.43x 91.5 tok/s 45.8 tok/s 16951.1 31.272
4x 47.3 tok/s 2.35x 81.3 tok/s 20.3 tok/s 30249.7 61.207
数据深度分析如下：一、 关键指标对比（oQ4e-mtp vs. 常规 4bit）指标常规 4bit 模型oQ4e-mtp 模型变化分析内存峰值 (Peak Mem)15.85 - 17.10 GB22.34 - 23.70 GB大增约 6.5 GB (+38%)，接近纯 6-bit 的开销单生成速度 (tg TPS)19.8 tok/s20.1 tok/s (pp1024)17.5 tok/s (pp4096)基础生成速度相当，但在长上下文下略有所衰减Prefill 吞吐量 (pp TPS)113.2 ~ 120.3 tok/s114.3 ~ 121.0 tok/s首字响应（TTFT）性能几乎完全一致Continuous Batching (4x)62.8 tok/s (3.17x)47.3 tok/s (2.35x)并发性能明显下降 (-25%)二、 性能与技术细节拆解为什么内存增加到了 22.34 - 23.70 GB？oQ4e 混合精度量化：它不是普通的均匀 4-bit 量化，而是通过 importance-matrix（重要性矩阵 calibration）对关键层/注意力层提高了精度（提升至 5-bit 或 fp16），因此实际权重体积接近 6-bit 量化。 MTP (Multi-Token Prediction / 投机/多Token预测模块)：附加了 MTP 预测头，这需要额外的显存空间用于加载加速权重和维持额外的 KV Cache。 为什么单生成速度没有大幅提升？MTP 本质是通过 Speculative Decoding（投机采样）以计算换速度。但在 M2 Max（显存带宽约 300-400 GB/s） 这种带宽受限设备上，当权重增长到 22GB+ 时，内存带宽瓶颈冲淡了 MTP 带来的并行收益。长上下文（pp4096）下生成速度降至 17.5 tok/s，也是因为更高的显存占用导致 Cache 访问开销变大。为什么多并发 (Continuous Batching) 性能下降严重？从 4x 批处理来看，常规 4bit 可以达到 62.8 tok/s，而本模型降到了 47.3 tok/s。这是由于 MTP 模块和更高权重的模型在多 Request 并发时抢占显存带宽与 GPU 计算单元更剧烈，造成 Batching 的并行加速效率下降。 -
-
-
-
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！