뉴스

816B 개방가중치 코딩 모델, GPU 8장 한 노드 서빙 조건

블로그로 돌아가기

AMD가 Meta의 816B 개방가중치 코딩 모델 Muse Spark Open을 Instinct GPU 8장 한 노드에서 vLLM으로 서빙하는 Day 0 레시피를 공개했습니다. 양자화 체크포인트와 최적화별 처리량 수치, 부하 구간별 권장 구성을 정리했습니다.

AX Specialist 김지우AMD InstinctvLLM개방가중치 모델온프레미스 AI코딩 에이전트MoE

공개 당일 지원이라는 신호

AMD가 2026년 10월 15일 Day 0 Enablement and Optimization for Muse Spark Open on AMD Instinct GPUs를 공개했습니다. Meta가 내놓은 개방가중치 모델 Muse Spark Open을 AMD Instinct MI355X와 MI350X에서 ROCm 소프트웨어와 vLLM으로 공개 당일부터 구동할 수 있게 했다는 발표입니다. 글에는 지원 체크포인트 목록, 커널 수준 최적화별 처리량 변화, 부하 구간별 권장 구성, 그대로 복사해 실행할 수 있는 vLLM 명령이 함께 담겼습니다.

기업 입장에서 이 발표의 의미는 성능 수치 자체보다 선택지의 폭에 있습니다. 코딩 에이전트급 대형 모델을 자체 호스팅하려는 조직은 가속기 공급처와 소프트웨어 스택을 먼저 정해야 하는데, 공개 당일에 특정 벤더 외의 경로가 열렸다면 조달 협상과 용량 계획의 전제가 달라집니다. AMD는 이 작업을 파트너인 Inferact와 Meta, 그리고 AMD Quark 팀과 함께 진행했다고 밝혔습니다.

Muse Spark Open의 사양

Muse Spark Open은 Muse Spark 계열의 첫 개방가중치 모델입니다. 원문은 이 모델을 현재까지 가장 유능한 미국산 개방가중치 모델이라고 설명하며, 여러 파일에 걸친 리팩터링과 장시간 디버깅처럼 오래 이어지는 작업을 수행하는 코딩 에이전트를 겨냥해 만들어졌다고 밝혔습니다.

구조는 네이티브 멀티모달 Mixture of Experts입니다. 총 파라미터는 8,160억 개이며 토큰당 활성 파라미터는 420억 개입니다. 컨텍스트 창은 100만 토큰이고, 추론 강도를 설정할 수 있으며 도구 호출을 모델이 기본으로 지원합니다. 배포 경로는 Hugging Face와 Muse Code, Meta Model API, OpenRouter입니다. AMD Instinct GPU에서는 vLLM이 BF16과 AMD가 양자화한 MXFP4, FP8 변형을 지원합니다.

활성 파라미터가 420억 개라는 점은 운영 비용 측면에서 중요합니다. 가중치 전체를 메모리에 올려야 하지만 토큰 하나를 생성할 때 계산되는 양은 전체의 5% 수준이므로, 메모리 용량과 대역폭이 충분한 노드 한 대에 모델이 들어가면 처리량은 밀집 모델보다 유리해집니다. 아래 구성은 모두 이 전제를 바탕으로 합니다.

한 노드 8장으로 서빙하는 구성

원문은 MI350X 또는 MI355X 8장으로 이루어진 단일 노드에서 텐서 병렬 8로 모델을 서빙합니다. GPU당 HBM3E 288GB에 대역폭은 8TB/s입니다. 소프트웨어는 ROCm 7.2와 vLLM 조합이고, 어텐션과 MoE, 통신에는 AMD AITER 커널 라이브러리를 쓰며 디코드 단계는 CUDA 그래프로 캡처합니다.

지원 체크포인트는 다음 세 가지입니다.

변형모델 이름설명
BF16 (공개 릴리스)meta-models/Muse-Spark-Open-816B-A42B전체 정밀도. 노드당 32k 토큰 요청 32개 동시 처리
MXFP4 (AMD Quark 내보내기)amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4라우팅되는 MoE 전문가를 OCP MXFP4로 양자화하고(0번·61번 레이어 제외) 나머지는 BF16으로 유지
FP8 (AMD Quark 내보내기, PTPC)amd/Muse-Spark-Open-816B-A42B-Quark-PTPC-FP8원문 표의 설명란에 MXFP4 행과 동일한 문장이 적혀 있습니다

FP8 행의 설명은 원문 표에서 MXFP4 행과 같은 내용으로 표기되어 있어 그대로 옮겼습니다. 실제 양자화 범위는 체크포인트 카드에서 확인하는 편이 안전합니다.

별도 체크포인트를 내려받지 않는 경로도 있습니다. BF16 체크포인트를 로드할 때 라우팅 전문가를 MXFP4로 반올림하는 옵트인 모드를 켜면 체크포인트는 BF16 상태로 두면서 MXFP4의 메모리와 처리량 특성을 얻습니다. 원문에 따르면 이 모드는 1번부터 60번 레이어의 라우팅 전문가를 로드 시점에 MXFP4로 반올림해 AITER MXFP4 MoE 커널에서 실행하며, 메모리 여유가 생기므로 서버가 시퀀스 128개를 받습니다.

어떤 최적화가 어디에 효과를 냈는지

원문의 최적화 항목은 측정 조건이 서로 다릅니다. 단일 요청 지연을 줄인 것과 동시 요청 처리량을 늘린 것을 구분해서 읽어야 합니다.

디코드 단계의 커널 정리

디코드 한 스텝에서 수행하는 작업을 재구성했습니다. 어텐션 프롤로그와 MoE 마무리 연산을 융합하고, 슬라이딩 윈도 레이어를 AITER 페이지드 어텐션으로 옮기고, 스텝당 커널 론치를 약 180회 줄이고, 라우터 GEMM을 정확한 bf16x3 방식으로 계산했습니다. 그 결과 MXFP4 체크포인트의 출력 처리량은 동시 요청 4개에서 206에서 350 tok/s로, 32개에서 719에서 1,180 tok/s로 올랐습니다.

전문가 병렬

--enable-expert-parallel을 켜면 전문가 256개를 GPU당 32개씩 나눠 맡습니다. MXFP4 기준으로 동시 요청 32개에서 128개 구간에서 처리량이 7%에서 20% 늘고, 첫 토큰까지의 시간은 약 24% 줄었습니다. 동시 요청 128개에서 2,197 tok/s를 기록했습니다.

AITER fused MoE 테이블 튜닝

작은 디코드 배치를 정렬 단계를 생략하는 1단계 MXFP4 조립 커널로 보내도록 AITER fused MoE 테이블을 튜닝했습니다. TP8 기준 단일 요청 디코드 속도가 98에서 114 tok/s로 16% 올랐습니다. 이 테이블은 Day 0 이미지에 포함되어 있어 사용자가 코드를 수정할 필요는 없습니다.

DSpark 투기적 디코딩

투기적 디코딩에는 DSpark를 씁니다. 검증 단계에 AITER의 짧은 쿼리용 3D 어텐션 스케줄을 적용하고, 드래프트 모델의 KV 캐시 삽입을 컴파일된 그래프 밖으로 빼냈습니다. 단일 스트림에서 199 tok/s에 도달했으며, 같은 이미지에서 튜닝된 테이블을 적용한 TP8 대비 72% 빠른 수치입니다. 동시 요청 2개에서 47%, 4개에서 31% 앞서고, 32개에서도 6% 우위가 남습니다. 동시 요청이 늘어날수록 이득이 줄어드는 전형적인 양상입니다.

정확도 확인

GSM8K 점수는 모든 MXFP4 구성에서 94.4%에서 95.5% 사이에 머물렀습니다. 텐서 병렬, 전문가 병렬, 튜닝된 테이블, DSpark를 각각 적용한 경우가 모두 이 범위에 들어갑니다. 양자화와 투기적 디코딩을 켜도 수학 추론 정확도가 눈에 띄게 떨어지지 않았다는 확인입니다. 다만 보고된 지표는 GSM8K 하나이고, 이 모델이 겨냥하는 다중 파일 리팩터링이나 장시간 디버깅 성능을 측정한 것은 아닙니다.

최적화측정 조건변화
디코드 단계 커널 정리MXFP4, 동시 요청 4개206 → 350 tok/s
디코드 단계 커널 정리MXFP4, 동시 요청 32개719 → 1,180 tok/s
전문가 병렬MXFP4, 동시 요청 32~128개처리량 7~20% 증가, 첫 토큰 시간 약 24% 감소, 128개에서 2,197 tok/s
AITER fused MoE 테이블 튜닝TP8, 단일 요청98 → 114 tok/s (+16%)
DSpark 투기적 디코딩단일 스트림199 tok/s, 튜닝 테이블 TP8 대비 +72%
GSM8KMXFP4 전 구성94.4~95.5%

부하에 따른 구성 선택

원문은 동시 요청 수를 기준으로 구성을 고르라고 정리했습니다. 동시 요청 64개 정도까지는 TP8에 전문가 병렬과 DSpark를 함께 쓰고, 단일 사용자라면 전문가 병렬 없이 TP8과 DSpark만 쓰고, 그 이상 부하에서는 TP8과 전문가 병렬 조합으로 가라는 권고입니다.

부하 구간권장 구성설정 요점
단일 사용자TP8 + DSpark권장 명령에서 --enable-expert-parallel을 제거
동시 요청 4~64개TP8 + EP8 + DSpark--max-num-seqs 64, 타깃과 드래프트 양쪽에 AITER 어텐션
동시 요청 64개 초과TP8 + EP8, DSpark 없음--max-num-seqs 128
두 번째 다운로드를 피하려는 경우BF16 체크포인트 + 온라인 MXFP4 전문가VLLM_ROCM_MUSE_MOE_ONLINE_QUANT=mxfp4, 시퀀스 128개

원문이 권장 1순위로 제시한 조합은 MXFP4 체크포인트에 TP8과 EP8, DSpark를 적용하고 시퀀스를 64개로 제한한 구성입니다. 드래프트 모델로는 Inferact/Muse-Spark-open-DSpark를 쓰고 투기 토큰 수는 7로 설정합니다.

실행 경로: Day 0 이미지와 레시피

배포에 쓰는 컨테이너 이미지는 vllm/vllm-openai-rocm:muse-spark-open이고, 실행 레시피는 vllm-recipe에 공개되어 있습니다. 튜닝된 AITER MoE 테이블과 짧은 쿼리 어텐션 스케줄은 이미지에 들어 있고, V2 모델 러너와 중단 가능한 CUDA 그래프, AITER 선형·MoE 커널은 ROCm에서 이 모델에 대해 자동 선택됩니다. 운영자가 직접 켜는 것은 환경 변수 몇 개와 vLLM 플래그입니다.

요청은 OpenAI 호환 API를 그대로 씁니다. 추론 강도는 reasoning_effort로 minimal부터 xhigh까지 조절하고, 도구는 표준 tools 필드로 전달합니다. 기존에 OpenAI 호환 엔드포인트를 쓰던 사내 에이전트라면 모델 이름과 엔드포인트 교체로 연결이 됩니다. 레시피는 추론 파서와 도구 호출 파서로 musespark1x를 지정하고 --enable-auto-tool-choice를 켜도록 안내합니다.

한 가지 짚어둘 점은 세 레시피 모두 --max-model-len이 32768로 설정되어 있고 접두어 캐시를 끄고 청크 프리필을 켠다는 사실입니다. 모델 자체는 100만 토큰 컨텍스트를 지원하지만, 공개된 성능 수치와 권장 설정은 32k 길이 기준으로 측정되었습니다. 긴 컨텍스트를 실제로 쓰려면 KV 캐시 용량과 동시 요청 수를 다시 계산해야 합니다.

같은 주에 공개된 로컬 추론 경로

AMD는 같은 기간에 데이터센터 밖의 추론 경로도 함께 내놓았습니다. 자체 호스팅을 검토하는 조직이라면 서버급과 데스크톱급 선택지를 같이 보는 편이 유용합니다.

Introducing FastFlow-SDK는 Ryzen AI NPU를 대상으로 하는 로컬 AI 개발 스택입니다. OpenAI 호환 스트리밍 API로 모델을 서빙하는 FastFlow, NPU를 직접 프로그래밍하는 Python API인 IRON, 실행을 담당하는 런타임 HRX로 구성됩니다. FastFlow는 도구 호출과 추론 모델을 지원해 NPU에서 에이전트 워크플로를 돌릴 수 있다고 설명합니다.

MiniCPM-V 4.7 Day 0 지원은 Radeon GPU와 Ryzen AI Max 내장 GPU, Ryzen AI NPU에서 1B과 35B-A3B 변형의 이미지·텍스트 추론이 동작함을 확인한 내용입니다. Radeon AI PRO R9700과 Radeon PRO W7900D, Radeon 8060S 조합에서 모두 통과했으며, 다만 이 검증은 기능 정확성에 한정되어 처리량과 첫 토큰 시간, 메모리 사용량은 보고되지 않았습니다. NPU 경로에서는 Ryzen AI Max+ 395 시스템에서 1B 모델의 첫 토큰 시간이 약 1.2초, 디코딩 속도가 컨텍스트 1K에서 32K 구간에 걸쳐 약 44에서 23 tok/s로 측정되었습니다.

Ryzen AI Halo 개발자 플랫폼은 최대 192GB 통합 메모리를 싣고 그중 160GB까지를 GPU VRAM으로 할당할 수 있으며, 4비트 양자화에서 3,000억 파라미터 이상 모델을 지원한다고 밝혔습니다. 비교 성능 수치는 AMD 자체 테스트 결과이므로 각주의 측정 조건을 함께 확인해야 합니다.

남는 질문과 한계

원문은 활성화와 최적화를 다룬 기술 글이고, 도입 판단에 필요한 항목 일부는 여기서 답이 나오지 않습니다.

첫째, 보고된 처리량은 모두 동일 노드 구성에서의 상대 비교입니다. 다른 벤더 가속기와의 비교나 총소유비용 계산은 글에 없습니다. 둘째, 품질 지표가 GSM8K 하나이므로 코딩 에이전트 과업에서 MXFP4 양자화의 영향은 조직이 자체 과업으로 다시 측정해야 합니다. 셋째, 레시피는 Hugging Face 체크포인트와 공개 컨테이너 레지스트리를 전제로 합니다. 폐쇄망에서 쓰려면 이미지와 가중치, 드래프트 모델까지 사전에 내부 저장소로 옮기는 절차가 따로 필요합니다. 넷째, MI350X 또는 MI355X 8장 노드의 국내 조달 가능성과 납기, ROCm 7.2 환경을 운영할 인력은 글의 범위 밖입니다.

우리나라 기업이 확인할 것

  • 모델 크기를 메모리 조건으로 환산해 보십시오. 총 8,160억 파라미터 모델이 HBM3E 288GB GPU 8장 한 노드에 들어가고 토큰당 활성 파라미터가 420억 개라는 점이, 자체 호스팅 비용 계산의 출발점입니다. 노드 한 대로 끝나는지 여러 대가 필요한지가 전력과 상면 요건을 결정합니다.
  • 부하 프로파일을 먼저 정의하십시오. 원문의 권고는 동시 요청 64개를 경계로 구성이 갈립니다. 사내 코딩 에이전트의 동시 사용자 수와 요청 길이를 모르는 상태에서는 투기적 디코딩을 켤지 전문가 병렬로 갈지 판단할 수 없습니다.
  • 양자화 영향은 자체 과업으로 검증하십시오. GSM8K 94.4~95.5%는 수학 추론 기준의 확인이며, 다중 파일 리팩터링이나 장시간 디버깅 품질을 보장하지 않습니다. 사내 코드베이스에서 돌리는 평가 세트를 먼저 만드는 편이 순서상 맞습니다.
  • 컨텍스트 목표를 분리해 검토하십시오. 모델은 100만 토큰을 지원하지만 공개된 권장 설정은 32k 기준입니다. 긴 문서나 대형 저장소를 한 번에 넣으려는 계획이 있다면 KV 캐시 용량과 동시 처리량을 다시 산정해야 합니다.
  • 공급처 다변화의 실익을 조달 조건으로 확인하십시오. 개방가중치 모델에 공개 당일 지원이 붙는다는 사실은 가속기 선택의 폭을 넓히지만, 실제 효과는 납기와 가격, ROCm 스택 운영 역량에서 결정됩니다. 파일럿 단계에서 vLLM 레시피를 그대로 재현해 보는 것이 가장 빠른 검증입니다.

출처: Day 0 Enablement and Optimization for Muse Spark Open on AMD Instinct GPUs, Introducing FastFlow-SDK: Run, Customize, and Optimize Local AI, MiniCPM-V 4.7 Gets Day 0 Support Across AMD Radeon GPUs, Ryzen AI integrated GPUs, and Ryzen AI NPU, Meet the Next AMD Ryzen AI Halo

김지우 (Tristan Kim)

코텍시스 창업자로 AX 컨설팅과 기업 AI 교육, AI 에이전트 개발을 직접 수행합니다.

임직원 AI 교육

AX 성숙도 진단부터 PoC 연계형 교육까지, 기업의 AI 역량을 체계적으로 강화합니다.