오늘은 업스테이지가 Solar Open 2 모델을 공개한 지 이틀째 되는 날입니다. 저희는 이 기간 동안, 공식 권장 사양에는 없지만 최근 개발자들에게 큰 인기를 얻고 있는 NVIDIA 의 개인용 워크스테이션인 DGX Spark 환경에서 Solar Open 2 NVFP4 모델을 실제로 올려서 서비스 가능한 상태까지 만드는 데 성공했습니다. 이 글을 통해 왜 DGX Spark가 Solar Open 2 NVFP4의 '지원되지 않는 조합'으로 여겨졌는지 그 기술적 이유를 짚고, FlashInfer와 vLLM 레벨에서 어떤 수정과 우회가 필요했는지를 정리해보려 합니다.

TL;DR

두 대의 DGX Spark를 사용하여 Solar Open2 NVFP4 모델을 실행하려면, NVIDIA의 멀티노드 vLLM 가이드의 1-6단계를 따르되, export VLLM_IMAGE=... 라인이 나오는 모든 부분을 export VLLM_IMAGE=cr.backend.ai/stable/ngc-vllm:26.06-cuda13.3-ubuntu24.04-solaropen2로 교체하세요. 그 후, 아래의 명령어를 사용하여 vLLM을 통해 Solar Open 2 모델 서빙을 시작할 수 있습니다.

Solar Open 2 개요

업스테이지는 2026년 7월 22일, 독자 AI 파운데이션 모델 프로젝트의 결과물인 Solar Open 2 모델을 공개했습니다. Solar Open 2는 총 2,500억 개 파라미터, 약 150억 개 활성 파라미터로 이루어진 Mixture-of-Experts(MoE) 모델로, 320개의 라우팅된 전문가(expert)와 1개의 공유 전문가, top-8 라우팅을 사용합니다. Solar Open 2의 아키텍처는 하이브리드 어텐션을 사용하며, 12개의 GQA(Grouped-Query Attention) 소프트맥스 레이어와 36개의 KDA(Kimi-Delta-Attention) 선형 어텐션 레이어가 번갈아 배치되어 있습니다. 이중 어떤 레이어도 포지셔널 인코딩을 사용하지 않으며, 1M 컨텍스트 윈도우를 지원합니다. 48개 레이어 중 12개 레이어만 KV 캐시를 유지하는데, 이는 선형 어텐션 설계의 특성입니다. Solar Open 2 BF16 풀 정밀도 기준 가중치 용량은 약 500GB이며, 업스테이지에서는 서빙을 위해 최소 4장의 H200 GPU를 이용하는 것을 권장하고 있습니다.

업스테이지의 릴리즈와 함께 Nota AI 또한 NVFP4 양자화 체크포인트를 compressed-tensors 형식(nvfp4-pack-quantized)으로 공개했습니다. compressed-tensors 형식은 vLLM 자체의 양자화 표준이므로, 이 형식의 체크포인트는 NVIDIA의 독점 ModelOpt 툴체인을 거치지 않고 vLLM의 가중치 파이프라인에서 직접 로드할 수 있습니다.

NVFP4로 양자화를 진행하면 GPU 메모리의 요구량이 줄어듭니다. 노타에서 제공하는 NVFP4 가중치를 사용할 경우 Solar Open 2를 서빙하는데 필요한 GPU 메모리 요구량은 500.6GB에서 153.3GB로 줄어듭니다. 모델 카드의 15개 영어 및 한국어 벤치마크에서 평균 점수는 81.57에서 81.35로 0.22점 하락하는 데 그쳤으며, 15개 벤치마크 중 4개는 양자화 후 실제로 점수가 향상되는 모습을 보여주는 것에서 미루어보아, 성능 손실은 거의 발생하지 않는다는 사실도 확인할 수 있습니다.

DGX Spark 2대에는 Solar Open 2 NVFP4 모델을 올릴 수 없다?

DGX Spark는 128GB의 Unified Memory 구조를 채택하고 있습니다. OS 및 기타 운영 구성 요소의 메모리 사용량을 감안하면, 실제 모델을 로드하는 데 사용 가능한 용량은 최대 110GiB 수준입니다. 따라서 DGX Spark 2대를 사용하면 하드웨어적으로 256GB, 우리가 사용할 수 있는 메모리 기준으로는 약 220GB 수준을 확보할 수 있으므로, 모델을 구동하기에는 충분합니다. 그러나 실제로 DGX Spark에 Solar Open 2를 로드해보면 메모리 여유가 있음에도 불구하고 모델은 정상적으로 로드되지 않습니다. 무엇이 문제일까요?

DGX Spark에 NVFP4 모델을 로드할 수 없었던 이유

바로 DGX Spark에 탑재된 GB10 GPU의 컴퓨트 아키텍처가 B200이나 B300과 같은 Blackwell과 다르기 때문입니다. 엔비디아도 GB10을 Blackwell이라고 부르고, 실제로 Blackwell이 맞긴 합니다만, DGX Spark는 B200이나 B300과 같은 데이터센터용 Blackwell과는 다소 다른 설계 철학을 가지고 있습니다. 아래의 표는 다른 Blackwell 시리즈와 DGX Spark의 Blackwell이 어떻게 다른지 요약한 것입니다.

이러한 아키텍처 간의 차이점에 대해 더 알고 싶다면, 이전 블로그 글인 NVIDIA DGX Spark 들여다보기: DGX Spark는 정말 블랙웰 기반일까요?를 참고하시면 좋습니다.

타겟	하드웨어	주요 기능
sm_100	B200, GB200 (데이터센터)	tcgen05 + Tensor Memory, 228KB smem/SM
sm_120	RTX 5090, RTX PRO (데스크톱)	warp-level mma.sync, ~100KB smem/SM
sm_121	GB10 / DGX Spark	sm_120과 동일한 ISA, 다른 기능 레벨

b12x 커널 트리

이 부분이 바로 FlashInfer의 b12x 버전이 등장하는 지점입니다. b12x 버전은 SM 12.x를 위한 별도의, 기능적으로 제한된 커널 트리로, 2026년 4월 커뮤니티 b12x 프로젝트에서 다수의 PR #3051, #3066, #3080을 통해 포팅되었습니다. NVIDIA의 CuTe DSL을 활용해서 JIT로 커널을 컴파일하게 됩니다.

그렇지만 FlashInfer의 b12x 버전이 원본의 모든 기능을 지원하는 것은 아닙니다¹. trtllm-gen attention, CUTLASS, FHMA, DeepGEMM 등의 가속 기능은 아직 지원하지 않고 있습니다. 그렇지만, 저희의 NVFP4 가중치를 돌리기 위해 필요한 만큼의 MoE 기능은 다 들어있는 것으로 보였죠.

하지만 실제로 b12x 버전을 사용해보니 두 가지 문제를 확인할 수 있었습니다.

Expert Parallelism 기능 미지원

Solar Open 2 같이 많은 개수의 Expert를 보유하는 가중치를 여러 GPU에 나누어 서빙하는 경우, 빠른 추론 경험을 위해서는 Expert Parallel(EP) 기능을 활성화하는 것이 필수입니다. 하지만 기본 FlashInfer b12x는 이 기능을 지원하지 않았습니다.

체크포인트 형식이 거부됨

EP를 비활성화 한다고 하더라도, b12x 트리는 Nota의 NVFP4 가중치를 로드하지 못합니다. 이는 FlashInfer b12x가 ModelOpt 형식 혹은 BF16 형식의 가중치를 온라인 양자화 하는 것만 지원하기 때문입니다. compressed-tensors 기술을 사용한 Nota의 NVFP4 가중치는 이 조건에 부합하지 않았습니다.

FlashInfer의 대안이 없을까?

다른 모든 vLLM MoE 백엔드는 이 특정 조합(SM 121 + Nota NVFP4 + EP=2)에서 각기 다른 이유로 실패합니다.

• FLASHINFER_TRTLLM / CUTEDSL / CUTEDSL_BATCHED는 Hopper, Blackwell (Datacenter) 아키텍처만 지원합니다.
• FLASHINFER_CUTLASS (vLLM의 AUTO 선택기가 SM 121에서 선택하는 것)은 문서상 동작해야 하지만, 실제로는 GB10에서 NVFP4 MoE 모델을 실행 시도하는 경우 가비지 출력 및 잘못된 주소 크래시 등의 다양한 오류가 보고된 바 있습니다.
• VLLM_CUTLASS는 Expert Parallel을 지원하지 않았습니다.

이러한 상황에서, 유일한 방법은 FlashInfer에 부족한 기능을 저희가 직접 구현하는 것이었습니다.

수정 사항

b12x에서의 Expert Parallelism 구현 추가

저희가 핵심적으로 추가한 사항은 JIT 컴파일되는 커널에 내장된 local_expert_offset 파라미터입니다. 각 노드는 연속된(contiguous) expert 샤드를 보유합니다. 우리의 DGX Spark 두 대 환경을 예로 들면, 한쪽 Spark에 expert 0–159가, 다른 쪽에 160–319가 배치되는 방식입니다. 커널은 전역적으로 라우팅된 expert ID를 샤드 상대(shard-relative) 인덱스로 변환하고, 샤드 범위를 벗어난 토큰–expert 쌍은 CTA-uniform 가드로 걸러냅니다. 이는 micro 경로(Triton compact pre-pass), static 및 dynamic NVFP4 W4A4, 그리고 W4A16 경로를 포함한 b12x의 4개 fused-MoE 백엔드 전체에 구현되어 있습니다.

출력은 샤드별 부분합(partial sum)이며, 호출자가 표준 all-reduce 연산을 통해 이를 조합하는 구조입니다. 이 외의 부수적인 변경 사항으로는 expert별 scale 텐서의 정렬(alignment) 요구를 16에서 4로 완화한 것(임의의 샤드 오프셋이 컴파일된 커널에 바인딩될 수 있도록), 백엔드 선택 휴리스틱을 전역 워크로드 기준이 아닌 예상 로컬 워크로드 기준으로 재조정한 것, 그리고 워크스페이스 버퍼를 레이어별 개별 할당에서 모듈 수준의 공유 풀로 옮긴 것이 있습니다. 이 공유 풀이 없으면 48개의 MoE 레이어가 각각 약 0.5 GB의 스크래치 메모리를 할당하게 되어 메모리에 다 들어가지 않습니다.

b12x 버전이 실제 NVFP4 체크포인트를 읽어들이도록 만들기

기존 b12x 구현체에도 W4A4 NVFP4 GEMM 커널은 이미 존재했으므로, 새로운 MMA 프리미티브를 추가하지는 않았습니다. 이 패치에서 추가한 것은 prepare_b12x_nvfp4_packed_weights 구현으로, 사전 양자화된(pre-quantized) 체크포인트를 받아 커널이 실제로 소비하는 형태로 변환하는 함수입니다.

이 경로는 packed FP4 가중치, FP8 블록 scale, expert별 전역 scale을 ModelOpt 또는 compressed-tensors 컨벤션 어느 쪽으로든 읽어들일 수 있습니다. Nota의 체크포인트(compressed-tensors)의 경우, 역수 형태의 전역 scale을 다시 뒤집은 뒤 재반올림(re-rounding)과 함께 FP8 블록 scale에 접어 넣고(448로 클램핑), 그 결과를 커널의 6D MMA 타일 레이아웃으로 스위즐(swizzle)합니다. 또한 vLLM의 fused gate/up projection 행 순서 처리와 EP 환경에서의 샤드별 scale 슬라이싱도 함께 처리합니다.

배포

이 글을 읽고 있는 여러분께서 Solar Open 2 모델을 실행할 때 별도의 환경을 준비할 필요가 없도록, 바로 동작하는 Docker 이미지 cr.backend.ai/stable/ngc-vllm:26.06-cuda13.3-ubuntu24.04-solaropen2를 준비해 두었습니다. 이 이미지는 NGC vLLM 26.06을 베이스로 하여, 아래 변경 사항을 추가하였습니다.

• 업스테이지의 vLLM 포크(브랜치 v0.22.0-solar-open2): 모델 구현, 추론/도구 파서, KDA 프리필 오토튠 웜업 수정
• 업스테이지의 transformers 포크(브랜치 v5.14.1-solar-open2): solar_open2 모델 타입 등록
• 래블업의 FlashInfer 포크: stock 0.6.12를 대체하는 0.6.15 기반 휠 3개

이것이 의미하는 바는?

2026년 7월 24일 현재, FlashInfer는 b12x 트리에서 Expert Parallel과 compressed-tensors W4A4 체크포인트 모두를 아직 지원하지 않고 있습니다(817e4bd1 커밋 참고). 자연히 vLLM에서도 b12x 백엔드에 대해 여전히 Expert Parallelism을 지원하지 않습니다(dd72658e 커밋 참고).

래블업이 만든 포크는 DGX Spark에서 네이티브 W4A4 NVFP4 Expert Parallel MoE 서빙의 첫 공개 데모입니다. 더욱 자세한 수정 사항에 대해서는 lablup/flashinfer에서 확인하실 수 있습니다.

Footnotes

1. https://github.com/flashinfer-ai/flashinfer/issues/3170 ↩