昨天最後一句是「而我剛好有第二台」。Day 3 畫拓撲圖的時候，那條 QSFP28 直連線旁邊寫著「已鋪好路等通車」，當時第二台 Spark 才剛歸隊，還沒進叢集。今天正式把雙機的設定與操作說清楚。
其實從 Day 21 開始，這個系列就已經在跑雙機了。那天三個 agent 一起打的 DeepSeek-V4-Flash-0731，背後就是兩台機器合力跑的 vLLM 張量平行（TP=2）。所謂張量平行，簡單說就是把模型每一層的權重切成兩半，分別放在兩台機器上，每算完一層就交換一次結果。昨天 hermes 吃掉 113 GiB 的那個「雙機叢集」也是它。前面為了敘事順序沒有點破，今天補上完整的故事。
兩台機器有兩種用法，今天兩種都測。
文章中間還會穿插兩場回歸戰。第一場檢驗 IFA 新版 vLLM 宣稱的 1.4 倍到底有沒有這回事，第二場看看 Day 10 那位跟我搏過感情的 TensorRT-LLM，在雙機場景下表現如何。
先交代硬體。兩台的 NVIDIA ConnectX-7 網卡直接對接，線材是價位新台幣五百多元的 QSFP28 DAC 銅線，跑 100GbE。手邊沒有多的預算，所以一直沒升級到 QSFP56。ethtool 兩端都回報 100000Mb/s、Direct Attach Copper。
| 測試 | 結果 |
|---|---|
| iperf3 單流（30 秒） | 43.1 Gbps |
iperf3 多流（-P 8，30 秒） |
99.0 Gbps |
| iperf3 對照組（10GbE LAN） | 9.41 Gbps |
| 往返延遲（ICMP，200 次） | min 0.141 / avg 0.833 / max 1.592 / mdev 0.383 ms |
| NCCL all-reduce 頻寬（2 GiB，nccl-tests） | 12.18 GB/s |
| RDMA 是否啟用 | 是，走 RoCE v2，不是純 TCP |
先解釋兩個名詞。RDMA 讓網卡直接讀寫對方機器的記憶體，不必經過作業系統的 TCP 堆疊。RoCE v2 則是在一般乙太網路上跑 RDMA 的做法，跟 InfiniBand 是不同的實作。
RDMA 那格這次終於有實證資料。過去每次跑都用 NCCL_DEBUG=WARN，全機找不到任何一行可以引用的傳輸層訊息，只能從頻寬比值反推。這次改成 INFO，日誌直接寫明走的是 RoCE。
NCCL INFO NET/IB : Using [0]rocep1s0f1:1/RoCE [RO]; OOB enp1s0f1np1:192.168.100.1<0>
NCCL INFO Using network IB
NCCL INFO Channel 00/0 : 1[0] -> 0[0] [receive] via NET/IB/0
同一張卡、同一條線，只把 NCCL_IB_DISABLE 改成 1，同一行就變成 NET/Socket，2 GiB 的 busbw 從 12.18 GB/s 掉到 2.16 GB/s，差 5.64 倍。ibv_devinfo 四個埠的 link_layer 全是 Ethernet，確認是 RoCE 而非 InfiniBand。另外提醒 NCCL_IB_HCA 一定要帶 port（寫成 rocep1s0f1:1），因為 socket-direct 會冒出第二個 ACTIVE 裝置當誘餌。
這些數字代表什麼?
12.18 GB/s 已經是 100GbE 線速（12.5 GB/s）的 97.4%，線材沒有拖後腿。不過這台機器的記憶體頻寬是 273 GB/s，兩者差了 22 倍。乍看之下網路慢很多，實際上不構成問題。TP=2 每一層前向要做一次 all-reduce，每個 token 每層的通訊量大約 10 KB，跟每個 token 要掃過的幾十 GB 權重相比微不足道，真正的瓶頸在記憶體頻寬。
這也解釋了 8 月 18 日那次雙機實測（Qwen3.8-27B-FP8，數字一直放在本機筆記裡）看似違反通則的結果。跨機 TP=2 拿到 1.83 倍，原因在於權重拆到兩台之後，每台每個 token 只需要掃一半。
延遲那格有個容易讀錯的地方。CX7 與 10GbE 的 ICMP 平均值幾乎相同（0.833 對 0.843 ms），差別在最小值（0.141 對 0.217 ms）。平均值被主機排程主導，反映的並非線路特性，引用時請看 min。
要跑雙機，除了有 NVIDIA 的 spark-vllm recipe，也有我目前實際跑的 ghcr.io/anemll/dspark-vllm-gx10:0.1.1（anemll / MiaAI-Lab 配方），vLLM 版本 0.25.2.dev0+g752a3a504.d20260714，用 vLLM 內建的 mp 多節點 executor，不需要 Ray。NVIDIA 這次在 IFA 新發表的 Sync cluster assistant 是另一條路，本機沒有採用，之後會再測試一遍。
以下用 Spark 1 與 Spark 2 稱呼兩台。
8008
--headless 啟動，不開任何 HTTP 埠--master-addr 192.168.100.1 --master-port 25000 對接，NCCL 綁在 enp1s0f1np1 上模型是 DeepSeek-V4-Flash-0731（官方 checkpoint 9e165c30…，48 個 shard）。量化格式我原本以為只有一種，筆記裡一直寫成「NVFP4 那套」，實測是兩種各佔一半。
quantization=deepseek_v4_fp8，E4M3、128×128 區塊、UE8M0 scale、動態啟動值，計算 dtype 是 bfloat16。checkpoint 的 config.json 裡只有 quant_method: fp8，沒有 hf_quant_config.json。kv_cache_dtype=nvfp4_ds_mla。正確的說法應該是「權重 FP8、KV NVFP4」，兩台各扛一半。
啟動很慢，昨天提過一次。今天這輪 03:14:01 起、03:52:58 KV 就緒，38 分 55 秒，「40 分鐘」這個說法站得住。記憶體方面每台權重 79.17 GiB、KV 池 16.99 GiB 可放 2,500,393 token，gpu-memory-utilization 設 0.835，兩台分別剩 8.6 與 7.5 GiB。
補充一點，KV 池這個數字每次重啟都會漂。Day 21 那輪是 2,478,130、9 月 2 日那輪 2,702,825、今天 2,500,393。同一組參數、同一份 checkpoint，差別來自載入當下的記憶體碎裂與 profiling 峰值。它並非模型的固有屬性，引用時要標明是哪一輪。
合體最大的意義在於不必付 2-bit 的品質稅。Day 17 講過 ds4 用 2-bit imatrix 把同一款 DeepSeek-V4-Flash 壓到 80.76 GiB 塞進單台，那是為了裝得下付出的代價。雙機讓它以 FP8 權重跑。兩條路徑並排比較，同一天、同一支腳本、同一份語料。
| ds4-server 單機 2-bit | vLLM 雙機 TP=2 | 差距 | |
|---|---|---|---|
| 量化 | IQ2_XXS 基底 + w2Q2K + AProjQ8 + SExpQ8 + OutQ8，imatrix，80.76 GiB | 權重 block-FP8 E4M3 + KV NVFP4-MLA，每台 79.17 GiB | |
| decode 單請求 | 17.24 t/s（離散 0.28%） | 42.14 t/s（離散 28.18%） | 2.44× |
| prefill pp2048 | 817.4 t/s | 1,729.1 t/s | 2.12× |
| prefill pp8192 | 801.0 t/s | 1,816.9 t/s | 2.27× |
| 考卷 繁中十題 | 20/20 | 20/20 | 打平 |
| 考卷 工具十輪 | 10/10 | 10/10 | 打平 |
| 考卷 多步 agent | 2/3 | 3/3 | vLLM 勝 |
| 考卷 JSON 緊湊度 | 單行 0/10，平均 64 字元 | 單行 10/10，平均 51 字元 | vLLM 完勝 |
| 工具 schema 合法性（20 題重放真實 hermes body） | 17/17，路由 19/20 | 17/17，路由 19/20 | 打平 |
| 同一批 20 題的牆鐘 | 202.6 秒 | 68.7 秒 | 2.95× |
| 繁中 PPL（Day 12 語料，142 chunk） | 16.6126 ± 0.2657 | 14.6232 ± 0.6089 | 2-bit 高 13.6% |
| 英文 PPL（wikitext-2，561 chunk） | 7.3706 ± 0.0560 | 5.3559 ± 0.1256 | 2-bit 高 37.6% |
| 平行處理 8 總吞吐 | 18.01 t/s（單請求中位 3.71） | 94.72 t/s（單請求中位 12.46） | 5.26× |
| 投機解碼接受率 | 有 --dspark，生產設定下不觸發 |
35.8%（本組 bench，Day 21 真實 agent 負載是 46.1%） |
先看結論。雙機在每一個維度都沒有輸，而且在最能拉開差距的三格大勝。速度 2.4 倍，平行處理 5.3 倍，PPL 上 2-bit 付的代價英文 37.6%、繁中 13.6%。
「考卷持平」這件事也值得寫，而且要寫對。前三項在現代模型上早已飽和（考卷自己的 README 就這麼說），真正有鑑別度的在 JSON 緊湊度那一格，0/10 對 10/10。2-bit 那款每一輪都吐出 pretty-print 的多行 JSON，還常常包在 ```json 圍籬裡，平均輸出 64 字元對 51 字元。在 agent 迴圈裡，這些多出來的字元每一回合都要付 token。換句話說，imatrix 撐住了知識與格式合法性，撐不住的是「照要求的形狀輸出」。
投機解碼（先用小模型猜幾個 token，再由大模型一次驗證）那格我原本以為 ds4-server 沒有，實際上有，但在生產設定下是死的。--dspark 選項存在，support GGUF 也在本機（5.58 GiB，stages=3 block=5 markov_rank=256），可是三件事讓它不會被觸發。第一，--batched-session > 0 會直接關掉整條投機路徑，而 ds4-up.sh 預設就是 2（給 0 會被 parser 拒絕，要關必須整個省略旗標）。第二，取樣一開就完全不提案，spec enter 是 0 行，屬於沒觸發，跟接受率高低無關。第三，就算全程貪婪也只有 1.06 倍。對照之下 vLLM 用 draft_sample_method: probabilistic，在機率取樣下照樣提案，實測接受率 35.8%，逐位置接受數 648 / 428 / 251 / 141 / 72（草稿 861 次）。同一個名字、同一種 support 模型概念，一邊在生產路徑上是死的，一邊是活的。
先解釋 PPL。Perplexity 衡量的是模型「看到一段文字有多驚訝」，數字越低代表模型越熟悉這類文字，常用來比較量化前後的品質損失。
原本以為做不成，因為 ds4-server 沒有 /tokenize，而且 logprobs、prompt_logprobs、echo 三個欄位全部靜默忽略，照樣回 200，只是回應裡沒有那些欄位。HTTP 這條路在它身上走不通。
救回來的是另一條路。GGUF 的 general.architecture 是 deepseek4，本機的 llama.cpp 認得這個架構，llama-perplexity 直接載得動這個混階量化。關鍵在於兩條路徑切出來的 chunk 數完全相同（繁中 142、英文 561），代表 vLLM 的 deepseek_v4 tokenizer 與 GGUF 內建 tokenizer 一致，兩個數字可以並排。計分視窗也對齊（都從 n_ctx/2 = 256 起算）。
三個閱讀提醒。
還有一個舊結論沒有重現。Day 12 在 Qwen3.8-27B 上量到「繁中在 4 位元付的代價是英文的 1.67 到 2.00 倍」，這次方向相反。不同模型、不同量化家族、不同位元深度，不能說 Day 12 錯了，但那條結論不會自動外推。
第一次跑 ds4 的考卷，繁中 13/20、工具 8/10，十題裡有六題回空字串。這是測試假象。ds4-server 把 chat_template_kwargs.enable_thinking 靜默忽略，思考預設是開的，內容跑進 reasoning_content 欄位，而考卷的 max_tokens 只有 300，光思考就吃掉 417 token。正確的開關寫在 --help thinking 裡，think: false 或 thinking: {"type":"disabled"}。換上去之後繁中回到 20/20、工具 10/10。
更難察覺的是第二層。空字串會讓「純繁體」那項自動通過。第一次那輪報的「純繁體 10/10」，其實只有四題真的被檢查過。評分器拿到空字串時應該報錯，而非給分。
我本來想用「同一款模型、同一個量化版本，單機對雙機」直接量通訊稅，但這條路在這款模型上不存在。DeepSeek-V4-Flash 的 FP8 權重總共約 158 GiB，單機裝不下，沒有對照組。
能講的只有舊數字。8 月 18 日那次 Qwen3.8-27B-FP8 雙機實測，單機 TP=1 是 8.08 t/s，跨機 TP=2 是 14.80 t/s。理想的 TP=2 應該是 2.00 倍，實測 1.83 倍，差的那 8.5% 就是通訊加上不完美平行的總和。今天的 NCCL 數字讓這 8.5% 有了對照，每層 all-reduce 約 10 KB，在 12.18 GB/s 之下是微秒等級。所以那 8.5% 大部分來自同步與尾端效應，網路佔的比例很小。
先把原文找出來。NVIDIA 官方部落格（2026-09-03，IFA）寫道
New XQA attention kernels in FlashInfer and backend optimizations help to accelerate inference across both platforms. vLLM delivers 1.2x on RTX PRO 6000 Blackwell Workstation Edition and up to 1.4x on two DGX Spark clusters.
這句話缺了很多東西。沒有模型、沒有量化、沒有平行度、沒有輸入輸出長度、沒有基準版本、沒有註腳。唯一的線索是歸因，XQA 是 FlashInfer v0.6.16（2026-07-31）引進的 decode attention kernel，涵蓋 attention sink、sliding-window 與投機解碼的 ragged Q。
接著是一個做不到的實驗。DeepSeek-V4-Flash 沒辦法「只換容器」，因為 ghcr.io/anemll/dspark-vllm-gx10 只有 0.1.0 與 0.1.1 兩個 tag，而這套雙機配方靠十幾個 hotfix 直接改容器內的 dist-packages/vllm，換掉映像等於換掉整套配方。
所以改用一組真的可以只換容器的，Qwen3.8-27B-FP8 雙機 TP=2，同一組參數、同一支腳本，兩台的 image ID 事先比對過相同。
服役中的版本 muse-glimmer |
上游 nightly（2026-09-07） | 倍率 | |
|---|---|---|---|
| vLLM | 0.26.1rc1.dev608+g99a10304d | 0.28.1rc1.dev472+gd9105ea80 | |
| FlashInfer | 0.6.16.post3 | 0.6.18 | |
| decode 單請求 | 14.23 t/s（離散 0.66%） | 14.26 t/s（離散 0.26%） | 1.00× |
| prefill pp2048 | 2,436.6 t/s | 2,473.0 t/s | 1.01× |
| prefill pp8192 | 2,535.7 t/s | 2,457.3 t/s | 0.97× |
| 平行處理 8 總吞吐 | 101.08 t/s | 100.98 t/s | 1.00× |
| KV 池 | 2,022,741 token | 2,170,880 token | 1.07× |
| 啟動時間 | 6 分 12 秒 | 6 分 42 秒 | 1.08× |
1.4 倍沒有落在這個工作負載的任何一格。唯一真的變好的是 KV 池，多 7.3%。
這並非「NVIDIA 灌水」，比較像口徑問題，而且可以解釋。XQA 針對的三個東西是 attention sink、sliding-window、投機解碼的 ragged Q，而這組對照是密集 FP8、沒有投機解碼、沒有滑動窗，三個目標一個都沒碰到。真要看到 1.4 倍，得找一款同時開投機解碼與滑動窗的模型。
這是 Day 24 那篇的續集。Day 24 問的是「倍率的分母是什麼」，這次問的是「倍率的工作負載是什麼」。沒有工作負載的倍率，沒辦法拿來預測你自己的工作負載。
昨天 zh-writer 被註解掉，因為單機養不起兩款模型。雙機分工的配置如下。
| 位置 | 服務 | 埠 | 大小 |
|---|---|---|---|
| Spark 1 | ds4-server DeepSeek-V4-Flash 2-bit | 8000 | 80.76 GiB |
| Spark 2 | Ornith-1.5-35B-A3B-NVFP4 單機 vLLM（TP=1） | 8007 | 22 GiB |
| Spark 2 | zh-writer q8_0 llama-server | 8080 | 27.05 GiB |
閘道 /health 回 healthy 4 / unhealthy 0，四個別名、三個後端，跨兩台機器。Day 26 那個問題解了。
兩種模式並排比較。
| 合體 | 分工 | |
|---|---|---|
| 同時活著的模型數 | 1 | 3 |
| 主力模型品質 | 權重 FP8 級 | 2-bit 級 |
| 主力模型 KV 池 | 2,500,393 token | ds4 的磁碟 KV，另一種哲學 |
| 平行處理服務能力 | 平行處理 8 總吞吐 94.72 t/s | ds4 平行處理 8 只有 18.01 t/s，其餘由 Spark 2 承擔 |
| 第二台的餘裕 | 7.5 GiB | 30 GiB，還放得下新面孔 |
| 單點故障 | 任一台掛，主力全掛 | 各自獨立 |
| 切換成本 | 改配置要重載 40 分鐘 | 各自重載互不影響 |
代價可以從品質稅那張表直接引。主力從 42.14 掉到 17.24 t/s，平行處理 8 從 94.72 掉到 18.01 t/s，繁中 PPL 從 14.62 升到 16.61。換句話說，分工換來的第三款模型，是拿主力的 2.4 倍速度與 5.3 倍平行處理換的。
分工模式上線後我用 max_tokens: 60 打四個別名，三個回空字串。原因還是思考吃光了輸出預算。ds4-server 與 Ornith 都預設開思考，而 LiteLLM 不轉發 reasoning 欄位，於是 token 花掉了、內容不見了、日誌毫無線索。放大到 800 之後四個都正常。
這跟前面考卷的假象是同一件事的兩個現場。這台機器上「回空字串」幾乎永遠與模型無關，問題出在 token 輸出預算。
Day 10 它在單機上拿到 42.5% 的 decode 達成率，prefill 贏 77%，KV 只有 vLLM 的十幾分之一。今天問兩個問題，新版有沒有進步，以及它有沒有雙機能力。
nvcr.io/nvidia/tensorrt-llm/release 匿名 tag 清單 488 筆，跟 sm_121 有關的只有三個，spark-single-gpu-dev、1.2.1（最新穩定）、1.3.0rc9（最新 RC）。那個 spark tag 的 config digest 是 sha256:474ca9e2e7b2…，跟 Day 10 用的 image ID 一模一樣，自 Day 10 以來沒有重建過。
1.2.1 與 1.3.0rc9 的映像 config 完全一致。CUDA_VERSION=13.1.0.036、CUDA_DRIVER_VERSION=590.44.01、CUDA_ARCH_LIST=8.0 8.6 9.0 10.0 11.0 12.0，仍然沒有 12.1。
我上次的結論是「1.2.1 要求驅動 590.44，本機 580.173，直接出局」。那個結論是讀標籤讀出來的，而它是錯的。實測 1.3.0rc9 在本機驅動 580.173.02 上完全跑得起來。
nvidia-smi NVIDIA GB10, 580.173.02
/usr/local/cuda/compat/ 存在（映像自帶 cuda-compat）
torch 2.10.0a0+b4e4ee81d3.nv25.12 cuda available: True
capability (12, 1)
matmul 通過
tensorrt_llm 1.3.0rc9 import 成功
CUDA_DRIVER_VERSION 只是資訊標籤，真正的執行期檢查是 NVIDIA_REQUIRE_CUDA=cuda>=9.0，而映像自己帶了 cuda-compat 把門檻墊過去。這跟 Day 17 那次「help 印得出來不代表 parser 收得下」是同一種錯誤的鏡像，這次是「標籤寫得出來不代表真的擋你」。
設定逐項對齊，gpt-oss-120b、max_seq_len 32768、max_batch_size 32、max_num_tokens 2048、free_gpu_memory_fraction 0.85（Day 10 的文章曾經誤寫為 0.7）。
| Day 10（1.1.0rc3） | 今天（1.3.0rc9） | 變化 | |
|---|---|---|---|
| decode 達成率（天花板 75.96 t/s） | 42.5%（32.30 t/s） | 42.3%（32.10 t/s） | 持平 |
| 單請求 pp2048 | 4,911.91 t/s | 4,824.81 t/s | 0.98× |
| prefill pp8192 | 6,278.27 t/s | 5,844.73 t/s | 0.93× |
| KV 容量（32K 設定） | 48,480 token | 40,256 token | 0.83× |
| fp8 KV | 被 FMHA 擋下 | 仍被擋下，但換了一道牆 | |
| 滑動窗分流 | 沒有 | 仍然沒有（單一 window size=32768 池） |
|
| KV 事件稽核 | /kv_cache_events 回 [] |
修好了（139 筆事件、stored_blocks 有值） |
|
| 雙機 | 不適用 | 官方明說只有 single-node DGX Spark beta |
做完的感想是，「跟預設值搏感情」那句話原封不動，隔了兩個大版本，三個速度指標全在誤差內，KV 反而少了 17%，prefill 那個原本最有說服力的優勢還退了 7%。sm_121 這次靠的已經不是 Day 10 那條 flashinfer JIT 路徑（1.3.0rc9 全程沒印 Prebuilt kernels not found，attention backend 是 TRTLLM），機制換了，結果沒變。
fp8 KV 唯一的變化是錯誤訊息。Day 10 是 KV cache data type e4m3 is not the same as input data type bf16，今天變成
Assertion failed: FMHA kernels are not found with these parameters:
S : 0 D : 64 DV : 64 AttentionMaskType : 2 ...
dtype 檢查那道牆拆掉了，往前走一步之後發現沒有對應的 kernel。從「不讓你試」變成「讓你試了才發現沒有」，對使用者來說是同一件事。
唯一真的修好的是可觀測性。Day 10 那三個永遠回空陣列的稽核端點，現在 /kv_cache_events 真的會吐事件了。這對「快取到底有沒有命中」這類問題有用。
多節點方面不必實測就有答案。官方 release notes 明寫 1.2 加入的是 "beta support for single-node DGX Spark"，多節點只在 GB300 上驗證過。它目前的雙機能力是零，而這本身就是結論的一部分。
合體買的是單款模型的品質上限、KV 池與平行處理。2.44 倍 decode、5.26 倍平行處理 8 吞吐、繁中 PPL 少 13.6%、英文少 37.6%。分工買的是多模型共存與獨立性。三款模型同時活著、第二台還留 30 GiB、任一台重載不影響另一台。
以我自己的用法來說，日常主力是 DeepSeek-V4-Flash，而且 hermes 的 agent 負載吃平行處理，那 5.26 倍是每天感受得到的差距，合體是對的。但微調實驗與新模型試用需要第二台的獨立空間，Day 26 那個「zh-writer 只能被註解掉」的窘境會反覆發生。所以真實答案大概是「平日合體，實驗日分工」，代價是每次切換 40 分鐘，一個月切個四次就是快三小時。
這也把問題推向 Day 29 的成本篇。第二台 Spark 的錢到底買到什麼。今天的資料給了一個具體的答案。買到的東西可以是「一個 2.44 倍的主力」，也可以是「三款模型同時活著」，兩者只能選一個，每次改選要花 40 分鐘。
順帶提 IFA 的另一條消息。NVIDIA PAIR 這個跨 PC 的個人 AI 路由器明說支援 Spark，等於是把桌機那兩張卡也拉進來的第三種用法。要先講清楚的是，它跟今天測的東西屬於不同層次。PAIR 把獨立的請求路由到不同機器，不會合併顯示記憶體，也不會把一款模型切開。所以它解的是「多款模型多個請求」那一面，「單機裝不下」那一面它管不到，這部分會在之後的番外篇說明。
硬體篇打完收工，明天進維運週。Day 24 那個「起跑溫度決定看門狗程式中止」的熱浸透發現、Day 25 那次因為把機器操太兇結果整台停擺只剩 ping 的記憶體 OOM、Day 17 埋的 ds4 磁碟 KV 對 SSD 寫入壽命的影響究竟為何，以及雙機叢集的監控與功耗實測，全部在 Day 28 一次見真章。
我們 Day 28 見。
（單位體例同 Day 26，記憶體與檔案大小沿用工具回報的 GiB，網路吞吐為 Gbps 與 GB/s 的十進位口徑。KV 池 token 數以該輪啟動日誌為準。）
Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理
Day 6｜llama.cpp、vLLM、TensorRT-LLM 、Ollama、DS4 與 Unsloth 的定位與取捨
Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程
Day 8｜llama.cpp 實測：先定量尺與 SOP
Day 9｜vLLM 實測：官方容器、同時處理吞吐曲線，與剛出爐的新模型 Ornith 1.5
Day 10｜TensorRT-LLM 實測：我花了一個下午，跟它的預設值搏感情
Day 11｜地端 AI 三大推論引擎綜合評測，同場加映神秘嘉賓
Day 12｜量化格式解析：「4-bit」兩個字，古今多少事 ? 都付笑談中
Day 13｜Perplexity 把整套 Agent 搬上 DGX Spark：地端元年的官方背書
Day 14｜Qwen3.8-27B 與 Flash-Next 加碼實測：地端模型世代對決與落地評估
Day 15｜Ornith 1.5 實測：為 AI agent 而生的 35B-A3B
Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型
Day 17｜ds4 深度解析：Redis 之父只為一種模型造了一個引擎
Day 18｜OpenAI 相容 API 層：地端 AI 多模型常駐好助手
Day 19｜地端 agent 框架總覽：它們到底對你的端點做了什麼呢?
Day 20｜DeepSeek Harness 實戰：21 萬款星的外掛式 harness 接上地端
Day 21｜herdr 是地端 AI 同時跑多個 AI agent 的最佳解
Day 22｜語意錨點對上 prefix cache，FreeToken VS vLLM，以及三個關於統一記憶體的教訓
Day 23｜ComfyUI 部署與 NFS 模型庫整合：把集中管理的哲學帶進生圖世界
Day 24｜MiniMax-H3 地端影片生成：h3-ui 與四步蒸餾版的三段對決
Day 25｜Unsloth 微調實戰：教一款模型用繁體中文思考，並遵守台灣的編輯規範
Day 26｜微調的最後一哩路：合併、轉檔、量化、上線
Day 27｜雙 DGX Spark GB10 合體與分工合作的部署與實測
iThome鐵人賽
看影片追技術