單張 RK182X 算力卡有明確的容量上限：模型必須放進本卡記憶體，而且每個 Token 都得經過同一顆晶片。級聯架構把這道天花板打開 —— 將 Transformer 依 Decoder 層連續切分成若干段（Segment），每段落在獨立的一張卡上，由 Host 統一調度整條鏈。容量隨卡數成長；卡與卡之間只傳 中間特徵（Hidden States），模型權重始終留在各自的卡上。
一台 Host、最多 4 張算力卡、本地跑到 27B 模型級 —— 不出內網、不上雲，前端裝置也不必重新架構。
三項彼此獨立的效益，而且都在同一套 Host 平台上實現。
容量不再受一張卡的本地記憶體限制。把 Decoder 堆疊切分到 2 張或 4 張裝置上，實際可用上限就能從小模型級抬到 27B 級，而且全程留在本地。
長輸入依 Bucket 拆分後沿分段鏈流水處理：第 N 段在做第 k 個 Bucket 時，第 N−1 段已經在處理第 k+1 個。長 Prompt 的吞吐是疊加上來的，而不是排在單張卡後面等。
PCIe 獨立直連、PCIe Switch 擴充、USB 3.0 HUB 共享，依可用介面、機箱空間與 BOM 來選。三種拓撲用的是同一套分段模型與同一套 Runtime 介面。
Host 統一編排，每張卡負責 Decoder 堆疊中連續的一段。
分詞器與詞向量映射跑在 Host CPU 上，文字先轉 Token ID，再轉詞向量。
裝置探索、分段調度、Bucket 佇列都在 Host 端。哪一段在哪張卡上跑、依什麼順序跑，由 Host 決定。
卡 0 執行 Decoder 層 0..k，把中間特徵交給卡 1 繼續算 k+1..m，依此傳遞到末段。
末段承載尾端 Decoder 層加上 Final Norm 與 LM Head，Logits 回到 Host 取樣，Decode 迴圈繼續。
調度規則：stage_count = 分段數，且 可用裝置數 ≥ stage_count。中間特徵經 Host 端傳遞；模型權重常駐各自卡上，不在鏈路上搬運。
三種接入承載同一套分段模型與同一套 Runtime 介面 —— 依介面數量、機箱空間與 BOM 做選擇。
| 接入方式 | 上行頻寬 | 佔用 Host 介面 | 適用場景 |
|---|---|---|---|
| PCIe 獨立直連（每卡一路） | PCIe 2.0 x1 × N | N | Host 還有餘裕的 PCIe 通道，而且希望拓撲最單純 —— 不要 Switch、不要 HUB、不共用匯流排。 |
| PCIe Switch 擴充 | PCIe 2.0 x1 / PCIe 3.0 x4 | 1 | Host 的 PCIe 通道吃緊。上行只佔一路，Switch 負責把頻寬獨立分給每張卡。 |
| USB 3.0 HUB 擴充 | USB 3.0 × 1 (shared) | 1 | 整合最快，也適合改造既有設備。4 張卡共用一個 USB 3.0 HUB。 |
參考平台實測顯示：長輸入 Prefill 場景下 PCIe 與 USB 3.0 差距在幾個百分點以內，PCIe 在首字延遲（TTFT）與 Prefill 上約有 2–3% 的小幅優勢。短上下文時兩者差異很小，因此 USB 3.0 往往是更務實的第一步。
兩個階段對分段鏈的使用方式完全不同 —— 級聯的效益正是來自這個差異。
長輸入先切成 Bucket，再沿分段鏈佇列化重疊執行：第 0 段處理 Bucket 1 時，第 1 段還在收尾 Bucket 0。長 Prompt 的吞吐就是靠這個重疊提上來的 —— 輸入越長，效益越明顯。
Decode 一次只出一個 Token。每個 Token 都要逐段走完整條鏈，末段輸出 Logits 後由 Host 取樣，再進入下一輪。這個階段是嚴格順序的，因此 Decode 速度取決於最慢的那一段。
分段不是簡單對半切。各層的權重體積與記憶體佔用差別很大（注意力區塊與 MLP 區塊的差異尤其明顯），工具鏈會依量化後的權重規模與分段記憶體佔用做均衡，把各段拉平。以 Qwen3.5-9B 為例，共 32 個 Decoder 層會被切成 19 層與 13 層兩段，而不是 16 / 16。
| 分段 / 卡 | 承載的 Decoder 層 | 產出物 |
|---|---|---|
| 分段 0 · 卡 0 | Layer 0 – 18 · 19 個 Decoder 層 | segment0.rknn + segment0.weight |
| 分段 1 · 卡 1 | Layer 19 – 31 · 13 個 Decoder 層 + Final Norm + LM Head | segment1.rknn + segment1.weight |
分段由工具鏈產出，但真正決定成敗的參數 —— 分段數、目標上下文、量化方案、連接方式 —— 必須結合你的延遲目標做工程決策，不能直接吃預設值。
量級參考，不是保證值。實際吞吐取決於量化方案、上下文長度與批次大小。
| 配置 | 晶片與模型量級 | 已驗證上下文 |
|---|---|---|
| 2 卡級聯 | 2 × RK182X · 9B | 4K / 8K |
| 4 卡級聯 | 4 × RK182X · 27B | 4K / 8K |
| Host 平台 | RK3588 / RK3576 / x86 (Windows) | RKNN3 Runtime · rkllm3-server |
首字延遲、Prefill 吞吐、Decode 吞吐、系統功耗與 Host 記憶體佔用，都會隨量化方案和配置顯著變化。我們依配置提供對應的實測資料 —— 告知模型、上下文與卡數，我們會給出同口徑的測試報告。
這不是一台現貨整機。卡堆疊、Switch、HUB、機箱都是工程決策 —— 這些工程正是我們承接的部分。
百斯通是瑞芯微全系列 IDH 設計夥伴。我們把這套級聯架構落成你場景裡可驗證的產品 —— 從模型可行性一直到小批試產。
先分析你的模型結構（Decoder 層數、Embedding、Final Norm、LM Head、特殊 Cache / State），再結合你的延遲預算確定目標：卡數、連接方式、上下文長度與量化方案。分段方案由這一步產出，而不是取預設值。
PCIe 獨立直連、PCIe Switch 或 USB 3.0 HUB —— 依你的機箱允許的形式，設計載板、時脈與電源樹、連接器佈局與訊號完整性。
多卡密度的本質是散熱問題，其次才是算力問題。我們依持續滿載工況設計散熱與風道，並把卡堆疊整合進你的結構包絡與安裝限制。
Host BSP 整合、裝置列舉、Runtime 對齊，以及全部各段的輸入 / Shape / 取樣一致性 —— 包括與你現有應用層的介面相容。
Prefill 與 Decode 實測、持續滿載下的穩定性與老化測試、功耗特性分析，以及進入小批試產與量產前的 DFM 評審。
可行性評估與分段報告 · 載板原理圖與 PCB · Host BSP 與裝置樹整合 · 分段與轉換腳本 · Runtime 對齊說明 · 含 Prefill / Decode / 穩定性 / 功耗資料的整機驗證報告 · DFM 評審與小批試產支援。
工具鏈把 HuggingFace / PyTorch 權重轉成逐段產物。真正的工作量在結構分析與 Runtime 對齊，而不在轉換指令本身。
| 項目 | 做什麼 | 產出 |
|---|---|---|
| 分段匯出與轉換 | 動手切之前先確認模型的實際結構 —— Decoder 層數、Embedding、Final Norm、LM Head，以及是否帶有特殊的 Cache / State。接著確認目標：模型版本、目標上下文、目標卡數與連接方式，以及你需要達到的 Prefill / Decode 效能。 | segment*.rknnsegment*.weight |
| 開發參考 | rknn3-model-zoo/examples/multicard | demo + scripts |
| 服務化 | rkllm3-server | OpenAI-compatible API |
只要能乾淨匯出為 ONNX 且 Decoder 結構規整，就可以分段 —— 這條管線並不綁定某一模型家族。帶自訂 Cache / State 的特殊結構需要額外的對齊工作，會在第一步評估中給出結論。
每個評估階段幾乎都會問到的問題，直接給出回答。
單卡的邊界就是本地記憶體。級聯把 Decoder 堆疊切片放到多張裝置上，讓容量隨卡數成長，而不是被單顆封裝鎖死。另一個好處是可以先用 2 張卡，之後再補 2 張，架構不用推倒重來。
目前支援的配置是 2 卡與 4 卡。調度器本質上只要求「可用裝置數 ≥ 分段數」，所以設計並不寫死在四張。
只傳中間特徵 —— 也就是分段邊界處的逐層啟動值。模型權重常駐各自卡上，從不跨鏈路搬運，這也是鏈路頻寬對吞吐影響有限的原因。
兩種都能用。長輸入 Prefill 場景下 PCIe 相對 USB 3.0 約有 2–3% 的優勢；短上下文差異很小。如果 Host 的 PCIe 通道吃緊，或者是在改造既有整機，USB 3.0 通常更務實。
RK3588 / RK3576，跑 ARM64 Linux 或 Android；也可以是 x86 Windows 主機。Host 負責分詞、詞向量、調度、Logits 與取樣，推理本身跑在卡上。
開銷很低 —— Host 只做編排，不做推理。具體的 CPU 與記憶體佔用取決於上下文長度和卡數，我們依你的目標配置給出實測值，而不是拋一個籠統的數字。
只要能乾淨匯出為 ONNX，而且是規整的 Transformer Decoder 結構，都可以。把 32 層 Decoder 均衡切到 2 張卡、把更大的堆疊切到 4 張卡，都是常規配置；帶自訂 Cache / State 的模型需要額外對齊工作。
兩種形態都有。服務化層已經適配為 OpenAI 相容 API，現有應用程式碼可以直接把級聯當成一般的模型端點來呼叫。
架構參數（卡數、Decoder 層區間、介面版本、上下文件位）是級聯設計與原廠參考工具鏈的確定屬性。
能力量級（2 卡 9B 級、4 卡 27B 級）是參考平台評估得出的量級區間，不構成對特定模型、量化方案或上下文的保證。
實測效能與功耗數值本頁刻意不公開。它們高度依賴量化方案與配置；我們依你的目標配置提供同口徑測試報告。