mac ultra deepseek harness & qwen3.8-27B 几点经验

[coefu]

1 ，不要用 llama.cpp ，虽然它可以超长 context ，并能量化 context ；但是超长 context 一旦处理慢了点，deepseek harness 底层用来连接模型的 pi 就容易超时 hang 住，再次连接的时候，重新 prefill 之前超长的 context 会非常耗时，且 llama.cpp 在同一个 slot 中处理的时候，后续不管 pp/tg 都非常慢。

2 ，推荐 mlx-dspark ，umem 够的情况下，用 draft 模型，不够，用--lookup-drafts 模式，context 不要搞默认 256k ，有个 64k 足矣，当单个 context 不够，自动切 slot 。前缀缓存（ Prefix Caching / KV-Cache Reuse ）和 探针验证与 Small-M 优化内核（ Small-M Kernel Optimization ），让其能在 context prefill 极速，这是 llama.cpp 的最大问题。后续的 tg 阶段，也提速。虽然没有 context 量化，但是以上技术完全弥补了，且 context 不量化不损失质量。

3 ，让 dsh 自己写联网插件和记忆插件，保证客观知识的相对准确性，以及多个会话的延续性。

[panas]

佬用的哪个量化版本的模型

[coefu]

@panas mlx-community 的 8 bit ，mlx-dspark 只支持这个。

[coefu]

mlx-dspark 短 context 情况下，tg 真的是快，一次性蹦出来的。比 llama.cpp 一点点的吐，牛逼太多了。而且在会话中断之后，prefill 就是瞬间完成。llama.cpp 要是在一次会话，context 搞到 200k 左右中断了的话，要继续，光 prefill 之前的 context 都要一两个小时。简直折磨，😩。

[beginor]

楼主确认 64K 上下文够用？

[coefu]

@beginor 不知道，我也还在测试。

[coefu]

@beginor 主要是 llama.cpp 256k context 的时候，后面实在太慢了，有时候慢到 deepseek harness 连模型的 pi 组件超时，重新发起会话又把之前的 context prefill 一遍，越长越慢，越慢越容易断，成了死循环了。

mlx-dspark 的 cache reused 估计能解决这个问题，但是 mlx-dspark 无法 量化 qwen3.8-27B 这种混合注意力模型 的 context ，导致 kvcache 膨胀的太快了，经常 oom 。更不用说用 draft 模型了。tg 速度其实和 llama.cpp 也差不多了。就图个 cache reused 。

[coefu]

最新进展：

1 ，又用回了 llama.cpp ，mlx-dspark 不能量化 context kvcache ，导致 64k context 都能 oom 。

2 ，llama.cpp 加上 -b 4096 -ub 2048 ，保证更多的压榨 Metal gpu ，pp 阶段有提升。

3 ，加上 --slot-save-path ./kv_cache_saves --cache-idle-slots ，保证 llama.cpp 当前进程 crash 之后，再启动的时候 能快速 prefill 。

4 ，用 hindsight 记忆组件，显示声明 deepseek harness 每次会话完结 都把当前进展存入记忆，保证重开会话的工作进展延续性。

5 ，在 225k 输入，10.6k 输出的时候，还能稳定平均 8 tok/s 。

爽，😊

[coefu]

最新进展：

因为 qwen3.8 27B 是一个非常典型的 Hybrid / Gated DeltaNet + Attention 模型.

整个 kvcache 包含了 Attention KV Cache+Recurrent State ，llama.cpp 的 context-shift 只能搞经典 attention ，没办法搞 recurrent state ，用不了 context shift 。通过缩小整个 context ，让 tg 一直保持一个比较高的状态，这条路走不通。

很烦，😡