Deploying Qwen3.8-2.4T-A95B on Amazon SageMaker HyperPod with vLLM

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Qwen3.8-2.4T-A95B를 Amazon SageMaker HyperPod의 8개 B300 GPU 노드에서 NVFP4와 vLLM으로 구동하는 구성과 운영 요건을 설명하며, 단일 노드 실측 성능과 배포 절차의 후반부는 제공된 본문에서 확인되지 않는다.

📌 핵심 요약

• Alibaba의 Qwen 팀은 2026년 8월 12일 Qwen-Max급 최초의 공개 가중치 모델 Qwen3.8-2.4T-A95B를 출시했다. 전체 파라미터는 2.4조 개이고 토큰당 950억 개가 활성화되며, 기본 문맥은 262,144토큰, 확장 문맥은 1,010,000토큰이다.
• 모델은 69개 Gated DeltaNet 계층과 23개 완전 어텐션 계층을 결합한다. 고정 크기의 순환 상태로 긴 문맥의 메모리 부담을 줄이고, reasoning_effort와 기본 활성화된 추론 기능으로 복잡한 에이전트 작업을 지원한다.
• NVFP4 양자화는 가중치 메모리를 BF16 기준 약 4.8TB에서 약 1.2TB로 줄여, 총 GPU 메모리 2.1TB로 제시된 ml.p6-b300.48xlarge의 8개 NVIDIA B300 GPU에 적재할 수 있게 한다. 이 인스턴스는 온디맨드로 제공되지 않으며 Flexible Training Plan을 통한 용량 예약이 필요하다.
• Amazon SageMaker HyperPod는 Amazon EKS와 Inference Operator를 통해 가중치 다운로드, GPU 할당, 상태 확인, 업데이트, 자동 확장과 장애 노드 교체를 관리한다. vLLM 구성에는 8분할 텐서 병렬화, NVFP4, 접두사 캐싱, 추론·도구 호출 파서와 네이티브 MTP가 포함된다.
• 공급업체 벤치마크는 PaperBench 93.0, IFBench 82.8, 터미널 기반 코딩 86.6을 제시하지만 SWE-bench Pro와 Toolathlon에는 개선 여지가 있다고 설명한다. 처리량 참고치는 72개 GPU의 GB300 NVL72에서 FP8로 측정한 결과로 단일 B300 노드의 NVFP4 실측값이 아니며, 제공된 본문은 MTP 설명 도중 끝난다.

🧩 주요 포인트

1. 공개 가중치로 데이터와 추론 동작을 직접 통제할 수 있음 → 토큰당 API 요금 대신 2.4조 파라미터 모델의 인프라 확보와 운영 부담을 감수해야 한다.
2. NVFP4와 하이브리드 어텐션이 단일 노드 적재와 문맥 확장을 지원함 → 가중치가 들어가는지와 별개로 완전 어텐션의 KV-cache, 배치 크기, 문맥 길이에 따른 메모리 여유를 평가해야 한다.
3. HyperPod의 운영 자동화와 vLLM의 추론·도구 호출 기능을 결합함 → 배포 기반은 제시되지만, 단일 노드 처리량과 실제 작업 적합성은 공급업체 벤치마크만으로 확정할 수 없다.

🧠 상세 정리

1. 공개 가중치 모델의 등장과 배포 목표

Alibaba의 Qwen 팀은 2026년 8월 12일 Qwen3.8-2.4T-A95B를 공개했으며, 원문은 이를 Qwen-Max급 모델의 첫 공개 가중치 출시이자 Qwen3.8-Max의 공개 버전으로 소개한다. 전체 2.4조 파라미터 중 토큰당 950억 개를 활성화하는 이 모델은 다단계 코딩, 장기 계획, 자율적 도구 사용 등 복잡한 에이전트·추론 작업을 겨냥한다. 공개 가중치는 데이터를 자체 인프라에 유지하고 추론 동작을 조정하며 대규모 사용 시 토큰당 API 요금을 피할 수 있게 하지만, 전용 GPU 인프라와 최적화된 서빙 구성을 운영해야 하는 부담도 따른다. 글의 목표는 Amazon SageMaker HyperPod의 8개 NVIDIA B300 GPU 인스턴스에서 vLLM으로 모델을 구동하고 OpenAI 호환 엔드포인트를 제공하는 경로를 설명하는 것이다. 이는 Kimi K3 배포 글에 이은 시리즈의 두 번째 글이지만, 제공된 본문은 MTP 설명 중간에서 끝나므로 이후의 실제 배포·호출 절차까지 확인할 수는 없다.

2. MoE와 하이브리드 어텐션의 구조

Qwen3.8-2.4T-A95B는 512개 라우팅 전문가와 1개 공유 전문가를 갖춘 세분화된 MoE 구조이며, 토큰마다 라우팅 전문가 10개가 활성화된다. 총 92개 계층은 Gated DeltaNet과 MoE의 조합을 세 번 배치한 뒤 Gated Attention과 MoE를 한 번 배치하는 패턴을 반복한다. 이에 따라 69개 DeltaNet 계층은 고정 크기 순환 상태를 사용하는 선형 어텐션으로 문맥 증가에 따른 메모리 부담을 줄이고, 23개 완전 어텐션 계층은 토큰 사이의 정밀한 상호작용을 담당한다. 기본 문맥 길이는 262,144토큰이고 1,010,000토큰까지 확장할 수 있으며, 최대 출력 길이는 128K토큰으로 제시된다. 원문은 이 구성이 도구 출력, 코드, 추론 기록이 여러 턴에 걸쳐 누적되는 작업에 유리하다고 설명하지만, 완전 어텐션 계층의 KV-cache는 여전히 문맥 길이에 따라 증가한다. 또한 활성 파라미터를 기준으로 연산 비용의 이점을 설명하는 한편, 가중치 저장에는 전체 모델을 수용할 메모리가 필요하다는 점을 별도로 다룬다.

3. 추론 제어와 벤치마크의 의미

모델은 다단계 코딩과 자율적 도구 사용 외에도 장기 계획 및 복잡한 연구 작업을 주요 용도로 제시하며, 요청별 reasoning_effort를 low, medium, high로 조절할 수 있다. 개발자는 어려운 다단계 문제에는 더 깊은 추론을 사용하고 처리량이 중요한 작업에는 추론 강도를 낮추는 방식으로 연산량과 추론 깊이를 조정할 수 있다. 공급업체가 제시한 벤치마크 결과는 연구 작업의 PaperBench 93.0, 지시 준수의 IFBench 82.8, 터미널 기반 코딩 86.6이며, 원문은 대부분의 범주에서 선도 모델과 비교할 만한 성능이라고 평가한다. 동시에 더 어려운 저장소 단위 작업인 SWE-bench Pro와 일반 도구 사용 평가인 Toolathlon에는 개선 여지가 있다고 명시한다. 따라서 코딩 에이전트와 연구 파이프라인을 위한 자체 호스팅 대안이라는 주장은 공급업체 평가에 근거한 것이며, 본문에는 해당 배포 환경에서 이 점수를 독립적으로 재현한 결과가 제시되지 않는다.

4. HyperPod가 담당하는 운영과 복원력

원문은 2.4조 파라미터 모델 배포가 GPU 확보만의 문제가 아니라 다운로드, 컨테이너 스케줄링, 상태 감시, 자동 확장 및 노드 장애 대응을 함께 요구하는 운영 문제라고 설명한다. HyperPod는 Amazon EKS를 제어 영역으로 사용해 kubectl, Helm, 사용자 정의 리소스를 활용하게 하면서, AWS가 네트워크와 스토리지, GPU 드라이버 및 NVIDIA 장치 플러그인 등 기반 인프라의 수명주기를 관리하도록 한다. Inference Operator의 InferenceEndpointConfig에는 모델, 컨테이너 이미지, GPU 요청량, vLLM 실행 인수를 선언하며, 운영자는 Hugging Face Hub·Amazon S3·Amazon FSx에서의 가중치 다운로드와 GPU 할당, 상태 확인, 준비 상태 판정, 순차 업데이트를 처리한다. 자동 확장은 KEDA와 Amazon CloudWatch 또는 Prometheus 지표를 통해 지원하고, HyperPod는 노드 상태를 지속적으로 감시해 성능이 저하된 노드를 자동 교체한다. Inference Operator v3.x의 추가 기능으로는 프리필과 디코드를 서로 다른 GPU 풀에 배치하는 DPD, 추론 데이터 캡처, 로컬 NVMe 기반 모델 적재, Amazon Route 53의 사용자 지정 도메인 레코드 관리가 소개된다.

5. B300 노드 사양과 예약 용량 요건

단일 노드 구성에 사용되는 ml.p6-b300.48xlarge는 NVIDIA B300 Blackwell Ultra GPU 8개를 제공하며, 원문은 GPU당 HBM3e 288GB와 총 GPU 메모리 2.1TB를 사양으로 제시한다. GPU당 메모리 대역폭은 초당 8TB이고, NVLink와 NVSwitch 연결의 양분 대역폭은 초당 14.4TB이며, FP4 연산 성능은 GPU당 약 15PFLOPS, 총 약 120PFLOPS로 소개된다. 호스트 자원에는 Intel Xeon Emerald Rapids 기반 vCPU 192개, 시스템 메모리 4,096GiB, 6,400Gbps EFA 네트워크, 3.8TB 로컬 NVMe SSD가 포함된다. 이 인스턴스는 온디맨드로 사용할 수 없으므로 Flexible Training Plan을 통해 HyperPod 클러스터에 할당할 GPU 가용 용량을 예약해야 한다. 인스턴스 그룹의 대상 가용 영역도 예약된 할당의 가용 영역과 일치시켜야 하며, 원문은 이러한 예약 방식이 온디맨드 풀의 경쟁과 시작 시점의 용량 확보 위험을 줄인다고 설명한다.

6. NVFP4 메모리 예산과 처리량의 한계

모델 가중치는 Hugging Face에 표준 Transformers 형식으로 공개되며, 커뮤니티 양자화로 MXFP4와 NVFP4가 소개되고 실제 서빙 예시는 NVFP4의 W4A4 구성을 사용한다. BF16에서는 가중치만 약 4.8TB가 필요해 단일 8-GPU 노드를 초과하지만, 파라미터당 약 4비트로 줄이면 약 1.2TB가 되어 총 2.1TB로 제시된 GPU 메모리에 적재할 수 있다. 대략적인 메모리 예산은 DeltaNet 순환 상태 약 50~100GB, 활성값과 프레임워크·텐서 병렬 버퍼 등의 부가 사용량 약 100~200GB, 배치와 긴 문맥을 위한 여유 약 500~700GB로 제시된다. 다만 23개 완전 어텐션 계층의 KV-cache 사용량은 문맥 길이 등에 따라 달라지므로, 이 수치는 고정된 동시 처리 용량을 보장하는 값이 아니다. 처리량 참고치는 NVIDIA의 GB300 NVL72 초기 벤치마크에서 FP8과 GPU 72개를 사용해 얻은 GPU당 초당 4천 토큰 초과, 사용자당 초당 350토큰 초과이며, 단일 8-GPU NVFP4 노드의 직접 측정 결과는 아니다. 원문은 단일 노드의 전체 처리량이 더 낮겠지만 적당한 동시성을 가진 운영 환경에는 적합할 것으로 설명한다.

7. vLLM 기본 실행 구성

기본 명령은 Inferact/Qwen3.8-2.4T-A95B-NVFP4를 vllm serve로 실행하고, --tensor-parallel-size 8로 모델을 B300 GPU 8개에 분산하며 --quantization nvfp4로 양자화 형식을 지정한다. --load-format fastsafetensors는 가중치 역직렬화를 가속해 초기 구동 시간을 줄이고, --trust-remote-code는 Hugging Face에 있는 Qwen3.8의 사용자 정의 모델 코드를 사용하기 위해 필요하다고 설명한다. --enable-prefix-caching은 공통 프롬프트 접두사의 계산된 KV-cache를 재사용하므로, 시스템 프롬프트와 대화 기록이 반복되는 여러 턴의 에이전트 작업에서 중요하게 다뤄진다. --moe-backend auto는 하드웨어에 맞는 MoE 디스패치 커널을 vLLM이 선택하도록 하고, --served-model-name Qwen3.8은 API에 노출할 모델 이름을 설정한다. 이 기본 구성에는 qwen3 추론·도구 호출 파서와 MTP 추측 디코딩도 함께 포함되며, 원문은 B300에서 NVFP4로 Qwen3.8을 실행하는 vLLM 레시피를 설정의 근거로 제시한다.

8. 추론 출력, 도구 호출과 네이티브 MTP

--reasoning-parser qwen3는 모델의 <think>...</think> 블록을 추출해 reasoning_content와 최종 답변인 content를 분리하며, Qwen3.8의 추론 기능은 기본적으로 활성화되어 있다고 설명한다. 요청별로 chat_template_kwargs의 enable_thinking을 false로 설정하면 추론을 끌 수 있고, guided_json과 guided_regex 같은 구조화 출력 제약은 content에만 적용되어 추론 기능과 함께 사용할 수 있다. --enable-auto-tool-choice와 --tool-call-parser qwen3는 OpenAI 호환 함수 호출을 활성화하며, tool_choice는 auto, required, none과 특정 함수 지정을 지원한다. 도구 호출은 reasoning_content가 아닌 content에서만 파싱되고, tool_choice가 auto이면서 도구 정의에 strict: true가 설정되면 도구 인수에 스키마 제약 디코딩을 적용한다. 네이티브 MTP는 별도 모델 없이 내장 초안 헤드로 추측 디코딩을 수행하는 기능으로 소개되며, 실행 예시는 method를 mtp, num_speculative_tokens를 1로 설정한다. 다만 제공된 본문은 이 기능의 상세 설명 중간에서 끝나므로, 이후의 추가 설정이나 성능 효과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 토큰당 활성 파라미터가 950억 개라는 연산상의 이점과 전체 2.4조 파라미터를 저장해야 하는 메모리 요구는 별개다. 단일 노드 배포 가능성은 MoE뿐 아니라 NVFP4 압축과 B300의 메모리 용량에 함께 의존한다.
• 하이브리드 어텐션은 긴 문맥의 메모리 부담을 줄이지만, 23개 완전 어텐션 계층 때문에 문맥 길이에 따른 KV-cache 증가는 남는다. 최대 문맥 지원과 실제 배치·동시성 수용 능력은 구분해 판단해야 한다.
• HyperPod와 vLLM은 운영 및 기능 구현의 기반을 제공하지만, 공급업체의 작업별 평가와 72개 GPU의 FP8 처리량은 서로 다른 근거다. 두 결과만으로 단일 노드 NVFP4 배포의 성능을 확정할 수 없다.

✅ 액션 아이템

• ml.p6-b300.48xlarge 도입 시 Flexible Training Plan의 용량 예약 가능 여부를 확인한다.
• NVFP4 적용 시 가중치 약 1.2TB와 완전 어텐션의 KV-cache를 함께 고려해 문맥 길이·배치 크기별 메모리 적합성을 평가한다.
• Qwen3.8-2.4T-A95B의 실제 작업 적합성과 단일 B300 노드의 NVFP4 처리량을 검증한다.

❓ 열린 질문

• Flexible Training Plan으로 필요한 ml.p6-b300.48xlarge 용량을 확보할 수 있는가?
• NVFP4 가중치 약 1.2TB를 적재한 뒤 완전 어텐션의 KV-cache를 고려하면 어느 문맥 길이와 배치 크기까지 수용할 수 있는가?
• 단일 B300 노드의 NVFP4 실측 처리량과 SWE-bench Pro·Toolathlon 관련 작업 성능은 실제 사용 요구를 충족하는가?