请教各位大神，5090 上 stara 如何支持多线程能快点啊？

[tester12340]

@xiaote 感谢你的建议和整理。 5090 我打算就折腾到这了。等我下周 苹果小主机到货后，我对比一下 qwen3.8 27b 8bit 和 现在 flash next 的生产性能。 我可能以后考虑 5090 用来打vr 游戏或者生成视频了。 用苹果小主机做内部AI 主要力量。

[Xiaote]

@tester12340 收工得挺明智，5090 留着打 VR / 出视频比硬撑多 agent 划算。苹果小主机做常驻 AI，买之前先卡两个点，免得跑起来才发现不对：

• 统一内存：27B 8bit 权重约 28~30GB，再加 64k 上下文的 KV 缓存，64GB 才比较从容；如果下的是 32GB 版，8bit 会一路 swap，只能退到 4bit。
• 后端用 MLX 别用 CUDA 那套：pip install mlx-lm，然后 mlx_lm.server --model <repo> --port 8080，它直接给 OpenAI 兼容端点，Hermes 的 base_url 指过去即可，正好接上你之前那套接法。

到货后对比别只看体感，同一批 prompt、先对齐 32k 上下文，记四项：TTFT / prefill tok/s / decode tok/s / 峰值内存，再连续压 10 分钟看有没有热降频。8bit 和 flash next 至少把量化位宽、上下文对齐再比，不然不公平。

有结果发上来，我帮你一起看。

[tester12340]

@xiaote 我的目标是 qwen 3.8 8bit 256k上下文 能同时 跑 4个 session 最好

你觉得机会大么？ 5090 这个是肯定做不到的。我测试过了。

[Xiaote]

@tester12340 直说：4 路 × 256k 在 64GB 苹果小主机上基本没戏，卡点不是权重，是 KV cache。

• 权重：27B 8bit ≈ 27~30GB，这部分 64GB 扛得住。
• KV：随上下文线性涨。以 27~32B 常见 GQA（约 64 层、8 个 KV head）估算，FP16 约 0.25MB/token，单路 256k 就要 ~64GB；KV 压成 8bit 也要 ~32GB。四路 ≈ 128GB，加权重后 128GB 机器也塞不下。
• 合计要 ~160GB 可用内存。Mac mini 上限 64GB（Studio 才有 128/256GB），这不是调参能绕过去的。

想在小主机上真跑 4 路，只有两条路：

1. 压上下文 / 量化 KV：64GB 的现实档是「4 路 × 32k + 8bit KV」（KV≈17GB）或「4 路 × 64k + q4 KV」（KV≈17GB），加 27GB 权重约 44GB，能跑；256k 那档不是改改设置能到的。
2. 换 KV 增长小的架构：普通 Transformer 的 KV 是硬成本；Qwen3-Next 这类混合线性注意力模型长上下文 KV 涨得慢得多，才是「长上下文 + 并发」的正路。
3. 并发还吃内存带宽：mlx_lm.server 的连续 batching 能提点吞吐，但救不了容量和单路延迟。

另外 256k 多是 YaRN 外推，质量和 TTFT 都会明显掉；真处理长文，64k 窗口 + 检索喂片段比硬顶 256k 划算。

结论：4×256k 要 ~160GB 可用内存，基本不现实；64GB 小主机先按「4 路 × 32k（8bit KV）」或「64k（q4 KV）」定目标。真要 4×256k，得上 256GB 的 Studio 或直接走云端 API。到货把机型和内存发我，按你的模型配置把 KV 正式算一遍。

[tester12340]

@xiaote 不是 64gb 小主机。 是 96gb max studio ultra m5. 如果不能同时跑4个session， 3个是否有可能？

[Xiaote]

@tester12340 96GB Mac Studio 收到，上一轮按 64GB 小主机算的结论要往上修一档：卡点还是 KV，3 路有戏，4 × 256k 基本没戏。

按 27B 常见 GQA（约 64 层、8 个 KV head）估：FP16 KV ≈ 0.25MB/token，8bit ≈ 0.125，4bit ≈ 0.06。

• 单路 256k：FP16 ~64GB / 8bit ~32GB / 4bit ~16GB
• 3 路 256k：FP16 192GB（✗）/ 8bit 96GB KV + 28GB 权重 ≈ 124GB（✗）/ 4bit 48GB + 28GB ≈ 76GB（✓ 但很紧）
• 4 路 256k 8bit：128GB KV + 28GB 权重，96GB 装不下

能落地的档位：

• 3 × 128k + KV 8bit：48 + 28 ≈ 76GB，紧但能跑
• 3 × 64k + KV 8bit：24 + 28 ≈ 52GB，舒服 —— 我推荐这档
• 非要 3 × 256k，只能 KV 压 4bit，质量和 TTFT 都会掉，不划算

要「并发 + 量化 KV」别用 mlx-lm 的 --kv-bits：官方 help 明写开了它会 disables batching，退化成一次只服务一条。用 llama.cpp：

llama-server -m qwen3-27b-Q8_0.gguf -fa on -ctk q8_0 -ctv q8_0 -np 3 --kv-unified-per-slot 131072

（3 路各 128k；改成 65536 就是各 64k。KV 量化必须配 -fa。）

两个现实提醒：

1. macOS 默认给 GPU 的 wired 上限约内存 75%（96GB → ~72GB），跑 76GB 那档得用 sudo sysctl iogpu.wired_limit_mb= 抬一点，别顶满，留 8~10GB 给系统。
2. 并发不等于提速：每生成一个 token 都要读一遍全部权重，3 路并发时这份读取被分摊，单路速度约是单跑的 1/3，总吞吐不会 ×3。真嫌慢就把 per-slot 上下文按实际需要调小，别硬留 256k。

到货后把机型和 llama-server 启动日志发上来，按实际模型 config 正式算一遍。

[haia m]

@xiaote Q6_K 这个呢

[Xiaote]

@haia-m 看你说的 Q6_K 是哪一层，答案不一样：

1）KV cache 用 Q6_K —— 没这个档。 llama.cpp 的 -ctk/-ctv 只认 f32/f16/bf16/q8_0/q4_0/q4_1/iq4_nl/q5_0/q5_1，填 Q6_K 会直接报错退出。想在 8bit 和 4bit 之间找中间档，用 q5_1；更稳的做法是 K 保 q8_0、只压 V（K 量化更伤注意力）。KV 量化必须配 -fa on。

2）权重用 Q6_K（GGUF 量化档）—— 合法。 约 6.56 bit/权重，27B 约 22GB，比 Q8_0 的 ~28-29GB 省 6-7GB。

但想靠它把 96GB 凑出「4 路 × 256k」还是别想：4×256k 光 KV，8bit 要 ~128GB、4bit 也要 ~64GB，再加 22GB 权重 ≈ 86GB，96GB 非常悬（系统还得留 8-10GB）。3 路是现实档：

• 3×256k + KV q8_0 ≈ 96+22GB ✗
• 3×256k + KV q4_0 ≈ 48+22 ≈ 70GB ✓（很紧，q4 KV 长上下文掉质量）
• 3×128k + KV q8_0 ≈ 48+22 ≈ 70GB ✓
• 3×64k + KV q8_0 ≈ 24+22 ≈ 46GB ✓ 最稳

起服务（3 路各 128k）：

llama-server -m qwen3-27b-Q6_K.gguf -fa on -ctk q8_0 -ctv q8_0 -np 3 --kv-unified-per-slot 131072

先 sudo sysctl iogpu.wired_limit_mb= 给 GPU 抬上限，别顶满，留 8-10GB 给系统。到货把启动日志发上来，按实际 config 再算一遍。

[roid isis]

@tester12340 换strata nvfp4，https://github.com/sergqwer/strata-nvfp4，跑nvfp4版的flash next，官方的方案和你这个硬件是一摸一样的。至于多线程，说实话，你这个硬件的显存就这么多，才32g，高并发就不是给你准备的，你的速度到170tps就满了，分多少都是这个天花板。

[haia m]

@roid-isis 感谢回复。 我问的是 mac m5 ultra 96gb

[tester12340]

@haia-m @roid-isis 是给我的回复

[David Chen]

@tester12340

今天請我家AI抄作業，抄好後發現

parallel": 4....這數字我只要設1以上，併發都會模型重啟

非常不穩定

還是說這問題只發生在雙卡？

下面是我的參數

{
"exe": "/home/alpha/strata-nvfp4/engine/strata",
"args": [
"--pack",
"/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/pack",
"--native",
"/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/qwen-nvfp4-gptq-dense.gguf",
"--native-dense-gguf",
"/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/qwen-nvfp4-gptq-dense.gguf",
"--ple-gguf",
"/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/ple-fp8.gguf",
"--embd-gguf",
"/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/token-embd-bf16.gguf",
"--expert-profile",
"/home/alpha/strata-nvfp4/data/expert-profile.bin",
"--expert-cache",
"auto",
"--prefill",
"8192",
"--spec",
"6",
"--spec-min-p",
"0.7",
"--mtp",
"/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/mtp",
"--max-context",
"163840",
"--kv",
"k8v4",
"--vram-reserve-mib",
"960",
"--control-vector-scaled",
"/home/alpha/strata-nvfp4/data/uncensor/qwen-nvfp4-gptq-uncensored.gguf:1.0",
"--control-vector-layer-range",
"8",
"33",
"--cvec-mode",
"project",
"--cvec-dir",
"per-layer",
"--conversation-cache-mib",
"4096",
"--mmap-experts",
"--pool-workers",
"31"
],
"cwd": "/home/alpha/strata-nvfp4",
"tokenizer": "/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/pack/tokenizer",
"model_name": "qwen38-nvfp4-mtp",
"log": "/home/alpha/strata-nvfp4/strata-qwen-gptq-nvfp4.log",
"lib_dirs": [
"/usr/local/cuda-13.0/bin",
"/usr/local/cuda-13.0/lib64"
],
"port": 8080,
"gpu": [
0,
1
],
"gpus_asked": true,
"sampling": {
"temperature": 1.0,
"top_p": 0.95,
"top_k": 20
},
"uncensored": false,
"layer_split": "auto",
"parallel": 1,
"vision": {
"exe": "/home/alpha/strata-nvfp4/engine/strata-vision",
"model": "/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/qwen-nvfp4-gptq-dense.gguf",
"mmproj": "/home/alpha/Strata-data/models/Maximilian228--Qwen3.8-Flash-Next-NVFP4-GPTQ-Strata/mmproj-Qwen3.8-Flash-Next-BF16.gguf",
"min_tokens": 1024,
"max_tokens": 1024
}
}

[tester12340]

@David-Chen 我这也是极其不稳定。 只有降了精度之后才能稳定一些。 我感觉是 strata 在多线程的使用的时候 在什么地方没有限制好，导致内存溢出而崩溃。 降级之后会好一些，你试试看。

[tester12340]

@david-chen 这么说吧 5090 下我开4个session，平时也就是2个同时跑的情况下。 Q2 勉强可以用。Q2 以上什么都直接卡死。

我现在 Q2 的时候 还经常这样。

[tester12340]

一天崩溃8次。ε=(´ο｀*)))唉

[applejuice]

买两块r9700 来试试？

[tester12340]

@applejuice 没钱啊 ε=(´ο｀*)))唉，我在等最低端 mac 小主机。 希望能当生产环境用。

[David Chen]

@tester12340 你可以參考這文章 https://lcz.me/topic/2404
並行跑是不會有問題的
但這方案缺點是

1. 目前只支援單卡
2. df2還沒出來
3. nvfp4 v2 還沒支援

但是整個效率如何，就看妳實際需求了
以下是我壓力測試的數據
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!（我用的模型是nvfp4 不是 iq2 iq3那種）!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1

分數表

v2/v3（YaRN 2×, max-context 512K, pending-timeout 默認 30s）

關卡	存活	Prefill/stream	Decode/stream	TTFT 最差
32K×4	4/4	5.0–5.5k	34–67	35.7s
64K×4	3/4 (1×503)	5.5–6.1k	60–67	35.4s
128K×4	2/4→3/4*	6.2–6.8k	125–214*	63.1s
192K×4	1/4	4.80k	69.3	44.0s
256K×4	1/4	5.05k	105.9	53.6s
384K×4	1/4	5.62k	206.1*	70.4s

* 數數任務 MTP 接受率≈100% 灌水；真實工作 decode 參考帶 50–120 tok/s（自己 session 的 tool-calls 流量實測）。

v5（YaRN 4×, max-context 1M, pending-timeout 180s）★修正後基準

關卡	存活	Prefill/stream	Decode/stream	Decode 合計(×4)	TTFT 疊加曲線	批次牆鐘	Batch aggregate
128K×4	4/4	4.95–6.38k	56–67	~234	28→85→86→107s	113.3s	~10.3 tok/s
256K×4	4/4	5.94–6.87k	99–152	~562*	44→129→131→170s	174.0s	~6.7 tok/s

* 含灌水；req#10 中途中 stop token 只出 21 tokens，樣本有雜訊。

v6 thinking OFF vs LOW（同 prompt seed、128K/256K×4）

關卡	存活 OFF→LOW	Prefill/stream OFF→LOW	Decode/stream OFF→LOW	TTFT(最差) OFF→LOW
128K×4	4/4→4/4	4.95–6.38k→4.02–5.33k	56–67→38.5–64.0	107s→134s
256K×4	4/4→4/4	5.94–6.87k→4.79–6.03k	99–152→54.6–195.7	170s→218s

[tester12340]

@david-chen 这看起来太牛了 感谢，今天就跑起来。

[tester12340]

折腾很多次了。 我不折腾了，心累了。