BesTom のサービス

RK182X マルチカード・カスケード推論
Decoder 層単位のセグメント分割で 2 枚または 4 枚の AI カードに分散 — 1 台のホストでオンデバイス LLM の容量と長入力 Prefill を拡張

RK182X AI カード 1 枚には明確な容量上限があります。モデルはカードのローカルメモリに収まる必要があり、すべてのトークンが同一チップを通ります。カスケード構成はこの天井を外します。Transformer を 連続する Decoder 層のセグメントに分割し、各セグメントを独立したカードに配置、ホストがチェーン全体を統括します。容量はカード枚数に応じて拡張し、カード間を流れるのは 中間特徴量（Hidden States） のみ。モデル重みは各カード上に留まります。

2 / 4 枚構成Decoder 層セグメント分割PCIe / PCIe Switch / USB 3.0OpenAI 互換サービング

ホスト 1 台、AI カード最大 4 枚、オンプレミスで 27B モデルクラスまで — クラウド往復なし、フロントエンド機器の再設計も不要。

カスケードの狙い

カスケードで得られるもの

3 つの独立した効果を、同一のホストプラットフォーム上で実現します。

単卡の容量上限を突破

容量はカード 1 枚のローカルメモリに縛られなくなります。Decoder スタックを 2 枚または 4 枚のデバイスに分割することで、実用上の上限を小型モデルクラスから 27B クラスへ引き上げられます。しかも完全にオンプレミスのままです。

長入力 Prefill の高速化

長い入力は Bucket に分割され、セグメントチェーンをパイプライン処理します。セグメント N が Bucket k を処理している間に、セグメント N−1 はすでに Bucket k+1 を処理しています。長いプロンプトのスループットは積み上がり、1 枚のカードの後ろで待つことはありません。

2 枚 / 4 枚の柔軟な構成と 3 つの接続方式

PCIe 直結、PCIe Switch 拡張、USB 3.0 HUB 共有。利用可能なポート、筐体スペース、BOM で選択できます。3 つのトポロジはいずれも同じセグメントモデルと同じ Runtime インターフェースで動作します。

動作原理

カスケードの原理

ホストが統括し、各カードが Decoder スタックの連続した一部を担当します。

図 1 · Decoder 層分割とカスケード実行

1 · ホストでトークン化

トークナイザと埋め込みマップはホスト CPU 上で動作します。テキストはまずトークン ID に、次に埋め込みベクトルに変換されます。

2 · ホストがセグメントをスケジュール

デバイス探索、セグメントスケジューリング、Bucket キューはホスト側にあります。どのセグメントをどのカードで、どの順に実行するかをホストが決めます。

3 · セグメントをチェーン実行

カード 0 が Decoder 層 0..k を実行し、中間特徴量をカード 1 に渡します。カード 1 は k+1..m を実行し、最終セグメントまで順に受け渡します。

4 · 最終セグメントが Logits を出力

最終セグメントは末尾の Decoder 層に Final Norm と LM Head を加えて担当します。Logits はホストに戻りサンプリングされ、Decode ループが繰り返されます。

スケジューリング規則：stage_count = セグメント数、かつ 利用可能デバイス数 ≥ stage_count。中間特徴量はホスト側を経由して転送され、モデル重みは各カード上に常駐します。

ハードウェア構成

カードを接続する 3 つの方法

3 方式はいずれも同じセグメントモデルと同じ Runtime API で動作します — ポート数、筐体スペース、BOM で選定します。

図 2 · 2 / 4 枚の 3 つの接続トポロジ

接続方式	上り帯域	占有ホストポート	適する場面
PCIe 直結（カードごとに 1 レーン）	PCIe 2.0 x1 × N	N	ホストに空き PCIe レーンがあり、トポロジを最も単純にしたい場合。Switch も HUB も共有バスも不要です。
PCIe Switch 拡張	PCIe 2.0 x1 / PCIe 3.0 x4	1	ホストの PCIe が不足している場合。上りは 1 本だけを使い、Switch がカードごとの帯域を独立に分配します。
USB 3.0 HUB 拡張	USB 3.0 × 1 (shared)	1	最速で統合でき、既存機のレトロフィットにも向きます。4 枚のカードが 1 つの USB 3.0 HUB を共有します。

リファレンスプラットフォームでの実測では、長入力 Prefill において PCIe と USB 3.0 の差は数パーセント以内です。PCIe は初回トークン遅延（TTFT）と Prefill で 2–3% 程度の小さな優位があります。短いコンテキストでは差はほとんどなく、USB 3.0 が現実的な第一候補になることが多いです。

実行モデル

Prefill パイプラインと Decode ループ

2 つのフェーズではセグメントチェーンの使われ方がまったく異なります — カスケードの効果はまさにこの差から生まれます。

図 3 · Prefill パイプラインと Decode ループ

Prefill · Bucket パイプライン

長い入力は Bucket に分割され、セグメントチェーン上でキューイングされつつ重なり合って実行されます。セグメント 0 が Bucket 1 を処理している間、セグメント 1 はまだ Bucket 0 を終わらせています。この重なりが長いプロンプトのスループットを押し上げます — 入力が長いほど効果は大きくなります。

Decode · 順次チェーン

Decode は 1 度に 1 トークンしか生成しません。各トークンはセグメントを順にたどってチェーン全体を通り、最終セグメントが Logits を出力、ホストがサンプリングして次のステップに進みます。このフェーズは厳密に順次処理なので、Decode 速度は最も遅いセグメントに律速されます。

モデルの分割方法

セグメント分割は単純な 2 等分ではありません。層ごとに重みサイズとメモリ占有量が大きく異なるため（アテンションブロックと MLP ブロックの差が特に顕著です）、ツールチェーンは量子化後の重み量とセグメントごとのメモリを均衡させて各段をならします。例えば Qwen3.5-9B の場合、32 個の Decoder 層は 16 / 16 ではなく 19 層と 13 層の 2 セグメントに分割されます。

セグメント / カード	担当 Decoder 層	生成物
セグメント 0 · カード 0	Layer 0 – 18 · Decoder 層 19 個	`segment0.rknn + segment0.weight`
セグメント 1 · カード 1	Layer 19 – 31 · Decoder 層 13 個 + Final Norm + LM Head	`segment1.rknn + segment1.weight`

セグメント分割はツールチェーンが生成しますが、成否を分けるパラメータ — セグメント数、対象コンテキスト、量子化方式、接続方式 — は、レイテンシ目標に照らして人が決めるべき設計事項であり、既定値のまま使うものではありません。

能力の範囲

どの構成でどのモデルクラスに届くか

桁感の目安であり、保証値ではありません。実際のスループットは量子化方式、コンテキスト長、バッチサイズに依存します。

構成	チップとモデルクラス	検証済みコンテキスト
2 枚カスケード	2 × RK182X · 9B	4K / 8K
4 枚カスケード	4 × RK182X · 27B	4K / 8K
ホストプラットフォーム	RK3588 / RK3576 / x86 (Windows)	RKNN3 Runtime · rkllm3-server

TTFT、Prefill スループット、Decode スループット、システム消費電力、ホストメモリ使用量は、量子化方式と構成によって大きく変動します。当社は構成に合わせた実測値を提供します — モデル、コンテキスト、カード枚数をお知らせいただければ、同一条件のテストレポートをお渡しします。

BesTom のサービス

BesTom がカスケード設計をどう納品するか

既製品の箱ではありません。カードスタック、Switch、HUB、筐体はいずれも設計判断であり、その設計を当社が担います。

BesTom は Rockchip フルラインナップの IDH 設計パートナーです。カスケードアーキテクチャを、お客様のシナリオで検証済みの製品に仕上げます — モデルの実現性評価からパイロット生産まで。

実現性評価とセグメント戦略

まずモデル構造を解析します（Decoder 層数、Embedding、Final Norm、LM Head、独自 Cache / State）。そのうえでレイテンシ予算に照らして目標を確定します：カード枚数、接続方式、コンテキスト長、量子化方式。セグメント設計はこのステップから出てくるもので、既定値ではありません。

キャリアボードとインターフェース設計

PCIe 直結、PCIe Switch、USB 3.0 HUB — 筐体が許容する方式に合わせて、キャリアボード、クロックと電源ツリー、コネクタ配置、信号品質を設計します。

熱・機構の統合

マルチカード密度は、計算力の問題である前に熱の問題です。連続高負荷を前提に放熱と風路を設計し、カードスタックをお客様の機構包絡と実装制約に統合します。

BSP・ドライバ・Runtime 整合

ホスト BSP 統合、デバイス列挙、Runtime 整合、そして全セグメントにわたる入力 / Shape / サンプリングの一貫性 — 既存アプリケーション層とのインターフェース互換を含みます。

検証とパイロット生産

Prefill / Decode の実測、連続負荷での安定性と耐久試験、消費電力の特性評価、そしてパイロット生産・量産へ向けた DFM レビュー。

納品物

実現性・セグメント評価レポート · キャリアボード回路図と PCB · ホスト BSP とデバイスツリー統合 · セグメント生成と変換スクリプト · Runtime 整合のドキュメント · Prefill / Decode / 安定性 / 消費電力を含む実機検証レポート · DFM レビューとパイロット生産支援。

開発・組み込み

モデルからマルチカード実装までの 5 ステップ

ツールチェーンは HuggingFace / PyTorch の重みをセグメント単位の成果物に変換します。工数の中心は構造解析と Runtime 整合であり、変換コマンドそのものではありません。

図 4 · モデルからマルチカード実装までの 5 ステップ

ステップ

ステップ 1構造評価

ステップ 2セグメント書き出し

ステップ 3RKNN 変換

ステップ 4Runtime 整合

ステップ 5対象カード検証

構造評価で確認すること

項目	内容	出力
セグメント書き出しと変換	分割の前に、モデルの実際の構造を確認します — Decoder 層数、Embedding、Final Norm、LM Head、そして独自の Cache / State の有無。そのうえで目標を確定します：モデル版、対象コンテキスト、カード枚数と接続方式、そして必要な Prefill / Decode 性能です。	`segment.rknn` `segment.weight`
開発リファレンス	`rknn3-model-zoo/examples/multicard`	demo + scripts
サービング層	`rkllm3-server`	OpenAI-compatible API

ONNX に正しく書き出せ、Decoder 構造が規則的であれば分割できます — このパイプラインは特定のモデルファミリに依存しません。独自の Cache / State を持つ特殊な構造は追加の整合作業が必要で、ステップ 1 の評価で判断します。

よくある質問

エンジニアが実際に尋ねるカスケードの疑問

どの評価フェーズでも出てくる疑問に、簡潔にお答えします。

もっと大きなカード 1 枚ではだめなのか？

単卡の上限はローカルメモリです。カスケードは Decoder スタックを複数デバイスに分けることで、容量が 1 つのパッケージに縛られずカード枚数に応じて伸びるようにします。2 枚で始めて後から 2 枚追加する、という進め方もでき、その際にアーキテクチャを作り直す必要はありません。

何枚まで対応しますか？

現在サポートする構成は 2 枚と 4 枚です。スケジューラの要件は本質的に「利用可能デバイス数 ≥ セグメント数」だけなので、4 枚に固定されているわけではありません。

カード間でどれくらいのデータが流れますか？

流れるのは中間特徴量だけです — セグメント境界における層ごとの活性値です。モデル重みは各カードに常駐し、リンクを越えて転送されることはありません。だからこそリンク帯域がスループットに与える影響は限定的です。

PCIe は必須ですか、USB 3.0 で足りますか？

どちらも動作します。長入力 Prefill では PCIe が USB 3.0 に対して 2–3% 程度優位ですが、短いコンテキストでは差はわずかです。ホストの PCIe レーンが不足している場合や既存筐体を流用する場合は、USB 3.0 が現実的な選択になります。

どのようなホストが必要ですか？

ARM64 Linux または Android を動かす RK3588 / RK3576、あるいは x86 Windows ホストです。ホストはトークン化、埋め込み、スケジューリング、Logits、サンプリングを担当し、推論本体はカード上で実行されます。

ホストの CPU とメモリの負荷は大きいですか？

負荷は小さく、ホストは推論ではなく統括のみを行います。正確な CPU とメモリ使用量はコンテキスト長とカード枚数に依存するため、一つの代表値ではなく、お客様の構成に合わせた実測値を提示します。

どのモデルをカスケードできますか？

ONNX に正しく書き出せ、規則的な Transformer Decoder 構造であれば対応します。32 層の Decoder を 2 枚に均衡分割する構成も、より大きなスタックを 4 枚に分ける構成も定番です。独自の Cache / State を持つモデルは追加の整合作業が必要です。

API として使えますか、組み込みライブラリですか？

どちらの形態もあります。サービング層は OpenAI 互換 API を公開するようすでに適合済みで、既存のアプリケーションコードからは通常のモデルエンドポイントとして呼び出せます。

本ページの数値の根拠

アーキテクチャパラメータ（カード枚数、Decoder 層の範囲、インターフェース版、コンテキストの単位）は、カスケード設計とベンダーのリファレンスツールチェーンの確定仕様です。

能力クラス（2 枚で 9B クラス、4 枚で 27B クラス）はリファレンスプラットフォーム評価による桁感の範囲であり、特定のモデル、量子化方式、コンテキストに対する保証ではありません。

実測の性能値と消費電力は本ページでは意図的に公開していません。量子化方式と構成に大きく依存するため、お客様の目標構成に合わせたテストレポートを個別に提供します。

モデルが収まらなくなっていませんか？

モデル、必要なコンテキスト、レイテンシ目標をお送りください。カード枚数、接続方式、セグメント戦略をご提案します。

評価を依頼する

tomyao@bestom.net

RK182X マルチカード・カスケード推論Decoder 層単位のセグメント分割で 2 枚または 4 枚の AI カードに分散 — 1 台のホストでオンデバイス LLM の容量と長入力 Prefill を拡張