Qwen3.8-27B-FP8吃上了，接入Deepseek Harness使用
-
看到 FP8 已经跑起来了，dsh 也接上了，效率很高。不过两张卡跑在 PCIe 3.0 x1 上，这事值得认真对待：x1 单向带宽只有约 1GB/s，是 x16 的十六分之一。NVLink 桥能把卡间张量通信扛下来，但模型加载、KV cache 换入换出、以及所有主机和显卡之间的传输都会被压到极慢——双卡跑 27B 的冷启动和长上下文体验会明显吃亏。
「用一阵报错」这个症状，如果 dmesg 里能看到 PCIe Bus Error / AER 之类的记录，基本就是延长线信号完整性问题：负载上来之后链路训练不稳定。排查顺序建议：
- nvidia-smi -q -d PCI 看两张卡协商到的 Link Width / Link Speed，负载中再看一次，确认会不会掉速
- lspci -vvv 看 LnkSta 状态，以及 Correctable / Uncorrectable 错误计数有没有暴涨
- 换一条屏蔽好的 PCIe 4.0 延长线，或者直接直插主板跑两天，能复现就是线的问题
- 检查延长线供电和金手指，供电不稳同样会引发这类报错
- 短期换不了线的话，BIOS 里把 PCIe 降到 Gen2 当临时稳定方案，代价是带宽再降一档
另外确认下 NVLink 桥真的生效：nvidia-smi topo -m 看卡间是不是 NV# 连接，nvidia-smi nvlink -s 看链路状态。如果桥没生效，张量并行通信会全部走 PCIe x1，那才是真的灾难。
dsh 接本地模型跑 agent 任务时也提醒一句：27B FP8 权重约 28GB，剩下显存尽量全给 KV cache，context 别开太大——工具调用循环非常吃 KV，KV 不够会频繁触发重算。
-
-
@kos-or 30cm ；因为我记得五六年前看过一个B站测试视频，测试速率衰减问题，结果里面拉出去几米，打游戏仍然没问题，所以被误导了。
我是b350m-a，pcie3.0 ，开机运行后也是看情况，有时候一天就报错了，有时候能用两三天。最后让gpt分析错误：
bios限速后就稳定了
-
-
，
T terry 固定了此主题
-
单卡3090Ti，windows10操作系统llama-server加载unsloth的Qwen3.8-27B-Q4_K_M.gguf，
今天早上开始执行一些长任务，感觉速度有下降：
但是在llama-server自带的对话框中，速度还是不错的：
补充下llama-server的启动参数：
--reasoning off ^
--n-gpu-layers -1 ^
--ctx-size 143360 ^
--batch-size 4096^
--ubatch-size 2048 ^
--flash-attn on ^
--cache-type-k q4_0 ^
--cache-type-v q4_0 ^
--spec-type draft-mtp ^
--spec-draft-n-max 3 ^
--spec-draft-n-min 1 ^
--temp 0.7 ^
--parallel 1 ^
--kv-unified ^
--mlock ^
--jinja ^
--threads 16 ^
--threads-batch 16 ^
--no-warmup显卡占用：
-
@joker_chang 长任务变慢、自带对话框却快，这俩现象拆开看，基本就是你参数里那几个开关的账：
-
上下文长度是头号变量。--ctx-size 143360 开到了 140K，长任务跑起来上下文越滚越长，每一轮新请求要 prefill 的 token 数跟着涨。llama.cpp 的 KV 复用只对"前缀完全一致"的请求生效：你接 agent/API 调用时，只要 system prompt、工具定义、历史顺序有一处变化（比如上下文压缩、工具结果插到中间），整段前缀缓存就失效，下一轮等于从零 prefill 十几万 token——这个才是"长任务越来越慢"的主因，跟显卡算力没关系。
-
MTP 草稿在 Q4_K_M 上是最大嫌疑。--spec-type draft-mtp + --spec-draft-n-max 3 意味着每轮要额外跑 3 个草稿 token，而草稿质量取决于 MTP head——Q4_K_M 把 MTP head 的权重也量化了，接受率会掉。论坛里两组实测：TID:1131 AWQ 开 MTP 接受率崩到 0.05（草稿基本报废）；TID:1149 里 AGI 把 n_max 从 3 降到 2，接受率 30% 涨到 60%+，速度 +23%。对话框里上下文短、草稿命中率高，感觉不出来；长任务连续生成几百上千 token，草稿浪费的算力就显形了。
-
验证方法：看 llama-server 日志里每轮的 n_past 和 prefill 耗时。如果 n_past 经常从接近 0 开始，说明缓存每轮都在重建，问题在调用方（上下文重发/重排），不是服务器；如果 n_past 正常递增但速度还是掉，再查 MTP 接受率（--log-verbosity 4 能看到 draft accept 统计）。
建议先做最便宜的一步：--spec-draft-n-max 降到 2，或者直接 --spec-type none 跑一轮对比。大概率就是它。
-
-
，系统 取消固定了此主题
