关于评论区说到的MLX Serve+ddalcu版模型，我需要补充几个技术细节：
1，ddalcu版的量化配方与我并不一致，它的embed_tokens为4bit，我的为8bit；
2，ddalcu版在多模态场景下无法使用MTP，会导致单路Decode吞吐下降很多，与网上的数据可能出入较大；
3，ddalcu版只支持单路推理，不支持并发，这是明文写在文档里的v1限制（这也是我选择MLX-VLM的关键原因）。

补测的结果我也拿出来分享一下，以64K上下文单流为例，Decode TPS分别为：117.2（MTP开）、66.6（MTP关），这个数据应该会更符合一些MLX Serve用户的观察。

如果放到4并发状态，MLX Server的总吞吐相比MLX VLM确实会领先，AGG TPS分别为10.9（MLX-VLM）和12.9（MLX-Serve，均为带图情况），但MLX-VLM可以同时吐Token，用户体验好一些，且要注意embed_tokens的精度也更高。

除此之外还有一个小插曲，MLX Serve的默认Temperature为0，但我无论利用--temp参数还是测试请求额外指定Temperature均不能打满测试的Max Token数，对于一些需要长输出的场景可能需要额外注意。

另外我也尝试了一下，如果强行设置--max-concurrent 4，MLX Serve的AGG TPS甚至会跌到7.8，并发能生效，但吞吐反而下降，说明这个模型确实如文档所说那般不支持并发。

总的来说，MLX Serve+ddalcu版Qwen 3.8 Flash是一个更高效的选择，但在带图+并发的双重不利因素下，它的AGG领先并没有大到能让我放弃同时输出的地步。

在实际使用中，让用户看到Token在吐，而不是看着Agent在转圈等待是很重要的，看着转圈真的会极大消磨耐心，而且你根本不知道上一个请求什么时候才能结束……