認真的有夠燒,plus改一段代碼,就5h額度燒沒了,但事情是真的搞定,還外加很多額外

不錯有成功拿到,免費的加減嚕,分享就給讚

果然是王者!頂上去

在單張 RX 7900 XTX（gfx1100 / 24GB）上編 SGLang 跑 Qwen3.8-27B —— 完整實作與踩坑全紀錄

目標讀者：手上有一張 7900 XTX、看到「SGLang 雙卡爽跑 Qwen3.8-27B」那篇文章、想自己抄一份的人。
這篇把「從讀大神 flyer666 雙卡7900xtx sglang文章 → 從原始碼編 → 單卡跑起來 → 為什麼還是不划算」整段寫清楚，8 個坑逐一標出來，你照走就不用再踩。
環境、指令、錯誤訊息全部照實貼，方便對照。

---

TL;DR（先講結論，省得你白花一個晚上）

你想做的	現實
單卡複製那篇的 88～116 t/s	做不到。那些數字是雙卡 48GB + MTP-3。單張 24GB 塞不下「GPTQ 本體 18GB ＋ 獨立的 GPTQ MTP draft 5.5GB ＋ KV cache」
單卡「關掉 MTP」跑	跑得動，decode ~35 t/s，跟 llama.cpp 不開投機解碼同一個檔次
單卡用 --cpu-offload-gb 硬塞 MTP	能載入、MTP 有啟動，但每個 forward 要從記憶體串 8GB 權重過 PCIe，GPU 使用率 2%，實測 <4 t/s，等於不能用
對照組：llama.cpp（Vulkan）+ GGUF + 它自帶的 MTP	程式碼 73 / 散文 33 / 平均 50 t/s，塞得進 24GB，systemctl restart 15 秒回來

一句話：單張 7900 XTX 就乖乖用 llama.cpp-HIP / llama.cpp-Vulkan。 SGLang 這個 fork 的價值在雙卡 tensor-parallel + MTP-3，單卡拿不到，還要多顧一堆版本相依。要複製那篇，先買第二張 7900 XTX。

這篇的價值：如果你之後真的有兩張卡，下面「怎麼編 / 踩過哪些坑」照樣有用（fork 的 build 部分兩張卡也一樣要做）。

---

這篇對照的原文

• 文章：https://lcz.me/topic/1532（SGLang 雙 7900 XTX，移植 vLLM kernel + EAGLE MTP-3）
• 對應 repo：https://github.com/StevenChenSE/sglang 的 gfx1100-support 分支
• 原文宣稱（全部是 TP=2 雙卡）：
  • 單併發 decode 97～116 t/s、prefill ~562、TTFT ~0.16s
  • 120k token agent 場景：平均 decode 87.9、最低 66.7（vs vLLM 最低只有 16.9）
  • 4 併發總吞吐 147.5 t/s

---

我的環境（照你自己的對）

GPU        : AMD Radeon RX 7900 XTX (Navi 31, gfx1100, 24GB) ×1
OS         : Ubuntu 24.04.4 LTS, kernel 7.0.0-28-generic
ROCm       : 7.2.0  (HIP 7.2.26015, amdclang 22.0.0git)   ← 注意 repo README 寫的是 7.14
Python     : 3.12.3
主記憶體    : 128GB（cpu-offload 會用到）

️ 本機同時裝了 NVIDIA CUDA toolkit（nvidia-cuda-dev / libthrust-dev / libcu++-dev），因為另一張卡在跑別的東西。坑 1 就是它引起的。如果你的機器很乾淨、沒裝過任何 CUDA/thrust 開發套件，坑 1 可能不會遇到。

---

全部要改的檔案一覽（先看這張，心裡有底）

#	檔案	改什麼	什麼時候需要
P1	python/sglang/kernels/aot/setup_rocm.py	加 -isystem /opt/rocm-7.2.0/include	機器裝過 CUDA/thrust 開發套件時
P2	setup_rocm.py + csrc/common_extension_rocm.cc	拿掉 moe_q_gemm_rdna3.cu、用巨集擋它的註冊	一定（fork 這檔有 bug，且 dense 模型用不到）
P3	模型的 config.json	+:.*mtp.* → -:.*mtp.* bits 16	一定（README 也有寫）
P4	python/sglang/srt/layers/layernorm.py	gemma weight loader 加 device 對齊	只有你要用 --cpu-offload-gb
P5	python/sglang/srt/utils/offloader.py	2 處 functional_call(..., tie_weights=False)	只有你要用 --cpu-offload-gb

---

Step 0：clone

cd ~/src
git clone --branch gfx1100-support --single-branch --depth 1 \
  https://github.com/StevenChenSE/sglang.git sglang-gfx1100

---

Step 1：建 venv、裝 PyTorch（ROCm 版）

# 用 uv 比較快，pip 也行
uv venv --python 3.12 ~/venvs/sglang-rocm
source ~/venvs/sglang-rocm/bin/activate

uv pip install "torch==2.11.0+rocm7.2" "pytorch-triton-rocm" \
  --index-url https://download.pytorch.org/whl/rocm7.2 \
  --index-strategy unsafe-best-match

torch-2.12.0+rocm7.2 也在同一個索引、也可用。README 寫「PyTorch 2.11.0+git」，抓 2.11.0+rocm7.2 最貼。

驗證（每次動完 pip 都要跑一下這個）：

python -c "import torch; print(torch.__version__, torch.version.hip, torch.cuda.is_available(), torch.cuda.get_device_properties(0).gcnArchName)"
# 期望： 2.11.0+rocm7.2 7.2.26015 True gfx1100

坑 1（PyTorch 被 CUDA 版覆蓋）

症狀：後面你裝別的套件（尤其 torchvision / torchaudio / 任何沒 pin 的東西），pip/uv 的相依求解會默默把 torch 換成 torch-2.14.0+cu130（CUDA 版）。之後 torch.version.hip 變 None、torch.cuda.get_device_properties(0).name 印出你的 NVIDIA 卡。編好的 .so 是對著 ROCm torch 連結的，torch 一換就全爛。

防呆：

1. torch / torchvision / torchaudio 一律從 .../whl/rocm7.2 這個索引裝、而且 pin 版本：

   uv pip install "torch==2.11.0+rocm7.2" "torchvision==0.26.0+rocm7.2" "pytorch-triton-rocm" \
     --index-url https://download.pytorch.org/whl/rocm7.2 --index-strategy unsafe-best-match
   

2. 之後每做完一批 pip 安裝，就跑一次上面那個 import torch 驗證。被換掉就照上面重裝一次（uv 會把 CUDA 版移除）。

---

Step 2：編 AOT HIP kernel（sgl_kernel）—— 成敗關鍵

source ~/venvs/sglang-rocm/bin/activate
uv pip install numpy setuptools wheel ninja "scikit-build-core>=0.10" packaging

cd ~/src/sglang-gfx1100/python/sglang/kernels/aot

坑 2（rocThrust 被系統的 CUDA thrust 蓋掉）

症狀：一開編就爆 300+ 個錯，長這樣：

/usr/include/vector_types.h:184:30: error: definition of type 'int2' conflicts with type alias of the same name
  184 | __cuda_builtin_vector_align8(int2, int x; int y;);
/opt/rocm-7.2.0/.../amd_hip_vector_types.h:811:1: note: 'int2' declared here

往回追 include 鏈會看到：

torch/headeronly/util/complex.h:9  →  #include <thrust/complex.h>
   ↓ 竟然解析到
/usr/include/thrust/complex.h        ← 這是 libthrust-dev（CUDA 味）的，不是 ROCm 的

根因：clang 的 include 搜尋順序裡，/usr/include 排在 /opt/rocm-7.2.0/include 前面（因為 rocm 的 include 目錄剛好也是 clang 內建系統路徑之一，你手動 -I 它會被 clang 判定重複而丟掉）。系統上 libthrust-dev + nvidia-cuda-dev 在 /usr/include/thrust 放了 CUDA 版 thrust，就贏了。

修法（P1）：setup_rocm.py 裡把 -isystem /opt/rocm-7.2.0/include 塞到編譯 flag 最前面。-isystem 會排在 /usr/include 之前，rocThrust 就勝出。

# setup_rocm.py

# 原本
cxx_flags = ["-O3"]
# 改成
cxx_flags = ["-isystem", "/opt/rocm-7.2.0/include", "-O3"]

# 原本
hipcc_flags = [
    "-DNDEBUG",
    ...
# 改成
hipcc_flags = [
    "-isystem",
    "/opt/rocm-7.2.0/include",
    "-DNDEBUG",
    ...

驗證這招有效的最小重現：

echo '#include <thrust/complex.h>' > /tmp/t.hip
/opt/rocm-7.2.0/lib/llvm/bin/clang++ -x hip --offload-arch=gfx1100 -isystem /opt/rocm-7.2.0/include -H -E /tmp/t.hip 2>&1 | grep 'thrust/complex.h'
# 要看到解析到 /opt/rocm-7.2.0/include/thrust/complex.h 才對

如果你的機器沒裝過 libthrust-dev / nvidia-cuda-dev / libcu++-dev，這坑不會出現，P1 可略。或者你也可以 sudo apt remove libthrust-dev libcub-dev（nvidia-cuda-dev 會被連帶移除，自己評估）。

坑 3（moe_q_gemm_rdna3.hip 本身有 bug）

症狀：P1 修完剩 8 個錯，全在同一個檔：

csrc/gemm/gptq/moe_q_gemm_rdna3.hip:292:68: error: non-const lvalue reference to type 'half2[2]'
  (aka '__half2[2]') cannot bind to a value of unrelated type 'half2' (aka '__half2')
qdq_4_rdna3.cuh:92:61: note: passing argument to parameter 'z1z16' here

dequant_4bit_8_fp16(...) 的參數要 half2 (&)[2]，caller 傳的是單個 half2 —— fork 的 MoE 版寫錯了。

修法（P2）：Qwen3.8-27B 是 dense，根本不會呼叫 MoE routing GEMM。把這個 source 拿掉、順便擋掉它在 extension 的註冊（不然 link 會缺符號）。

setup_rocm.py，sources 清單裡：

    "csrc/gemm/gptq/q_gemm_rdna3.cu",
    "csrc/gemm/gptq/q_gemm_rdna3_wmma.cu",
    # "csrc/gemm/gptq/moe_q_gemm_rdna3.cu",   ← 註解掉

setup_rocm.py，is_rdna 那段之後加一個編譯巨集：

if is_rdna:
    hipcc_flags.append("-DSGL_IS_RDNA")
    cxx_flags.append("-DSGL_IS_RDNA")

# 加這兩行
hipcc_flags.append("-DSGL_SKIP_MOE_GPTQ_RDNA3")
cxx_flags.append("-DSGL_SKIP_MOE_GPTQ_RDNA3")

csrc/common_extension_rocm.cc，把 moe_gptq_gemm_rdna3 的 extern 宣告 和 m.def + m.impl 各自用 #ifndef 包起來：

#ifndef SGL_SKIP_MOE_GPTQ_RDNA3
  extern void moe_gptq_gemm_rdna3(torch::Tensor a, torch::Tensor c,
                                  ... 
                                  int64_t output_topk);
#endif

#ifndef SGL_SKIP_MOE_GPTQ_RDNA3
  m.def(
      "moe_gptq_gemm_rdna3(Tensor a, Tensor! c, ... int output_topk) -> ()");
  m.impl("moe_gptq_gemm_rdna3", torch::kCUDA, &moe_gptq_gemm_rdna3);
#endif
}

開編

source ~/venvs/sglang-rocm/bin/activate
rm -rf build
AMDGPU_TARGET=gfx1100 PYTORCH_ROCM_ARCH=gfx1100 HIP_VISIBLE_DEVICES=0 MAX_JOBS=32 \
  ROCM_HOME=/opt/rocm-7.2.0 ROCM_PATH=/opt/rocm-7.2.0 \
  python setup_rocm.py build_ext --inplace

setup_rocm.py 會自動從 torch.cuda.get_device_properties(0).gcnArchName 抓到 gfx1100（白名單裡本來就有 gfx1100，社群講的「要 patch 白名單」在這個 fork 不必），RDNA 分支會自動不編 CDNA 專用的 all-reduce。

成功長這樣：

[19/19] ...
creating build/lib.linux-x86_64-cpython-312/sgl_kernel
x86_64-linux-gnu-g++ ... -o build/.../sgl_kernel/common_ops.cpython-312-x86_64-linux-gnu.so
copying build/.../common_ops.cpython-312-x86_64-linux-gnu.so -> python/sgl_kernel

把 .so 放進 site-packages：

SP=~/venvs/sglang-rocm/lib/python3.12/site-packages
mkdir -p $SP/sgl_kernel
cp -r python/sgl_kernel/. $SP/sgl_kernel/
python -c "import torch, sgl_kernel; print('sgl_kernel OK')"

---

Step 3：裝 sglang 本體（editable）+ 一堆 runtime 相依

cd ~/src/sglang-gfx1100/python
uv pip install --no-build-isolation --no-deps -e .

坑 4（--no-deps 是必須的，且 editable 會「消失」）

• 必須 --no-deps：pyproject.toml 的相依清單整串是 CUDA 專用（cuda-python>=13、flash-attn-4、flashinfer_python[cu13]、quack-kernels、tilelang…），照裝會把 CUDA torch 拉回來、或直接裝不起來。
• editable 安裝會被後續的 uv pip install 悄悄移除：我遇到兩次「pip install -e . 成功 → 裝別的東西 → import sglang 又 No module named 'sglang'」。
  對策：① editable 用 uv pip install ... -e .（跟後面的 uv 操作同一個工具，比較不會打架）；② 每裝完一批相依，重跑 python -c "import sglang" 確認，掉了就再 uv pip install --no-build-isolation --no-deps -e . 一次。

手動補相依（照 import 錯誤一個個補）

先裝這批（都是 ROCm 安全的、不會拉 CUDA torch）：

uv pip install \
  orjson transformers tokenizers safetensors huggingface_hub hf_transfer \
  fastapi "uvicorn[standard]" uvloop python-multipart requests aiohttp \
  pyzmq msgspec psutil setproctitle scipy pillow pydantic packaging \
  interegular llguidance einops sentencepiece tiktoken partial_json_parser \
  pybase64 blobfile compressed-tensors prometheus-client cloudpickle py-cpuinfo \
  anthropic openai ipython outlines datasets modelscope numba

# torchvision 一定要從 rocm 索引 pin，不然又把 CUDA torch 拉回來（坑 1 的變體）
uv pip install "torchvision==0.26.0+rocm7.2" \
  --index-url https://download.pytorch.org/whl/rocm7.2 --index-strategy unsafe-best-match

然後迴圈補剩下的：

cd ~/src/sglang-gfx1100/python
while true; do
  ERR=$(python -c "from sglang.srt.entrypoints.http_server import launch_server" 2>&1 | grep ModuleNotFoundError | tail -1)
  [ -z "$ERR" ] && { echo "OK"; break; }
  MOD=$(echo "$ERR" | grep -oE "named '[^']+'" | tr -d "named '" | cut -d. -f1)
  case "$MOD" in
    tvm_ffi) PKG="apache-tvm-ffi==0.1.11";;   # ← 坑：import 名是 tvm_ffi，套件名不同
    *)       PKG="$MOD";;
  esac
  echo "缺 $MOD → 裝 $PKG"
  uv pip install --no-deps "$PKG"
done

我這輪最後補進去的：gguf、xgrammar、apache-tvm-ffi==0.1.11（imported as tvm_ffi）、soundfile。

驗證整條：

python -c "
import torch; print('torch', torch.__version__, torch.version.hip, torch.cuda.get_device_properties(0).gcnArchName)
import sgl_kernel; print('sgl_kernel OK')
import sglang; print('sglang OK')
from sglang.srt.entrypoints.http_server import launch_server; print('launch_server OK')
"
python -m sglang.launch_server --help | head -3

---

Step 4：下模型 + patch config.json

hf download Vishva007/Qwen3.8-27B-W4A16-AutoRound-GPTQ \
  --local-dir ~/models/qwen3.8-27b-mtp-fixed

（W4A16 GPTQ，本體 5 個 shard ≈ 19GB＋model_extra_tensors.safetensors 849MB 放 MTP 張量。硬碟上約 19GB。）

坑 3.5 → P3（GPTQ loader 想量化 MTP 層 → 載入失敗）

症狀（不 patch 的話，載模型階段就爆）：loader 相信 config.json 裡 quantization_config.dynamic 的
"+:.*mtp.*" / "+:.*mtp\.fc.*" 正向規則（bits 4、group 64），拿 4-bit 參數去載 MTP 層，但那些張量其實是 BF16 → 掛。

修法（P3，README 也有寫）：

cd ~/models/qwen3.8-27b-mtp-fixed
cp config.json config.json.orig
python3 - <<'EOF'
import json
c=json.load(open("config.json"))
dyn=c["quantization_config"]["dynamic"]
dyn.pop("+:.*mtp.*", None)
dyn.pop("+:.*mtp\\.fc.*", None)
dyn["-:.*mtp.*"] = {"bits": 16, "group_size": 128}   # 明確排除 MTP 層量化
json.dump(c, open("config.json","w"), indent=2, ensure_ascii=False)
print("patched")
EOF

---

Step 5：啟動（單卡）

這個 fork 是雙卡專案，README 的範例是 --tp-size 2 --context-length 196608 --mem-fraction-static 0.91（給 2×24GB）。單卡要自己砍。

5a. 先試「照抄 + --tp-size 1 + 帶 EAGLE MTP」→ OOM

 Load weight end. type=Qwen3_5ForConditionalGeneration, quant=gptq, bits=4, mem usage=18.18 GB.
[...] Load weight end. type=Qwen3_5ForCausalLMMTP,          quant=gptq, bits=4, mem usage=5.53 GB.
[...] ValueError: Loaded weights leave no GPU memory for the KV cache under --mem-fraction-static=0.9.
      Raise --mem-fraction-static above 0.997 (minimum viable = 0.9961).

坑 6（單卡塞不下 target + MTP draft + KV）

• GPTQ 本體 18.18GB
• EAGLE 的 draft 是「整個 Qwen3_5ForCausalLMMTP 當獨立 GPTQ 模型載」= 5.53GB（不是 llama.cpp 那種塞在 GGUF 裡的小 head）
• 18.18 + 5.53 = 23.7GB，24GB 卡連 KV 都放不下

雙卡（48GB）就沒事 —— 這就是為什麼原文是雙卡。

5b. 「關掉 MTP」→ 跑得動，~35 t/s

啟動腳本（存成 run_sglang_singlecard.sh）：

#!/bin/bash
source ~/venvs/sglang-rocm/bin/activate
export HIP_VISIBLE_DEVICES=0
export SGL_DTYPE=bfloat16
export SGL_RDNA_VLLM_VERIFY=1
export SGL_RDNA_NO_FUSED=1
export SGL_RDNA_GEMMA_TRITON=1
export ROCM_HOME=/opt/rocm-7.2.0
export ROCM_PATH=/opt/rocm-7.2.0
export TOKENIZERS_PARALLELISM=false
exec python -m sglang.launch_server \
  --model-path ~/models/qwen3.8-27b-mtp-fixed \
  --host 0.0.0.0 --port 8080 \
  --served-model-name qwen3.8-27b \
  --tp-size 1 \
  --quantization gptq \
  --dtype bfloat16 \
  --mamba-ssm-dtype bfloat16 \
  --kv-cache-dtype auto \
  --attention-backend triton \
  --context-length 16384 \
  --mem-fraction-static 0.93 \
  --max-running-requests 2 \
  --max-mamba-cache-size 16 \
  --triton-attention-num-kv-splits 16 \
  --trust-remote-code

成功關鍵行：

Load weight end. type=Qwen3_5ForConditionalGeneration, quant=gptq, bits=4, mem usage=18.18 GB.
Mamba Cache is allocated. ssm_state size: 1.20GB
KV Cache is allocated. dtype: torch.bfloat16, #tokens: 42880, K size: 1.31 GB, V size: 1.31 GB
rdna_unified_verify ACTIVE (decode path)
Linear attention kernel backend: decode=triton, prefill=triton, verify=triton
Uvicorn running on http://0.0.0.0:8080

實測（同機、暖機後）：

程式碼   decode ≈ 35.1 t/s
散文 x2  decode ≈ 35.3 t/s
Rust     decode ≈ 35.3 t/s
→ 平均 35.3 t/s（非常穩，35.1～35.4）
第一次請求（暖機）約 38 秒（graph / 編譯）

這個數字 = 純 GPTQ dense forward，跟 llama.cpp 不開投機解碼差不多。沒有優勢。

5c. 想單卡也吃 MTP：--cpu-offload-gb 硬塞 → 又踩 2 個坑，最後「能跑但太慢」

概念：把一部分 target 權重丟主機 RAM（--cpu-offload-gb 8），空出顯存給 5.5GB 的 MTP draft。

坑 7（--cpu-offload-gb + gemma layernorm，裝置不一致）

File ".../sglang/srt/layers/layernorm.py", line 1122, in _weight_loader
    torch.add(param.data, 1.0, out=self.gemma_weight)
RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cuda:0 and cpu!

offload 把 param 放到 CPU，但 self.gemma_weight buffer 在 GPU。

修法（P4） python/sglang/srt/layers/layernorm.py 的 _weight_loader：

    def _weight_loader(self, param, loaded_weight):
        assert param.size() == loaded_weight.size()
        param.data.copy_(loaded_weight)
        # --cpu-offload-gb 會讓 param 在 CPU、gemma_weight 在 GPU
        if self.gemma_weight.device != param.data.device:
            self.gemma_weight = self.gemma_weight.to(param.data.device)
        torch.add(param.data, 1.0, out=self.gemma_weight)

坑 8（--cpu-offload-gb + Qwen3.8 hybrid GDN，tied 權重）

File ".../sglang/srt/utils/offloader.py", line 148, in forward
    output = functional_call(module, device_state, args=args, kwargs=kwargs)
ValueError: functional_call got multiple values for keys
  ['linear_attn.A_log', 'linear_attn.attn.A_log'], which are tied.
  Consider using tie_weights=False

Qwen3.8 的 Mamba/GDN 層那個 A_log 在 state_dict 裡以兩個名字出現（tied），offloader 的 functional_call 不吃。

修法（P5） python/sglang/srt/utils/offloader.py，兩處 functional_call(...) 都加 tie_weights=False：

# line ~148
output = functional_call(module, device_state, args=args, kwargs=kwargs, tie_weights=False)

# line ~269
output = functional_call(
    module, get_parameter_and_buffer_dicts(), args=args, kwargs=kwargs, tie_weights=False,
)

5c 啟動腳本（帶 MTP + offload）

在 5b 的腳本上加/改：

  --context-length 8192 \
  --mem-fraction-static 0.95 \
  --cpu-offload-gb 8 \
  --max-running-requests 1 \
  --max-mamba-cache-size 8 \
  --speculative-algorithm EAGLE \
  --speculative-draft-model-path ~/models/qwen3.8-27b-mtp-fixed \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4 \
  --speculative-draft-kv-cache-dtype fp8_e4m3 \
  --cuda-graph-bs-decode 1 \

這次真的載入成功了：

Load weight end. type=Qwen3_5ForConditionalGeneration ... mem usage=10.05 GB.   ← 8GB offload 到 RAM
Load weight end. type=Qwen3_5ForCausalLMMTP           ... mem usage=4.84 GB.
KV Cache (target) bf16: 3.01 + 3.01 GB ; (draft) fp8: 0.09 + 0.09 GB
rdna_unified_verify ACTIVE (verify path)
rdna_unified_verify ACTIVE (decode path)
Uvicorn running on http://0.0.0.0:8080

但實測：10-token 的暖機請求跑 3 分鐘沒回來；rocm-smi 看 GPU 使用率 2%；SGLang 的 Decode batch log 一行都沒印。原因很直接：每個 forward 都要把 8GB 的 GPTQ 權重從 RAM 串過 PCIe Gen4 x16（~31GB/s），光傳輸就 ~0.25s/token → <4 t/s，GPU 全程在等。

→ 能跑 ≠ 能用。單卡 + offload 的 MTP 沒有意義。

---

對照表（同一台機、同一顆 Qwen3.8-27B）

方案	decode（程式碼 / 散文）	塞得進 24GB？	備註
SGLang 單卡，無 MTP	~35 / ~35 t/s		= 純 GPTQ forward
SGLang 單卡，MTP + --cpu-offload-gb 8	<4 t/s	靠 offload	PCIe 串權重把速度打死
SGLang 雙卡 MTP-3（原文，非本機實測）	97～116 t/s	需 48GB	這才是那篇的數字
llama.cpp（Vulkan）+ GGUF + 自帶 MTP	73 / 33 t/s（平均 50）		prefill 6.4K=706 / 25K=607 t/s
llama.cpp 無 MTP	~35 t/s		跟 SGLang 無 MTP 一樣

llama.cpp 的 MTP head 是塞在 GGUF 裡的小東西（不是獨立 5.5GB 模型），所以單張 24GB 就能開 MTP，這是它單卡贏的關鍵。

---

已知坑速查（照這個順序就不會卡）

#	症狀關鍵字	解法
1	裝完 torchvision 後 torch.version.hip 變 None / 印出 NVIDIA 卡	torch/torchvision/torchaudio 一律 pin 版本從 whl/rocm7.2 索引裝；每次 pip 後驗證
2	error: definition of type 'int2' conflicts / include 鏈跑到 /usr/include/thrust	setup_rocm.py 加 -isystem /opt/rocm-7.2.0/include（或移除 libthrust-dev）
3	moe_q_gemm_rdna3.hip:...: non-const lvalue reference to type 'half2[2]'	從 sources 拿掉該檔 + -DSGL_SKIP_MOE_GPTQ_RDNA3 擋註冊（dense 模型不用 MoE）
4	import sglang → No module named 'sglang'（明明剛裝過）	editable 用 uv pip install --no-build-isolation --no-deps -e .；每次裝完相依重驗
5	No module named 'tvm_ffi' 裝不起來	套件名是 apache-tvm-ffi==0.1.11
6	ValueError: Loaded weights leave no GPU memory for the KV cache	單卡塞不下 target(18G)+MTP draft(5.5G)+KV → 關 MTP，或 --cpu-offload-gb（見坑 7/8，但會很慢）
7	RuntimeError: Expected all tensors to be on the same device in layernorm.py _weight_loader	P4：gemma weight loader 加 device 對齊（只有用 --cpu-offload-gb 才會遇到）
8	ValueError: functional_call got multiple values for keys ['linear_attn.A_log'...] which are tied	P5：offloader.py 兩處 functional_call(..., tie_weights=False)
️	—	千萬不要對 gfx1100 下 rocm-smi --gpureset（會鎖死 PCIe root complex，只能硬關機）—— README 自己的警告
️	閒置時 2 個 CPU 核心 100%	ROCm KFD event-age busy-wait bug；--sleep-on-idle 或編 scripts/rdna_ar/kfd_event_age_fix.c 做 LD_PRELOAD
	log 一直說 "model can run with gptq_marlin ... faster"	marlin 是 CUDA kernel，RDNA3 維持 --quantization gptq（用 fork 的 q_gemm_rdna3）

---

我的建議

• 只有一張 7900 XTX → 用 llama.cpp（HIP 或 Vulkan）+ GGUF，開它自帶的 MTP。單卡場景它就是最佳解，systemctl restart 15 秒回來，不用顧 ROCm/torch 版本相依地獄。
• 有兩張 7900 XTX → 這個 fork 才有意義。照 README 原始的 --tp-size 2 路徑跑（上面 P1～P3 的 build patch 兩張卡也要；P4/P5 是單卡 offload 專用，雙卡用不到）。那時 target+draft+KV 全塞進 48GB，就能拿到原文的 88～116 t/s。
• 上游 SGLang 目前（2026-09）還沒有官方 consumer RDNA3 支援（追蹤在 sgl-project/sglang issue #30599）。這個社群 fork 是目前唯一把 q_gemm_rdna3 GPTQ kernel 補上的。

---

寫於 2026-09-08。環境 ROCm 7.2.0 / torch 2.11.0+rocm7.2 / SGLang fork StevenChenSE/sglang@gfx1100-support（該日最新 commit）。

@terry 他這個很厲害,不用之前學生案這麼麻煩,他發連結你點一下 就完成訂閱,,我查了是印度那邊的方案,

@AGI 對我最近hermes也轉去gemini3.8 flash,台灣這有人搞jio訂閱一年半,台幣150,我嚕了三個小號

要哭,上個月才賣掉1張7900xtx,好像買不回來了

推一個 優質好文,願意分享就給讚

@Michael-Zhou 有影片看看嗎？哈
非常好奇

讚讚 先推一個，已抓下來測試

我覺得也能換兩張 7900xtx 24g 一張跑qwen3.8 27b 一張comfyui 我本來也這樣,但有更好的雲端api選擇 就把一張賣了,留一張玩 本地模型跟comfyui輪流用

我也是推hermes agent 目前是絕對的AI助理主力,要開發也能開發多功能,手機帶著走 發tg真的方便

當然要本地 才可以出色色圖文 哈,看需求吧,沒需求當然是雲端API便宜又快

@densha 對阿 不要多花錢的 先用起來

跪拜大師,謝謝分享

@Bunsei 台灣我的廠商 技嘉 Radeon AI PRO R9700 AI TOP 32G 49500台幣,不知道算貴還便宜?

看論壇滿多朋友有佈署本地模型的一些困擾,這邊分享只要你有訂閱 西方御三家或grok也行,或有訂閱制的其他的應該都行,能接成cli agent使用訂閱額度,其中codex及grok hermes原生合法支援,透過hermes調用使用oauth,個人實測超過一個月目前沒有封號問題,御三家都能正常使用,你們可以接agent 幫你們佈署本地qwen等模型,效率會更好,直接複製論壇大佬們的文章,丟給agent抄作業即可,以下ai整理的內容,希望對你們有幫助!

Hermes 多家 AI 的 OAuth、原生 Provider 與 Proxy/Bridge 接法

查詢與驗證日期：2026-08-22
適用範圍：本機 Hermes 以多個模型 provider 運作的架構說明。本文不包含帳號、token、API key、私人網址或可直接連入的端點。

一句話結論

「能在 Hermes 裡選到模型」不代表它們都用同一種登入方式。實務上有三條完全不同的路徑：

原生 provider：Hermes → 官方服務
Proxy/bridge：  Hermes → 本機轉接程式 → 官方 CLI 或官方服務
正式雲端 OAuth：Hermes → 雲端平台（ADC／service account）→ 模型服務

差別會影響：誰保存憑證、使用哪一種配額或帳單、是否可看見正確 token 用量，以及故障時應查哪一層。

---

1. 先理解四個名詞

原生 provider

Hermes 直接支援該模型服務的協定與驗證。Hermes 自己負責選模型、保存或讀取認證、向官方服務送請求。

Hermes → 官方 API / 官方 provider

優點是結構短、狀態和用量較容易查；缺點是 Hermes 必須真的支援那一種驗證方式。

OAuth

OAuth 是「授權登入」機制，不等於 API key，也不等於所有服務都能拿來當 API。通常會得到短期 access token 與可續期的 refresh token。

OAuth 可出現在不同層：

• Hermes 自己持有 OAuth：例如原生 Codex provider。
• 官方 CLI 持有 OAuth：例如 Gemini CLI 或 Claude Code 登入後，CLI 自己管理 token。
• 雲端平台持有 OAuth：例如 Google Cloud ADC 或 service account 對 Vertex AI 取得短期權杖。

API key

API key 是給正式 API 呼叫的長期憑證。它通常綁定專案、帳單和 API 配額，並不會自動使用個人訂閱方案的額度。

Proxy / bridge

Proxy 或 bridge 是本機常駐的中介程式。它把 Hermes 的請求轉成另一種協定，或轉交給已登入的 CLI。

Hermes → OpenAI 相容介面 → proxy/bridge → CLI 或官方服務

它的價值是兼容性；代價是多一層服務、更多故障點與較不透明的用量統計。

---

2. 本機各 provider 的實際路由

A. OpenAI Codex：原生 Hermes provider

Hermes → openai-codex provider → OpenAI

這條是 Hermes 原生 provider 路徑。Hermes 管理其登入狀態並直接向 OpenAI 請求，不需要額外本機 bridge。

適合：想要較少元件、較直接的 provider 狀態與穩定性時。

注意：不要把「Codex/ChatGPT 登入」和「OpenAI Platform API key」混為同一種帳務或授權。正式 OpenAI API 的公開文件以 API key 作為一般 API 驗證方式；實際帳戶可用的登入與產品權益仍以官方帳戶設定為準。

B. Anthropic Claude 原生 provider：直接由 Hermes 呼叫

Hermes → anthropic provider → Anthropic

以 claude-opus-4-6 這類指定為 anthropic provider 的模型為例，走的是 Hermes 原生 Anthropic 路徑，概念上最接近 Codex 的「Hermes 直接管理 provider」模式。

適合：需要短路徑、清楚區分 Hermes 原生登入與本機 CLI 的情況。

C. Claude Code bridge：由本機 Claude Code OAuth 執行

Hermes
  → custom:claude-code-proxy
  → 本機 Claude Code bridge
  → claude -p
  → Claude Code 的 Claude.ai OAuth
  → Anthropic

claude-opus、claude-sonnet、claude-haiku 這類 custom alias 屬於這條路。bridge 對 Hermes 提供 OpenAI 相容 chat 介面，收到請求後再啟動已登入的 Claude Code CLI。

這不是 Hermes 原生 Anthropic provider。它適合把「已登入的 Claude Code 工作流程」接進 Hermes，但請注意：

• Claude Code 可能把內容視為 agent 任務，會帶入其系統指令、工具設定或額外處理回合。
• bridge 若回傳簡化的 usage 欄位，Hermes 端數字不一定能代表真實 Claude Code 消耗。
• Claude 的訂閱與第三方工具使用必須依 Anthropic 當時的方案與條款；技術可通不等於永久保證可用。

D. Gemini proxy：由本機 Gemini/Google OAuth 轉接

Hermes
  → custom:gemini-proxy
  → 本機 cli-proxy
  → Gemini CLI / Google OAuth
  → Google Gemini

本機 Gemini alias 都指定 custom:gemini-proxy。因此 hermes auth status gemini 即使顯示未登入，也不等於 Gemini 不能用：那個指令檢查的是 Hermes 原生 gemini provider；實際模型走的是 proxy 裡保存的 Google OAuth。

適合：希望使用 Gemini CLI／Google AI Pro 這類 Google 帳號登入後的 CLI 額度，而 Hermes 本身沒有對應的個人 Gemini CLI OAuth 原生 provider。

注意：proxy 是相容性轉接層，不是官方 Gemini API key 的直連路徑。它應只在本機使用，不應公開成他人可共用的服務。

E. Gemini 原生 API provider：正式 Gemini API key

Hermes → gemini provider → Gemini API

這條不需要本機 cli-proxy，但使用的是 GEMINI_API_KEY（或 Google AI Studio 專案的正式 API 憑證）。它走 Gemini API 的專案配額與帳單，不會使用個人 Google AI Pro／Gemini CLI 訂閱額度。

適合：正式應用、可預測的 API 帳單、高用量或需要較完整的 API 功能時。

F. Vertex AI：原生雲端 OAuth2 路徑

Hermes → vertex provider → Google Cloud / Vertex AI → Gemini

Vertex 路徑使用 Google Cloud 的 Application Default Credentials（ADC）或 service account，取得短期 OAuth2 access token。它不使用個人 Gemini CLI/Google AI Pro 訂閱額度，而是使用 GCP 專案的 Vertex AI 帳單與配額。

適合：企業、可稽核部署、服務帳號、明確 GCP 專案與生產環境。

---

3. 一張比較表

路徑	Hermes 是否原生支援	登入憑證持有者	用量／帳務主要歸屬	是否需要本機常駐程式
OpenAI Codex provider	是	Hermes / OpenAI 登入流程	該 OpenAI provider 的帳戶規則	否
Anthropic 原生 provider	是	Hermes / Anthropic provider	Anthropic provider 的帳戶規則	否
Claude Code bridge	否，屬 custom provider	Claude Code CLI	Claude Code 訂閱或其設定的帳務	是
Gemini proxy	否，屬 custom provider	Gemini CLI / Google OAuth	Gemini CLI／Google 帳號方案配額	是
Gemini API	是	API key	Google AI Studio / Gemini API 專案帳單	否
Vertex AI	是	ADC / service account OAuth2	GCP / Vertex AI 專案帳單	否

---

4. Token、配額與費用到底有何差異？

同一模型、同一完整輸入，proxy 不會憑空大量增加 token

HTTP 轉送本身不會產生模型 token。真正決定消耗的是模型收到的：

• 完整對話歷史與 system prompt
• 輸入與輸出長度
• reasoning / thinking token
• 工具呼叫與回傳結果
• 是否有 prompt cache 或 server-side cache

但不同路徑仍可能有顯著差異

情境	為何可能增加消耗或降低可觀測性
Claude Code bridge	CLI 可能把 Hermes 對話重包成 agent 任務，帶入額外指令、工具、推理或多輪處理；bridge usage 不一定是官方真實 usage。
Gemini OAuth proxy	會使用 Gemini CLI／Google OAuth 對應的配額。官方 Gemini CLI 文件指出，OAuth 使用者目前不能建立 prompt cache；重複長上下文可能比 API key/Vertex cache 路徑更難節省。
Gemini API key / Vertex	有正式 API 的 usage、專案帳單與快取能力；適合需要精準成本與可觀測性的工作。
原生 provider	中介層最少，通常最容易把 provider 回傳的 usage 與實際請求對上。

因此不能只看 Hermes 的 token 數字來比較所有路徑；對 bridge 尤其要以底層 CLI 或官方帳戶的配額／用量頁為準。

---

5. Google AI Pro / Gemini CLI 訂閱與 Gemini API 的差別

這是最常被混淆的地方：

Google AI Pro / Gemini CLI OAuth
→ Google 帳號、Gemini CLI 使用量或方案配額

Gemini API key
→ Google AI Studio / Cloud 專案、API 配額與帳單

Vertex AI
→ GCP 專案、Vertex AI 配額與帳單

三者不是同一個錢包，也不是同一套上限。若目標是使用個人 Google AI Pro 的 Gemini CLI 額度，現有的 Gemini proxy 是實際路徑；若目標是正式、可量化、可長期自動化的 API，則應使用 Gemini API 或 Vertex。

以 Jio 等合作促銷取得的 Google AI Pro 權益亦屬 Google 帳號／訂閱路徑，而非 Gemini API key。它的持續性取決於促銷提供者、資格與條款，不應當作正式 API 成本替代品。

---

6. 合規與帳號風險

可以合理使用的範圍

• 在本人本機，以自己的帳號與正常使用頻率執行已登入的官方 CLI。
• 將只監聽 localhost 的 proxy 作為個人工具整合。
• 遵守服務的使用條款、模型配額、內容政策與帳號資格條件。

應避免的行為

• 將個人訂閱 OAuth 包裝成對外販售或公開 API。
• 多帳號輪替、偽裝 client 身分、繞過 429、繞過方案或促銷資格限制。
• 公開 proxy port、API key、OAuth refresh token 或把憑證交給第三方。
• 將促銷／個人訂閱帳號作為高頻、商業化或唯一生產依賴。

風險不是「只要使用 proxy 就一定封號」。OAuth 本身是官方支援的驗證機制；但非官方相容 proxy、跨區促銷、過度自動化或規避配額都會提高 token 被撤銷、服務受限或帳號被檢視的風險。正式生產工作建議使用官方 API key、Vertex 或服務帳號。

---

7. 故障時先辨識路由，再查對的地方

原生 provider

模型是否指定原生 provider？
→ Hermes provider auth status
→ Hermes Gateway 狀態
→ 在使用者授權下再做一次真實模型請求

Claude Code bridge

Claude Code 是否登入？
→ bridge 是否存活並只監聽 localhost？
→ 已認證的 /v1/models 是否能列出模型？
→ 在使用者授權下做一次 completion

Gemini proxy

cli-proxy 是否存活並只監聽 localhost？
→ Google OAuth 憑證是否存在、可更新？
→ 已認證的 /v1/models 是否回 HTTP 200？
→ 在使用者授權下做一次 completion

不要只看「Model switched」或「模型名稱出現在清單」就宣稱可用；那只證明設定或 discovery 成功，未必證明底層帳號真的可生成內容。

---

8. 選擇建議

需求	優先選擇
個人、本機、低頻，想用 Google AI Pro 的 CLI 額度	Gemini OAuth proxy
個人、本機，想使用 Claude Code 已登入帳號	Claude Code bridge（注意條款、工具回合與用量不透明）
想要簡單、少元件、直接 provider 管理	原生 Codex 或原生 Anthropic provider
正式應用、穩定帳單、可量化成本	Gemini API key 或 Vertex AI
企業、服務帳號、IAM、稽核與 GCP 控制	Vertex AI

最好的架構通常不是只押一條路：將個人 OAuth proxy 視為方便的低頻來源，同時保留至少一個正式原生 provider 或 API provider 作 fallback。

---

9. 官方參考資料

• OpenAI API Quickstart
• Anthropic：登入 Claude 帳號與第三方工具說明
• Anthropic：Claude Code 訂閱方案
• Gemini CLI：Authentication
• Gemini CLI：Token caching
• Gemini API：Billing
• Gemini API：OAuth quickstart
• Google Gemini API：Abuse monitoring

免責聲明

本文是技術架構與公開條款的整理，不是法律、稅務、帳務或平台政策保證。模型可用性、方案內容、帳單、促銷資格、token 限制與第三方整合規則會變動；要做生產或商業決策時，請以各官方帳戶後台與最新官方條款為準。

@Quanta-Magic 確定可以啊,你讓agent幫你佈署就好啦,128k+視覺 穩定跑 不會oom,作業複製貼上一定成功,但沒保證每一個任務都70幾 t/s 我只能說他大部分都能完成任務,讓codex or claude or ds4 flash先幫hermes把skill工作流 寫好,之後讓本地qen3.8 27b跑,一個字 穩! 不要錢的 速度慢一點 就接受了

@terry 感謝,但我承擔不起超凡大師,並沒有非常專業,從看老特的片買7900xtx開始摸的小白,最初玩rtx3060 12g x3 vllm失敗才下定決心買卡來玩,主要還是看到老特的影片,才入坑的,您才是大師,我只是跟您一樣,想把知識提早分享出去,讓網友們少走彎路,一起努力 哈

@kylin_Zaki 恭喜 起飛了