10.7. 파이프라인 서빙¶

Backend.AI GO는 한 대의 머신에 올리기 어려운 대형 MLX 모델을 파이프라인 병렬 방식으로 여러 노드에 나눠 서빙할 수 있습니다. 각 노드는 트랜스포머 레이어의 연속된 구간(스테이지)을 담당하며, 노드 경계는 토큰당 스테이지 경계마다 활성값 텐서만 넘어갑니다. 이 방식은 어떤 단일 노드로도 올릴 수 없는 모델을 낮은 대역폭의 인터커넥트로 실행하는 용량을 제공합니다. 추론 속도를 높이지는 않습니다. 토큰은 여전히 모든 레이어를 순차로 통과합니다.

이 페이지는 전체 과정을 다룹니다. 모델 선택, 모든 노드에 모델 준비, 클러스터 실행, 채팅 사용, 실시간 상태 확인, 중지까지입니다. 읽기 전용 계획 미리보기는 파이프라인 병렬 계획을 참고하세요.

분산 라우팅과의 차이¶

Backend.AI GO에는 함께 사용할 수 있는 독립적인 확장 축이 두 가지 있습니다.

축	분산 라우팅	파이프라인 서빙(이 페이지)
방향	수평: 복제본을 늘림	수직: 하나의 모델, 더 큰 용량
각 노드가 담당	완전한 모델	레이어의 연속 구간
라우터의 시각	복제본당 백엔드 1개	백엔드 총 1개(코디네이터)
목적	처리량과 장애 조치	단일 노드로 올릴 수 없는 모델 실행

실행 중인 파이프라인 클러스터 자체도 수평 라우터가 부하 분산 대상으로 삼을 수 있는 하나의 백엔드일 뿐입니다.

요건¶

등록된 피어 노드 2개 이상(수동 등록 또는 자동 검색 참고).
동질 클러스터: 모든 노드가 같은 가속기 계열(전부 Apple Silicon 또는 전부 Linux CUDA)과 같은 mlxcel 버전을 사용.
선택한 노드 중 어느 하나에도 가중치와 KV 캐시가 들어가지 않는 MLX 형식 모델.
노드 간 전송 포트 범위에서 노드 대 노드 직접 TCP 도달 가능(네트워크 및 방화벽 요건 참고).
"분산 서빙 사용" 설정이 켜져 있어야 함(기본값은 꺼짐, 설정 참고).

서빙 과정¶

모델 탭에서 분산 하위 탭을 엽니다. 분산 서빙이 켜져 있으면 클러스터로 서빙 섹션이 전체 과정을 안내합니다.

모델 선택. 드롭다운에서 MLX 모델을 고릅니다. MLX 형식 모델만 대상이 됩니다.
노드 선택. 등록된 노드를 2개 이상 켭니다. 각 노드에는 지원 여부 배지와 보고된 여유 메모리가 표시됩니다.
샤드 계획 미리보기. 샤드 계획 미리보기를 선택합니다. 노드별 레이어 구간, 노드별 메모리 적합성 막대, 경고가 표시됩니다. 읽는 방법은 파이프라인 병렬 계획을 참고하세요.
모델 준비. 모든 노드에 준비를 선택합니다. 각 노드는 이미 있음, 내려받기 필요, 불일치 중 하나로 분류되며, 모델이 없는 노드는 자체 내려받기 경로로 받습니다. 노드별 진행률이 표시됩니다. 실행 전에 모든 노드에서 준비가 끝나야 합니다.
클러스터 실행. 클러스터 실행을 선택합니다. 실행 타임라인이 순서대로 진행되는 기동 과정을 보여줍니다. 스테이지가 먼저 시작되어 전송 준비를 마치고, 그다음 코디네이터가 올라와 라우터에 등록됩니다. 실행은 전부 아니면 전무 방식입니다(아래 참고).
사용. 클러스터가 정상이 되면 일반 모델 선택기에서 모델을 사용할 수 있습니다. 단일 노드 모델과 똑같이 채팅이나 컴플리션을 실행하면 라우터가 요청을 코디네이터로 프록시합니다.
모니터링과 중지. 섹션이 실시간 모니터로 전환됩니다. 종합 상태 배지와 스테이지별 카드(노드, 레이어 구간, 프로세스 생존 여부, 전송 포트 상태)가 표시됩니다. 클러스터 중지를 선택하면 깔끔하게 정리됩니다.

클러스터 생명주기¶

순서 있는 실행은 필수¶

코디네이터가 스테이지로 연결을 거는 구조이므로, 코디네이터가 시작되기 전에 모든 스테이지 워커가 자신의 전송 주소에서 수신 대기해야 합니다. 따라서 오케스트레이터는 다음 순서로 동작합니다.

모든 원격 스테이지를 스테이지 번호 오름차순으로 시작합니다.
각 스테이지의 전송 포트가 연결을 받기 시작할 때까지 기다립니다.
그다음에야 로컬 코디네이터를 시작하고 헬스 체크가 통과할 때까지 기다립니다.
코디네이터의 엔드포인트를 continuum-router에 백엔드 하나로 등록합니다.

어느 단계라도 실패하면 이미 시작된 모든 것이 정리되므로 반쯤 시작된 클러스터나 고아 프로세스가 남지 않습니다.

코디네이터가 유일한 진입점¶

하나의 코디네이터 프로세스가 OpenAI 호환 HTTP 리스너를 바인딩하고 요청을 받아 파이프라인을 구동하며 결과를 스트리밍합니다. 스테이지 워커는 클라이언트 HTTP를 제공하지 않고 노드 간 전송 주소만 바인딩합니다. continuum-router는 mlxcel 백엔드 하나만 보며 그것이 샤딩된 클러스터라는 사실을 알지 못합니다.

실패는 전부 아니면 전무¶

파이프라인은 스테이지 하나를 잃으면 살아남을 수 없습니다. 스테이지 워커가 죽으면 클러스터 전체가 비정상으로 표시되고 정리됩니다. UI에서는 종합 상태 배지가 비정상으로 바뀌고 클러스터가 제거되는 것으로 나타나며, 라우터 백엔드도 등록 해제되어 낡은 백엔드가 남지 않습니다.

세션 통합¶

실행 중인 클러스터는 세션 화면에 세션 하나(코디네이터의 투영)로 나타나며 클러스터 배지가 붙습니다. 세부 정보 드로어를 열고 클러스터 스테이지 탭을 선택하면 실시간 모니터와 동일한 스테이지별 분해와 종합 상태를 볼 수 있습니다. 세션의 중지 동작은 분산 모델 탭과 같은 생명주기 명령을 재사용합니다.

네트워크 및 방화벽 요건¶

파이프라인 서빙은 OpenAI HTTP 리스너와 별개로, 전용 노드 간 전송 포트 범위에서 노드 대 노드 직접 TCP가 필요합니다. 각 노드의 스테이지는 이 범위의 포트 하나(TOML의 address)를 바인딩하고, 코디네이터가 그 포트로 연결을 겁니다.

기본 범위는 39600-39629입니다. 설정 -> 고급 -> 분산 서빙 -> 전송 포트 범위에서 변경하세요.
호스트나 네트워크 방화벽에서 노드 사이의 이 범위를 열어야 합니다. 포트는 로컬 네트워크의 노드 대 노드에서만 도달 가능하면 되며 공용 인터넷에서 접근할 필요는 없습니다.
Wi-Fi나 이더넷의 지연 시간이 실용적인 클러스터 크기를 제한합니다. 전부 Apple Silicon인 로컬 클러스터에서는 Thunderbolt가 더 빠른 전송이며, RDMA는 TCP로 폴백하는 선택형 고속 경로입니다.

설정¶

설정 -> 고급 -> 분산 서빙에서 설정합니다.

분산 서빙 사용은 클러스터로 서빙 흐름을 켭니다. 기본값은 꺼짐입니다.
기본 전송 백엔드는 계획기가 제안하는 노드 간 전송을 선택합니다. tcp(기본값, 어디서나 동작), thunderbolt(전부 Apple Silicon인 로컬 클러스터), rdma(선택형, TCP로 폴백) 중에서 고릅니다.
전송 포트 범위는 위에서 설명한 노드 간 전송 포트 풀을 설정합니다.

제한 사항¶

파이프라인 병렬만 지원합니다. 텐서 병렬과 분리형 서빙은 이 흐름에 포함되지 않습니다.
동질 클러스터만 지원합니다. 한 클러스터 안에서 가속기 계열이 섞이는 것은 지원하지 않습니다.
모든 노드에 동일한 가중치가 필요합니다. 각 노드는 같은 양자화의 같은 모델 사본을 디스크에 직접 보유하며, 준비 단계에서 존재 여부를 확인하고 없으면 노드별로 내려받습니다.
업스트림은 파이프라인 병렬을 Llama 계열 텍스트 모델과 2단계 토폴로지에서 가장 잘 검증했습니다. 계획기는 모델 계열을 확인하고 2단계를 넘어서면 경고합니다.