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 一直保持一个比较高的状态，这条路走不通。

很烦，😡

[diudiuu]

佬的研究还是那么细致

[coefu]

@diudiuu shit bro ，我最近脑补了一个 类似 nvidia spark 跑 2.x T 的 超大 moe 方案。你那个 spark ，得闲了没，我们可以一起搞一下，有搞头的。

[diudiuu]

@coefu #10 同学的他给卖了，25000 出了，我也才知道，我最近找他要机子玩玩新的模型

[coefu]

@diudiuu 他卖便宜了。这个用来跑昨天开源的 qwen3.8 flash ，就很合适。

[yachen]

最近发现 https://github.com/ddalcu/mlx-serve 跑 qwen3.8-flash-next 挺好，可以试试

[coefu]

qwen3.8 27B 263k context Q8 kvcache no think ，大概在 128k 不到的长度，decode 就<2tok/s 。如果 kv cache Q4 能在 200k 左右，还有 3 tok/s ，但是会出现遗忘现象，比如一开始的规则后续就不再遵循。

我发现 muse glimmer 30B 在同样的 context 下，还能稳定 9tok/s 。muse glimmer 30B 的 benchmark ，其实都是在后训练得到的场景里不如 qwen3.8 27B,不过也是超过了 qwen3.6 27B 。

所以，263k context ，kvcache 必然要 Q8 。

我选 muse glimmer 30B 。但凡它要是能在后训练上再进步一点，不说超越 qwen3.8 27B , 只要能打平，就是当前最适合的。

[coefu]

muse glimmer 30B Q8 kvcache Q8 ,最新的 llama.cpp 支持 context shift, flash attention 。

极致的内存效率：
通过 -ctk q8_0 -ctv q8_0 ，整整 524K （ 2 个 Slot 各 262K ）的 KV Cache 居然只占用了 3.78 GB 显存（ 3,536 MiB + 248 MiB ）！如果换成 FP16 ，光是 KV Cache 就会暴涨到 15 GB+。

长上下文 Prefill 极速提升：
-fa 1 成功开启后，处理几万到几十万 Token 的超长 Prompt 时，Prefill （首包延迟）速度和内存带宽压力会得到数倍的改善。

Context Shift：llama-server 会自动剔除最早的旧对话 Token ，并将 KV Cache 中的数据整体向前平移，保留初始的 System Prompt （系统提示词）和最新的上下文，无需重新计算全量 KV Cache 。
设置 --keep -1：这意味着服务器会自动识别并完整保留初始化输入的 System Prompt ，只对后面的 User/Assistant 历史对话进行平移和丢弃。

比较癫狂。😂

[coefu]

muse glimmer 30B benchmark 看起来可以，但是实质上是两种情况。跑得快，看似听话，但是呆板。让它搞了一周，差点坏我大事。换 qwen3.8 27B 去回顾 muse 的工作，一堆 bug 。

https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF ，这个 team ，简直神人。

3bit quant ，AIME25 ，GPQA-D ，LCB v6 ，在这 3 个硬指标上能和 BF16 基本一样的成绩。关键是才 11GB 左右。用 Q4 kvcache 加 draft ，在 17W context ， 还能搞到 5 tok/s 。

智慧和速度兼得，无敌。😄

[coefu]

ISTA-DASLab 是量化届的 goat 。

太屌了，qwen3.8 flash 竟然在我的环境能跑了，而且，比 qwen3.8 27B 还快。最主要是：

Variant bpw GB ZS avg↑ recovery AIME25↑ GPQA-D↑ LCB v6↑ Task avg↑
BF16 16.00 354 76.94 100.0% 100.00 91.92 87.43 93.12
GSQ-RCO Q2_0 2.40 66.4 78.00 101.4% 96.67 89.39 81.14 89.07
GSQ-RCO IQ2_XS 2.50 68.0 77.16 100.3% 96.67 87.37 83.43 89.16
GSQ-RCO IQ3_XXS 3.00 75.8 77.23 100.4% 100.00 91.41 86.29 92.57

屌翻天。GPQA-D 能惊人的贴近 BF16 ，比 qwen3.8 27B 89.2 ，还高，进入了 90 分大关。

🐮🍺