49B만 활성화하는 770B 모델, Hy4를 장비 사기 전에 읽는 법

먼저 확인된 숫자부터 분리한다

Tencent가 공개한 Hy4 Preview의 백본은 총 770B 파라미터이며, 토큰마다 활성화되는 파라미터는 49B다. 문맥 길이는 최대 1M 토큰이고 Apache-2.0 라이선스로 공개됐다. 현재 공개 모델은 텍스트 생성용이며 이미지 입력 모델은 아니다.

백본은 78개 층으로 구성된다. 첫 번째 층은 일반 피드포워드 구조이고 나머지 77개는 MoE 층이다. 각 MoE 층에는 256개의 선택형 전문가와 1개의 공용 전문가가 있으며, 토큰마다 선택형 전문가 8개와 공용 전문가가 계산에 참여한다.

Hugging Face의 배포본이 약 780B로 표시되는 것은 별도의 MTP 레이어 10B가 포함되기 때문이다. 770B는 백본, 약 780B는 MTP까지 포함한 배포본이라는 차이다. 숫자가 다른 모델 두 개를 뜻하는 것은 아니다.

• 770B: Hy4 백본의 전체 파라미터
• 49B: 토큰마다 계산에 참여하는 활성 파라미터
• 약 780B: 10B MTP 레이어를 포함한 배포본 표기
• 1M: 최대 문맥 길이이며 정확도 보장 수치가 아님

EDITOR'S NOTE같은 모델을 설명하는 숫자라도 전체 규모, 계산 규모, 배포 규모를 섞으면 장비 요구사항을 잘못 판단하게 된다.

MoE는 큰 병원에서 필요한 전문의만 부르는 방식이다

MoE를 큰 종합병원으로 생각해 보자. 병원에는 여러 진료과의 전문의가 상주하지만 환자 한 명을 진료할 때 모든 의사가 모이지는 않는다. 접수 단계에서 증상을 보고 관련 전문의만 부른다. Hy4에서는 라우터가 이 접수 역할을 한다.

환자 한 명을 실제로 진료한 전문의 수는 활성 파라미터에 가깝다. 토큰당 계산량과 처리 속도를 이해할 때 중요하다. 그러나 어떤 질문이 들어올지 모르므로 다른 전문의도 병원에 상주해야 한다. 이 전체 인력이 총 파라미터이며, 모델 파일과 메모리 요구량을 생각할 때 중요하다.

따라서 49B active는 ‘49B 모델 파일만 있으면 된다’는 뜻이 아니다. 모든 전문가 가중치를 저장하고 필요한 장치에 배치한 뒤, 토큰마다 일부 전문가를 선택해 계산한다. MoE의 절감 효과는 주로 계산 경로에서 나오며 전체 가중치를 없애는 압축과는 다르다.

• 라우터: 토큰을 담당할 전문가를 선택한다.
• 활성 전문가: 해당 토큰의 계산 비용에 직접 영향을 준다.
• 전체 전문가: 모델 파일, 메모리 배치, 장치 간 통신 비용에 영향을 준다.

49B active인데 공개 파일은 왜 약 1.56TB인가

공개 저장소의 모델 파일 규모는 약 1.56TB로 분석된다. 이는 활성 파라미터만 따로 내려받는 구조가 아니라 전체 전문가의 가중치를 배포해야 한다는 점을 보여준다. 49B급 dense 모델을 운영했던 경험만으로 필요한 저장공간과 메모리를 추정하면 시작 단계에서 막힐 수 있다.

공식 vLLM 실행 예시는 tensor parallel size 8을 사용한다. 이는 여러 장치에 모델과 계산을 나누는 출발점이지만, 곧바로 특정 GPU 8장이면 모든 서비스 요구사항을 충족한다는 보장은 아니다. 사용 정밀도, 동시 요청 수, 문맥 길이, KV cache, 장치 간 대역폭에 따라 실제 구성이 달라진다.

특히 1M 문맥을 실제 서비스에서 사용하면 모델 가중치 외의 메모리와 지연 시간도 커질 수 있다. 최대 문맥 길이는 입력을 담을 수 있는 상한이지, 긴 자료에서 필요한 사실을 항상 정확히 찾는다는 품질 보증이 아니다.

• 가중치 저장공간과 로딩 시간을 먼저 계산한다.
• GPU 수뿐 아니라 장치 간 통신 대역폭을 확인한다.
• 실제 문맥 길이와 동시 요청 수를 넣어 KV cache를 추정한다.
• 장애 후 모델 재로딩과 트래픽 복구 시간을 측정한다.

EDITOR'S NOTE공식 예시의 8-way tensor parallel은 실행 방법의 예이지 운영 환경의 최소 사양이나 서비스 수준 보장이 아니다.

다운로드 전에 API로 검증하는 네 단계

첫째, 정답이나 완료 여부를 확인할 수 있는 대표 업무를 고른다. 예를 들어 장애 로그와 관련 저장소를 제공하고 원인 후보, 재현 절차, 회귀 테스트를 만들게 할 수 있다. 단순한 질의응답보다 실제 도구 사용과 산출물이 포함된 업무가 비교에 유리하다.

둘째, 입력 자료와 완료 기준을 고정한다. 기본 high reasoning과 no_think 옵션을 각각 실행해 같은 문제에서 깊은 추론이 실제로 도움이 되는지 확인한다. 빠른 응답이 중요한 작업에서는 no_think가 더 적합할 수 있고, 복잡한 분석에서는 high가 유리할 수 있다. 작업별로 측정해야 한다.

셋째, 결과의 말투가 아니라 운영 지표를 적는다. 재현 테스트 통과율, 완료 시간, 도구 호출 성공률, 입력·출력 비용, 사람이 수정한 시간을 한 표에 기록한다. 넷째, 최소 10건을 반복한 뒤 기존 모델과 비교한다. 한 번의 성공 사례로 전체 업무에 일반화하지 않는다.

• 과제: 지난 장애의 원인 분석과 재현 테스트 생성
• 조건: 같은 자료, 같은 도구, 같은 완료 기준
• 모드: high와 no_think 각각 실행
• 지표: 정답·시간·도구 성공률·비용·사람 수정 시간

EDITOR'S NOTE오류, 사람 검토 시간, 비용 중 하나도 개선하지 못한다면 770B라는 숫자만으로 도입할 이유는 부족하다.

벤치마크와 알려진 한계를 함께 읽어야 한다

Tencent는 내부 업무형 평가에서 Hy4가 일부 경쟁 모델보다 근소하게 앞섰다고 보고했다. 이 결과는 후보 모델을 고르는 참고자료가 될 수 있지만, 공급사가 수행한 내부 평가이므로 독립 검증과 구분해야 한다. 평가 과제와 실제 조직의 업무 분포가 다르면 순위도 달라질 수 있다.

공식 모델 카드는 답변이 필요 이상으로 길어지거나 검증을 반복할 수 있다는 한계를 적고 있다. 긴 추론이 항상 더 신뢰할 수 있는 결과를 뜻하지 않는다. 비용과 지연 시간이 늘고, 도구 호출이 반복되면 오히려 운영 실패 지점이 많아질 수 있다.

Preview 상태와 text-only 범위도 도입 문서에 명시해야 한다. 장점만 적고 알려진 한계를 생략하면 평가가 아니라 구매 제안서에 가까워진다. 모델 업데이트에 따라 행동과 비용이 달라질 가능성까지 포함해 재평가 시점을 정하는 편이 좋다.

• 공급사 내부 평가와 독립 평가를 분리한다.
• 긴 응답과 반복 검증이 비용·지연에 미치는 영향을 측정한다.
• Preview 업데이트 뒤 동일 과제를 다시 실행한다.

직접 호스팅은 모델 성능이 아니라 통제 요구로 결정한다

애플리케이션 팀은 API나 공식 서비스로 대표 과제 10건부터 비교하는 편이 빠르다. 데이터 반출 제한, 지연 시간, 비용, 사용자 경험을 측정한 뒤 직접 운영이 필요한지 판단할 수 있다. 모델 파일을 먼저 내려받는 것은 가장 비싼 질문부터 시작하는 셈이다.

직접 호스팅은 보안과 데이터 위치, 일정한 처리량, 모델 수정 필요성처럼 명확한 통제 요구가 있을 때 검토한다. 이때 GPU 구매비만 보지 말고 저장공간, 네트워크, 캐시, 모니터링, 장애 복구, 모델 업데이트와 롤백 비용을 합산해야 한다.

Hy4의 핵심은 770B라는 숫자 자체보다 큰 전문가 집합에서 필요한 경로만 계산하는 구조다. 이를 제대로 평가하려면 49B active를 로컬 요구 사양으로 오해하지 않고, API에서 업무 가치를 확인한 뒤 인프라 비용으로 넘어가야 한다.

• 앱 팀: API로 10개 대표 과제와 두 추론 모드를 비교한다.
• 인프라 팀: 가중치·메모리·통신·복구의 총비용을 계산한다.
• 보안 팀: 데이터 위치와 로그 보존, 외부 전송 조건을 확인한다.

EDITOR'S NOTEHy4는 개인 PC용 49B 모델이 아니라, 1.56TB급 가중치를 여러 GPU나 API로 평가해야 하는 770B MoE 모델이다.