ASUS 几千个比特币，确定是比特币……解出来 上B300 集群好了。
你不是我们兄弟。（狗头doge~）
陈
陈鸿
@陈鸿
-
哈哈，找到一份当年在南洋理工读书的时候做的关于GPU加速的报告 -
中国缺算力 VS 美国缺电力，AI战争是综合国力的比拼，谁会笑到最后？是中国保住工业霸主地位，还是美国再工业化？ -
ddr3 x99 7900XTX vulkan 后端的llama速度60 t ,有个功耗不能满载问题x99 ddr3 64GB ubuntu26 vulkan 后端llama.cpp 的 qwen3.8 27B 7900XTX 速度大约60token /s/
就是在我的机器上有一个电源reset 的问题。
需要启动llama第二次才会满速和满载显卡功耗。
rocm 后端就可以满载功耗，但是速度只有30token 每秒。
————————————【实际启动命令】(~/.config/systemd/user/llama-server-vulkan-qwen38.service) /home/hong/Desktop/llama.cpp/build-vulkan/bin/llama-server \ -m /home/hong/Desktop/Qwen3.8-27B-Uncensored-Q4_K_M.gguf \ --host 0.0.0.0 --port 8086 \ -ngl 99 -c 102400 --n-predict 30000 \ --cache-type-k q8_0 --cache-type-v q8_0 \ --batch-size 512 --ubatch-size 256 --parallel 1 \ --load-mode mlock \ --spec-type draft-mtp --jinja \ --api-key KEY 服务附加配置: Environment=GGML_VK_DISABLE_COOPMAT=1, LimitMEMLOCK=infinity, Restart=on-failure (10s), 模型 = Vulkan 后端 + Qwen3.8-27B-Uncensored Q4_K_M (标准量化), MTP 草稿模式。 【关联的显卡 reset 命令】(ExecStartPre, 每次启动服务前自动执行) ExecStartPre=/usr/bin/sudo /usr/local/bin/gpu-reset.sh gpu-reset.sh 脚本内容 (card1 固定写死): GPU=/sys/class/drm/card1/device 1. 循环等待 reset 节点就绪 (最多 60 秒) 2. echo on > $GPU/power/control 3. echo high > $GPU/power_dpm_force_performance_level 4. sleep 1 5. echo 1 > $GPU/reset # GPU 硬重置, 期间的 I/O error 属正常 6. sleep 10 7. echo on > $GPU/power/control # 重置后恢复 8. echo high > $GPU/power_dpm_force_performance_level 即: 先把电源控制设为 on + 强制高性能档 → 对 GPU 写 reset=1 做硬重置 → 等 10 秒 → 重新 on + high。这就是解决开机后 Vulkan 首次启动慢 / DPM 卡死的那个 reset。 注意: 记忆里 gpu-reset.service 自启已禁用, 但 #6 服务自身 ExecStartPre 仍带这个 reset, 所以每次 (re)start 都会触发一次。 【平均速度】(journalctl 历史, 5235 个采样) - 全历史: p50 = 44.9 t/s, p90 = 60.0, max = 76.2 (含降速坏日, 被拉低) - 健康日 (8/18, 8/20, 8/31, 9/1): 日均 52-58 t/s, 9/1 最高 71.3 - 降速故障日: 13-17 t/s (RADV shader 缓存损坏 / 开机首启 DPM 卡死) 结论: 正常状态平均约 52-58 token/s, 峰值可到 71-76; 故障时跌到 13-15, 重启一次服务即恢复。─────────────────────────────────
整理如下（基于历史排查记录，均为本机实测）：【现象】显卡无法满载 - 推理速度从正常的 50-88 t/s 跌到 10-28 t/s - 功耗不满：满载应 250-350W，故障时只有 140-200W，甚至 <100W - 有时 sclk/mclk 已满频、GPU 98-100%，但功耗低、token 产出只有 1/6（GPU 空转） - 典型特征是"时好时坏"：按天交替 52→14→56→17→13 t/s 【四种已知根因】 1. RADV shader 缓存损坏（最常见） 特征：间歇性复发 + 功耗 140-200W 不满载 + 缓存只有几 MB 修复：停服务 → mv ~/.cache/mesa_shader_cache 改名备份 → 重启服务 效果：13 → 67 t/s。注意 2026-08-30 有一例清缓存无效（需走 A3 对照） 2. Vulkan DPM 电源状态卡死 特征：sclk 卡最低档(0MHz*) 或 mclk 卡 456MHz，功耗 <100W 修复：restart 服务；无效则 echo high 强制高性能；再无效 reboot 3. 开机后首次启动服务必慢（GPU 硬重置与 GDM 显示栈冲突） 特征：开机第一次启动 13-15 t/s，restart 一次即恢复 52 t/s 现状：已接受此 workaround，不再深究根治 4. 模型文件是混合量化配方 特征：文件名 Q4_K_M 但张量混 f32/q8_0/q5_K/q6_K，走 Vulkan 通用慢路径 表现：14.5 vs 标准量化 63 t/s（字节数只差 5% 但速度差 4 倍） 修复：llama-quantize --allow-requantize 重量化为标准 Q4_K_M 【判定顺序】 1. journalctl 查该服务历史 tg 分布 → 一直慢还是间歇性 2. 查 sclk/mclk 档位 + 功耗 → 排除电源卡死 3. 分不清就做 A3 对照：停 Vulkan 服务，用 ROCm build 跑同一模型 - ROCm 快 (40+) = RADV 层问题 → 清 shader 缓存 - 两者都慢 = 系统层（内核/DKMS/PCIe） 【当前处置（2026-08-30 起生效）】 - 开机后启动服务若慢（<20 t/s）→ 手动 restart 一次即恢复 50+ - perf 已改回 auto（待机省电），gpu-reset/gpu-perf-high 服务已禁用，udev 规则已备份 - 完整诊断手册在 llama-cpp-performance-troubleshooting 技能里，需要时可随时取用 -
# 7900 XTX 跑 Qwen3.8-27B 實測73.4t/s 完整部署與實測指南,claude code opus5協助佈署的,分享給大家 -
阿里下周将开源 Qwen3.8-27B !!! -
7900XTX + llama.cpp Qwen3.6 27B TurboQuant + MTP 测试结果分享我是用hermes 接入 deepseek flash ，然后帮我做的。 目前机器先配置好了出国的代理。在ubuntu下。
折腾了两个末模型。╭─
Hermes ─────────────────────────────────────────────────────────────────────────────────────────────────────╮
以下是两个模型的完整对比：模型一：Heretic v2（hmenu #4） 文件： Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-Q4_K_M.gguf 大小： 17 GB 规格： Q4_K_M 量化 | 参数 | 值 | |-----------------|---------------------| | 架构 | qwen35 | | 层数 | 65 | | Attention heads | 24 | | KV heads (GQA) | 4 | | KV 维度 | 256 per head | | 最大上下文 | 262,144（256K） | | 混合注意力 | 每 4 层一次全注意 | | MTP | 有，Native 原生保留 | 当前配置： - KV cache：f16（2 bytes per value） - 上下文：94K（-c 94208） - 实测速度：60+ t/s（MTP 有效加速） 优点： MTP 原生完好，接受率高 → 速度快 2 倍，越狱有效 缺点： f16 KV cache 体积大（每 token ~580 KB），94K 上下文已吃满 99% VRAM，无法再扩大 模型二：Fable 711（hmenu #11，当前运行中） 文件： Qwen3.6-27B-Fable-Fus-711-UnHeretic-NM-DAU-NEO-MAX-NEO-MTP-Q4_K_M.gguf 大小： 18 GB 规格： Q4_K_M 量化 | 参数 | 值 | |-----------------|----------------------------------| | 架构 | qwen35 | | 层数 | 65 | | Attention heads | 24 | | KV heads (GQA) | 4 | | KV 维度 | 256 per head | | 最大上下文 | 262,144（256K） | | 混合注意力 | 每 4 层一次全注意 | | MTP | 标称有，实为残废（16.7% 接受率） | 当前配置： - KV cache：q4_0（0.5 bytes per value，省 4 倍） - 上下文：180K（-c 184320） - 实测速度：31 t/s（MTP 几乎无效，纯裸推理） 优点： q4_0 KV cache 省 4 倍空间，可跑 180K 大上下文，VRAM 仅 88% 缺点： 7 模型 Fusion merge 洗掉了 MTP 头和越狱能力，速度只有 Heretic 的一半，且无法越狱 KV Cache 类型对比 | KV cache 类型 | bytes/值 | 体积比 | 精度 | 适用场景 | |---------------|----------|--------|------|---------------------| | f16 | 2.0 | 1x | 高 | 追求精度，短上下文 | | q4_0 | 0.5 | 1/4 | 中低 | 大上下文，VRAM 有限 | 按当前 65 层 + KV 256 per head + 4 KV heads + 混合注意力架构计算： | 上下文 | f16 KV cache | q4_0 KV cache | |---------------------|-------------------------------|------------------------| | 32K | ~19 GB | ~4.7 GB | | 94K（Heretic 当前） | ~55 GB → VRAM 99%，大量 spill | — | | 180K（Fable 当前） | ~105 GB → 不可能 | ~11.6 GB → 88% VRAM ✅ | 总对比表 | 项目 | Heretic v2 (#4) | Fable 711 (#11) | |------|:-:|:-:| | 文件大小 | 17 GB | 18 GB | | 模型来源 | 原生微调 | 7 模型 Fusion 合并 | | MTP | ✅ 原生保留，60%+ 接受率 | ❌ Merge 损坏，16.7% 接受率 | | 越狱/破解 | ✅ 有效 | ❌ "UnHeretic" 已反向合并 | | 速度 | 60+ t/s | 31 t/s | | KV cache | f16（大但精度高） | q4_0（小但省 4 倍） | | 当前上下文 | 94K（VRAM 极限） | 180K（还有余量） | | 显存占用 | 99%（24.7 GB） | 88%（21.1 GB） | | 余量 | 几乎没有 | ~3.9 GB 可用于 KV cache 增长 | 一句话总结： Heretic 胜在速度和越狱，但 VRAM 已到极限；Fable 胜在上下文大且有余量，但 MTP 和越狱都被 merge 毁了。两者的取舍就是 速度快/越狱 vs 上下文大。 -
一口气用本地Ltx2.3 来生成 2026 上半年热门舞蹈 -
换了好几个模型，有些简单问题AI就是很难回答上来 -
ubuntu26.04下7900xtx跑comfyui工作流阶段总结 -
7900xtx+华南x99 cd3 e5-2666 安装ubuntu26.04和24.04 发生异常 请教 -
X99 Dual 7900 XTX + DFlash Qwen3.6-27B 實測 -
ubuntu26.04下7900xtx跑comfyui工作流阶段总结 -
LTX2.3工作流分享，刘悦大神出品 -
ubuntu26.04下7900xtx跑comfyui工作流阶段总结