Parallax：用 Lattica P2P 把異質節點串成推論叢集
Parallax is a distributed model serving framework that lets you build your own AI cluster anywhere
秒懂
- 它是什麼？
- Parallax 是 Gradient 推出的分散式模型服務框架，目標是讓不同規格、不同地點的機器共同承載一個模型的推論。它的關鍵不在模型本身，而在節點之間怎麼連、模型怎麼切、請求怎麼導。
- 適合誰用？
- Parallax 適合手上已有多台異質機器、想把它們湊成一個推論端點，且願意自己處理節點連線與模型切分設定的團隊；若你只有單機單卡、或需要嚴格的延遲保證與成熟維運工具鏈，現在導入的摩擦成本會高於收益。動手前先確認三件事：install.sh 在你的平台與 Python 版本下能否走完、目標模型是否落在 README 列出的支援清單內、以及 Lattica 的 P2P 連線在你的網路環境中能否打通。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 77 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是「機器規格不一致」這個前提
多數推論框架預設你有一組同構的 GPU 機器，最好還在同一機房、同一網段。Parallax 的前提正好相反：README 寫的是讓使用者在「varying configuration and physical location」的節點上建立 AI 叢集。這個前提決定了它的設計取捨。它不追求把單卡吞吐推到極限，而是先解決節點之間能不能互相看見、模型能不能被拆到不同機器上、請求進來之後要往哪裡送。
目標使用者因此相當明確：手上有一堆規格不一的機器，可能是幾台不同世代的 GPU 主機加上幾台 Mac，想把它們當成一個服務端點來用。專案首頁列出的核心功能第一條就是「Host local LLM on personal devices」，這個定位比一般的 serving framework 更靠近個人或小團隊自建叢集的情境。
反過來說，如果你的機器本來就同構、放在同一個機櫃裡，Parallax 多出來的那層 P2P 與跨節點排程只會增加你要理解的東西，而不會帶來對應的好處。
三層後端分工：Lattica 連線、SGLang 與 vLLM 跑 GPU、MLX LM 跑 Mac
README 把後端架構拆成三塊，這個拆法本身就是理解 Parallax 的入口。P2P 通訊由 Lattica 負責，那是 GradientHQ 自己的另一個專案；GPU 後端交給 SGLang 與 vLLM；Mac 後端交給 MLX LM。也就是說，Parallax 本身並不做 attention kernel 或 KV cache 的底層實作，它做的是把這些既有引擎接起來，並在它們之上加一層跨節點的協調。
這個分工有實際後果。模型能不能跑，很大程度取決於底下引擎對該架構的支援程度；Parallax 的支援清單基本上是跟著 SGLang、vLLM 與 MLX LM 的進度走的。README 列的模型橫跨 DeepSeek、MiniMax、GLM、Kimi-K2、Qwen、gpt-oss、Step 幾個系列，其中不少是 MoE 或稀疏注意力架構，這類模型對切分策略比稠密模型敏感。
值得注意的是 Mac 路徑被單獨拉出來。README 提到「Paged KV cache management & continuous batching for Mac」，這意味著在 Mac 上不是只能跑單一請求的示範，而是有做批次與 KV 分頁管理。不過文件沒有說明這套 Mac 路徑與 GPU 路徑能否混在同一個叢集裡協同服務同一個模型，這點在評估時必須自己確認。
模型切分用管線平行，請求則靠動態排程與路由
README 列出的核心功能裡，「Pipeline parallel model sharding」講的是模型怎麼被拆。管線平行是把模型按層切成若干段，每一段放在不同節點上，前一段算完把中間結果往後傳。相對於張量平行需要節點之間高頻寬、低延遲的同步，管線平行對網路的要求寬鬆一些，這正好對應到「不同地點、不同規格」的節點這個前提：節點之間可能只有一般的廣域網路連線，不可能做每層的 all-reduce。
代價是管線氣泡。切得越細、節點越多，同一時間能填滿的計算就越少，除非有足夠的並行請求把管線餵飽。這也解釋了為什麼 Parallax 同時強調「Dynamic request scheduling and routing for high performance」：排程器要負責把進來的請求分配到管線的各個階段，讓每個節點盡量不要閒著。
這裡有個文件沒有回答的問題：管線切分的粒度與節點指派是自動決定還是需要人工設定，README 與 Quick Install 都沒有交代。在真正導入前，這是必須從 docs/user_guide 目錄下的文件確認的第一件事，因為它直接決定你要花多少時間在調參上。
安裝與啟動：從 install.sh 到 parallax serve
README 給的安裝流程很短，值得逐行看清楚。先 clone 倉庫、進目錄、執行 install.sh，再啟用虛擬環境，最後用 parallax serve 指定模型啟動：
git clone https://github.com/GradientHQ/parallax.git cd parallax ./install.sh source .venv/bin/activate parallax serve -m Qwen/Qwen3.5-0.8B
幾個可以從這幾行推出來的事實。install.sh 會建立一個名為 .venv 的虛擬環境，路徑固定在專案目錄下，所以啟動前必須 source .venv/bin/activate，否則 parallax 這個指令不在 PATH 上。模型是以 HuggingFace 風格的識別碼透過 -m 參數傳入，範例用的是 Qwen/Qwen3.5-0.8B，一個小到可以在單機上跑起來的模型，適合先驗證環境而不是驗證效能。
README 沒有在 Quick Install 段落裡示範多節點要怎麼加入同一個叢集，只給了單節點啟動的指令。多節點的設定方式應該在 docs/user_guide/install.md 與 quick_start.md 裡，但這兩份文件的内容不在我手上的材料中，因此無法說明具體的設定鍵或節點加入流程。若要評估跨節點部署，這兩個檔案是必讀的起點。
支援清單很長，但它不等於保證
README 的支援模型表列了七個系列，每個系列還掛著 HuggingFace collection 與官方部落格連結。這張表讀起來像是覆蓋率很高，但表格描述的多半是模型本身的特性，例如 MiniMax-M3 是稀疏注意力、Qwen3.6-35B-A3B 是 MoE、Step-3.5-Flash 每次只啟用部分參數。這些描述來自模型方的發布說明，不是 Parallax 對自身支援程度的承諾。
真正該問的是：這些模型在 Parallax 上是跑在 SGLang 路徑、vLLM 路徑還是 MLX 路徑？不同路徑能用的模型不一樣，能用的切分策略也不一樣。表格沒有標註這層對應關係。對於動輒百 B 參數的模型，能不能在你的節點組合上真的跑起來，取決於每一段管線是否塞得進對應節點的記憶體，這件事表格幫不上忙。
還有一個容易被忽略的訊號：專案最近的版本號是 v0.1.2，發佈於 2025 年 12 月，前一個版本 v0.1.1 相隔不到一週，再前一個 v0.1.0 在 11 月。三個版本集中在一個月內，說明這仍是一個快速變動的早期專案，介面與設定檔格式在升級時出現破壞性變更的機率不低。
什麼情況下它會是錯的工具
第一種情況是單機單卡。Parallax 的價值來自跨節點協調，如果模型本來就塞得進一張卡，直接用 vLLM 或 SGLang 啟動會少掉一層 P2P 與排程的複雜度，而且能拿到這些引擎原生的完整功能與社群支援。
第二種情況是對延遲有硬性要求。管線平行天生有氣泡，跨廣域網路的節點之間每一段中間結果都要傳輸，這個延遲不是排程器能消掉的。README 沒有提供任何延遲或吞吐的數字，因此無法判斷它在什麼規模下才划算，但如果你的服務有明確的 p99 目標，跨地點的管線平行很難給出保證。
第三種情況是維運能力有限的團隊。Parallax 依賴 Lattica 做 P2P 連線，這意味著你的網路環境要允許節點之間建立連線，NAT 穿透、防火牆規則、憑證管理都會落到你頭上。README 沒有描述這些面向，但從架構上來說它們無法迴避。
最後一種是只想找一個現成 API 服務的人。Parallax 要你自己準備硬體、自己跑 install.sh、自己處理節點加入，它不是託管服務。
與直接使用 SGLang 或 vLLM 的差別在哪
最直接的替代方案就是 Parallax 底下那兩套引擎本身。SGLang 與 vLLM 都是成熟的推論伺服器，各自有完整的連續批次、KV cache 管理與 OpenAI 相容 API。Parallax 並沒有取代它們，README 明說 GPU 後端就是由這兩者驅動。差別在於部署拓撲：SGLang 與 vLLM 的分散式能力主要建立在張量平行與管線平行之上，而且預設節點之間有高速互連，通常是在同一台機器內的多卡或同一機房內的多機。
Parallax 換掉的是這個前提。它透過 Lattica 建立 P2P 連線，讓節點不需要共享同一個網路平面，代價是把通訊、節點發現、容錯這些問題從引擎層拉到框架層。這也意味著如果你已經在同機房內用 vLLM 跑得很順，改用 Parallax 不會讓你更快，只會讓你多一層要除錯的東西。
另一個方向是 Ray Serve 這類通用分散式服務框架。它同樣能做跨節點部署與請求路由，但抽象層級更高，不會替你決定模型怎麼切。Parallax 在模型切分與 Mac 後端上做得更具體，這是它的差異點，也是它綁定特定引擎的原因。
授權、升級成本與導入前該驗證的事
專案採用 Apache-2.0，這是一個寬鬆授權，允許商用與修改，通常只需要保留著作權聲明與授權條文。但 Parallax 不是單一元件：它依賴 Lattica 做 P2P、依賴 SGLang 與 vLLM 做 GPU 後端、依賴 MLX LM 做 Mac 後端，這些依賴各自的授權條款需要分別確認，Apache-2.0 只涵蓋 Parallax 本身的程式碼。這裡不構成法律意見，實際條款以各倉庫的 LICENSE 檔案為準。
升級成本方面，v0.1.x 的版本節奏顯示 API 與設定還在變動。由於安裝腳本會建立專案內的 .venv，最保險的做法是每個版本用獨立的虛擬環境，避免升級時把前一版的依賴覆蓋掉。多節點部署還牽涉到所有節點上的版本必須一致，否則節點之間的通訊協定可能對不上，而 README 沒有描述版本相容性政策。
導入前值得先驗證的具體項目有三個。第一，install.sh 在目標平台的 Python 版本下能否順利完成，這是最容易卡住的一步。第二，目標模型是否真的在支援清單內，且對應到你打算使用的後端路徑。第三，節點之間的 Lattica 連線能否建立，這一項在跨網路環境下最不確定，也最難在事後補救。
編輯結論
Parallax 適合手上已有多台異質機器、想把它們湊成一個推論端點，且願意自己處理節點連線與模型切分設定的團隊；若你只有單機單卡、或需要嚴格的延遲保證與成熟維運工具鏈，現在導入的摩擦成本會高於收益。動手前先確認三件事：install.sh 在你的平台與 Python 版本下能否走完、目標模型是否落在 README 列出的支援清單內、以及 Lattica 的 P2P 連線在你的網路環境中能否打通。這三項任一不通，後面的排程與批次機制都無從驗證。
社群筆記