抡锤者

CHIA AN YANG

以下是讓codex cli直接連進ubumtu幫我優化本地模型qwen3.6 27b q4km 跑hermes agent使用telgram對話速度的優化，跑完真的飛起了，我128k上下文，平常查台股跟幣價K線分析幾乎可以做到與雲端API秒級回應的速度，建議大家都去優化，我另外裝一張rtx3060 12g跑 9B模型讓他專職壓縮,這樣0.5到了壓縮幾乎也是30-40秒內跑完,可以玩的飛飛起以下文章請codex做的總結,分享給大家,晚點再補截圖

Hermes Telegram 瘦身總結（本地模型版）

日期：2026-06-03
環境：AMD 7900XTX 24GB + 本地 Qwen3.6 27B q4
目標：讓 Hermes 在 Telegram 上回應更快、更穩，不要每次先背一大包提示詞和工具 schema。

這份整理只講 Telegram 方向的 Hermes 瘦身。
不討論幣價分析腳本本身的策略與演算法，只講 Hermes 怎麼變瘦、怎麼減少工具/skill/prompt 負擔。

一、先說結論

我這次做的不是單一小改動，而是把 Telegram 用到的 Hermes 執行面拆成更小、更乾淨的版本。

重點有 5 類：

縮 Telegram 可用工具集
減少 system prompt 會自動注入的內容
關掉對本地 27B 性價比不高的附加功能
處理 skill 撞名與 skill 繞路
把新聞查詢統一路由，避免模型自己亂選入口

這些調整的目的都一樣：

減少首輪輸入 token
減少工具 schema 體積
減少 skill 搜索/歧義/繞路
減少不必要的工具決策回合
讓 Telegram 問句更常直接進 terminal 跑腳本

二、Telegram 工具面瘦身

1. Telegram 平台工具集縮到最小

目前 config.yaml 已調成：

platform_toolsets:
  telegram:
    - terminal
    - no_mcp

也就是 Telegram 這邊 只保留：

terminal
no_mcp

2. 砍掉 Telegram 不需要的工具面

原本這類工具都可能一起進場，增加 schema 與判斷成本：

web
file
skills
clarify
messaging
cronjob
各種 browser / image / tts / mcp 相關能力

現在 Telegram 這邊都先不帶。

3. 這樣做的效果

對雲端大模型來說，這種工具面膨脹有時還撐得住。
但對本地 27B q4，每次多帶一批工具定義，模型都要先理解：

有哪些工具
每個工具做什麼
參數格式是什麼
這題要不要叫工具

所以縮工具集的收益很直接：

首輪思考更快
比較不會亂繞工具
比較少出現「先想一堆，晚點才跑 terminal」

三、System Prompt / Context 瘦身

1. 關掉 skills prompt index 注入

我改了：

新增了這個控制：

skills:
  prompt_index_enabled: false

並在 prompt_builder.py 裡讓它真的生效：

當 skills.prompt_index_enabled: false
直接 不把 skills 索引注入 system prompt

2. 這件事為什麼重要

你本機 ~/.hermes/skills 裡 skill 很多。
如果每輪都把一大串 skills index 塞進 system prompt，本地 27B 會先浪費大量 prefill 在讀這些資訊。

這次等於直接砍掉：

一整段 skills 目錄說明
一大包 skill 名稱 / 描述 / 可用項

3. 精簡 SOUL.md

我把 SOUL.md 改成 Telegram 實戰版，只保留：

身份
路由原則
新聞 / 技術分析 / BSB 常見問句的執行邏輯

拿掉或大幅縮短了：

Windows Task Scheduler 相關內容
舊版 Windows 路徑
冗長版本歷史
過長腳本欄位解說
不屬於 Telegram 日常對話必需的說明

目的很單純：

SOUL 只保留每輪真的要用的高優先級規則
不讓本地模型反覆重讀無關說明

4. 關掉額外 prompt 區塊

在 config.yaml 關掉了：

agent:
  task_completion_guidance: false
  environment_probe: false

這兩塊都會讓每輪 prompt 變更長。
對 Telegram 這種短問短答，收益不高，成本比較明顯。

四、關掉對本地 27B 不划算的附加功能

1. memory 關掉

memory:
  memory_enabled: false
  user_profile_enabled: false

理由：

本地 27B 先把眼前問題答快，比長期個人化更重要
memory 相關內容會增加上下文與管理成本

2. curator 關掉

curator:
  enabled: false

理由：

你當前需求不是技能自動維護
對 Telegram 即時回應幫助不大

3. lsp 關掉

lsp:
  enabled: false

理由：

Telegram 上主要不是在做 repo 級語義編輯
LSP 對這條使用路徑是額外負擔

五、Skill 層瘦身

1. 解掉 skill 撞名

之前 Hermes 會遇到這種情況：

同名 skill 出現兩份
模型先去 skills_list
再去 skill_view
然後報 ambiguous
最後才進入真正任務

這會讓首輪甚至前幾輪都浪費在 skill 系統裡。

我處理掉的重名入口包括：

crypto-ceo-trading-agent
bsb-analysis
orderbook-analysis
crypto-multiframe-trend-analysis

內層重複副本改成 *-internal，避免 Hermes 在公開 skill 名稱上撞名。

2. 驗證結果

我重新掃過整棵 ~/.hermes/skills 的 frontmatter name:，
目前 沒有重複的真實 skill name。

3. 為什麼這對速度有感

這種問題不會讓腳本變慢，
但會讓模型在真正跑腳本前先經歷：

skill 搜尋
skill 檢視
skill 錯誤
再重試

對本地模型來說，這類「前置繞路」很傷。

六、新聞查詢路由瘦身

這部分雖然是功能更新，但本質上也是 Hermes 路由瘦身。

1. 統一成單一入口

新增：

news_router.py

現在新聞類都先走：

~/.hermes/hermes-agent/venv/bin/python3 ~/.hermes/skills/tw-news/scripts/news_router.py "完整問題或關鍵字"

它會自動判斷：

即時新聞
原因型查詢
事件 / 事實型查詢

2. 為什麼要統一入口

以前模型可能在這幾個概念之間搖擺：

tw-news.py
news_search.py
舊文案裡殘留的 web-search.py

入口越多，模型越容易：

想太久
選錯
先問或先繞

現在改成單一路由，模型只要先判斷：

這是不是新聞問題

一旦是，就走同一入口。

3. universal_news.py 也做了提速

我改了：

universal_news.py

主要提速手段：

timeout：12s -> 6s
查詢組數：8 -> 4
改成 並行抓 Google News RSS

這樣做的效果是：

查新聞時比較不容易整串卡很久
失敗時也比較快回退

七、orderbook 路徑瘦身

這段雖然跟幣價流程接壤，但這裡只講 Hermes 路由與工具負擔，不講分析邏輯。

1. 舊問題

舊的 orderbook skill 還留著這類做法：

curl ...
python -c
python3 -c

而你的 Hermes 設定裡，對這類 -c / -e 腳本執行是敏感的。
結果就是：

模型一旦選到這條路
terminal 可能被 guard/approval 擋住
白白卡掉約 60 秒

2. 新做法

新增正式腳本：

analyze_okx_orderbook.py

現在 orderbook skill 改成：

直接跑正式腳本
不再依賴 inline python

3. 這對 Telegram 有什麼幫助

很直接：

少掉被攔截的命令模式
少掉 60 秒級的假卡頓
模型也比較容易理解「這題有專用腳本可以直接跑」

八、實際效果

1. 首輪延遲改善

之前曾出現：

首輪 API call 80 秒以上
甚至 100 秒以上才開始跑工具

做完 prompt / tool / skill 瘦身後，近期測到的首輪常見區間已經降很多：

約 3s ~ 12s

2. Telegram 類型問句更常直接進 terminal

這次調整後，模型對短問句比較容易：

先判斷類型
直接跑 terminal
再整理回答

而不是：

先找 skill
先想要不要叫別的工具
先繞新聞入口

3. 實測例子

Hermes 本體測試：

今天幣圈有什麼新聞
- wall time 約 35s
- 無 blocked terminal
BSB 壓力點到了沒
- wall time 約 25s
- 無 blocked terminal

這代表這次不是只改文案，
而是把 原本會慢、會卡、會被攔的實際路徑 拆掉了。

九、這次改過的關鍵檔案

設定 / Prompt

新聞

Skills / 路由

十、適合分享給網友的重點一句話版

如果你的 Hermes 跑在本地中大型模型上，
最有效的優化通常不是改一點 prompt，而是把平台工具集縮小、關掉 skills index 注入、解掉 skill 撞名、把多入口路由收成單一路徑。

對 Telegram 這種短問短答場景，這比加更多功能更重要。

十一、目前還可以再優化的地方

雖然這次已經瘦很多，但還有兩個方向還能繼續做：

再瘦 crypto 主 skill
- 目前它仍然偏長
- 可以再拆成 Telegram 極簡版
把 Telegram 和 CLI profile 分更乾淨
- 現在已經有平台級工具差異
- 再往前可以做 profile 級的 prompt / skills 分流

十二、備份

這次相關備份包含：

十三、給網友的實務建議

如果你也在本地跑 Hermes，尤其是 20B~30B 級模型，建議優先做這些：

Telegram 只留真的會用到的 toolset
關掉 skills index 注入
關掉 memory / curator / lsp 這類非當前必要功能
把同類查詢收成單一路由入口
清掉 skill 撞名
避免 inline python / 臨時拼命令 / 多層工具繞路

這些通常比「再換一版 prompt」更有效。

CHIA AN YANG

7900 XTX 本地 LLM 優化實測報告（Qwen3.6-27B）

硬體： AMD RX 7900 XTX 24GB / AMD Ryzen 9 7950X / Windows 11 原生
用途： Hermes Agent、加密貨幣分析、查資料、opencode/pi.dev 本地 API
推論框架： llama.cpp Vulkan（Windows Native）

優化前 vs 優化後

指標	優化前	優化後	提升
Prefill（長 context 14k token）	~273 t/s	~530 t/s	+94%
TG 生成速度（Hermes）	~37 t/s	62–80 t/s	+68~116%
TG 生成速度（一般對話）	~37 t/s	~42 t/s	+14%
Qwen3 thinking 卡死問題	偶發（8000+ token 無限生成）	已解決
VRAM 佔用	~18.7 GB	~18.7 GB	不變

優化一：KV Cache q8_0 → q4_0

改動： run.bat 和 start-all.bat 的 -ctk q8_0 -ctv q8_0 改成 -ctk q4_0 -ctv q4_0

效果：

Prefill：273 t/s → 730 t/s（+167%）
TG：37 t/s → 42 t/s（+14%）
品質：差異可忽略（q4_0 vs q8_0 KV cache 品質損失極小）

原因： Vulkan 後端的 q8_0 KV cache 有嚴重 Prefill 瓶頸，q4_0 就沒有這個問題。
這是最簡單、最有效的改動，不需要換模型或換 binary。

優化二：關閉 Qwen3 Thinking（--reasoning off）

改動： run.bat 加上 --reasoning off

效果： 解決 Qwen3.6 偶發性卡死問題。

原因： Hermes Gateway 送的請求會觸發 Qwen3 的 thinking mode，budget 預設為 INT_MAX（無限），
導致 server 有時生成 8000+ 個 thinking token 停不下來，後續所有請求全部卡在 queue 裡。

優化三：MTP（Multi-Token Prediction）升級

升級內容

Binary： 從 PR #22673 源碼編譯（llama.cpp MTP 分支，尚未合入主線）
模型： 換成帶 MTP 層的 Qwen3.6-27B-Q4_K_M-mtp.gguf（15.8 GB，froggeric/Qwen3.6-27B-MTP-GGUF）
新增參數： --spec-type draft-mtp --spec-draft-n-max 3 -fa 1
注意： 參數名稱是 draft-mtp，不是 mtp（新版 PR 已改名）

實測速度（Hermes 結構化輸出）

請求	Prefill	TG	MTP 接受率
系統提示暖機（14k tokens）	531 t/s	62.8 t/s	95.6%
第 1 次 Telegram 指令	398 t/s	60.0 t/s	72.7%
第 2 次 Telegram 指令	453 t/s	73.6 t/s	98.5%
第 3 次 Telegram 指令	469 t/s	59.5 t/s	72.6%
直接 API 測試（短句）	—	79.9 t/s	—

重要：MTP 加速效果依任務而定

場景	接受率	TG 速度	說明
Hermes 結構化輸出（工具呼叫、JSON）	72–100%	60–80 t/s	最佳
加密貨幣分析、查資料（固定格式）	預估 70%+	60–75 t/s	很好
Web UI 自由對話	30–45%	35–49 t/s	效果有限

結論： MTP 對結構化輸出效果顯著（+68~116%），自由對話效果有限甚至可能略慢。

最終啟動設定

run-mtp.bat（只跑 llama-server，測試用）

@echo off
C:\llama-cpp-mtp\build\bin\Release\llama-server.exe ^
 -m C:\llama-cpp\Qwen3.6-27B-Q4_K_M-mtp.gguf ^
 --device Vulkan0 -ngl 999 -c 65536 ^
 -ctk q4_0 -ctv q4_0 -np 1 ^
 --spec-type draft-mtp --spec-draft-n-max 3 ^
 --reasoning off -fa 1 ^
 --port 8080 --host 0.0.0.0
pause

start-all-mtp.bat（完整啟動：llama-server + Hermes + 暖機）

@echo off
set "H_EXE=C:\Users\jaran\AppData\Local\hermes\hermes-agent\venv\Scripts\hermes.exe"
set "L_EXE=C:\llama-cpp-mtp\build\bin\Release\llama-server.exe"
set "M_PATH=C:\llama-cpp\Qwen3.6-27B-Q4_K_M-mtp.gguf"
set "H_HOME=C:\Users\jaran\AppData\Local\hermes"
set PATH=C:\llama-cpp-mtp\build\bin\Release;%PATH%

echo [STEP 1] Launching llama-server (MTP)...
start "llama-server-mtp" cmd /k "%L_EXE% -m %M_PATH% --device Vulkan0 -ngl 999 -c 64000 -ctk q4_0 -ctv q4_0 -np 1 --spec-type draft-mtp --spec-draft-n-max 3 -fa 1 --reasoning off --port 8080 --host 127.0.0.1"

timeout /t 8

echo [STEP 2] Launching Hermes Gateway...
start "hermes-gateway" cmd /k "set HERMES_HOME=%H_HOME%&& set HERMES_GIT_BASH_PATH=C:\Program Files\Git\bin\bash.exe&& %H_EXE% gateway run --replace"

timeout /t 5

echo [STEP 3] Running Warmup Script...
powershell -ExecutionPolicy Bypass -File "%H_HOME%\scripts\warmup.ps1"

echo.
echo =======================================================
echo   SYSTEM READY  [MTP Mode: draft-mtp, n-max 3]
echo =======================================================
pause

踩坑紀錄

BITS Transfer 不支援 HuggingFace redirect → 改用 curl.exe -L -C -（支援斷點續傳）
Vulkan SDK 裝好但 cmake 找不到 → 需手動 set VULKAN_SDK=C:\VulkanSDK\1.4.350.0
VS Build Tools 需手動勾選「使用 C++ 的桌面開發」 → winget 不帶 --override 只裝框架
WebUI 編譯需 npm build → node/npm 裝好後先 build WebUI 再編 server
MTP 參數名稱是 draft-mtp，不是 mtp → PR 更新後改名，文章版本較舊
llama-common.dll 被 server 鎖住無法重編 → 先關 server 再 build
Qwen3.6 是 hybrid SSM 架構 → KV cache 無法跨對話複用，每次都重跑全部 prompt（正常現象）

等待中的升級

PR #22673 合併進主線後：不用自行編譯，直接下載官方 release binary 即可
MTP Prefill 降速 bug 修復後：Prefill 速度可望進一步提升（目前 Prefill 略慢於非 MTP）
Vulkan + TurboQuant 整合穩定後：Prefill 和 TG 都有進一步提升空間

測試日期：2026/05/14–15

CHIA AN YANG

7900 XTX + Qwen3.6-27B 測試完整整理

整理日期：2026-05-29

原本在win11原生llama.cpp+vulken,但想為雙卡7900XTX做準備,
換了洋垃圾的主機板裝原生ubuntu24.04+rocm,以為會更好,結果折騰了3天,最終還是vulken更優,測所有參數,發文上來跟大家分享,尋找更優的腳本設計,以下是折騰後請AI整理的資料,部分有參考David Zhang大神的文章

這份整理的是目前在 Ubuntu 24.04 + RX 7900 XTX 24GB 上，針對 llama.cpp 做過的 ROCm / Vulkan / MTP 實測彙整。
目標是找出最適合 Hermes / 長上下文 / 單卡可用的路線。

一、測試環境

主機：jaran-Z10PE-D16-WS
CPU：Intel Xeon E5-2678 v3 @ 2.50GHz（雙路）
RAM：64GB
GPU：AMD Radeon RX 7900 XTX 24GB（gfx1100 / RADV NAVI31）
OS：Ubuntu 24.04
目標：Qwen3.6-27B，單卡先跑通，並評估 Hermes 實戰可用性

二、模型清單

本次主要測過的模型：

Qwen3.6-27B-MTP-IQ4_XS.gguf
Qwen3.6-27B-UD-Q4_K_XL.gguf
Qwen3.6-27B-Q4_K_M-mtp.gguf

補充說明：

測試過程中，Qwen3.6-27B-Q4_K_M-mtp.gguf 這個檔名曾被做過 alias / symlink 對照，實際內容在某些階段指向 IQ4_XS
因此下面的結果會以「實際跑到的模型 / 腳本」為準

三、ROCm 測試

1. clean ROCm + turboquant

模型：Qwen3.6-27B-UD-Q4_K_XL.gguf

pp512: 747.91 t/s
tg128: 29.36 t/s

判讀：

prefill 很強
decode 明顯慢
對 Hermes 日常回應不理想

2. clean ROCm + llama-server + MTP

模型：Qwen3.6-27B-Q4_K_M-mtp.gguf

裸 decode / llama-bench: 29.27 t/s
llama-server + MTP: 約 36-37 t/s

判讀：

比 turboquant 的 decode 好一些
但仍未到 50+

3. ROCm + MTP + IQ4_XS

模型：Qwen3.6-27B-MTP-IQ4_XS.gguf

64K 真實測試：43.845 t/s

判讀：

比舊版 ROCm MTP 更好
但 64K 下仍未穩定達到 50+

四、Vulkan 測試

共通 Vulkan build

Ubuntu 原生 llama.cpp
build 目錄：~/src/llama.cpp.clean/build-vulkan
server 路徑：/home/jaran/src/llama.cpp.clean/build-vulkan/bin/llama-server

共通參數基準

多數測試共通的參數大致如下：

-ngl 99
-fa on 或 -fa 1
--cache-type-k q4_0
--cache-type-v q4_0
--spec-type draft-mtp
-np 1
--temp 0.7 或 0.6
--top-k 20
--host 0.0.0.0
--port 8080

五、Vulkan + 64K 測試

1. `Qwen3.6-27B-MTP-IQ4_XS.gguf`

共通條件：

-c 65536
--spec-draft-n-max 2
-b 2048
-ub 512
-t 12

結果：

48.03 / 46.99 / 46.52
48.32 / 47.67 / 46.54
49.52 / 45.93 / 42.59

判讀：

穩定值大約在 46.5 - 48.0 t/s
平均大約落在 47 t/s 左右
偶爾可以摸到接近 50
但整體未穩定破 50

2. `Qwen3.6-27B-UD-Q4_K_XL.gguf`

結果：

44.60 / 49.25 / 44.60

判讀：

平均約 46.15 t/s
有峰值，但波動比 IQ4_XS 大

3. `Qwen3.6-27B-Q4_K_M-mtp.gguf`

結果：

46.93 / 41.54 / 49.70

判讀：

平均約 46.06 t/s
也能接近 50，但穩定性不如 IQ4_XS

六、Vulkan + 128K 測試

1. 早期 128K（偏保守參數）

條件概念：

-c 131072
--spec-draft-n-max 2
-ub 256

結果：

44.76
VRAM Used: 20,909,498,368 B
VRAM Total: 25,753,026,560 B

後續同組測到：

49.40
44.57
46.11

判讀：

平均約 46.69 t/s
可跑，但不是最優

2. 對齊大神的David Zhang文章思路的 128K

條件：

--spec-type draft-mtp
--spec-draft-n-max 3
-c 131072
-ub 256
-fa 1
-np 1
--temp 0.7
--top-k 20

結果：

52.62
53.32
51.47
53.95

平均：

約 52.84 t/s

判讀：

這是目前很好的 128K 版本
已穩定進入 50+
比前面的 64K 保守版明顯更快

3. 128K 的結論

128K 是目前的甜蜜點之一
比 64K 的保守版更有機會穩定 50+
也比 256K 更容易維持穩定

七、Vulkan + 256K 測試

對齊他文章思路的 256K

條件：

--spec-type draft-mtp
--spec-draft-n-max 3
-c 262144
-ub 256
-fa 1
-np 1
--temp 0.7
--top-k 20

結果：

53.06
55.14
49.07

平均：

約 52.42 t/s

判讀：

256K 可以跑，而且峰值不差
但平均略低於 128K
波動也更大

八、對照結論

路線	模型	代表結果	判讀
ROCm	`UD-Q4_K_XL`	`pp512 747.91 / tg128 29.36`	prefill 強，decode 慢
ROCm	`Q4_K_M-mtp`	`29.27 / 36-37 t/s`	有改善，但仍未穩定 50+
ROCm	`MTP-IQ4_XS`	`43.845 t/s @ 64K`	比舊版好，但仍未達標
Vulkan	`MTP-IQ4_XS`	`46-48 t/s` 穩定	64K 最穩的基準
Vulkan	`UD-Q4_K_XL`	平均 `46.15 t/s`	有峰值，但較抖
Vulkan	`Q4_K_M-mtp`	平均 `46.06 t/s`	可用，但不如 IQ4_XS 穩
Vulkan	`128K draft-mtp n=3`	平均 `52.84 t/s`	目前最佳平衡點
Vulkan	`256K draft-mtp n=3`	平均 `52.42 t/s`	可跑，但不如 128K 穩

九、最終判斷

1. ROCm 路線

適合研究與調校
prefill 很強
decode 對 Hermes 實戰來說偏慢
不如 Vulkan 穩

2. Vulkan 路線

是目前單卡最實用的方向
尤其是 draft-mtp + Qwen3.6-27B-MTP-IQ4_XS
在 64K/128K/256K 都能跑，但表現以 128K 最平衡

3. 最適合 Hermes 的結論

如果重視穩定與實戰：128K 最推薦
如果重視簡單與保守：64K 也可用
如果重視極限與展示：256K 可以，但不如 128K 穩

CHIA AN YANG

# RX 7900 XTX 跑 Qwen3.6-27B Hermes Agent — 從 Win11 Vulkan 到 Ubuntu ROCm 的完整實戰與踩坑全紀錄

原本已經優化的差不了,看到大神Dflash60-80t/s我又折騰了快三天,出動codex cloude code 最終把dflash修成可以用hermes的版本,但速度最終提不上,最終棄坑,最後還是走最早之前的win11 +vulken的腳本 mtp投機,抄該腳本得到一個還不錯的結論,分享給大家,讓大家少走歪路,從中也學了許多,歡迎大家多分享發文,才會一起更懂這個新世界。

一張 7900 XTX、一個 27B 稠密模型、一個接 Telegram 的 Hermes agent，目標 45+ tok/s。
這篇把所有試過的路、所有踩過的坑、所有真實數據攤出來分享。結論可能跟你想的相反：
繞了一大圈、研究了 DFlash 等各種花招，最後贏在把設定拉回最樸素的「純 MTP n=3」。

0. TL;DR（先給結論）

可用解：llama.cpp（HIP/ROCm）+ Qwen3.6-27B-Q4_K_M + 純 MTP 投機解碼（--spec-type draft-mtp --spec-draft-n-max 3）。在真實 Hermes 加密分析 agent 上 decode 37–51 tok/s，工具調用尤其快。
最大教訓：RDNA3 上 MTP 投機 n=3 是甜點，n=4 過度投機反而把接受率壓垮。這點被 Win11 報告、Lucebox DFlash 社群報告、跟我自己的真實 log 三方獨立印證。
走錯的路：(a) 疊 ngram 草稿器（對中文分析輸出沒貢獻還拉低整體接受率）；(b) 改用 DFlash（block-diffusion 草稿器，benchmark 數字漂亮但不適合長系統提示的 agent，詳見第 4 節）。
戰略真相：ROCm 單卡相對 Win11 Vulkan 是「側升」不是「提升」。而且實測兩張 7900 XTX 跑 llama.cpp 雙卡，generation 反而更慢（28 vs 單卡 37 t/s，無 NVLink、每步 decode 走 PCIe 同步）——雙卡只贏 prefill。要真的破 50–60 天花板，唯一沒測過的路是 vLLM tensor-parallel（理論 120–150，但那是跟 llama.cpp 雙卡完全不同的機制）。

1. 硬體與目標

項目	內容
GPU	撼訊地獄犬丐版雙8Pin 以後比較好處理? 哈 AMD Radeon RX 7900 XTX 24GB ×2（Navi 31 / gfx1100 / RDNA3），顯存帶寬 ~960 GB/s／卡；兩卡走 PCIe 4.0 x16、無 NVLink/fabric 直連。LLM 日常用單卡，另一張平時跑 ComfyUI
CPU	AMD Ryzen 9 7950X	照片是洋垃圾	最終的設備主板是 ASUS TUF X670E-PUS WIFI 可雙卡pcie-x8+x8	32G DDR5-6000
OS / 驅動	Ubuntu，ROCm 7.2.0（gfx1100 需 `HSA_OVERRIDE_GFX_VERSION=11.0.0`）
模型	Qwen3.6-27B 稠密 Q4_K_M（~16 GB），含 MTP 層
用途	Hermes Agent 接 Telegram，跑加密貨幣盤勢分析、工具調用
目標	decode ≥ 45 tok/s、context 32K→64K、工具調用要正常、不能 OOM
限制	第二張卡跑 ComfyUI（port 8188）不能動；既有 production fallback 腳本不能覆蓋

2. 完整速度數據（最終可用配置：純 MTP n=3）

全部是 RX 7900 XTX 單卡、ROCm 7.2.0、Q4_K_M、KV q4_0、真實工作負載實測。

2-1 Hermes agent（接 Telegram，含 6.6k token 系統提示 + 工具）

請求類型	decode tok/s	MTP 接受率	備註
工具調用（結構化 JSON 輸出）	47–51	80–88%	最快，JSON 超好預測
長篇中文盤勢分析（10k+ context）	36–37	54–56%	長 context + novel 輸出
prefill（冷啟動 9.5k tokens）	734 tok/s	—	~13s
prefill（checkpoint 復用）	~600 tok/s	—	新 token 才算，~2s

2-2 純模型回應速度（無工具、短提示、自由生成，各跑一次）

內容	decode tok/s	接受率
中文散文	38.9	56%
中文文章（區塊鏈介紹）	39.6	58%
中文條列清單	39.7	58%
中文對話問答	40.3	59%
中文翻譯改寫	43.7	67%
程式碼生成（Python + 測試）	42.2	64%
英文散文	41.7	62%
英文技術說明	41.1	61%
平均	~41	56–67%

反直覺但真實的發現：純對話（~41）比工具調用（47–51）慢。原因是 MTP 投機解碼的速度跟「輸出可預測性」直接掛勾——固定格式的 JSON 工具調用接受率 80–88%，自由中文/英文散文只有 56–67%，所以反而慢。速度不是固定值，是隨輸出內容浮動的。

2-3 長 context 速度（重要：幾乎不掉速）

context 長度	decode tok/s	接受率	prefill
~10K	37–51	54–88%	734 tok/s
~38K	37.5	69%	578 tok/s

補一個更高的點（~60K context）：decode 34.1 tok/s、接受率 70%——從 10K 到 60K 只掉約 8%，不是斷崖。推到 128K 滿載約 ~28–32 tok/s。

context	decode tok/s
~10K	37–51
~38K	37.5
~60K	34.1
128K（推估）	~28–32

長 context decode 速度掉得很慢——Qwen3.6 是 hybrid SSM 架構，64 層裡只有 16 層有 attention（會隨長度變貴），其餘 48 層是 SSM 遞推（無 KV、成本與長度無關），加上 q4_0 KV 極省。因此 ctx-size 開到 128K 也只是極限長度才略降速。

VRAM 實測：--ctx-size 131072（128K）在 24GB 7900 XTX 上啟動佔用 21GB（含預配的 128K KV cache），留 ~3.5GB 餘裕，可行。跑超長對話時建議瞄 rocm-smi，逼近 24GB 就降到 96K（--ctx-size 98304）。這也呼應 Win11 當時「80K–128K 速度沒差多少」的觀察。

2-4 實戰補充：128K 腳本多輪真實 session（telegram 加密 agent）

實際用 128K 腳本連續跑了 12 輪真實 Telegram 加密分析請求（ctx-size 設 128K，實際對話長度落在 13K–20K token）。體感很順，數據如下：

輸出型態	接受率	decode tok/s	樣本
工具調用 / 結構化	71–93%	42–51	51.0 / 48.7 / 47.2 / 46.2 / 41.8 …
自由中文分析（長文）	50–57%	34–36	34.7 / 34.0 / 34.5 / 36.2 …

prefill（後續輪次）：靠 llama-server 的 context-checkpoint 自動復用，後續每輪只 prefill 新 token（459–568 tok/s，約 1–7 秒），不是每次重算整個 prompt。每個 checkpoint ~158–172 MiB、隨位置緩慢長大，restore 僅 ~17–20 ms。

三個結論：

128K ctx-size 在實際 13–20K 對話下完全不拖慢 decode——預先配置的 128K KV 不影響 decode 速度，decode 只付「實際 context 長度」的注意力成本（不是 ctx-size 上限）。設大 ctx-size 是免費的保險。
速度雙峰、由輸出型態決定：工具調用 JSON 接受率 71–93% → 42–51 tok/s；自由中文分析接受率 50–57% → 34–36 tok/s。這就是「體感不錯」的原因——agent 互動主力是工具調用，正好落在快的那一檔。
context-checkpoint 讓多輪對話的首 token 延遲很低，這對 Telegram 即時互動比「純 decode 峰值速度」更重要。

3. 時間線：每個階段做了什麼

階段 0 — 起點：Win11 + Vulkan，本來就有 50–80 tok/s

最早在 Windows 11 原生 + llama.cpp Vulkan 上就跑得很好，配置極簡：

llama-server.exe -m Qwen3.6-27B-Q4_K_M-mtp.gguf（froggeric 版，含 MTP 層）
  --device Vulkan0 -ngl 999 -c 65536
  -ctk q4_0 -ctv q4_0 -np 1
  --spec-type draft-mtp --spec-draft-n-max 3   ← 關鍵：純 MTP，n=3
  --reasoning off -fa 1

實測（Hermes 結構化輸出）：

場景	TG	MTP 接受率
系統提示暖機（14k）	62.8	95.6%
Telegram 指令	60–74	72–98%
直接 API 短句	79.9	—

關鍵調參結論（當時就驗證過）：

KV cache q8_0 → q4_0：Vulkan 後端 q8_0 有嚴重 prefill 瓶頸，q4_0 沒有（prefill 273→730 tok/s）。
n=3 是甜點，n=4 過度投機反降（n=2→43.3、n=3→47.3、n=4→40.7）。
--reasoning off：不關的話 Qwen3 thinking budget 預設無限，會生 8000+ token 卡死整個 queue。

Hybrid SSM 架構（Qwen3.6）的 KV cache 無法跨對話複用，每次都要重跑全部 prompt，這是正常現象。

階段 1 — 為何想搬到 ROCm（遷移研究）

當時想突破 50–80，做了 WSL2/ROCm/vLLM 升級研究。研究結論（事後看完全命中）：

路線	速度預估	對 Hermes
現狀 Vulkan + MTP 單卡	60–80	已夠用
ROCm llama.cpp 單卡無 MTP	29	太慢
ROCm llama.cpp 單卡有 MTP	67	當時有 context 只剩 4K 的 bug
vLLM ROCm 單卡	80–100	️ 64K 壓線、長對話 OOM 風險
vLLM ROCm 雙卡 tensor-parallel	120–150	真正的提升

「WSL2/ROCm 單卡對 Hermes 是側升不是提升」——白紙黑字寫在研究裡。真正提升要雙卡 vLLM。

ROCm 遷移的三個地雷（避免重蹈）：

不設 HSA_OVERRIDE_GFX_VERSION=11.0.0 → No AMD GPUs found（gfx1100 預設識別失敗）。
ROCm 版本要鎖，別讓 apt 亂升。
（WSL2）vLLM 的 amdsmi 不通，要改用 PyTorch 偵測 GPU；且絕不能在 WSL2 裡裝 amdgpu kernel driver。

階段 2 — 搬到 ROCm 後反而變慢：設定「漂移」

搬到 Ubuntu + ROCm 後，配置不知不覺從證明過的「純 MTP n=3」漂移成：

--spec-type draft-mtp,ngram-mod,ngram-map-k4v（疊了兩個 ngram 草稿器）
--spec-draft-n-max 4（不是 3）

結果真實加密 agent 只剩 ~22–25 tok/s。比 Win11 還慢。

階段 3 — 一頭栽進 DFlash（漂亮的 benchmark，錯的方向）

詳見第 4 節。簡言之：DFlash 社群報告在 7900 XTX 上跑出 68.8 tok/s，看了手癢，花了大把時間在它身上 debug、改 code、修 bug……最後發現它的數字是短程式碼 benchmark，套到長系統提示的 hermes agent 上只有 ~23 tok/s。

階段 4 — 找回速度：拉回 Win11 配方

翻出當年的 Win11 報告，發現答案一直都在：純 MTP n=3。把 ROCm 的設定拉回去（去掉 ngram、n=4→3），真實 agent 立刻從 ~22 跳到 ~43 tok/s（工具調用 47–51），接受率從 36% 回到 54–88%。問題就是設定漂移，根因解決。

4. DFlash 深入研究：為什麼社群的 68 tok/s 用不到 Hermes agent

這節獻給所有看到 Reddit/論壇「DFlash 在 7900 XTX 跑 68 tok/s」而心動的人。

4-1 DFlash 是什麼

Lucebox DFlash 是一種投機解碼法，用輕量 block-diffusion 草稿模型並行起草，再用 DDTree 樹狀驗證。社群（lcz.me / Reddit）在 7900 XTX + Qwen3.6-27B 上實測：

方案	tok/s	說明
純自回歸基線	30.8	—
ROCm MTP n=3	47.3	純 MTP（就是我們最後用的）
DFlash Q8 draft + budget=8	68.8	社群最佳
DFlash Q4 draft + budget=22	27.0	Q4 反量化拖慢 + 樹太大

4-2 致命前提：那 68.8 是怎麼測的

社群用 bench_he.py——10 道 HumanEval 程式題，prompt 只有 ~300 token，純解碼，binary 熱機。

程式碼輸出超好預測（接受率 30–40%，AL 4.8）
prompt 短 → 草稿每步只處理 ~300 token、驗證 context 短
同一份報告也寫：用 run.py 單 prompt（含 prefill）只剩 56 tok/s

4-3 為什麼套到 Hermes agent 就崩

Hermes agent 是三重不利，跟 HumanEval 完全相反：

因素	HumanEval bench	Hermes 加密 agent
系統提示	~300 token	6,600 token
輸出性質	程式碼（好預測）	中文盤勢分析（novel）
context	短	10k–14k

實測 DFlash daemon 在真實 agent 上：18–25 tok/s，接受率只有 11–18%。比純 MTP（~43）還慢一半。

4-4 過程中挖出的 DFlash 真實 bug（修了也救不回）

DFLASH27B_DRAFT_CTX_MAX=512 從沒生效過：程式碼是 min(ring_cap, max(2048, draft_ctx_max))，那個 max(2048,…) 把任何 <2048 的設定強制拉回 2048。改成讓明確設定值生效後，draft 每步成本下降，decode 從 13 拉到 23——但還是不到 45。
長系統提示讓 draft 成本爆炸：DFlash 草稿每步處理 min(committed, draft_ctx_max) 個 token。6.6k 系統提示後就是每步重算數千 token，draft_compute 從 ~12ms（短 prompt）暴增到 ~160ms。這是 13.6× 差距的根源。
DFLASH27B_CHUNKED=1 是毒藥：號稱能並行 SSM 加速，實測造成 loopy/畸形輸出、接受率腰斬。別開。
per-request 重載：用 Python 包的 server 每個請求都重新 spawn 進程、--no-mmap 重載 16GB 模型，互動式 Telegram 每則訊息付數十秒延遲——直接「沒回應」當掉。要用常駐 daemon。

結論：DFlash 適合「短 context + 程式碼/結構化」的 batch 工作，不適合「長系統提示 + 自由中文 + 即時互動」的 agent。 它的 block-diffusion 草稿在我們的場景反而是負擔。

5. 雙卡實驗（2× 7900 XTX）：為什麼日常還是用單卡

既然有兩張 7900 XTX，自然想用雙卡加速。花了最多時間做的就是「分割模式決戰」，結論非常反直覺。

5-1 分割模式實測（128K context，tg = 生成速度）

模式	tg（生成）	prefill（輸入）	備註
`--split-mode layer --tensor-split 1,1`	~30	~350	VRAM 分攤好，生成有跨 GPU 等待
`--split-mode tensor --tensor-split 6,5`	~32	~420	prefill 快，生成有 all-reduce 開銷
`--device ROCm0,ROCm1 --tensor-split 6,5`	~28	~445	prefill 最快，tg 最慢
單卡（GPU0 only）	~37	~380	tg 最快

5-2 結論：雙卡贏 prefill、輸 generation

兩張 7900 XTX 沒有 NVLink / Infinity Fabric 直連，雙卡資料交換得走 CPUPCIe。 每個 decode 步驟都要跨卡同步，所以：

prefill（一次處理整個 prompt）：雙卡能並行，445 vs 單卡 380，快 ~18%。
generation（一個一個 token 出）：每步都被 PCIe 同步拖住，雙卡 28 vs 單卡 37，反而慢。

對 Hermes Agent 這種「長對話、逐 token 生成」的場景，generation 速度才是體感關鍵，所以日常 Telegram 用單卡。雙卡只在「貼超長文件、prefill 量極大」時才有意義。

️ 這跟「vLLM 雙卡 tensor-parallel 120–150」不衝突：vLLM 的 TP 是每層矩陣同時拆兩卡再合併的真並行，機制跟 llama.cpp 的 layer/tensor-split（序列等待 / all-reduce）完全不同。llama.cpp 雙卡實測 tg 反降是事實；vLLM TP 是另一條沒測過的路。

5-3 腳本矩陣（按場景）

腳本	GPU	context	tg	prefill	場景
日常 Telegram	單卡	64K	~40	~377	對話（最常用）
長文穩定	單卡	128K	~36	~383	長文分析
長文快速（ub512）	單卡	128K	~36	~390	偶爾 OOM
雙卡高 prefill	雙卡	128K	~28	~445	超長 prompt 預填

（註：以上是 n=4+ngram 配置的歷史數據；本報告第 2 節的 n=3 純 MTP 在工具調用上更快，47–51。）

6. 完整踩坑清單（分享重點）

投機解碼 / 模型層

RDNA3 上 MTP n=3 是甜點，n=4 過度投機反降。 三方印證。別抄 CUDA 的「n 越大越好」。
ngram 草稿器疊加在中文/分析輸出上是死重：幾乎不命中（接受率貢獻 ~0），還拉低整體 acceptance。純 MTP 最快。
MTP 速度隨輸出可預測性浮動：JSON 工具調用 47–51 tok/s（接受率 80–88%），自由散文只剩 ~40（56–67%）。報速度一定要講工作負載。
DFlash 的 68 是短程式碼 benchmark，別當通用值（見第 4 節）。
DFLASH27B_CHUNKED=1 會造成畸形輸出，別開。
Qwen3 thinking 要關，但 --reasoning-budget 0 沒用！（實測踩到）用 --jinja 載 Qwen3.6 內建 template 時 thinking 預設開；--reasoning-budget 0 只是把預算設 0，模型照樣生整段思考鏈（會跑進 reasoning_content，webui 看得到，白白浪費 token 拖慢速度）。必須用 --reasoning off（-rea off）才真正關閉。實測：budget 0 → reasoning_content 有整段思考；--reasoning off / enable_thinking=false → 思考清空。
Hybrid SSM 架構 KV 無法跨對話複用，每次重跑 prompt 是正常現象；要靠 prefix-cache / context-checkpoint 省 prefill。

ROCm / RDNA3 後端

絕大多數網路上的「ROCm 優化參數」都是抄 CUDA 的，在 RDNA3 沒效甚至反效果。 實測：--batch-size 1024、--flash-attn、MMVQ_MAX_BATCH 全沒用或變慢；--no-mmap 在 ROCm 上甚至 OOM。
ROCBLAS_USE_HIPBLASLT=1 在 gfx1100 根本不支援（只給 MI200/MI300），設了無效還可能報警告。
rocWMMA flash-attn 調優分支（曾宣稱長 context decode +136%）已被官方拒絕（PR #16827），且在 ROCm 7.2.x 是 regression，head_dim>128 也打不贏現有 tile kernel。對 Qwen3 沒好處。
KV cache 量化（q4_0 / tq3_0 / q8_0）對 decode 速度幾乎無影響，純粹是 VRAM/context 長度的取捨；q4_0 最省、能上 64K+。別把它當速度 fix。
tq3_0 KV + 溫度>0 的 AR decode 在 HIP 會 crash（VEC kernel 不支援 tq3_0），需 kq_stride_pad=256 + 補 mask。

量測方法（最容易自欺）

合成 benchmark 一律會誤導：純散文低估、純 JSON 高估，兩次都讓我得到相反的調參結論。只有使用者真實工作負載的 log 才算數。
量測工具要對齊：bench_he.py（多 prompt 純解碼）vs run.py（單 prompt 含 prefill）差了 20%。對標別人一定要同款工具。
--fa-window 小於系統提示長度會切掉工具格式指令 → 工具調用失敗。6.6k 系統提示就別設 4096 以下（或直接 0）。

架構 / 戰略

ROCm 單卡相對 Win11 Vulkan+MTP 是「側升不是提升」。而且實測 llama.cpp 雙卡（layer/tensor/device split 都試過）generation 反而比單卡慢（28 vs 37 t/s，無 NVLink、每步 PCIe 同步；見第 5 節）。雙卡只贏 prefill。要破天花板只剩 vLLM tensor-parallel（真並行，機制不同，未實測）。
雙卡的隱形坑：cache-ram > 0 會讓部分 KV 在 RAM、PCIe 傳輸不一致 → 生成速度劇烈抖動，要 --cache-ram 0 全進 VRAM；HIP_FORCE_DEV_KERNELS=1 在 gfx1100 不生效（ROCm 7.2 已預編譯）；batch 4096 / ubatch 2048 在 128K 直接 OOM，單 user 場景用 512/256 就好。
設定會「漂移」：一路調一路加，最後離當初證明過的配方越來越遠。留一份「黃金配方」隨時能退回。

7. 最終可用設定

#!/bin/bash
export HIP_VISIBLE_DEVICES=0
export ROCR_VISIBLE_DEVICES=0
export HSA_ENABLE_SDMA=0
export HSA_OVERRIDE_GFX_VERSION=11.0.0     # gfx1100 必設
export LLAMA_ARG_STOP="<think>,</think>"

llama-server \
  --model Qwen3.6-27B-MTP-Q4_K_M.gguf \
  --device ROCm0 \
  --spec-type draft-mtp \                  # 純 MTP，不要疊 ngram
  --spec-draft-n-max 3 \                   # RDNA3 甜點，別用 4
  -b 512 -ub 512 \
  --ctx-size 131072 \                      # 128K；hybrid SSM 長 context 不掉速，OOM 就降 96K
  --flash-attn on \
  --n-gpu-layers 99 \
  --cache-type-k q4_0 --cache-type-v q4_0 \ # 省 VRAM，上 64K 的關鍵
  --reasoning off \                         # 關 thinking！必須用 reasoning off，不是 budget 0（見坑 #6）
  --prefix-cache-slots 4 \                  # 快取系統提示，省 prefill
  --host 0.0.0.0 --port 8080 --parallel 1 --jinja

實測：Hermes 工具調用 47–51 tok/s、純對話 ~41 tok/s、長分析 ~37 tok/s，工具調用正常，達成 ≥45 目標。

8. 給想複製的人

只想能用、省事：照第 6 節，純 MTP n=3，就到 40–50 tok/s 了。別碰 DFlash、別疊 ngram、別亂抄 CUDA flag。
想衝更高：你已經到單卡 7900 XTX + 27B 的物理天花板附近（~50–60）。唯一沒測過、可能真正往上的路是 vLLM tensor-parallel 雙卡（真並行、理論 ~120–150；注意 llama.cpp 雙卡反而更慢，見第 5 節）。
DFlash 想玩可以，但請認清它的舞台是短 context / 程式碼，不是長系統提示的即時 agent。

硬體：RX 7900 XTX 24GB ×1｜ROCm 7.2.0｜Qwen3.6-27B Q4_K_M｜2026-06

9.附上128k長任務生產力成功達成,附圖

CHIA AN YANG

看目前這社區越來越多人買7900XTX了，大家為了一個爽度token無限連發與反應速度，這幾天折騰的過程分享給大家，我主要場景是hermes agent,透過telgram發任務請求

7900 XTX × 2 跑 Qwen3.6 27B 本地 LLM 測試報告

硬體：Z10PE-D16-WS 工作站主機板 × 雙 Xeon E5-2678v3（24C/48T）× 128GB DDR4 ECC × 雙 RX 7900 XTX 24GB
系統：Ubuntu + ROCm / Vulkan（AMD GPU 的 Linux 推理框架）
模型：Qwopus3.6-27B-v2-MTP（Unsloth 發布，基於 Qwen3.6 27B，內建 MTP 輔助頭）
量化：IQ4_XS（4.25 bpw）
時間：2026-06

名詞解釋（新手看這裡）

量化（Quantization）：把模型權重壓縮存放，犧牲一點點精度換取更小的檔案和更快速度。

fp16：16-bit 浮點數，每個值 2 bytes，沒有壓縮，是 GPU 的「原始精度」。27B 模型 fp16 約需 54 GB VRAM，一般玩家裝不下。

Q4_K_M：每個值平均 4.5 bpw（bits per weight），是最普遍的量化格式，品質好、速度穩定。

IQ4_XS：每個值 4.25 bpw，比 Q4_K_M 稍微更壓縮，在 RDNA3 架構（7900 XTX）上因為 VRAM 佔用更少，實際跑起來反而更快。

turbo4：beellama fork 獨有的 KV cache 量化，3.5 bpw，比 q4_0（4 bpw）更省 VRAM，用在 KV cache（不是模型本身）。

KV cache：模型在處理長對話時，會把「記憶」存在 VRAM 裡，稱為 KV cache。對話越長，佔用越多 VRAM。量化 KV cache 可以在不降低多少品質的前提下省 VRAM。

MTP（Multi-Token Prediction）：一種加速推理的技術。模型一次預測多個「草稿 token」，再批次驗證，如果草稿正確就直接採用，不正確就丟掉重算。接受率越高速度越快，若接受率 0% 反而比不開更慢（多餘計算）。

t/s（tokens per second）：每秒輸出多少個 token。中文大約 1 個 token = 1 個字，英文 1 個 token ≈ 0.75 個單字。一般對話感覺順暢約需 20+ t/s。

背景與問題

之前在 Win11 + Vulkan 跑 Qwen3.6 27B 可以穩定 60-80 t/s，換到 Ubuntu + ROCm 後掉到 28-33 t/s，本篇記錄怎麼找回速度。

測試過程

階段一：找出 ROCm 慢的原因

配置	速度	備註
goodbyecain b9256 + Q4_K_M + q4_0 KV	22-27 t/s	舊主力，最慢
goodbyecain b9256 + IQ4_XS + q4_0 KV	30-33 t/s	換小量化有幫助
Vulkan build + IQ4_XS（無 MTP）	31-33 t/s	Vulkan base 跟 ROCm 差不多

發現：Vulkan base 速度跟 ROCm 幾乎一樣。Win11 快那麼多，關鍵不在 Vulkan vs ROCm，而是 MTP 能否有效運作。

階段二：MTP 在 Linux 上的問題

原始結論（goodbyecain b9256，AMD 7900 XTX）：Vulkan MTP 接受率約 0.7%，幾乎無效。

更新（2026-06-22，upstream b9377）：實測後確認 issue #22842 已在新版修復。同樣硬體（AMD 7900 XTX），升級到 upstream b9377 之後：

配置	MTP 接受率	速度
goodbyecain b9256 + Vulkan	~0.7%	31-33 t/s
upstream b9377 + Vulkan（實測）	53.5%	49.8 t/s
goodbyecain b9256 + ROCm	54-77%	39-42 t/s

結論更新：舊版 Vulkan MTP 確實有 bug，新版已修。AMD 7900 XTX 上新版 Vulkan MTP 接受率（53.5%）與 ROCm 相近，速度更快（49.8 vs 39-42 t/s）。如果你在 AMD GPU 上跑 Vulkan，建議升級到 upstream b9377 以上。

階段三：beellama + TurboQuant（turbo4 KV cache）

beellama（v0.3.2）是 llama.cpp 的非官方 fork，加入了 TurboQuant（ICLR 2026 論文），一種更激進的 KV cache 量化方式，稱為 turbo4（3.5 bpw，比標準 q4_0 的 4 bpw 更壓縮）。

更省 VRAM → KV cache 更小 → MTP draft 驗證更快 → 接受率更高

配置	速度	MTP 接受率
beellama + IQ4_XS + turbo4 KV + n=4 草稿	38-40 t/s	~38%（n4 太多，浪費）
beellama + IQ4_XS + turbo4 KV + n=3 草稿	39-42 t/s	54-77%

n=4 表示一次預測 4 個草稿 token，但這個模型在 n=4 時常常只接受 0 或 1 個，白費算力；n=3 接受率更穩定。

階段四：Context 大小與速度曲線

Vulkan b9377（q4_0 KV，65K ctx，2026-06-22 實測）：

Context 大小	速度	備註
1K–5K tokens	72–75 t/s	KV cache 小，attention 快
5K–17K tokens	70–72 t/s	輕微下降
27K tokens	40.7 t/s	明顯減速
48K tokens	34.7 t/s	趨於穩定
59K tokens	35.7 t/s	大 context 底限

Vulkan b9377 在短 context 下速度驚人，但隨 context 成長速度明顯衰減。在 48K+ 時（35 t/s），ROCm beellama + turbo4（39-42 t/s）反而更快，因為 turbo4 KV cache 更小（3.5 bpw vs 4 bpw），attention bandwidth 占用更少。

階段五：KV cache 精度（q4_0 vs q8_0）對 MTP 的影響

這個發現比較意外：KV cache 精度直接影響 MTP 接受率。

原因：MTP 的 draft head 在驗證草稿 token 時，需要讀取已有 token 的 KV cache 做 attention。KV cache 精度越低，attention 結果的誤差越大，導致 draft 驗證時機率分佈偏移，更多草稿被拒絕。

KV cache 格式	VRAM（65K ctx）	MTP 接受率	速度
q4_0（4 bpw）	73%（~18GB）	38-51%	35-42 t/s
q8_0（8 bpw）	75%（~18.4GB）	52-57%	44-51 t/s

只多用 2% VRAM（約 400MB），速度提升 25%。 這是這次測試中 CP 值最高的發現。

128K context 也測了：

配置	VRAM	速度
128K + q4_0	76%	~40 t/s（短 ctx）
128K + q8_0	84%（~20.6GB）	47-52 t/s

兩種 128K 配置都能裝進 24GB 的 7900 XTX，之前 ROCm beellama 128K 溢出是 ROCm 的記憶體管理問題，Vulkan 不同。

階段六：AMD GPU 時脈陷阱

症狀：同樣配置，server 第一次啟動時速度明顯比後來重啟的慢。

根本原因：AMD GPU 在 auto 效能模式下，閒置時 shader clock（sclk）會降到 25-87 MHz（正常推理需要 2371 MHz）。新啟動的 server 若沒有立即收到請求，GPU 時脈爬升不及，前幾個 query 在極低頻率下跑。

驗證：在推理進行時監控 sclk：

閒置：25 MHz
推理中：2080 → 2369 → 2400 MHz（正常）
推理結束：立刻掉回 94 MHz

解法：手動鎖定 sclk 和 mclk 到最高頻：

# 需要 sudo
rocm-smi --device 0 --setperflevel manual
echo "2" > /sys/class/drm/card0/device/pp_dpm_sclk  # 鎖 sclk → 2371 MHz
echo "3" > /sys/class/drm/card0/device/pp_dpm_mclk  # 鎖 mclk → 1249 MHz

注意：card0 編號因系統而異，用 ls /sys/class/drm/card*/device/pp_dpm_sclk 查詢。

階段七：server 層 sampling 參數會殺死 MTP

症狀：在 llama-server 啟動時加了 --presence-penalty 1.5 --top-k 20，MTP 接受率從 54% 掉到 41%，速度從 52 t/s 掉到 37 t/s。

原因：MTP 的 draft head 預測的是「原始機率分佈」，不知道有 sampling 限制。當 server 強制 top-k 20 時，很多 draft head 認為高機率的 token 其實在 top-20 之外，被過濾掉，導致接受率下降。

解法：server 層不設 sampling 參數，讓 client 每次 request 自帶。這樣 MTP 在驗證時用的是完整分佈，接受率恢復正常。

最終最佳配置（2026-06-22 更新）

使用軟體：upstream llama.cpp（b9377 以上，標準 Vulkan build）
模型：Qwopus3.6-27B-v2-MTP IQ4_XS（Unsloth HuggingFace）

#!/bin/bash
# 先鎖 GPU 時脈（需 sudo）
sudo rocm-smi --device 0 --setperflevel manual
sudo bash -c "echo '2' > /sys/class/drm/card2/device/pp_dpm_sclk"
sudo bash -c "echo '3' > /sys/class/drm/card2/device/pp_dpm_mclk"

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json

SERVER=/path/to/llama.cpp/build-vulkan/bin/llama-server
MODEL=/path/to/Qwopus3.6-27B-v2-MTP-IQ4_XS.gguf

"$SERVER" \
  --host 0.0.0.0 --port 8080 \
  --device Vulkan0 \            # 指定 GPU0
  -m "$MODEL" \
  --alias "unsloth/Qwen3.6-27B-GGUF" \
  --spec-type draft-mtp \       # 開啟 MTP 推測解碼
  --spec-draft-n-max 3 \        # 一次預測 3 個草稿 token
  -ngl 99 \                     # 全部層放 GPU
  --ctx-size 65536 \            # 65K context
  -n 8192 \
  -b 2048 -ub 512 -np 1 \
  --cache-type-k q8_0 \         # q8_0 KV cache（比 q4_0 接受率高 10-15%）
  --cache-type-v q8_0 \
  --no-mmap --mlock \
  --flash-attn on \
  --jinja --no-warmup --reasoning off
  # 注意：不在 server 層設 sampling 參數（top-k/presence-penalty 會降低 MTP 接受率）

速度總結

配置	速度	vs 舊主力
goodbyecain + Q4_K_M + q4_0（舊主力）	22-27 t/s	基準
goodbyecain + IQ4_XS + q4_0	30-33 t/s	+25%
Vulkan 無 MTP（b9256）	31-33 t/s	+25%
beellama + IQ4_XS + turbo4 + n3 MTP（ROCm）	39-42 t/s	+60%
Vulkan b9377 + IQ4_XS + q4_0 + n3 MTP	35-42 t/s	+50%
Vulkan b9377 + IQ4_XS + q8_0 + n3 MTP（現役）	44-51 t/s	+90%

關鍵結論

Vulkan MTP bug 已在 b9377 修復（issue #22842）：舊版 b9256 接受率 0.7%，新版 53%+
q8_0 KV cache 比 q4_0 快 25%：只多用 2% VRAM，MTP 接受率從 42% 升到 54%，CP 值最高的優化
server 層 sampling 參數會殺 MTP：--presence-penalty、--top-k 等讓 draft 被過濾，接受率掉 10-15%；改由 client 每次帶
AMD GPU 時脈陷阱：auto 模式閒置時 sclk 掉到 25-87 MHz，啟動 server 前要先鎖時脈
n=3 草稿比 n=4 好：接受率更穩定，不浪費算力
65K 是 Vulkan 的甜蜜點，128K q8_0 也能裝（84% VRAM），但速度差不多
IQ4_XS 比 Q4_K_M 快：VRAM footprint 更小，MTP 批次更有效率

已知限制

結構化輸出（JSON schema）時 MTP 失效：grammar constraint 會讓 MTP 接受率歸零，速度掉回 ~21 t/s。這是 llama.cpp 的已知問題。
Win11 的 60-80 t/s 差距：現在 Linux Vulkan 已可到 44-51 t/s，差距縮小。Windows 快的部分原因可能是 grammar 限制較少，還在研究中。

Hermes Agent 接 Gemini Pro 訂閱 OAuth：不是 MCP，是本機 OpenAI-compatible Proxy

這篇記錄我這次把 Gemini Pro 訂閱帳號接進 Hermes Agent 的做法。

先講結論：這條路線不是用 Hermes 的 MCP，也不是只讓 Hermes 去呼叫 agy CLI。實際跑通的是：

Google OAuth / Antigravity
        ↓
CLIProxyAPI 本機代理
        ↓
http://127.0.0.1:8317/v1  OpenAI-compatible API
        ↓
Hermes custom provider

也就是把 Gemini/Antigravity 的 OAuth 能力包成一個本機 /v1 API，Hermes 再把它當成 OpenAI-compatible provider 使用。

成功後的狀態

本機跑起來後會有兩個重要服務：

127.0.0.1:8317  CLIProxyAPI，負責 Gemini OAuth proxy
127.0.0.1:8080  原本本機 Qwen / llama-server

Hermes 裡面則可以同時保留兩個 provider：

custom_providers:
  - name: gemini-proxy
    base_url: http://127.0.0.1:8317/v1
    key_env: CLIPROXY_API_KEY
    api_mode: chat_completions
    models:
      gemini-pro-agent:
        context_length: 1048576
      gemini-3.1-pro-low:
        context_length: 1048576
      gemini-3-flash-agent:
        context_length: 1048576
      gemini-3-flash:
        context_length: 1048576
      gemini-3.5-flash-low:
        context_length: 1048576
      gemini-3.5-flash-extra-low:
        context_length: 1048576

  - name: qwen-local
    base_url: http://127.0.0.1:8080/v1
    api_mode: chat_completions
    models:
      Qwopus3.6-27B-v2-MTP-Q4_K_M.gguf:
        context_length: 131072

目前我自己的 Hermes 主模型可以這樣設：

model:
  provider: custom:gemini-proxy
  default: gemini-3.5-flash-extra-low
  context_length: 1048576

如果要改回 Gemini Pro agent，也可以改成：

model:
  provider: custom:gemini-proxy
  default: gemini-pro-agent
  context_length: 1048576

安裝 CLIProxyAPI

我把它放在 Hermes 目錄底下：

mkdir -p ~/.hermes/cli-proxy/bin
cd ~/.hermes/cli-proxy

下載 CLIProxyAPI Linux amd64 release，例如我這次用的是：

CLIProxyAPI_7.2.58_linux_amd64.tar.gz

解開後會有：

~/.hermes/cli-proxy/bin/cli-proxy-api
~/.hermes/cli-proxy/bin/config.example.yaml

確認 binary 可以執行：

chmod +x ~/.hermes/cli-proxy/bin/cli-proxy-api
~/.hermes/cli-proxy/bin/cli-proxy-api --help

建立 proxy config

我用的設定大概是這樣，API key 請自己產生，不要貼真值：

host: 127.0.0.1
port: 8317
api_keys:
  - "replace-with-your-local-random-key"
auth_dir: /home/YOUR_USER/.hermes/cli-proxy/auth
log_dir: /home/YOUR_USER/.hermes/cli-proxy/logs
static_dir: /home/YOUR_USER/.hermes/cli-proxy/static

我另外把 key 放進 Hermes 的 .env：

CLIPROXY_API_KEY=replace-with-your-local-random-key

這樣 Hermes config 裡就可以用：

key_env: CLIPROXY_API_KEY

不要把 proxy API key 寫進分享文、git repo 或截圖。

Google OAuth

這一步是關鍵。

CLIProxyAPI 啟動後，照它提供的 login/OAuth flow 讓瀏覽器完成 Google 授權。授權成功後，auth_dir 裡會出現類似：

~/.hermes/cli-proxy/auth/antigravity-<your-google-account>.json

這個檔案是 OAuth 憑證，權限建議至少設成：

chmod 600 ~/.hermes/cli-proxy/auth/*.json

我這台是透過遠端機器操作，所以 OAuth 頁面需要用 SSH tunnel 或可以開瀏覽器的方式完成。這也是很多人會卡住的地方：不是 Hermes 不能接，而是 OAuth callback 沒有正確回到本機 proxy。

用 PM2 常駐 CLIProxyAPI

我的 pm2 不在系統 PATH 裡，所以用完整路徑：

~/.hermes/node/bin/pm2 start ~/.hermes/cli-proxy/bin/cli-proxy-api \
  --name cli-proxy-api \
  -- -config ~/.hermes/cli-proxy/config.yaml

~/.hermes/node/bin/pm2 save

確認它有活著：

~/.hermes/node/bin/pm2 status
ss -ltnp | grep 8317

應該看到：

cli-proxy-api  online
127.0.0.1:8317 LISTEN

測試 proxy

先測 /v1/models：

curl -s http://127.0.0.1:8317/v1/models \
  -H "Authorization: Bearer $CLIPROXY_API_KEY"

我這邊能看到的模型包含：

gemini-pro-agent
gemini-3.1-pro-low
gemini-3-flash-agent
gemini-3-flash
gemini-3.5-flash-low
gemini-3.5-flash-extra-low

再測 chat completions：

curl -s http://127.0.0.1:8317/v1/chat/completions \
  -H "Authorization: Bearer $CLIPROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-pro-agent",
    "messages": [
      {"role": "user", "content": "Reply with exactly: Gemini proxy confirmed"}
    ]
  }'

能正常回覆後，再接 Hermes。

Hermes 設定 custom provider

在 Hermes 的 config.yaml 加上：

custom_providers:
  - name: gemini-proxy
    base_url: http://127.0.0.1:8317/v1
    key_env: CLIPROXY_API_KEY
    api_mode: chat_completions
    models:
      gemini-pro-agent:
        context_length: 1048576
      gemini-3.1-pro-low:
        context_length: 1048576
      gemini-3-flash-agent:
        context_length: 1048576
      gemini-3-flash:
        context_length: 1048576
      gemini-3.5-flash-low:
        context_length: 1048576
      gemini-3.5-flash-extra-low:
        context_length: 1048576

主模型可以設：

model:
  provider: custom:gemini-proxy
  default: gemini-pro-agent
  context_length: 1048576

或改成比較省的：

model:
  provider: custom:gemini-proxy
  default: gemini-3.5-flash-extra-low
  context_length: 1048576

改完後重啟 Hermes gateway：

systemctl --user restart hermes-gateway
systemctl --user is-active hermes-gateway

Hermes 裡切換模型

在 Telegram / Hermes bot 裡可以用：

/model custom:gemini-proxy:gemini-pro-agent --global
/model custom:gemini-proxy:gemini-3.1-pro-low --global
/model custom:gemini-proxy:gemini-3.5-flash-low --global
/model custom:gemini-proxy:gemini-3.5-flash-extra-low --global

切完建議開新 session：

/new

--global 是改預設新 session。只想改目前 session，可以用 --session。

接回原本 8080 Qwen

原本本機 Qwen 也可以保留成另一個 provider：

custom_providers:
  - name: qwen-local
    base_url: http://127.0.0.1:8080/v1
    api_mode: chat_completions
    models:
      Qwopus3.6-27B-v2-MTP-Q4_K_M.gguf:
        context_length: 131072

要切回 Qwen：

/model custom:qwen-local:Qwopus3.6-27B-v2-MTP-Q4_K_M.gguf --global
/new

前提是你的 llama-server / OpenAI-compatible Qwen server 已經在 8080 跑著。

確認：

ss -ltnp | grep 8080

我這次踩到的坑

1. 一開始容易誤會成 MCP

Hermes 本來就可以用 MCP 去調外部工具，agy CLI 也可以透過 MCP/CLI 被呼叫。

但這次要的是「把 Gemini Pro 訂閱 OAuth 當成 Hermes 的模型 provider」，不是「讓 Hermes 呼叫一個工具」。所以正確方向是 OpenAI-compatible local proxy。

簡單判斷：

MCP / CLI tool：模型還是 Hermes 原本的模型，只是多一個工具可以叫
OpenAI-compatible proxy：Gemini 變成 Hermes 的模型本體

2. `agy` 能跑，不代表 Hermes 直接吃得到 OAuth

agy 自己有 Google OAuth，但 Hermes 不會自動讀 agy 的登入狀態。中間需要一層 proxy，把 OAuth 模型包成 /v1/chat/completions。

這就是 CLIProxyAPI 的角色。

3. `pm2` 可能不在 PATH

我這台不能直接跑：

pm2 status

要用：

~/.hermes/node/bin/pm2 status

文章或 runbook 建議都寫完整路徑，少一個環境差異。

4. OAuth callback 在遠端機器上會卡

如果是在 SSH server、遠端桌面、無頭環境上跑，Google OAuth 頁面開在你本機瀏覽器，但 callback 要回到遠端機器上的 proxy。

解法通常是：

用 SSH tunnel 把 callback port 轉回遠端
或在遠端機器上直接完成瀏覽器授權

授權成功的判斷不是「網頁看起來過了」，而是 auth_dir 裡真的出現 OAuth JSON。

5. Hermes provider 名稱要寫完整

切模型時不是只打模型名，而是：

custom:<provider-name>:<model-name>

例如：

/model custom:gemini-proxy:gemini-pro-agent --global

少了 custom:gemini-proxy: 這段，Hermes 可能會找不到正確 provider。

6. 不要把 key 和 OAuth JSON 放進文章

至少這幾個東西不能貼：

CLIPROXY_API_KEY 真值
~/.hermes/cli-proxy/api_key
~/.hermes/cli-proxy/auth/*.json
任何 Google OAuth token

分享時用 placeholder 就好。

最後驗證

我這次最後驗證了三件事：

1. CLIProxyAPI 在 127.0.0.1:8317 online
2. /v1/models 能列出 Gemini models
3. Hermes 可以用 custom:gemini-proxy 跑 Gemini，也可以切回 custom:qwen-local 的 8080 Qwen

這樣 Hermes 就不是只能 MCP/CLI 調用 Gemini，而是可以把 Gemini Pro OAuth proxy 當成真正的模型 provider 使用。

CHIA AN YANG

突然想到之前滑過影片有看到可以用,gemini pro訂閱使用新的gemini cli,讓hermes爬文後一下子就裝好了,多一個額度可以用了,不知道是不是我最後一個知道,反正先分享~
重點有多款模型可以使用喔!

以下是 agy CLI 中可供選擇的完整模型清單以及相關說明：

可選擇的模型種類與切換方式

在 agy CLI 中，你可以在 Pro 訂閱額度下，依據不同任務需求切換以下所有支援的模型：

1. Gemini 系列（原廠首選，與 Pro 訂閱完美相容）

• Gemini 3.5 Flash (Medium) (預設)
• 特點：平衡性最佳，速度與生成品質兼顧。最推薦日常的程式修改、快速 Debug 與小型 Script 撰寫。
• Gemini 3.5 Flash (High)
• 特點：高精度 Flash 版本，針對代碼語意有更細緻的理解，適合中等難度的 Bug 排查。
• Gemini 3.5 Flash (Low)
• 特點：極速版本，回應時間最短，適合格式化調整、程式碼排版或非常簡單的生成。
• Gemini 3.1 Pro (High)
• 特點：具備極強的邏輯推導能力，適合跨檔案的大規模重構、演算法設計與極具挑戰性的 Bug 除錯。
• Gemini 3.1 Pro (Low)
• 特點：Pro 的基礎推理版本，速度介於 Flash 與 Pro High 之間，提供穩定的大模型推理骨幹。

2. Claude 4.6 系列（引入思考鏈的推理利器）

• Claude Sonnet 4.6 (Thinking)
• 特點：基於 Anthropic 旗艦模型，並開啟了思考鏈 (Thinking) 機制，極其擅長長上下文的邏輯編碼與架構重構。
• Claude Opus 4.6 (Thinking)
• 特點：最強的 Claude 思考大模型，專門應對極端複雜的邏輯推理與架構設計。

3. 開源模型支援

• GPT-OSS 120B (Medium)
• 特點：開源的 120B 大參數模型，提供不同的代碼風格與生成思維，適合作為備用參考。

│ [!NOTE]
│ 雖然 agy 同步支援 Claude 與 GPT-OSS 模型，但為了確保完全使用你每月 20 美元 (Google One AI Premium) 的訂閱額度，強烈建議優先選用
│ Gemini 3.5/3.1 家族模型，以獲得最穩定的配額保障與流暢的開發體驗。

終極省錢秘笈：如何用 Gemini Advanced (Pro) $20/月訂閱，暢玩 Gemini Antigravity `agy` CLI 介面！

[!NOTE]

文件建立時間：台灣時間 (CST) 2026-07-06

適用對象：已訂閱 Gemini Advanced (Google One AI Premium) 的開發者，或正在評估是否切換為包月制 AI 開發工具的使用者。

許多人在使用 AI 終端機開發工具（如 Claude Code 或各類 Agent CLI）時，常常會遇到一個痛點：使用付費 API Key (Pay-as-you-go) 太燒錢了！
尤其在大型專案中，每次詢問都需要讀取數萬行的程式碼上下文，一來一回，單日 Token 費用可能就高達數美元甚至數十美元。

但你可能不知道，Google Antigravity CLI (agy) 其實支援直接綁定你的 Gemini Pro / Advanced 訂閱！
這意味著，你只需要支付與 ChatGPT Plus、Claude Pro 或 Claude Code 同等的 每月 20 美元 (約台幣 $650 元) 訂閱方案，就能在終端機內享受無痛、不額外收費的 Agentic Coding 體驗。

計費方案大比拼：API Key vs Pro 包月訂閱

比較項目	API Key 付費 (Pay-as-you-go)	Gemini Advanced (Pro 訂閱)
計費方式	依 Input/Output Token 用量計費	每月固定 $20 美元 (台幣約 650 元)
額度與心理壓力	用越多越貴，高頻開發時會產生「Token 焦慮」	包月制，享有個人日常開發的高 Rate Limit，無額外帳單壓力
適用場景	低頻率、間歇性的小工具呼叫	高強度 Pair Programming、大規模重構、跨多檔案 Codebase 分析
額外福利	無額外權益	同步享有 Google One 2TB 空間、Google Workspace 內 Gemini 助理、Web 版 Gemini Advanced

️ 快速上手：3 步驟用 Pro 訂閱帳戶啟用 `agy` CLI

使用你的 $20 訂閱方案來啟動 agy 非常簡單，只需要依照以下步驟進行：

步驟 1：確認訂閱狀態

確保你目前登入的 Google 個人帳戶已經訂閱了 Gemini Advanced (或屬於 Google One AI Premium 方案的訂閱者)。

步驟 2：執行 `agy` CLI

在你的終端機中，直接輸入以下指令啟動：

agy

[!TIP]
如果你是第一次在該電腦或環境下執行，系統會偵測到未驗證狀態，並主動引導你進行 Google 帳戶授權。

步驟 3：網頁瀏覽器授權 (Oauth 驗證)

終端機會顯示類似以下的提示：

Please visit the following URL to authorize:
https://accounts.google.com/o/oauth2/auth?...
Enter verification code: [ ▍ ]

複製終端機中顯示的 URL，並在登入有 Gemini Advanced 訂閱帳戶的瀏覽器中打開。
點擊「允許授權」以提供 agy CLI 使用該帳號呼叫模型的權限。
將網頁上顯示的驗證碼（Verification Code）複製，貼回終端機並按下 Enter。

大功告成！ 現在你的 agy CLI 已經跟你的 $20 Pro 訂閱方案完美對接，可以開始暢快地進行 AI pair programming 了！

常見問題與實用小技巧 (FAQ)

Q1：使用 Pro 訂閱會限制我的 Token 或是次數嗎？

會，但通常非常寬裕。
與 Web 版的 Gemini Advanced 類似，agy CLI 在 Pro 訂閱下擁有相當高額的速率限制 (Rate Limits)。除非你進行 24 小時不間斷的極限並行壓力測試，否則對於正常的人機協作開發，其額度絕對綽綽有餘，體驗與 ChatGPT Plus / Claude Code 完全一致。

Q2：我可以自訂 CLI 的設定嗎？

可以，agy CLI 的所有偏好設定、預設模型等，都儲存在本機的設定檔中：

設定檔路徑：~/.gemini/antigravity-cli/settings.json
你可以透過編輯此 JSON 檔案來調整 UI 外觀、提示詞偏好或 MCP (Model Context Protocol) 伺服器的設定。

Q3：如果在終端機卡住或想結束，該怎麼做？

結束對話並退出：輸入 /exit 或 /quit，或者在空白輸入列連按兩次 Ctrl + D。
推薦的 Slash 命令：
- /help：列出所有可用的 Slash 命令。
- /schedule：設定定時任務或背景監控。
- /goal：適合用於 overnight 的超長執行複雜任務。

[!IMPORTANT]
結論：不要再傻傻地為了跑 CLI Agent 去儲值昂貴 of API Key 了！
只要善用你手邊的 Gemini Advanced $20 包月訂閱，就能無縫享有 Google 最頂尖的 Antigravity AI 編碼助手。趕快打開終端機，輸入 agy 開始體驗吧！

CHIA AN YANG

本文新增接gemini pro訂閱額度給herems調用的簡單教學,這樣一來有codex,gemini 輪流調用

CHIA AN YANG

推推!!有這裡這好~~!

CHIA AN YANG

謝謝拉,但技術還有待加強,一起折騰起來吧哈,入手了7900XTX 第二張但雙卡沒有變快...超哭

CHIA AN YANG

@貝大頭總感覺你用雲端API比較省事,把基礎建設打好,再考慮本地部屬

CHIA AN YANG

@怪物如果兩張pro6000可以跑deepseek v4 flash 體驗應該是很不錯的,另外你把模型改用 qwen3.6 27b看看你會開心很多,我目前7900xtx 24g,單卡就玩的飛起了,讓cc or codex幫你把hermes你平常的工作流跑通寫成skill給hermes會好用很多的!!供你參考

CHIA AN YANG

個人直覺建議,有預算直接多一張rtx pro 6000 96g 我也是台灣小白哈,台灣硬件真的貴得離譜..

CHIA AN YANG

@艷陽天台灣人+1 舉手

CHIA AN YANG

@sospda 想請教如果tg調用hermes實際的token速度

CHIA AN YANG

我之前有發文分享win11+vulken可以到4-50,可以爬一下

CHIA AN YANG

恭喜入坑~7900XTX家族

CHIA AN YANG

基本上你上完ubuntu後就不會再去看你的電腦畫面了,之後全程hermes代勞了,所以應該不用太擔心不習慣的問題,我也是過來人!!一開始win11轉ubuntu挺擔心不會用的,後來發現根本用不太到~頂多開檔案總管看comfyi出的圖,最後也把google driver接上同步,就再也沒去電腦前了,偶爾rustdesk遠端連過去

抡锤者

小天子

帖子