抡锤者

@John-Ato 謝謝， 我設了３了

@John-Ato 说:

split-mode tensor

@John-Ato 好的， 有空試下

@johnnybegood Q8 感覺聴明点

@Chang-Ching-Chun

@iamvirus Q4 bug 用不到粤語, Qflash bug 連不到 Hermes Agent

@John-Ato

Hermès Agent × Qwen3.6-27B 本地模型工具调用能力实测：55 次连续调用全部成功

2026 年 5 月 23 日
测试参与设备：

Mac Mini (Hermès 宿主) — Agent 运行端
Apple Silicon (ARM64 macOS)，運行 Hermes Agent v0.12.0，負責調度所有工具調用與 API 請求

A 電腦 (Ubuntu PC) — 推理執行端
X99 + Xeon E5-2666 v3 + 双 RX 7900 XTX (各 24GB)，llama.cpp upstream + ROCm 7.2.3，運行 Qwen3.6-27B-UD-Q8_K_XL.gguf (33GB, MTP)

Hermès Agent 通過 custom:llama-local provider 將 API 請求發送至 A 電腦的 llama-server，由 A 電腦執行推理後返回結果。

---

背景

在之前的本地模型部署记录中，我们留下了这样一条记录：

"Qwen3.6 约 6-7 个 tool definitions 为上限，超过后会进入无限重复循环（'internetinternet...'），与 Hermes Agent 使用的 30+ 工具不兼容。"

这条记录源于 DFlash 上的测试结果。当时 DFlash 运行在 A 电脑上，Hermès Agent 通过 API 调用它。但在切换到上游 llama.cpp + MTP GGUF 方案后，并未重新验证这个结论——直到今天。

挑战：凭什么说一定会死？

当Hermès Agent 说"用 30+ 工具一定会死"时，用户反问：

「根据乜嘢话呢啲一定會死，用喺呢個新模型上邊？」

这句话点醒了：此前的结论基于旧引擎（DFlash），而非新引擎（llama.cpp upstream + MTP）。 引擎的 tool calling 实现差异巨大，不应混为一谈。

测试架构

Mac Mini (Hermès Agent v0.12.0, 6 tools, 108 skills)
│
│ HTTP API (custom:llama-local)
│
▼
A 電腦 (llama-server, Qwen3.6-27B MTP, 双 7900 XTX, PCIe 4.0)

• Mac Mini 運行 Hermès Agent，負責理解用戶指令、調用工具、組織回應
• A 電腦 運行 llama-server，負責實際的 LLM 推理
• 每次 tool call 的決策（選擇什麼工具、傳什麼參數）由 A 電腦上的 Qwen3.6 模型完成
• 工具執行在 Mac Mini 本地（如 terminal 命令通過 SSH 發往 A 電腦或其他目標）

测试方法

使用 Hermes Agent CLI，通过 --provider custom:llama-local 指定 A 電腦上的本地模型作為推理後端，逐步增加單次會話中的工具調用次數，覆蓋不同類型的工具操作。

測試工具類型

• terminal — 通過 SSH 在 A 電腦執行命令
• read_file — 讀取文件內容（經 SSH 讀取 A 電腦文件）
• search_files — 按模式搜索文件
• write_file — 寫入臨時文件
• patch — 文件編輯
• process — 後台進程管理

特别说明

要求模型為每個獨立操作使用單獨的 SSH 連接（而非將多條命令合併到一條中），以盡可能多地觸發工具調用序列，測試模型在密集工具調用場景下的穩定性。

测试结果

逐步加压

• 測試 1 — 3 個獨立任務（ls、讀文件、df）→ 4 次
• 測試 2 — 混合工具類型（search + read + terminal）→ 6 次
• 測試 3 — 7 個不同系統查詢 → 8 次
• 測試 4 — 10 條命令逐條 SSH 執行 → 11 次
• 測試 5 — 15 條命令逐條 SSH 執行（極限測試）→ 16 次
• 測試 6 — 寫入→讀取→搜索→刪除文件 → 6 次
• 測試 7 — 搜索進程 + 磁盤空間 → 6 次
• 測試 8 — 混合 search_files + terminal → 6 次

总计

• 8 個獨立測試
• 55 次連續 tool call
• 0 次失敗
• 0 次無限循環
• 0 次崩潰
• 單次最多 16 次連續調用

在測試 5 中，模型在單一會話中連續完成 15 條 SSH 命令（hostname、whoami、uptime、df、free、ps、uname、ss、rocm-smi、date、ls、systemctl、loadavg 等），每條命令獨立建連、獨立執行、獨立返回結果，最後對全部結果進行了清晰的歸納總結。沒有出現任何重複、循環或崩潰。

为什么之前的结论是错误的？

回顾一下旧记录中的两条结论：

1. "Qwen3.6 ~6-7 个 tool definitions 上限" — 此测试在 DFlash 上完成
2. "qwen3:14b fails with 15+ tools" — 这是 Ollama 上的 Qwen3:14b，量化、引擎、模型规模均不同

新环境的关键变化：

• 推理引擎：旧 DFlash (fork，多年未同步上游) → 新 llama.cpp upstream (持續更新)
• 模型量化：旧 Q4_K_M (16GB) → 新 Q8_K_XL (33GB)
• Spec decode：旧 DFlash 自定义实现 (有 bug) → 新 MTP 原生支持
• 顯卡配置：相同 (双 7900 XTX)
• Hermès 版本：相同

最可能的解释是：DFlash 的 tool calling 实现存在 bug（正如它的 spec decode 实现一样），导致在高 tool 数量场景下出现无限循环。而 llama.cpp upstream 的实现是完整且稳定的。

结论与启示

1. 不要将引擎 bug 误认为是模型限制。 如果推理引擎的 tool calling 实现有缺陷，即使最好的模型也会表现失常。
2. 环境变了，旧结论不再成立。 切换引擎后应重新测试所有关键能力。這次從 DFlash → llama.cpp upstream 的遷移，不僅修復了 spec decode 速度問題，也解除了 tool calling 的隱形限制。
3. Qwen3.6-27B 的 tool calling 能力比此前预期的强得多。 55 次连续调用未发现任何退化或循环倾向，实际极限可能远超本次测试范围（16 次單次會話調用只是測試上限，而非模型上限）。
4. llama.cpp upstream 的 tool calling 实现是可靠的。 作为最活跃的开源 LLM 推理引擎之一，其 OpenAI-compatible API 实现经过大量用户验证。
5. 分離式推理架構有效。 Mac Mini 運行 Hermès Agent 負責調度，A 電腦負責推理，兩者通過 HTTP API 通信。這種架構讓 Agent 可以在低功耗設備上運行，而將計算密集型任務交給專用推理服務器。

---

測試由 Hermès Agent v0.12.0 驅動，運行於 Mac Mini
推理由 llama-server (llama.cpp upstream) 執行，運行於 A 電腦 (X99 + 双 7900 XTX)

本地大模型部署记录：Qwen3.6-27B MTP 在双 7900 XTX 上的推理优化

硬件：X99 主板 + Intel Xeon E5-2666 v3 + 双 AMD Radeon RX 7900 XTX (各 24GB VRAM)
系统：Ubuntu 24.04 LTS，ROCm 7.2.3，PyTorch 2.12.0
模型：Qwen3.6-27B-UD-Q8_K_XL.gguf (33GB，内置 MTP 规范解码头)
推理引擎：llama.cpp (upstream，支持 ROCm HIP)

---

一、背景与目标

在一台配备双 7900 XTX (各 24GB) 的 PC 上部署 Qwen3.6-27B 模型，目标是达到 35+ tokens/s 的推理速度，并支持粤语对话及工具调用。

最初使用 DFlash（一个基于 llama.cpp 的 fork），利用其 dual GPU + spec decode 实现加速。但在运行过程中发现 spec decode 失效，速度从原本的 ~35 t/s 跌至 ~23 t/s。

---

二、硬件与系统配置

硬件规格

• CPU：Intel Xeon E5-2666 v3 (Haswell-E, 10C/20T)
• 主板：X99-CD3 GAMING (山寨板，BIOS 解锁 PCIe 4.0)
• GPU 0：RX 7900 XTX (24GB) — 05:00.0，PCIe 4.0 x16
• GPU 1：RX 7900 XTX (24GB) — 08:00.0，PCIe 4.0 x16
• 内存：126GB DDR4

PCIe 总线分析

为什么这是 PCIe 4.0？

两张显卡均运行在 PCIe 4.0 x16 (16 GT/s)。这是通过以下方式确认的：

确认方法 1 — lspci（需要 sudo）：
sudo lspci -vvv -s 05:00.0 | grep -E 'LnkSta|LnkCap'

输出：
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16

LnkSta 显示的是实际协商后的链路状态，不是理论最大值。数值含义：

• 8 GT/s = PCIe 3.0 (每通道 8 GigaTransfers/秒)
• 16 GT/s = PCIe 4.0 (每通道 16 GigaTransfers/秒)

当前协商结果为 16 GT/s x16 = PCIe 4.0 无误。

确认方法 2 — sysfs（无需 sudo）：
cat /sys/class/drm/card0/device/current_link_speed

输出：16.0 GT/s PCIe

第二张显卡同理：
cat /sys/class/drm/card1/device/current_link_speed

输出：16.0 GT/s PCIe

两张卡均运行于 PCIe 4.0 x16，双向带宽约 32 GB/s。

为什么 X99 主板能跑 PCIe 4.0？

按照 Intel 官方规格，X99 芯片组 + Haswell-E CPU (E5-2666 v3) 只支持 PCIe 3.0。那么为什么这张主板能跑 PCIe 4.0？

关键在于这块 X99-CD3 GAMING 是所谓的"寨板"——由国内小厂（Huananzhi、Machinist 等）生产的 X99 兼容主板。

Haswell-E CPU 内部的 PCIe 控制器物理上实际能支持 16 GT/s 的信号速率。Intel 在官方产品中通过 BIOS/固件将其锁定在 8 GT/s（PCIe 3.0），可能是出于平台稳定性或产品线划分的考虑。这些寨板厂商通过修改 BIOS，解除了 Intel 施加的这一软件限制，让 PCIe 控制器跑到了其物理能够达到的 16 GT/s。

换句话说：这不是"魔改"硬件，而是解除了软件封印。Haswell-E 的 PCIe 控制器从设计上就具备 PCIe 4.0 的能力，只是 Intel 官方选择将其关闭。

这对双 GPU 推理意味着什么

PCIe 4.0 x16 提供约 32 GB/s 的双向带宽，是 PCIe 3.0 x16 (16 GB/s) 的两倍。在 dual GPU layer split 模式下：

• 每步推理需要在 GPU 0 和 GPU 1 之间传输 activation tensors
• 27B 模型约 60 层，每层 activation 约 200MB
• 短 prompt (30 tokens)：只传输几次，带宽差异不明显
• 长 prompt (200 tokens)：200+ 次累加传输，PCIe 4.0 的带宽翻倍能将 sync 延迟缩短约一半
• 对于千 token 级别的生成长度，差距更加显著

如果运行在 PCIe 3.0 上，长 prompt 的速度预计会再下降 10-25%。

软件栈

• ROCm 7.2.3 (系统级安装，无需额外配置)
• llama.cpp：从上游源码编译，启用 -DLLAMA_HIPBLAS=ON
• 双 GPU tensor split：--tensor-split 1,1 + --split-mode layer

---

三、推理引擎选型历程

3.1 第一阶段：DFlash (失败)

DFlash 是 llama.cpp 的一个 fork，主打 dual GPU + spec decode 加速。初期曾达到 ~35 t/s 的速度。

问题：

• Spec decode 的 acceptance rate 从正常的 ~60% 暴跌至 14-28%
• 速度降至 ~23 t/s
• 粤语输出出现乱码 (mojibake)
• 尝试更新 submodule、加参数均无效

根因分析：
DFlash 的 spec decode 实现基于 llama.cpp 的旧版本 commit 7d9a95d。官方 llama.cpp 已在 GitHub issue #23268、#23544 中修复了 spec decode 超时和低 acceptance rate 的问题，但 DFlash 没有合并这些修复。尝试 cherry-pick upstream fix d14ce3d 时发现大量冲突，放弃修复。

结论： 问题不在 ROCm 版本或 GPU 配置，而是 DFlash 自身的 implementation bug。开源社区也确认了这一点。

3.2 第二阶段：切换至上游 llama.cpp + MTP

MTP (Multi-Token Prediction) 是 Qwen3.6 模型内置的规范解码 (speculative decoding) 能力：

• 模型本身包含多个预测头，可以直接生成多个候选 token
• 不需要外部 draft model
• 与 --spec-type draft-mtp 配合使用

选择 UD-Q8_K_XL (33GB) 量化：

• 用户指定，质量远高于 Q4_K_M
• Q8 保留了更好的精度，适合粤语和复杂指令
• 代价是 VRAM 占用大，几乎占满两张 24GB 显卡

---

四、最终配置

llama-server 启动参数

llama-server
--model Qwen3.6-27B-UD-Q8_K_XL.gguf
--port 8080
--host 0.0.0.0
--n-gpu-layers 99
--flash-attn on
--split-mode layer
--tensor-split 1,1
--ctx-size 65536
--batch-size 2048
--ubatch-size 512
--spec-type draft-mtp
--spec-draft-n-max 6
--temp 0
--parallel 1
--no-mmap
--reasoning off

关键参数说明：

• --split-mode layer：按层分割到双 GPU (比 row 模式更好)
• --tensor-split 1,1：平均分配到两张显卡
• --spec-type draft-mtp：启用 Qwen3.6 内置的 MTP 规范解码
• --spec-draft-n-max 6：每步生成 6 个 draft tokens (1/2)
  [2026/5/23 下午7:33] HKT_Bot: - --ctx-size 65536：最大上下文 64K tokens
• --flash-attn on：启用 Flash Attention 节省 VRAM

Systemd 服务配置

[Unit]
Description=llama-server
After=network.target

[Service]
Type=simple
User=ic
ExecStart=/home/ic/llama.cpp/build/bin/llama-server
--model /home/ic/.cache/huggingface/hub/models--unsloth--Qwen3.6-27B-MTP-GGUF/snapshots/b3a58239d8d40b953e34936c9afeb28baa518230/Qwen3.6-27B-UD-Q8_K_XL.gguf
--port 8080 --host 0.0.0.0 --n-gpu-layers 99 --flash-attn on
--split-mode layer --tensor-split 1,1 --ctx-size 65536
--batch-size 2048 --ubatch-size 512
--spec-type draft-mtp --spec-draft-n-max 6
--temp 0 --parallel 1 --no-mmap --reasoning off
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

---

五、性能测试结果

5.1 速度基准

• 短 prompt (~30 tokens)：35-57 t/s，~92% MTP Acceptance，最高峰值，cold start 后稳定
• 中 prompt (~100 tokens)：40-45 t/s，~65%，典型日常使用场景
• 长 prompt (~200 tokens)：20-23 t/s，~21%，长生成时 draft 偏移，reject 增多
• 粤语对话 (150 tokens)：~22 t/s，~21%，粤语输出正常，无乱码

5.2 与 DFlash 对比

• 速度 (短)：DFlash ~25 t/s → llama.cpp 35-57 t/s
• 速度 (长)：DFlash ~23 t/s → llama.cpp 20-23 t/s (持平)
• 初始延迟：DFlash 低 → llama.cpp 较高 (33GB 模型加载慢)
• 模型质量：DFlash Q4 (损失大) → llama.cpp Q8 (几乎无损)
• 粤语支持：DFlash 乱码 → llama.cpp 正常
• 稳定性：DFlash spec decode 间歇性崩溃 → llama.cpp 稳定运行

5.3 长短 prompt 速度差异分析

长 prompt (200 tokens) 速度明显低于短 prompt (30 tokens)，原因有三：

1. MTP acceptance rate 随生成长度下降

   • 短 prompt：draft token 与 main model 的分布接近，~92% 被接受
   • 随着 context 增长，draft 预测偏离 main model 越来越大，acceptance 降至 ~21%
   • 更多 reject → 更多 main model evaluation → 更慢

2. KV Cache 增长

   • 30 tokens：attention matrix 小，VRAM bandwidth 充足
   • 200 tokens：attention matrix 增长 ~44 倍，GPU 需要搬运更多数据
   • Q8 33GB 模型已经几乎占满 dual 24GB VRAM，KV cache 空间紧张

3. 双 GPU layer split 的 PCIe 同步开销

   • 每步推理需要在 GPU 01 之间传输 activation data
   • 短 prompt：只传输几次，开销可忽略
   • 长 prompt：200+ 次累加传输，PCIe latency 显著

5.4 GPU 资源使用

• GPU 0：VRAM 24GB 总量，~22.7 GB (95%) 使用，剩余 ~1.3 GB，PCIe 16.0 GT/s x16
• GPU 1：VRAM 24GB 总量，~18.9 GB (79%) 使用，剩余 ~5.1 GB，PCIe 16.0 GT/s x16

剩余 VRAM 约可容纳 5-20K tokens 的 KV cache。超过此量会 spill 到系统 RAM (126GB)，导致速度进一步下降。

---

六、遇到的关键问题

6.1 DFlash spec decode 失效

• 症状： acceptance rate 14-28%，速度 ~23 t/s
• 根因： DFlash 基于旧版 llama.cpp (commit 7d9a95d)，未合入上游修复 (d14ce3d #23268 #23544)
• 处理： 放弃 DFlash，转用上游 llama.cpp + MTP GGUF

6.2 Qwen3.6 粤语支持

最初在 DFlash 上粤语输出为乱码 (mojibake)。切换到 llama.cpp MTP Q8_K_XL 后，粤语完全正常：
"你好呀！今日天氣幾好，你有冇出街行下？"

6.3 Qwen3.6 工具调用限制

Qwen3.6 模型的工具定义数量有限 —— 实测约 6-7 个 tool definitions 为上限，超过后会进入无限重复循环。这与 Hermes Agent 使用的 30+ 工具不兼容。

6.4 上下文长度设置

配置了 --ctx-size 65536 (64K tokens)，但实际可用长度受限于 VRAM：

• 33GB Q8 模型已占用绝大部分 VRAM (GPU0 95%, GPU1 79%)
• 剩余 VRAM 不足以支持满 64K 的 KV cache

---

七、总结

从 DFlash 切换到上游 llama.cpp + MTP GGUF 是一个正确的决策：

• 速度：短 prompt 提升至 35-57 t/s，恢复原有水平
• 质量：Q4 → Q8，精度大幅提升
• 粤语： → 完美支持
• 稳定性： 频繁崩溃 → 持续稳定运行
• 维护性：DFlash 已停更多年的 fork → upstream 持续更新

最终 verdict： Qwen3.6-27B Q8_K_XL 在双 7900 XTX 上通过 llama.cpp + MTP 实现了高性能本地推理，短 prompt 达到 35-57 t/s，长 prompt 20-23 t/s，粤语正常。

X99 Dual 7900 XTX + DFlash Qwen3.6-27B 實測

硬體： X99底板 + 2張 AMD RX 7900 XTX 顯示卡 (每張24GB RAM) + ROCm 7.2.3
模型： Qwen3.6-27B Q4_K_M (~16GB，官方原版)
加速模型： dflash-draft-3.6-q8_0 (~1.8GB)
框架： DFlash (lucebox-hub)

乜嘢係 DFlash？

想像你打字好慢，但身邊有個助手（Draft 模型）可以幫你估你會打乜，你每次出 1 個字，佢就估下一句 10 個字。你只需睇一眼確認啱唔啱，啱就跳過 — 唔使逐個字打，咁就快好多。

呢個就係「speculative decode」嘅概念。

花咗好多時間發現嘅重點

DFlash 入面有啲叫「Phase 2」嘅加速 kernel，第一次 compile 嗰陣唔小心關咗，搞到慢咗成 1.7 倍。要手動開返先正常。

速度結果

普通模式（兩張卡分工）

• 測試模式: 普通模式（兩張卡分工）

• 記憶長度: 4K

• 速度: 18 tokens/s

• 對比普通模式: 1.00x（基準）

DFlash 加速（最佳設定）

• 測試模式: DFlash 加速（最佳設定）

• 記憶長度: 4K

• 速度: 52 tokens/s

• 對比普通模式: 2.88x

DFlash 加速

• 測試模式: DFlash 加速

• 記憶長度: 128K

• 速度: 50 tokens/s

• 對比普通模式: 2.79x

DFlash 加速

• 測試模式: DFlash 加速

• 記憶長度: 256K

• 速度: 50 tokens/s

• 對比普通模式: 2.77x

有幾快？ 普通模式每秒出 18 個字，開 DFlash 後每秒出 50 個字，快差唔多 3 倍。

256K 長度係幾多？ 大約等於半本《三體》嘅長度。就算模型要記咁多嘢，速度都幾乎冇跌（51 → 50 tokens/s），只慢 4%。

技術用語解碼

• Token = AI 模型嘅「字詞單位」，一個中文字大約 1-2 個 token
• tok/s (tokens per second) = 每秒生成幾多個字，越高越快
• Context / ctx = 模型記得幾多內容，256K ≈ 約 20 萬中文字
• GGUF = 模型檔案格式，類似 .mp4 但係俾 AI 用
• ROCm = AMD 版嘅 CUDA，俾顯示卡做 AI 計算
• q4_0 = 壓縮率，將 16GB 模型壓細嘅程度，q4_0 用 4-bit 儲存，慳位又快
• AR baseline (Autoregressive) = 普通逐個字生成模式，最慢但最穩
• Budget = DFlash 助手每次幫你估幾多個字，10 係最理想
• Draft-feature-mirror = 一個「對齊」功能，令助手嘅估算更加準確，快多 30%
• Dual-split = 兩張卡各做一半運算，分擔 workload

最佳指令（for 技術讀者）

./build/test_dflash <target.gguf> <draft.gguf> <prompt.bin> 512 <out.bin>
--ddtree --ddtree-budget=10 --fast-rollback
--target-gpu=0 --draft-gpu=1
-ctv q4_0 -ctk q4_0
--max-ctx=262144 --draft-feature-mirror

@fenky0304 純粹為了興趣

@David-Zhang 謝謝，這個我做吓研究

@terry 说:

说实话哥们能把这张肥卡用两张放到一个机箱里我也挺震惊的，我的主板除非用延长线，否则做不到。

雖然是同一個機箱內，但我用了延長線把下面的卡放在底部，把下面卡的風扇對住底部的風口，墊高了一點

@terry 遲些會補充的

硬件：

• 主板：HUANANZHI X99-CD3 GAMING（X99）
• CPU：Xeon E5-2666 v3（10C/20T）
• RAM：128GB DDR3 ECC @ 1600
• GPU：2× RX 7900 XTX（PULSE，各 24GB）
• 儲存：NVMe 1.9TB（Win + Ubuntu + Shared）
• OS：Ubuntu 24.04.4 / kernel 6.17.0

軟件：

• ROCm 6.3 / Python 3.12.3
• llama.cpp b9198（自編譯 ROCm）
• ComfyUI + ComfyUI-Manager
• Shell scripts 管理全部操作（~/bin/）

LLM Benchmark（Qwen3.6-27B Q4_K_M）：

單卡

• 配置: 單卡

• Context: 8K

• Token Gen: 27.2 t/s

單卡

• 配置: 單卡

• Context: 128K

• Token Gen: 27.0 t/s

雙卡 tensor-split

• 配置: 雙卡 tensor-split

• Context: 8K

• Token Gen: 19.8 t/s

雙卡 tensor-split

• 配置: 雙卡 tensor-split

• Context: 128K

• Token Gen: 21.4 t/s

→ 單卡打贏雙卡 tensor-split！27B Q4_K_M fit 入 24GB VRAM 單卡已經最快。雙卡只係 >64K context 先用得著。

投機解碼：
Qwen3.6 用 M-RoPE，同 llama.cpp 投機解碼唔相容（全部 spec type 失敗，accept rate < 13%）。Skip，27 t/s 已經夠快。

ComfyUI 雙 Instance：
兩張卡各一個獨立 ComfyUI（port 8188/8189），systemd 管理自動開機。

Flux.1 dev：78.9s（雙 instance）vs 73.4s（tensor-split）
LTX Video：13.5s（雙 instance）vs 22.9s（tensor-split）

→ 雙 instance 整體完勝，尤其 LTX 快接近一倍，仲可以同時跑兩個 workflow。

ROCm 6.3 tips：

• 記得 delete blacklist-amdgpu.conf
• 唔使 HSA_OVERRIDE_GFX_VERSION（gfx1100 原生支援）
• tensor-split 用 --tensor-split 24,24（absolute GiB）
• ROCm 6.3 對 RX 7900 XTX 支援完善

AI 據說可以跑70B模型

讓Hermès Agent + deepseek v4 flash 線上版幫我裝

謝謝, 我在弄了

打算双7900XTX卡, 128GB DDR3 RAM, 双OS系統 LINUX(搞AI) + WINDOWS (打机, 雖然很少打机). X99主板 1350W电源. 用來跑QWEN跟ComfyUI (LTX2好嗎), 用SG Lang / vLLM / llama.cpp 哪个較好? ROCm 哪個版本 7.X /0 6.X OK?

我一星期前閑魚南山区入了 Mac Mini M4 16GB 用 Hermes, 現在想試用本地模型, 保留 Mac Mini+ Hermes 接去双7900XTX組合用模型可取嗎.技術配置上有啥要注意?