Hunyuan Hy3: 295B MoE의 21B 활성 파라미터·MTP 레이어·Expert Parallelism으로 오픈소스 추론 에이전트를 배포하는 방법

왜 지금 봐야 하나

2026년 7월 6일, Tencent Hunyuan 팀이 Hy3를 Apache 2.0으로 공개했다. 숫자만 보면 295B 파라미터 MoE 모델이지만, 실제로 중요한 건 세 가지다.

첫째, 21B 활성 파라미터. 추론 시 포워드 패스당 192개 전문가 중 상위 8개만 활성화된다. 21B 활성 규모에서 40~70B 밀집 모델 수준의 벤치마크 결과를 낸다.

둘째, MTP 레이어 내장. 3.8B 파라미터짜리 Multi-Token Prediction 레이어가 메인 모델에 붙어 있다. 별도 드래프트 모델 없이 투기적 디코딩을 쓸 수 있어 처리량이 오른다.

셋째, 오픈소스 에이전트 모델. 도구 호출 안정화와 장문 컨텍스트 멀티턴 최적화가 훈련에 포함됐다. 256K 컨텍스트에서 에이전트 루프를 돌리는 걸 전제로 설계됐다.

이 글은 Hy3의 MoE 아키텍처, MTP 레이어 작동 방식, Expert Parallelism 기반 배포 구성, 그리고 운영 판단 기준을 다룬다.

모델 스펙 요약

MoE 아키텍처: 192개 전문가와 이형 전문가 구성

기본 MoE 구조

MoE(Mixture-of-Experts) 레이어는 각 토큰마다 전체 전문가 집합 중 일부만 선택해 계산한다. Hy3의 라우터는 토큰 표현을 보고 192개 전문가 중 상위 8개를 선택한다. 선택된 8개 전문가의 출력이 가중 합산되어 다음 레이어로 전달된다.

공유 전문가(shared expert) 1개는 모든 토큰에 항상 적용된다. 라우팅 결정과 무관하게 기본 피처를 처리하는 역할이다.

이형 전문가 크기

Hy3 문서에서 눈에 띄는 부분은 전문가들이 동일한 크기가 아니라는 점이다. 일부 전문가는 더 넓어 일반적인 도메인 간 라우팅을 처리하고, 다른 전문가는 더 좁아 다단계 수학 추론이나 도구 호출 시퀀싱 같은 추론 집약적 하위 문제를 전담한다.

라우터는 균일하게 크기가 조정된 전문가가 아니라 적절하게 크기가 조정된 전문가에게 토큰을 보내도록 학습된다. 21B 활성 파라미터에서 40~70B 활성 파라미터 모델과 동등한 출력 품질을 내는 배경이 여기에 있다.

MTP 레이어: 투기적 디코딩을 내장한 방법

전통적 투기적 디코딩의 비용

표준 투기적 디코딩은 소형 드래프트 모델이 다음 N개 토큰을 먼저 생성하고, 대형 타깃 모델이 이를 한 번에 검증하는 구조다. 처리량을 높이지만, 드래프트 모델을 별도 VRAM에 올리고 두 모델의 생명주기를 함께 관리해야 한다.

MTP 레이어의 작동

Hy3는 3.8B 파라미터짜리 MTP 레이어를 아키텍처에 직접 붙였다. 이 레이어가 다음 2개 토큰을 동시에 드래프팅한다. vLLM은 이 MTP 레이어를 드래프트 모델로 인식해, 메인 모델 포워드 패스가 검증 역할을 한다.

• 별도 드래프트 모델 불필요 → VRAM 절약, 운영 단순화
• 2개 투기 토큰 → 수락률에 따라 처리량 최대 2배 가능
• 드래프트와 검증이 같은 가중치 공간에서 이루어지므로 정렬이 더 좋다
• MTP 레이어는 메인 모델과 함께 공동 훈련됨 → 독립 학습된 드래프터보다 긴 드래프트 체인에서 더 안정적

vLLM 기준 설정:

speculative_config = {
    "method": "mtp",
    "num_speculative_tokens": 2
}

GQA와 KV 캐시 효율

Hy3는 Grouped Query Attention(GQA)을 사용한다. 64개 쿼리 헤드가 8개 KV 헤드를 공유한다. 각 헤드 차원은 128이다.

256K 토큰 컨텍스트에서 KV 캐시 메모리는 무시할 수 없다.

KV 캐시 크기 (레이어당, BF16):

K 캐시: 256K × 8 KV heads × 128 dim × 2 bytes = 512MB / 레이어
V 캐시: 동일

80개 레이어 기준 최대 256K 컨텍스트 시 KV 캐시 총량: 약 80GB.

이것이 단일 8×H100-80G 노드에서 BF16 전체 모델을 올리기 어려운 이유다. 모델 가중치 600GB + KV 캐시를 합산하면 2노드가 현실적이다.

배포 아키텍처: Expert Parallelism과 Multi-Node

Expert Parallelism이 필요한 이유

Hy3의 192개 전문가 가중치가 총 파라미터의 대부분을 차지한다. 단일 GPU에 모두 올리면 메모리 한계에 걸린다. Expert Parallelism(EP)은 전문가들을 여러 GPU에 분산 배치한다.

• GPU 0~N: 각자 다른 전문가 집합 보유
• 라우터가 토큰별 전문가를 선택하면 해당 GPU로 토큰을 전송
• 선택된 전문가 계산 후 결과를 다시 집계

EP와 Tensor Parallelism(TP)을 함께 써서 각 전문가 내부 계산도 분산할 수 있다.

권장 배포 구성

vLLM 멀티노드 배포 예시

# 노드 0 (Leader)
vllm serve tencent/Hy3 \
    --tensor-parallel-size 16 \
    --pipeline-parallel-size 1 \
    --speculative-config '{"method":"mtp","num_speculative_tokens":2}' \
    --max-model-len 32768

# Kubernetes: LeaderWorkerSet으로 2노드 Pod 묶기
# lws.kubernetes.io/name: hy3-inference

훈련 방향과 에이전트 최적화

Hy3는 세 가지 훈련 방향이 제품 품질에 직접 반영된다.

도구 호출 안정화: 50개 이상의 내부 서비스에서 피드백을 받아 도구 호출 출력 형식의 일관성과 신뢰성을 높였다. 에이전트 파이프라인에서 파싱 실패율을 줄이는 게 목표였다.

반환각 훈련: 사실 기반 응답을 우선시하도록 강화학습 신호를 설계했다. 도구 응답을 신뢰하고 자신의 파라미터 지식과 충돌할 때 도구 응답을 우선하도록 유도한다.

멀티턴 컨텍스트 유지: 256K 컨텍스트에서 긴 대화 이력을 유지하면서 초기 지시사항을 잊지 않도록 최적화됐다. 오래 실행되는 에이전트 세션에서 목표 추적 능력이 유지된다.

성능 기준점

전문가 맹검 평가에서 2.67/4.0은 GPT-4 급 모델들과 경쟁하는 수준이다. AIME/SWE-Bench 세부 수치는 공개 문서에서 확인이 필요하다.

운영 판단 기준

이 모델이 적합한 경우

• Apache 2.0 라이선스가 필요한 상업적 에이전트 프로덕션 배포
• 256K 컨텍스트의 장문 멀티턴 에이전트 워크로드
• 도구 호출 안정성이 중요한 코딩·분석 자동화 파이프라인
• 21B 활성 파라미터 대비 높은 품질을 원하는 비용 효율형 추론

주의해야 할 경우

• BF16 전체 모델은 ~600GB — 2× 8× H100-80G 이상 또는 대용량 메모리 GPU 필요
• 단일 노드 배포는 H20-3e처럼 노드당 메모리가 충분한 구성에서만 가능
• AIME/SWE-Bench 세부 수치가 공개 문서에서 확인 전 — 벤치마크 직접 측정 권장
• MTP 투기 디코딩 수락률은 도메인과 프롬프트 길이에 따라 달라진다 — 실환경 측정 필요

Open Questions

• 공식 AIME·LiveCodeBench·SWE-Bench Verified 수치는 기술 보고서 공개 후 확인 필요
• 이형 전문가 크기의 정확한 구성(각 전문가의 intermediate\_size 분포)은 공개 문서에 미기재
• FP8 또는 INT4 양자화 체크포인트의 공식 지원 여부와 MTP 레이어 동작 보존 방법 미확인
• Hy3-preview와 Hy3 정식 릴리스 간 성능 차이의 공개 분석 대기 중

References

• Tencent Hunyuan Hy3 GitHub
• vLLM Recipes: tencent/Hy3
• Spheron: Deploy Hunyuan 3 on GPU Cloud
• Hyperstack: Deploy Hy3-preview on Kubernetes (Multi-Node)
• Kie.ai: What Is Hy3? Tencent's 295B Open-Source MoE
• AI Wiki: Tencent Hunyuan Hy3
• HuggingFace Blog: Hy3 preview — A Rebuilt Hunyuan
• llama.cpp PR #25395: Hy3 MTP speculative decoding support