M5MAX 128G换了快30个本地部署模型后，唯一选择edge0-35B-A3B-Preview

[johnnybegood]

@Bin-Mao 这两天也研究了一下， 给边缘设备用的。 手机上用也不错。 本地部署更是大牛拉小车。 简单工作肯定没问题， 但是我为什么要用这个而不去用我的 coding plan呢

[jin weng]

这个并发咋样，我的是 M3 Ultra 512G，并发速度减的太狠了

[Xiaote]

M3 Ultra 的瓶颈不在算力，在统一内存带宽。decode 每生成一个 token 都要把激活的权重从统一内存过一遍，多个请求共享同一条带宽，所以并发是从「每路可用带宽」里分，不是线性叠加。

edge 这类 35B-A3B 是 MoE，激活参数少，单 token 要搬的字节比稠密模型低得多，批量并发会好很多。建议用支持 continuous batching 的运行时（MLX / llama.cpp server），batch 上限压到内存能稳的范围，别一次拉满。

判断是不是带宽顶住：看 GPU 内存带宽利用率（asitop / powermetrics 的带宽项），接近峰值时加并发只会让每路更慢；要提总吞吐只能降量化、缩短上下文，或换带宽更高的 M5 Max。

512G 的另一个玩法：同时起多个 server 各跑一份小模型，比单实例硬堆并发更稳。

[Bin Mao]

@johnnybegood 说:

@Bin-Mao 这两天也研究了一下， 给边缘设备用的。 手机上用也不错。 本地部署更是大牛拉小车。 简单工作肯定没问题， 但是我为什么要用这个而不去用我的 coding plan呢

因为粗重活我还是不想用coding plan，现在唯一可以信任的是ds v4系列，现在ds涨价，平常粗重活又多，感觉有些划不来。而mimo感觉有些闹着玩（年费），本地模型要兼顾速度和agent调用，确实尝试了很多遍才选择了这款本地部署的llm。

[Bin Mao]

@jin-weng 说:

这个并发咋样，我的是 M3 Ultra 512G，并发速度减的太狠了

你这台mac完全没问题，不用考虑这个模型，试试Qwen3.8-27b全量吧，按照M3 ultra 512G，应该可以跑到130t每秒，感觉更符合你的agent日常所需。

[Bin Mao]

@許托比 说:

有詳細的測試畫面跟配置嗎？

我是菜鸟，确实不知道如何测试，抱歉给不了详细的benchmark，不过从使用以及实际体验上来说，特别是hermes接入的体验，我觉得对我是完全够用，更别说dsh了。

现在写个报告，搞个量化python什么的绰绰有余，不过程序最后得让ds过一遍，会发现一些bug，但是不多，总之真的够用！

这就是hermes的粗粮，吃大餐还得ds v4 flash或者ds v4 pro

[Bin Mao]

经过1天的高强度测试，我还是改为了Qwen3.6-35B-A3B-MTPLX-Optimized-Balance-FP16，edge0虽然速度快，但是从质量上还不够成熟，核心是edge0没有识图能力（自己阉割了），且edge0是基于qwen3.5训练的，现在Qwen3.6-35B-A3B-MTPLX-Optimized-Balance-FP16在M5max 128G速度上可以保持近100t/s的输出，比edge0差点儿，但是质量高了不少！！！

[stormaround]

a3b靠谱吗，之前用过的a3b经常会死循环，而且mac跑大模型太热了，我都改用r9700跑了，双r9700 配洋垃圾部署qwen3.8-flash-next很稳，我现在替换掉deepseek-flash完全没问题，肯定不如云端，但是比35b ，27b要强很多

[stxpnet]

今天试了一个Q8 XL的A3B，输入TOKEN太大了，但是又没以做VLLM或者SGLANG的，比较尴尬。 前缀缓存无法生效

[Bin Mao]

@stormaround 说:

a3b靠谱吗，之前用过的a3b经常会死循环，而且mac跑大模型太热了，我都改用r9700跑了，双r9700 配洋垃圾部署qwen3.8-flash-next很稳，我现在替换掉deepseek-flash完全没问题，肯定不如云端，但是比35b ，27b要强很多

我这还不是被逼着用MOE嘛，M5MAX 128G单独跑qwen3.8-27B没啥问题，加上dflash2，上下文262144，可以到43T/S，但是挂dsh或者codex，那速度就太拉胯了。换成qwen3.6 35B A3B，速度可以保证，质量也不会太拉胯，暂时没碰到死循环问题。