Rebel100™ 기반 Coding Assistant¶

개요¶

이 레퍼런스 디자인은 Rebel100™에서 코딩 에이전트용 서빙 스택을 구성하는 방법을 설명합니다. 이 스택은 RBLN vLLM으로 MiniMax-M2.7을 서빙하고 llm-d를 사용해 Kubernetes에 배포하며, prefill/decode(P/D) 분리, prefix 캐시를 고려한 라우팅, Rebellions Direct Storage(RDS)로의 KV 오프로딩, speculative decoding을 사용합니다. 하드웨어와 소프트웨어 버전부터 Kubernetes 리소스와 서빙 인자까지 하나의 구성을 고정하고 각 값을 선택한 이유를 설명하므로 설계를 재현하고 자체 배포의 출발점으로 활용할 수 있습니다. 또한 이 문서는 검증한 부분과 검증하지 않은 부분을 구분하여 작성하였으며 Target Configuration을 검증한 방법을 설명합니다(검증 방법 참고).

대상 독자¶

• modelserver를 최적화하는 AI 엔지니어: 서빙 설정에서 병렬화, KV 캐시, speculative decoding 인자와 값을 변경했을 때의 영향을 먼저 확인하는 것을 권합니다.
• 클러스터를 구축하고 운영하는 시스템 관리자: 하드웨어, Kubernetes 배포, 운영부터 확인하세요.
• 엔드포인트에 코딩 에이전트를 연결하는 개발자: 클라이언트 연동부터 읽어 보는 것을 권합니다.

해결하려는 문제¶

코딩 에이전트는 채팅 클라이언트와 다른 방식으로 모델을 사용합니다. 같은 코드 저장소 컨텍스트로 만든 수만 토큰의 프롬프트를 보내 짧은 답변을 받고, 도구를 호출할 때마다 모델을 다시 호출합니다. 따라서 작업 하나가 여러 요청으로 이어지고 각 요청의 지연 시간이 누적됩니다. 일반 로드 밸런서 뒤에 있는 모델 서버는 이런 사용 패턴을 잘 처리하지 못합니다. 긴 prefill이 같은 서버에 있는 다른 요청의 토큰 생성을 늦추고, 로드 밸런서는 프롬프트의 prefix가 이미 어느 서버에 있는지 알지 못하며, 재사용할 수 있는 KV 캐시가 디바이스 메모리에서 축출됩니다.

다음 워크로드 특성이 이 설계의 구성 선택을 결정합니다.

설계 목표¶

• 지연 시간 우선. 전체 처리량을 높이려고 배치 크기를 늘리기보다 요청별 지연 시간을 낮게 유지하도록 설계했습니다.
• prefill과 decode 분리. 두 단계를 별도 인스턴스에서 실행해 긴 프롬프트가 토큰 생성을 방해하지 않도록 하고 RDMA로 두 인스턴스 사이에서 KV를 전송하도록 설계했습니다.
• 프롬프트 prefix 재사용. 각 요청을 해당 prefix가 이미 있는 인스턴스로 보내고 디바이스 메모리를 넘어 tier 2(RDS)에도 KV를 유지하도록 설계했습니다.
• 생성 속도 향상. 이 모델용으로 공개된 draft head를 사용하는 EAGLE-3 speculative decoding을 기본으로 적용했습니다. Draft 모델이 필요 없는 대안으로는 검증된 suffix decoding과 n-gram을 적용할 수 있습니다.
• 표준 Kubernetes API와 단일 차트로 배포. 하나의 Helm 차트로 게이트웨이, 라우터, modelserver를 시작하고 디바이스에는 DRA를, 라우팅에는 Gateway API를 사용하도록 했습니다.
• 검증 범위 명시. 4노드 Target Configuration을 구성하여 실제 동작을 검증하였고 각 구성 요소를 해당 구성에서 사용했는지 상태로 표시했습니다.

엔드포인트의 인증과 권한 부여는 이 설계의 범위에 포함되지 않으며 게이트웨이 앞에서 처리해야 합니다(클라이언트 연동 참고).

아키텍처¶

각 요청은 게이트웨이를 거쳐 llm-d 라우터의 Endpoint Picker(EPP)에 도달합니다. EPP는 prefix 캐시 친화도와 부하를 기준으로 prefill 및 decode 인스턴스를 선택합니다. prefill 인스턴스가 프롬프트의 KV를 계산하면 decode 인스턴스가 이를 가져와 출력 토큰을 생성합니다.

flowchart TB
  C["Client or coding agent"] --> GW["Gateway"]
  GW --> EPP["Router (EPP)<br/>picks prefill and decode"]
  EPP --> SC
  subgraph DPOD["Decode pod"]
    SC["Routing sidecar"]
    D["Decode instance<br/>DP4 + expert parallel, 4 NPUs"]
  end
  SC -->|"1. prefill"| P["Prefill instance<br/>PP4, 4 NPUs"]
  D -->|"2. pulls KV over NIXL (RDMA)"| P
  SC -->|"3. decode"| D
  P <-->|"KV tier 2 (LMCache)"| RDS[("RDS on NVMe")]

1. decode 인스턴스 앞의 라우팅 사이드카가 먼저 선택된 prefill 인스턴스에 요청을 보냅니다.
2. decode 인스턴스는 NIXL과 RDMA를 통해 prefill 인스턴스에서 프롬프트의 KV를 가져옵니다. prefill은 LMCache를 통해 KV를 RDS에도 저장하고 이후 요청에서 조회합니다.
3. decode 인스턴스가 출력 토큰을 생성하면 응답은 라우팅 사이드카와 게이트웨이를 거쳐 반환됩니다.

라우터는 각 Pod에 이미 보낸 요청을 바탕으로 prefix 캐시 hit을 예측합니다. Target Configuration(4P4D)에서는 각 노드에 prefill 인스턴스와 decode 인스턴스가 하나씩 실행됩니다. 모든 prefill 인스턴스는 노드에 관계없이 모든 decode 인스턴스와 짝을 이룰 수 있습니다(하드웨어 › 네트워크 참고). 각 구성 요소에 해당하는 Kubernetes 리소스는 Kubernetes 배포를 참고하세요.

모델¶

MiniMaxAI/MiniMax-M2.7은 전체 파라미터가 229B이고 활성 파라미터가 약 10B인 MoE 모델입니다.

권장 샘플링 파라미터는 클라이언트 연동 › 권장 샘플링 파라미터를 참고하세요.

구성 요약¶

다음 상태 배지는 레퍼런스 디자인 › 상태 배지의 정의를 따릅니다.

검증에서는 서빙 설정의 서빙 인자를 사용했습니다. 예외는 두 가지입니다. KV는 LMCache와 RDS 없이 NIXL을 통해 prefill에서 decode로 전송했습니다. P/D 배치 비교는 라우터 없이 라운드 로빈으로 요청을 분산했고, 라우터는 에이전트 워크로드에서만 서빙 설정 › 라우터와 다른 설정으로 사용했습니다(Target Configuration 검증 참고). 표준 설정 중 검증에서 사용하지 않은 부분은 해당 부분을 정의하는 페이지에 Unverified로 표시하며 검증 범위와 제한 사항에도 기재합니다.

설계 대안¶

이 설계는 다음 각 항목에서 하나의 방식을 선택합니다. 대안도 지원하지만 준비 사항이나 포기해야 하는 조건이 달라집니다.

검증 방법¶

배포 규모를 결정하기 전에 자체 워크로드로 설계를 평가하세요.

Target Configuration은 코딩 에이전트 트래픽의 형태를 재현하는 SWE-bench Verified 기반 합성 워크로드로 검증했습니다. 워크로드, P/D 배치, 동시성 범위, 기능 확인과 정확도 결과는 검증 및 제한 사항을 참고하세요.

검증 범위와 제한 사항¶

다음 표는 Target Configuration 검증에서 사용하지 않은 주요 항목입니다. 전체 목록이 아니며, 각 페이지에도 상태를 표시합니다.

다음 단계¶