把家裡的舊電腦串成一台 LLM 伺服器：distributed-llama 的實際代價
Distributed LLM inference. Connect home devices into a powerful cluster to accelerate LLM inference. More devices means faster inference.
秒懂
- 它是什麼？
- distributed-llama 把 tensor parallelism 搬到區域網路，讓多台家用裝置協同跑大型語言模型。這篇文章拆解它的節點架構、啟動指令、記憶體分配方式，以及那些文件沒明說的限制。
- 適合誰用？
- 如果你的目標是讓一台 8GB 記憶體的樹莓派或舊筆電跑 70B 模型，而且你手上剛好有 2、4 或 8 台同網段的機器，distributed-llama 是少數真正能用的開源方案。它不適合只有兩台異質裝置、想跑非 q40 量化、或需要 GPU 加速的人，因為節點數必須是 2 的冪次、量化格式只有 q40 配 q80 或 f32 配 f32，Vulkan 支援也還在實驗階段。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 72 天前。
- 用什麼語言寫的？
- 主要是 C++（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是記憶體牆，不是運算牆
單機跑大型語言模型，卡住的往往不是 CPU 不夠快，而是 RAM 裝不下權重。Llama 3.1 405B 的 q40 量化檔就要 238GB，這不是消費級主機板能插滿的容量。distributed-llama 的做法是把模型切成 slices，root node 負責載入權重並分送給 worker，每台機器只留自己那一塊。文件說 RAM 使用量會平均分散，但 root 會多耗一點，因為它還要同步整個網路的狀態。這代表你的瓶頸從「一台機器有多少記憶體」變成「整個區域網路加起來有多少」。對手上有一堆 8GB 樹莓派或舊筆電的人來說，這確實是把 70B 模型塞進家用環境的唯一務實路徑，而不是去買一張 48GB 的顯示卡。
Tensor parallelism 的代價：同步精度與網路延遲
它用的是 tensor parallelism，不是 pipeline parallelism。每一層的計算都被拆到所有節點上，所以每個 forward pass 都需要跨節點同步中間結果。文件特別提供 `--buffer-float-type` 參數，預設是 `q80`，也就是用 8-bit 定點數來傳遞同步資料。這是個關鍵取捨：用較低精度壓低網路流量，但可能會影響最終輸出的品質。如果你的模型是 f32 格式，那就只能配 f32 的 buffer，流量會暴增。Ethernet 的延遲在這裡是硬傷，10GbE 跟 1GbE 的體驗會差很多，但文件沒有給任何實測數字，只說需要「high-speed synchronization」。你可以把這理解成：它假設你的交換器不會掉封包，而且節點間的 ping 時間要非常低。
啟動流程比想像中簡單，但前提是模型得先轉好
最吸引人的部分是 `python launch.py` 一行指令。它會自動下載模型和 tokenizer，例如 `python launch.py llama3_3_70b_instruct_q40` 就會抓 40GB 的權重檔。這對不想碰轉檔細節的人很友善。但如果你要跑的文件清單以外的模型，就得走 `HOW_TO_CONVERT_HF_MODEL.md` 的手動流程，把 Hugging Face 的模型轉成 `.m` 格式。轉檔需要 Python 和 C++ compiler，這不是零門檻。啟動 root 節點時，你要用 `dllama inference --model <path> --tokenizer <path> --workers 10.0.0.2:9999 10.0.0.3:9999` 指定 worker 位址。worker 端只需 `dllama worker --host 0.0.0.0 --port 9999`，不需要知道模型長什麼樣子。這個設計讓 worker 可以無腦加入，但 root 的設定檔就會變得複雜，尤其當節點數超過 4 台時，位址列表會很長。
節點數的數學限制：2 的冪次與 KV heads 天花板
文件在 Known Limitations 寫得很清楚：你只能跑 1、2、4 直到 2^n 個節點。這不是軟體沒寫好，而是 tensor parallelism 的切分方式要求每一層都能均分成整數份。更麻煩的是，最大節點數等於模型的 KV heads 數量。KV heads 是 attention 機制裡負責快取的頭數，小型模型可能只有 8 或 16 個，這代表你就算有 32 台樹莓派，也只能拿其中 16 台來跑。實務上，這意味著你要先查模型的組態，再決定要買幾台機器。如果你想先加 3 台 worker 試試，那就是不行，系統會直接拒絕或算出錯誤結果。這個限制在 README 的第一頁就寫了，但很多人會忽略，等到架好四台機器才發現第五台加不進去。
量化格式的窄門：只有 q40 和 f32 兩條路
另一個容易被低估的限制是量化支援。文件列出的支援組合只有兩種：q40 模型配 q80 buffer，或是 f32 模型配 f32 buffer。q40 是 4-bit 量化，這讓 70B 模型能壓到 40GB，但它的品質損失比 q80 或 q60 明顯。如果你已經有習慣用的 GGUF 格式 q80 模型，抱歉，這裡不支援。你必須回頭找 q40 的來源，或自己用轉檔工具重轉。這在生態系裡是個孤島：Hugging Face 上主流是 GGUF 和 safetensors，q40 是這個專案自己定義的格式。文件有提供轉換指南，但那代表你每次想換模型都得經過一道編譯和轉檔的流程。對於只想快速測試的人，這會是第一個勸退點。
Vulkan 的 GPU 支援還是實驗品，CPU 才是主戰場
2025 年 3 月釋出的 v0.13.0 加入了 Vulkan 支援，新聞提到 Qwen 3 MoE 模型在 Vulkan 上可用，但標籤是「Experimental」。這代表 GPU 加速不是這專案的成熟路線。README 的效能最佳化描述集中在 ARM 和 x86_64 AVX2 CPU，也就是說，作者預設的使用場景是拿多顆 CPU 來堆算力，而不是拿 GPU 來加速。這跟 llama.cpp 的路線完全不同，後者對 CUDA 和 Metal 的支援已經很成熟。如果你手上有一張 RTX 4090，與其組叢集不如直接跑單機。distributed-llama 的價值在於那些沒有 GPU、只有一堆閒置 CPU 的家庭實驗室。Vulkan 支援看起來是為了讓樹莓派或內顯裝置能加減貢獻一點算力，但別把它當作可以取代顯示卡方案。
它跟 llama.cpp 的差別：單機最佳化 vs 網路分散
最直接的替代方案是 llama.cpp，它同樣用 C++ 寫、同樣支援多種量化、同樣能在 CPU 上跑。但 llama.cpp 的預設思維是單機最佳化，它把執行緒開滿、用 mmap 載入權重、盡量減少記憶體複製。distributed-llama 則是把單機的 tensor parallelism 搬到網路上，這帶來兩個後果。第一，它需要 root 節點做集中式同步，單一節點故障整個叢集就停擺。第二，它的同步 buffer 精度選項（q80 或 f32）直接影響網路頻寬需求，這是單機方案不會遇到的問題。如果你只有一台機器，llama.cpp 的成熟度和社群支援都遠勝過 distributed-llama。但如果你有 4 台 Mac Mini M4 Pro，每台 24GB RAM，llama.cpp 頂多讓你跑 14B 模型，而 distributed-llama 的討論區有人宣稱能跑 Llama 3.3 70B。這是質的差異，不是快慢的差異。
維護與升級：活躍但版本節奏不規律
最後一次 push 是 2026 年 7 月，最近的 release 是 v0.16.5（2026 年 2 月），顯示專案仍在維護。但版本間隔很跳：v0.16.3 到 v0.16.4 隔了三個月，v0.16.4 到 v0.16.5 只隔兩週。這代表你可以預期 API 會變動，例如 v0.12.0 做了一次 fundamental codebase refactor，那可能會破壞舊的啟動指令。授權是 MIT，這對商用或個人使用都很寬鬆，沒有 copyleft 包袱。升級成本主要體現在兩處：一是你得重新編譯所有節點的 binary，二是如果模型格式有變（像新增 Qwen 3 支援），舊的轉檔流程可能要調整。文件沒有提供自動更新機制，所以你得自己追 release notes。對於一個依賴多台機器同步的系統，版本不一致會導致無法預期的行為，這點在部署前就要有心理準備。
編輯結論
如果你的目標是讓一台 8GB 記憶體的樹莓派或舊筆電跑 70B 模型，而且你手上剛好有 2、4 或 8 台同網段的機器，distributed-llama 是少數真正能用的開源方案。它不適合只有兩台異質裝置、想跑非 q40 量化、或需要 GPU 加速的人，因為節點數必須是 2 的冪次、量化格式只有 q40 配 q80 或 f32 配 f32，Vulkan 支援也還在實驗階段。採用前先確認你的模型能轉成 q40，且所有裝置的 CPU 都支援 AVX2 或 ARM 指令集，然後用 launch.py 的單一指令先在一台機器上跑通，再加第二台驗證同步延遲是否可接受。
社群筆記