抡锤者

TLDR

先上個實體圖

Beelink Ser 8 8745HS 用Oculink連接 RTX Pro 4500

跑在Ubuntu 26.04, Kernel 7.0

因爲Oculink的關係, 不會考慮使用MoE

啓動咒語, 注意這個是我在vLLM cu130 nightly (0.20)設立的, cu129 0.22估計會有更多優化, 我會試試看其他版本

docker run -d \
  --name vllm-Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP \
  --restart unless-stopped \
  --ipc host \
  --gpus '"device=0"' \
  -p 0.0.0.0:7380:8000 \
  -v "~/vllm/models:/models:ro" \
  -v "~/vllm/.cache/huggingface:/root/.cache/huggingface" \
  -e GPU_MEMORY_UTILIZATION="0.95" \
  -e HF_HUB_OFFLINE="1" \
  -e KV_CACHE_DTYPE="fp8" \
  -e MAX_MODEL_LEN="230400" \
  -e MODEL_PATH="/models/sakamakismile/Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  -e PYTORCH_CUDA_ALLOC_CONF="expandable_segments:True" \
  -e SERVED_MODEL_NAME="Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  -e VLLM_ATTENTION_BACKEND="FLASHINFER" \
  -e VLLM_EXTRA_ARGS='--quantization modelopt --trust-remote-code --enable-chunked-prefill --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice --max-num-seqs 1 --max-num-batched-tokens 4096 --speculative-config {"method":"qwen3_5_mtp","num_speculative_tokens":3} --language-model-only --performance-mode interactivity --attention-backend flashinfer --skip-mm-profiling --enable-prefix-caching --no-disable-hybrid-kv-cache-manager' \
  -e VLLM_LOGGING_LEVEL="INFO" \
  -e VLLM_NVFP4_GEMM_BACKEND="flashinfer-cutlass" \
  -e VLLM_USE_FLASHINFER_MOE_FP4="0" \
  -e VLLM_USE_FLASHINFER_SAMPLER="1" \
  --health-cmd 'curl -fsS http://localhost:8000/v1/models || exit 1' \
  --health-timeout 5s \
  --health-interval 30s \
  --health-retries 5 \
  --health-start-period 5m \
  --entrypoint /bin/bash \
  vllm/vllm-openai:cu130-nightly \
  -lc 'exec vllm serve "$MODEL_PATH" --served-model-name "$SERVED_MODEL_NAME" --host 0.0.0.0 --port 8000 --max-model-len "$MAX_MODEL_LEN" --gpu-memory-utilization "$GPU_MEMORY_UTILIZATION" --kv-cache-dtype "$KV_CACHE_DTYPE" $VLLM_EXTRA_ARGS'

llama-benchy benchmark

llama-benchy \
  --base-url "http://localhost:7380/v1" \
  --model "Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  --tokenizer "$HOME/vllm/models/sakamakismile/Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  --pp 2048 \
  --tg 480 \
  --depth 0 1000 5000 10000 20000 50000 100000 150000 200000 \    #(不同上下文長度)
  --latency-mode generation \
  --skip-coherence \
  --concurrency 1 \

效果

| model                                    |             test |               t/s |     peak t/s |         ttfr (ms) |      est_ppt (ms) |     e2e_ttft (ms) |
|:-----------------------------------------|-----------------:|------------------:|-------------:|------------------:|------------------:|------------------:|
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |           pp2048 | 7741.01 ± 1375.30 |              |    373.94 ± 54.49 |    274.26 ± 54.49 |    373.94 ± 54.49 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |            tg480 |      68.87 ± 6.65 | 81.33 ± 3.68 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   pp2048 @ d1000 |   8136.73 ± 32.84 |              |     474.32 ± 1.44 |     374.64 ± 1.44 |     474.32 ± 1.44 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |    tg480 @ d1000 |      67.73 ± 5.06 | 88.00 ± 5.72 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   pp2048 @ d5000 |   6615.23 ± 22.79 |              |    1165.21 ± 3.86 |    1065.53 ± 3.86 |    1165.21 ± 3.86 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |    tg480 @ d5000 |      72.92 ± 3.56 | 89.33 ± 3.77 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d10000 |   6008.73 ± 10.16 |              |    2104.88 ± 3.47 |    2005.20 ± 3.47 |    2104.88 ± 3.47 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d10000 |      65.25 ± 2.21 | 82.00 ± 4.32 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d20000 |    5152.21 ± 0.52 |              |    4379.13 ± 0.52 |    4279.45 ± 0.52 |    4380.19 ± 0.46 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d20000 |      70.45 ± 1.27 | 89.67 ± 0.47 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d50000 |    3690.36 ± 5.88 |              |  14203.66 ± 22.59 |  14103.98 ± 22.59 |  14205.86 ± 22.80 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d50000 |      67.03 ± 1.67 | 84.67 ± 0.47 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d100000 |    2528.58 ± 0.55 |              |   40457.51 ± 8.72 |   40357.83 ± 8.72 |   40461.50 ± 8.69 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d100000 |      60.96 ± 0.75 | 78.33 ± 3.68 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d150000 |    1922.36 ± 0.98 |              |  79194.84 ± 39.68 |  79095.17 ± 39.68 |  79201.49 ± 39.50 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d150000 |      62.53 ± 3.29 | 76.33 ± 1.89 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d200000 |    1556.00 ± 0.99 |              | 129951.65 ± 82.49 | 129851.97 ± 82.49 | 129959.72 ± 82.53 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d200000 |      59.58 ± 1.31 | 69.67 ± 1.70 |                   |                   |                   |

---

碎碎唸, 講一下參數選擇邏輯

GPU_MEMORY_UTILIZATION => 0.95, Headless伺服器, 顯示輸出由iGPU負責
KV_CACHE_DTYPE => FP8, Ada架構以後基本統一FP8
MAX_MODEL_LEN => 230K, 之前有嘗試試過極限拉到240K左右, 但是會在部分長上下文出現OOM, 穩定點用230K

PYTORCH_CUDA_ALLOC_CONF => Pytorch實驗性參數, 透過呼叫CUDA内核API整理VRAM碎塊, 降低OOM機會
VLLM_ATTENTION_BACKEND => FLASHINFER, 很奇怪的是vLLM是推薦用這個而不是Flash Attention, 理論上在NVFP4在sm 12X (Desktop Blackwell)還沒完善下的情況用FA估計會比較好, 在sm 10X (Datacenter Blackwell)則FLASHINFER比較好

quantization => modelopt, vllm會跑去讀hf_quant_config.json裏的quant_algo, 這個模型是nvfp4
enable-chunked-prefill => 必開不解釋, 優化VRAM避免Spike導致OOM
speculative-config => 2 或者 3 都可, 激進點就用了3
skip-mm-profiling => 因爲這個模型只支持Text, 所以不需要multi model設定,省點VRAM
enable-prefix-caching => 降低TTRT
no-disable-hybrid-kv-cache-manager => 避免因爲Qwen模型的混合Attention導致挂掉

VLLM_NVFP4_GEMM_BACKEND => 叫vLLM 使用 FlashInfer/Cutlass NVFP4 kernels進行矩陣計算, Blackwell特點
VLLM_USE_FLASHINFER_MOE_FP4 (0) + VLLM_USE_FLASHINFER_SAMPLER (1) => 優化CUDA内核

@linkdesu

Oculink受限在PCIe 4.0 x4, 有些甚至要降到3.0 x4, 用Type C TB4跑就更慢

在比較高端點的卡例如7900XTX, 4090跟5090吞吐會就卡得死死的

顯存能容納所有權重或者Cache倒是還好

7900XTX只有24GB, 需要切換內存 + 顯存的情況估計比較多, 對於這些工作流來說基本上還是免了

@CHIA-AN-YANG

訂閱變成API其實有點踩到灰色地帶了, 雖然說我自己設立給自己一個人用的Sub2API也半斤八兩

不過一天沒有把這個功能開放給別人用 以及 不要被Gemini判定成過多請求 應該都沒什麼問題, 我記得之前因為過多請求導致Claude直接封掉Openclaw

純文字的話7900XTX沒什麼問題, 圖生成的話N卡還是比A卡佔優

至於帶寬的話, 只要卡本身能把權重都塞到顯存裡就沒問題, 必須避免Offload到內存裡

USB4則是最後的選擇, 沒辦法再拉Oculink的時候再用

很看你的用途吧, 這張卡本來就是閹割之後的5070Ti然後再加VRAM

不涉及ComfyUI的話只跑LLM或者昨天的trellis 2, 其實這張卡跑Qwen 3.6 27B估計也能拉到80到100K上下文, Gemma 4 31B就算能用NVFP4估計上下文也不會太多, MoE應該問題不大

不過買之前推薦上Vast.ai租借個兩三天測試一下跟跑一跑Benchmark

@imbiplaza-ASUS

1.35其實算高了

我DDR5 6400 也就是跑在1.3附近

而且4條來説很難散熱, 建議用個小風扇吹著

我上一間公司有試過因爲顯卡在機箱内排熱結果把内存給熱到當掉了

@terry 说:

这个内存条散热真的有用吗？会不会是反向效果

這個内存散熱外殼有用, 但是得必須依靠機箱風流或者CPU的風冷塔散才能發揮效果

聽起來你缺了個集合中心, 這個應該選一個慣用的通訊平臺就行了吧? 最簡單就是QQ, 微信或者Discord之類開個群組再把Agent拉進去?

Mattermost之前公司用過, 感覺就是一個比較先進跟加了個Bot的Discord

@bily-j

我自己有在用vLLM搭建API配合cline使用, 可以給點意見

除了跟@xiaote 說的用有寫abliterated的模型, 也可以用有寫heretic的模型

heretic在 重新訓練的數據集比較好 的情況下, 模型的思考能力, 連貫性跟邏輯會比abliterated更強, 也相對會更加少出現拒絕回答的情況

---

以下是碎碎唸跟簡單講一下原理, 有興趣可以讀一下

在hf的model card上通常都會有refusals rate, 我拿兩個模型作為例子

llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-GGUF

wangzhang/Qwen3.6-35B-A3B-abliterated-GGUF

KL越接近基礎模型越好, 代表兩個模型的思維偏差越低, 在這兩個例子下就是越接近0越好, KL基本上低於0.3就沒什麼大問題

heretic跟abliterated都是去審核的方式

abliterated只能說是減低拒絕的概率(refusal-reduced), 因為只單純控制權重(Weight Projection), 不涉及微調

heretic則是利用貝葉斯優化(Bayesian optimization)微調模型

但很遺憾的是沒有一個通用準則說什麼時候用abliterated, 什麼時候用heretic

---

然後就有人腦洞大開會跑去弄個混合模型

Youssofal/Qwen3.6-35B-A3B-Abliterated-Heretic-GGUF

@williamlouis

終端的實現不難, 難就是在難以穩定找到提供算力的終端

畢竟電腦都是拿來用的, 所謂的家用閒置也只是一個個時段而不是24/7

Salad官方用了個愚蠢但無可奈何的方法: 懲罰穩定性不足的終端

對於經常開啟/關閉的終端收益會大幅降低, 不過這正是違反家用閒置的邏輯

至少Salad sub reddit上沒什麼人發言, 有的也是在報怨收益降低, 然後選擇走人

基本上我是把上下文拉爆(日間Coding需要), 然後concurrency單純調1, 並沒有特別針對hermes做什麼特別優化 (也許研究一下會更好, 不過得要有空)

@tony-wang @rolex-lo

趁現在午休的時候跑了一下llama benchy

llama-benchy \
  --base-url "http://localhost:7380/v1" \
  --model "Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  --tokenizer "$HOME/vllm/models/sakamakismile/Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP" \
  --pp 2048 \
  --tg 480 \
  --depth 0 1000 5000 10000 20000 50000 100000 150000 200000 \    #(不同上下文長度)
  --latency-mode generation \
  --skip-coherence \
  --concurrency 1 \

Context Ladder

| model                                    |             test |               t/s |     peak t/s |         ttfr (ms) |      est_ppt (ms) |     e2e_ttft (ms) |
|:-----------------------------------------|-----------------:|------------------:|-------------:|------------------:|------------------:|------------------:|
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |           pp2048 | 7741.01 ± 1375.30 |              |    373.94 ± 54.49 |    274.26 ± 54.49 |    373.94 ± 54.49 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |            tg480 |      68.87 ± 6.65 | 81.33 ± 3.68 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   pp2048 @ d1000 |   8136.73 ± 32.84 |              |     474.32 ± 1.44 |     374.64 ± 1.44 |     474.32 ± 1.44 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |    tg480 @ d1000 |      67.73 ± 5.06 | 88.00 ± 5.72 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   pp2048 @ d5000 |   6615.23 ± 22.79 |              |    1165.21 ± 3.86 |    1065.53 ± 3.86 |    1165.21 ± 3.86 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |    tg480 @ d5000 |      72.92 ± 3.56 | 89.33 ± 3.77 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d10000 |   6008.73 ± 10.16 |              |    2104.88 ± 3.47 |    2005.20 ± 3.47 |    2104.88 ± 3.47 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d10000 |      65.25 ± 2.21 | 82.00 ± 4.32 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d20000 |    5152.21 ± 0.52 |              |    4379.13 ± 0.52 |    4279.45 ± 0.52 |    4380.19 ± 0.46 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d20000 |      70.45 ± 1.27 | 89.67 ± 0.47 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  pp2048 @ d50000 |    3690.36 ± 5.88 |              |  14203.66 ± 22.59 |  14103.98 ± 22.59 |  14205.86 ± 22.80 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |   tg480 @ d50000 |      67.03 ± 1.67 | 84.67 ± 0.47 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d100000 |    2528.58 ± 0.55 |              |   40457.51 ± 8.72 |   40357.83 ± 8.72 |   40461.50 ± 8.69 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d100000 |      60.96 ± 0.75 | 78.33 ± 3.68 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d150000 |    1922.36 ± 0.98 |              |  79194.84 ± 39.68 |  79095.17 ± 39.68 |  79201.49 ± 39.50 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d150000 |      62.53 ± 3.29 | 76.33 ± 1.89 |                   |                   |                   |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP | pp2048 @ d200000 |    1556.00 ± 0.99 |              | 129951.65 ± 82.49 | 129851.97 ± 82.49 | 129959.72 ± 82.53 |
| Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP |  tg480 @ d200000 |      59.58 ± 1.31 | 69.67 ± 1.70 |                   |                   |                   |

Token速度相當可用, 200K上下都能大約有60 tks

這個在國外叫Lenny face, 在中文應該有"你懂的"的意思

(͡ ͡° ͜ つ ͡͡°)

我有時會把主機的5090D放在Salad上, 不過發現連電費都蓋不了還是算了

認同GIGO的概念, 如果沒理解錯的話提到應該就是Naive RAG在應對錯誤資訊的痛處: 大學生在開書考試帶錯書了 希望這個比喻沒錯

但不太認同一棍子打掉所有RAG, 先不說RAG有分很多類型, 這裏說幾個比較常見的: FLARE, DRAGIN, Adaptive, Probing

Naive RAG自己也有不同的變種來增加搜索準確率吧, RRR (Rewrite-Retrieve-Read) 跟 RRF (Reciprocal Rank Fusion), 上面kop大提到的語意搜尋應該就是RRF中的語意搜尋 (Semantic Search) + 關鍵字搜索 (Lexical Search, BM25)吧?

我在目前測量公司弄的就是RRR

Naive RAG永遠只適合在陳述事實的場合, 也就是媽媽是女人, 或者沒什麽人知道的冷知識

因爲之前在幫忙架構RAGFlow, 所以有跑去研究了一下幾個不同設計方向的RAG, 基本上也是針對著Naive RAG不同方面進行改進 (何時檢索, 如何查)

框架	思路	優勝點
FLARE	按需觸發 ＋ 預測性查詢：僅在低置信度 token 時檢索，以「預測下一句」構造查詢	避免長生成過程中的無效檢索
DRAGIN	全域智慧決策：RIND 綜合評估不確定性／語義／上下文影響；QFS 基於完整歷史自注意力權重構建查詢	打破靜態規則與窄上下文限制
Adaptive	難度分級路由：分類器預判複雜度，動態分配「免檢索／單次／多步迭代」策略	解決「一刀切」帶來的計算浪費
Probing	內省式知識評估：隱藏狀態探針直讀 LLM 內部認知，判斷「是否已知情」	消除冗餘檢索與知識覆蓋衝突

最近好像也出了個Skill RAG, 不過我還沒去看Paper所以也不知道設計思路是什麽, 只在Twitter上知道是關於失敗後如何修復

---

無意引戰, 單純抛磚引玉 + 避免一刀切XXX沒用這種説法
技術 + 設計思路是需要時間成熟, 慢慢進步的

要知道Naive RAG已經是2023年的產物了, 當時還單純叫RR, Retrieve-Read 突然覺得時間飛得有點快

我倒是覺得大部份盈利都跑到Salad手上了

而且認真來說, 倒不如老老實實去那些能穩定提供算力的平台租借, 至少穩定性上比家用閒置好太多了

@CHIA-AN-YANG

OpenAI Compatible Proxy這個方式其實一直都有, Github上面也有很多Repo有做這件事

而我不是說方式本身, 是這個行為的動機, 因為OpenAI, Claude跟Google都明確在ToS裏面寫明不能把個人帳號 (公司跟團隊另計) 分給其他人用, 所以才說不要把這個Proxy給自己以外的人用就可以

應該會看到這些Proxy類的Repo都會先警告用戶有可能違反ToS和後果自負

不要被Gemini判定成過多請求這個就是各大廠商判定是否有把帳號分給其他人用的證據之一, 當然也有其他證據就是了

I believe it when I see it

不是說有什麼立場, 但是無論是大陸跟外國都太多PPT產品了, 開頭講到天花龍鳳然後最後翻車

沒有用家實際評測其實說到追到老黃也沒用

嘛, 不過有競爭者總是好事

N1X基本上就是DGX Spark拔掉ConnectX-7網卡, 而ConnectX-7也是被很多人詬病說發熱嚴重 (畢竟就是伺服器裏拔出來的)

DGX Spark本身就只是個實驗品, 給大學實驗室或者小團隊決定是否要用DGX H100伺服器, 然而Spark的強悍之處也就是用這個網卡聯接多部DGX Spark做成一個Cluster, 用Token速度換取大統一內存容量

如果質疑自己是否需要DGX Spark的話, 那百份之九十以上是不需要

更大參數的模型基本知識量會更多, 不過現在很多大參數的模型都在用MoE了, Deepseek自己也是Activation 49B

@Dijkstra

坊間大多數都780M宇宙啊

R7 7840系列
R9 7940系列
R7 87xx系列
R7 88xx系列
R7 89xx系列
R7 H25x, H26x跟H27x系列

這堆基本上就只是Zen 4移動端改名 + 廠家拉不同數量的PCIe插槽出來 (USB, M2之類的)

分別明顯就要上H3xx系列了

還是那句老話, AMD用腦做產品, 用脚做市場策略, 這個爛名字估計就是讓消費者搞不清楚自己到底買了什麽

@Tony-Wang

對, 就算是沒load也會固定在30%風扇, RTX Pro系列風扇都不可調

補一補圖, 今晚可能會發個文簡單講一下

@rolex-lo

這就是玩本地模型的醍醐味啊

我估計hermes到最後就變成數字分身了, 然後我的不多不少染上我自己一些不好的習慣, 直來直往的