BesTom 서비스

RK182X 멀티카드 캐스케이드 추론
Decoder 레이어 단위 분할로 2장 또는 4장의 AI 카드에 분산 — 호스트 한 대에서 온디바이스 LLM 용량과 긴 입력 Prefill 확장

RK182X AI 카드 한 장에는 명확한 용량 한계가 있습니다. 모델이 카드의 로컬 메모리에 들어가야 하고, 모든 토큰이 같은 칩을 통과합니다. 캐스케이드 구조는 이 천장을 열어젖힙니다. Transformer를 연속된 Decoder 레이어 세그먼트로 분할하고, 각 세그먼트를 독립된 카드에 배치하며, 호스트가 체인 전체를 총괄합니다. 용량은 카드 수에 따라 늘어나고, 카드 사이를 오가는 것은 중간 특징(Hidden States)뿐입니다. 모델 가중치는 각 카드에 그대로 남습니다.

2 / 4장 구성Decoder 레이어 분할PCIe / PCIe Switch / USB 3.0OpenAI 호환 서빙

호스트 한 대, AI 카드 최대 4장, 온프레미스에서 27B 모델급까지 — 클라우드 왕복 없이, 프런트엔드 기기를 다시 설계할 필요도 없습니다.

캐스케이드의 목적

캐스케이드로 얻는 것

서로 독립적인 세 가지 효과를 같은 호스트 플랫폼에서 구현합니다.

단일 카드 용량 한계 돌파

용량이 더 이상 카드 한 장의 로컬 메모리에 묶이지 않습니다. Decoder 스택을 2장 또는 4장의 디바이스로 나누면 실용 상한이 소형 모델급에서 27B급으로 올라가며, 전 과정이 온프레미스에 머뭅니다.

긴 입력 Prefill 가속

긴 입력은 Bucket으로 나뉘어 세그먼트 체인을 파이프라인 방식으로 통과합니다. 세그먼트 N이 Bucket k를 처리하는 동안 세그먼트 N−1은 이미 Bucket k+1을 처리합니다. 긴 프롬프트의 처리량이 쌓여 올라가며, 카드 한 장 뒤에서 대기하지 않습니다.

2장 / 4장 유연 구성, 세 가지 연결 방식

PCIe 직결, PCIe Switch 확장, USB 3.0 HUB 공유. 사용 가능한 포트, 인클로저 공간, BOM에 따라 선택합니다. 세 토폴로지 모두 같은 세그먼트 모델과 같은 Runtime 인터페이스로 동작합니다.

동작 원리

캐스케이드 원리

호스트가 총괄하고, 각 카드가 Decoder 스택의 연속된 일부를 담당합니다.

호스트토크나이저임베딩 매핑디바이스 탐색세그먼트스케줄링Logits / 샘플링세그먼트 0카드 0Decoder 레이어 0..ksegment0.rknn + .weight세그먼트 1카드 1레이어 k+1..msegment1.rknn + .weight세그먼트 N카드 N레이어 m+1..z+ Final Norm + LM Headsegment2.rknn + .weight중간 특징출력 토큰 · 루프stage_count = N · devices ≥ stage_count
그림 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. 중간 특징은 호스트 측을 거쳐 전달되며, 모델 가중치는 각 카드에 상주합니다.

하드웨어 구성

카드를 연결하는 세 가지 방법

세 방식 모두 같은 세그먼트 모델과 같은 Runtime API로 동작합니다 — 포트 수, 인클로저 공간, BOM으로 선택합니다.

PCIe 직결호스트카드 0RK182X카드 1RK182X카드 2RK182X카드 3RK182X카드당 레인 1개PCIe Switch 확장호스트PCIe Switch 확장카드 0RK182X카드 1RK182X카드 2RK182X카드 3RK182X업링크 1개, 대역폭 개별USB 3.0 HUB 확장호스트USB 3.0 HUB 확장카드 0RK182X카드 1RK182X카드 2RK182X카드 3RK182X카드가 HUB를 공유
그림 2 · 2 / 4장의 세 가지 연결 토폴로지
연결 방식업링크 대역폭점유 호스트 포트적합한 상황
PCIe 직결(카드당 1레인)PCIe 2.0 x1 × NN호스트에 여유 PCIe 레인이 있고 토폴로지를 가장 단순하게 가져가려는 경우. Switch도 HUB도 공유 버스도 필요 없습니다.
PCIe Switch 확장PCIe 2.0 x1 / PCIe 3.0 x41호스트 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이 현실적인 첫 선택이 되는 경우가 많습니다.

실행 모델

Prefill 파이프라인과 Decode 루프

두 단계는 세그먼트 체인을 전혀 다르게 사용합니다 — 캐스케이드의 이득은 바로 이 차이에서 나옵니다.

PrefillBucket이 세그먼트를 겹쳐 통과B0B1B2B0B1B2B0B1B2세그먼트 0세그먼트 1세그먼트 Nt0t1t2t3t4Decode토큰 하나가 체인 전체를 통과호스트세그먼트 0세그먼트 1세그먼트 NLogits출력 토큰 · 루프
그림 3 · Prefill 파이프라인과 Decode 루프

Prefill · Bucket 파이프라인

긴 입력을 Bucket으로 나눈 뒤 세그먼트 체인에 큐잉해 겹쳐 실행합니다. 세그먼트 0이 Bucket 1을 처리할 때 세그먼트 1은 아직 Bucket 0을 마무리합니다. 이 겹침이 긴 프롬프트 처리량을 끌어올립니다 — 입력이 길수록 효과가 커집니다.

Decode · 순차 체인

Decode는 한 번에 토큰 하나만 생성합니다. 각 토큰은 세그먼트를 차례로 지나 체인 전체를 통과하고, 마지막 세그먼트가 Logits를 출력하면 호스트가 샘플링해 다음 단계로 넘어갑니다. 이 단계는 엄격히 순차적이므로 Decode 속도는 가장 느린 세그먼트에 좌우됩니다.

모델을 나누는 방법

분할은 단순한 반반 자르기가 아닙니다. 레이어마다 가중치 크기와 메모리 점유가 크게 다르기 때문에(어텐션 블록과 MLP 블록의 차이가 특히 큽니다) 툴체인은 양자화 후 가중치 규모와 세그먼트별 메모리를 균형 있게 맞춰 각 단계를 고르게 만듭니다. 예를 들어 Qwen3.5-9B는 Decoder 레이어 32개를 16 / 16이 아니라 19개와 13개 두 세그먼트로 분할합니다.

세그먼트 / 카드담당 Decoder 레이어산출물
세그먼트 0 · 카드 0Layer 0 – 18 · Decoder 레이어 19개segment0.rknn + segment0.weight
세그먼트 1 · 카드 1Layer 19 – 31 · Decoder 레이어 13개 + Final Norm + LM Headsegment1.rknn + segment1.weight

분할은 툴체인이 만들어내지만, 성패를 가르는 파라미터 — 세그먼트 수, 대상 컨텍스트, 양자화 방식, 연결 방식 — 는 지연 목표에 맞춰 사람이 결정해야 하는 설계 사항이며 기본값으로 처리할 수 없습니다.

능력 범위

어떤 구성이 어느 모델급에 도달하는가

자릿수 기준의 가이드이며 보장값이 아닙니다. 실제 처리량은 양자화 방식, 컨텍스트 길이, 배치 크기에 따라 달라집니다.

구성칩과 모델 등급검증된 컨텍스트
2장 캐스케이드2 × RK182X · 9B4K / 8K
4장 캐스케이드4 × RK182X · 27B4K / 8K
호스트 플랫폼RK3588 / RK3576 / x86 (Windows)RKNN3 Runtime · rkllm3-server

첫 토큰 지연, 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 리뷰와 파일럿 생산 지원.

개발 연동

모델에서 멀티카드 구현까지 다섯 단계

툴체인은 HuggingFace / PyTorch 가중치를 세그먼트 단위 산출물로 변환합니다. 실제 공수는 구조 분석과 Runtime 정합에 있고, 변환 명령 자체에 있지 않습니다.

모델 입력HF / PyTorch / ONNX구조평가단계 1세그먼트내보내기단계 2RKNN변환단계 3Runtime정합단계 4대상 카드검증단계 5세그먼트 산출물segment*.rknn + segment*.weightRKNN3 Toolkitrknn3-model-zoo/examples/multicard
그림 4 · 모델에서 멀티카드 구현까지 다섯 단계

단계

단계 1구조 평가
단계 2세그먼트 내보내기
단계 3RKNN 변환
단계 4Runtime 정합
단계 5대상 카드 검증

구조 평가에서 확인하는 것

항목내용산출물
세그먼트 내보내기와 변환분할에 들어가기 전에 모델의 실제 구조를 확인합니다 — Decoder 레이어 수, Embedding, Final Norm, LM Head, 그리고 별도의 Cache / State 유무입니다. 이어서 목표를 확정합니다. 모델 버전, 대상 컨텍스트, 카드 수와 연결 방식, 그리고 필요한 Prefill / Decode 성능입니다.segment*.rknn
segment*.weight
개발 레퍼런스rknn3-model-zoo/examples/multicarddemo + scripts
서빙 계층rkllm3-serverOpenAI-compatible API

ONNX로 깔끔하게 내보낼 수 있고 Decoder 구조가 규칙적이면 분할할 수 있습니다 — 이 파이프라인은 특정 모델 패밀리에 묶여 있지 않습니다. 별도 Cache / State를 가진 특수 구조는 추가 정합 작업이 필요하며, 1단계 평가에서 판단합니다.

자주 묻는 질문

엔지니어가 실제로 묻는 캐스케이드 질문

모든 평가 단계에서 나오는 질문에 간단히 답합니다.

더 큰 카드 한 장을 쓰면 안 되나요?

단일 카드의 한계는 로컬 메모리입니다. 캐스케이드는 Decoder 스택을 여러 디바이스에 나눠 담아 용량이 패키지 하나에 묶이지 않고 카드 수에 따라 늘어나게 합니다. 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