Hy-SimulMT vs Hy-SimulMT-30B-A3B: 하나의 이름, 여섯 개의 파일, 두 개의 출력

입력: Hy-SimulMT를 Hugging Face에 넣으면 그 이름의 저장소는 찾을 수 없습니다. 여섯 개가 나오며, 그 모두가 Hy-SimulMT-30B-A3B라는 이름에 접미사가 붙은 형태입니다. 이것이 한 문장으로 정리한 전체 비교입니다. Hy-SimulMT는 Tencent Hunyuan이 2026년 10월 26일 발표에 붙인 이름으로, 언론 보도에서 화자보다 약 3초 뒤처져 작동한다고 묘사한 실시간 중국어↔영어 통역기입니다. Hy-SimulMT-30B-A3B는 실제로 다운로드할 수 있는 산출물에 붙은 이름입니다. 짧은 이름 아래에 더 작은 형제 모델도, dense 변형도, 그 뒤에 숨은 평범한 "base" 모델도 없습니다. 짧은 이름은 프로젝트이고, 긴 이름은 여섯 개 파일의 패밀리입니다. 다음은 대개 versus 페이지가 묻어 두는 결정입니다: 그 여섯 개 중 무엇을 실행할지, 그리고 자막 오버레이와 오디오 출력만 필요한 회의 피드에서 답이 왜 달라지는지입니다.

텐센트가 출시한 것, 그리고 그것을 무엇이라고 부르기로 했는지

Tencent의 자체 저장소는 Hy-SimulMT를 프로젝트 이름으로 취급합니다: "Tencent Hunyuan이 개발한 실시간 동시통역 모델." 모델 카드에서도 동일한 짧은 레이블로 분류합니다. 컬렉션 제목은 "Hy Simultaneous Interpretation Model"입니다. 그 자료 어디에도 패밀리와 그 구성원의 계층 구조가 정의되어 있지 않습니다 — Hy-SimulMT-Small도, Hy-SimulMT-Mini도, 80기가바이트 가속기가 없는 사람을 위한 dense 체크포인트도 없습니다. 공개된 모든 가중치는 동일한 30B급 mixture-of-experts 아키텍처입니다.

그래서 그 컬렉션의 여섯 항목은 어떤 의미에서도 여섯 개의 모델이 아닙니다. 그것들은 하나의 모델을 여섯 가지 방식으로 포장한 것입니다:

• Hy-SimulMT-30B-A3B — 번역 전용 출력, 전체 정밀도, safetensors.

• Hy-SimulMT-30B-A3B-Interleave — 원본 전사와 번역, 전체 정밀도, safetensors.

• Hy-SimulMT-30B-A3B-FP8 및 Hy-SimulMT-30B-A3B-Interleave-FP8 — 단일 GPU 서빙을 위해 의도된 8비트 부동소수점 빌드에서 동일한 두 가지 출력 형태입니다.

• Hy-SimulMT-30B-A3B-GGUF 및 Hy-SimulMT-30B-A3B-Interleave-GGUF — llama.cpp용으로 Q4_K_M 및 Q8_0으로 양자화된 동일한 두 가지 출력 형태입니다.

그 밑에 깔린 아키텍처는 304억 개 파라미터의 희소 모델로, 토큰당 약 30억 개 파라미터가 활성화됩니다. 48개 레이어, 토큰당 8개가 라우팅되고 1개가 공유되는 128개 전문가, 그리고 30초 창의 16kHz 오디오를 입력받는 24개 레이어 오디오 인코더로 구성됩니다. 주목할 부분은 바로 그 인코더 설계입니다. 이 모델은 완성된 파일을 받는 것이 아니라 오디오가 아직 도착하는 동안 소비하도록 설계되었습니다. 그래서 지연 시간 관련 주장과 벤치마크 관련 주장은 서로 다른 대상에서 측정되며, 둘 중 어느 것도 여섯 파일 중 어떤 파일이 그 수치를 만들어냈는지 알려주지 않습니다.

라이선스는 Apache-2.0이며 게이트가 없는데, 이는 이번 릴리스에서 가장 강력한 단일 사실입니다. 양식도, 허용적 사용 게이트도, 비상업적 조항도 없습니다. 상업적 사용, 수정 및 재배포가 허용되며, Tencent는 추론 서버와 함께 학습 툴킷을 공개하여 지속적 학습이 지원되지 않는 용도가 아니라 의도된 용도가 되도록 했습니다.

실제로 중요한 선택은 출력 형태입니다

두 full-precision 체크포인트 사이의 차이는 품질이 아닙니다. 그것은 모델이 말할 수 있는 내용입니다. Base 체크포인트는 번역만 내보내고 그 외에는 아무것도 내보내지 않습니다. Interleave 체크포인트는 인식된 원문 텍스트를 내보낸 다음 번역을 내보내며, 오디오 스트림처럼 인터리브됩니다.

표면적인 문제처럼 들리지만, 이런 시스템이 어디에 배포되는지를 보면 이야기가 달라집니다. TTS를 구동하는 실시간 회의 피드는 기본 체크포인트를 원합니다. 전사문은 출력 토큰을 소모하고, 모든 청크에 지연을 더하며, 유일한 소비자가 음성인 파이프라인에 원문 언어를 흘려보내는 쓸모없는 부담이기 때문입니다. 자막 오버레이, 규정 준수용 캡처, 이중 언어 전사, 또는 사람이 발언 내용과 번역을 대조해야 하는 모든 워크플로는 Interleave 체크포인트를 원합니다. 그 대안은 번역기 옆에 별도의 음성 인식기를 돌리면서 두 시스템이 오디오를 같은 방식으로 분절하기를 바라는 것인데, 그렇게 되지 않습니다.

Tencent의 자체 원클릭 배포 예제는 기본적으로 Interleave 변형을 사용합니다:

• bash deploy.sh --install-server --model tencent/Hy-SimulMT-30B-A3B-Interleave

데모에서는 소스 텍스트를 보여 주는 것이 시스템이 듣고 있음을 입증하므로, 그것은 합리적인 기본값입니다. 음성 전용 제품에서는 잘못된 기본값이며, 이번 릴리스에 대한 대부분의 보도가 건너뛰는 바로 그 세부 사항입니다. 토큰 비용이나 엔드투엔드 지연 시간으로 모델을 평가하고 있다면, 어떤 체크포인트를 로드했는지에 따라 다른 시스템을 측정하고 있는 것입니다.

Interleave에는 카드가 암시하지만 수치화하지는 않는 2차 비용이 있다. 스트리밍 트랜스크립트는 변경 가능하다. 더 많은 오디오가 도착하면 초기 출력이 수정될 수 있으므로, 부분 텍스트를 표시하는 클라이언트는 추가 전용 줄이 아니라 수정 사항을 받아들일 수 있도록 구축해야 한다. 이번 릴리스에 대한 AlphaSignal의 분석 글은 이 점을 직접적으로 지적하며, 이는 이틀짜리 프로토타입을 3주짜리로 바꾸는 종류의 통합 세부 사항이다.

벤치마크는 어떤 변형을 측정했는지 밝히지 않습니다.

텐센트는 단문 점수 네 개와 장문 지연 시간 수치 하나를 공개했으며, 모든 행에는 "Hy-SimulMT"라고 표시되어 있다 — "Hy-SimulMT-30B-A3B"도 아니고, 더더욱 base 대 Interleave도 아니다. 이것이 이번 발표의 솔직한 공백이며, 그 안의 어떤 단일 수치보다 더 중요하다.

• FLEURS — 90.3. Gemini3.5-LiveTranslate는 92.4점을 기록하므로, 이는 카테고리 우승이 아닙니다.

• CoVoST2 — 75.5으로, 82.1을 기록한 Qwen3.8-LiveTranslate에 뒤처집니다. 이는 표에서 가장 명백한 패배이며, 주요 보도에서 흔히 건너뛰는 부분입니다.

• ACL6060 — 81.2. Gemini3.5-LiveTranslate는 82.6점을 기록합니다.

• RealSI-Sentence — 84.7, 비교 세트에서 가장 높은 수치입니다.

• RealSI 장문 지연 시간 — 약 3초의 StreamLAAL로, 비교 대상 시스템 중 가장 낮은 수준이라고 설명됩니다.

이것들은 모두 공급업체가 직접 실행한 것입니다. 어느 것도 독립적으로 재현되지 않았으며, 설명 카드에는 StreamLAAL이 첫 음성 출력까지의 시간과 동일한 측정값이 아니라는 점이 명시되어 있습니다. 시연 영상은 오프라인 재생본이므로, 그 재생 타이밍 역시 실시간 지연 수치로 볼 수 없습니다. 이 표는 모델을 만든 연구소가 자체적으로 선택한 하네스에서, 변형(variant)의 이름은 밝히지 않은 채 제시한 일련의 주장으로 읽어야 합니다.

그 마지막 누락은 하드웨어만 갖추면 누구나 반나절이면 고칠 수 있다: 두 체크포인트를 같은 오디오에 실행하고 델타를 공개하면 된다. 누군가 그렇게 하기 전까지는, 공개된 수치가 번역 전용 경로를 설명한다고 보는 것이 합리적인 가정이다. 왜냐하면 그것이 더 깔끔한 측정이기 때문이다 — Interleave 변형은 더 많은 토큰을 내보내야 하고, 스트리밍 디코더에서 토큰이 더 많다는 것은 지연이 더 크다는 뜻이다. 하지만 그것은 가정일 뿐, 공개된 정보가 아니다.

형식은 세 번째 결정이며, GGUF 경로에는 함정이 있습니다.

전체 정밀도 체크포인트는 BF16 기준 약 61GB입니다. 이는 무리 없는 배포를 위한 실질적 하한을 80GB 가속기로 끌어올리며, 출시된 그대로 모델을 서비스할 의도라면 예산에 잡아야 하는 수치입니다. FP8 빌드는 바로 이 요구 사항을 더 작은 단일 카드로 낮추기 위해 존재하며, Tencent는 그렇게 포지셔닝합니다.

GGUF 경로는 여전히 더 저렴해 보이고, 파일 크기도 구체적입니다. Interleave GGUF 저장소에는 Q4_K_M이 19.7GB, Q8_0이 33.3GB로 나와 있습니다. 300억 개 매개변수 모델을 19.7GB로 양자화한다는 것은 "데이터센터용 카드가 필요하다"와 "워크스테이션에 들어간다"의 차이이며, 대부분의 사람이 가장 먼저 시도할 버전입니다.

문제는 이 아키텍처에 대한 llama.cpp 지원이 업스트림 저장소에 아직 병합되지 않았다는 점입니다. Tencent는 이미 실행 중인 오디오 지원 llama.cpp 서버를 전제로 하는 브리지를 제공하며, 여기에는 MODEL_TYPE 스위치가 있습니다. 번역 전용 체크포인트에는 target_only, 인터리브된 체크포인트에는 source_target을 사용하며, 문서에서는 공식 릴리스가 나올 때까지 기다리라고 권고합니다. 오늘날 양자화된 빌드를 실행한다는 것은 이 모델이 무엇인지 아직 모르는 llama.cpp 빌드 위에서 벤더 브리지를 실행하는 것을 의미합니다. 평가 목적이라면 합리적인 선택입니다. 하지만 제품을 위한 기반으로는 취약하며, 실패 모드는 벤더의 패치와 독립적으로 업그레이드할 수 없는 의존성입니다.

vLLM 경로의 경우 HYV3ForCausalLM 지원이 포함된 버전 0.31 이상과 simulst 패키지가 필요합니다. 다중 GPU 배포는 텐서 병렬 처리를 통해 지원됩니다. 단일 명령 설치 프로그램은 웹 및 API 서비스를 8080 포트에서, 모델 서버를 8800 포트에서 기동하며, 격리된 환경에서 실행됩니다. 즉, 기존 스택을 대상으로 지정하면 SimulInfer를 재설치하거나 종속성 버전을 변경할 수 있습니다. Tencent는 바로 그 이유로 단계별 절차를 문서화합니다.

서비스하는 데 필요한 것과 릴리스에 포함되지 않는 것

음성 출력과 음성 복제는 체크포인트의 속성이 아니다. 모델은 텍스트를 생성한다. 그 텍스트를 화자의 목소리로 음성으로 바꾸려면 별도로 구성된 TTS 서비스가 필요하며, 이 문장의 모든 요소에는 비용이 따른다: 운영해야 할 또 하나의 서비스, 지연 예산에 추가되는 또 하나의 네트워크 홉, 검토해야 할 또 하나의 벤더 약관, 그리고 마이크와 청취자 사이의 또 하나의 장애 지점. 모델 카드는 이 점을 분명히 밝히고 있으며, 이는 데모와 배포 가능한 통역기 사이의 가장 큰 단일 격차이다.

{{1}}호스팅된 API도 없고 공개된 가격도 없습니다{{/1}}. 텐센트의 소비자 접점은 {{2}}Hy Translate 앱{{/2}}으로, Android와 iOS에서 무료 티어를 제공합니다 — 모델이 무엇을 하는지 들어볼 수 있는 가장 저렴한 방법이지만, 프로덕션 의존성으로는 쓸모없습니다. 그 외의 모든 것은 직접 셀프 호스팅해야 하므로, 비용은 가속기, 운영 시간, TTS 청구서이지 스프레드시트에 넣을 수 있는 토큰당 요금이 아닙니다.

언어 지원 범위에도 같은 수준의 검증이 필요합니다. 설명문에는 중국어와 영어의 양방향이 문서화되어 있습니다. Hugging Face 메타데이터는 이 체크포인트에 36개 언어 태그를 붙여 두었습니다. 나머지 34개 언어의 목록은 공개되지 않았고, 저장소 자체의 예시는 모두 en-zh 또는 zh-en입니다. Tencent가 별도로 문서화하기 전까지는 해당 태그를 상속된 메타데이터로 간주하고, 태그 하나만 믿고 36개 언어 출시 계획을 세우지 마십시오.

두 번째 출처가 필요한 주장들

인간 통역사와의 비교는 이번 발표에서 가장 많이 인용된 주장이자 가장 근거가 약한 주장이다. 텐센트는 약 6분 분량의 새로 수집한 녹음 18개를 바탕으로 품질이 "숙련된 인간 동시통역사와 대등하면서도 종종 더 빠르게 응답한다"고 보고했는데, 이 녹음들은 10개 분야에서 가져온 것이며 경력 있는 통역사 6명 — CATTI 1급 보유자 3명과 2급 보유자 3명 — 이 평가했다. 각 급수별로는 세 통역사 중 가장 높은 점수가 사용되었다.

{{1}}그 마지막 세부 사항은 상당한 역할을 합니다.{{/1}} 단일 모델 실행에 맞서 세 번 중 최고를 취하는 것은 관대한 구성이며, 카드는 신뢰구간이나 도메인별 분석을 공개하지 않습니다. 또한 음성 복제에 대한 객관적인 화자 유사도 점수도 공개하지 않는데, 이는 배포가 현장에 있는 사람들에게 수용 가능하게 느껴질지를 가장 좌우할 가능성이 큰 기능입니다. {{2}}카드 자체가 밝힌 한계{{/2}} — 즉 이 결과가 표본과 참가자, 설정에 의해 제한되며 포괄적인 평가가 아니라는 점 — 이 올바른 해석입니다. 의료, 법률, 소음이 많은 대화형 오디오는 통역사 비교에 도메인별 수치가 꼭 필요한 영역이며, 바로 그 수치가 빠져 있습니다.

책임 소재, 전문가 검토 또는 중대한 이해가 걸린 결정이 관련된 상황이라면 전문 통역사가 여전히 올바른 선택입니다. 이는 비판자의 표현이 아니라 텐센트의 프레이밍이며, 이번 발표의 헤드라인 버전에는 그것이 담기지 않았기 때문에 다시 말할 가치가 있습니다.

직접 호스팅한다면, 그 뒤에 무언가를 두세요.

두 체크포인트 모두 OrcaRouter의 카탈로그에 없으므로 우리는 어느 쪽으로도 가는 경로가 아니며, 이 글도 그렇지 않은 척하지 않는다. 그렇다고 해서 라우터가 자체 호스팅 통역기와 무관해지는 것은 아니다 — 라우터를 엣지로 옮길 뿐이다. 실시간 번역 경로는 긴 사슬이다: 오디오 캡처, 모델 서버, 선택적 TTS 서비스, 그리고 클라이언트. 각 연결 고리는 멈출 수 있으며, 회의 중 멈춤은 약간 더 나쁜 번역보다 더 나쁘다. 호스팅된 텍스트 모델을 오디오 경로가 아니라 트랜스크립트 경로의 폴백으로서 같은 엔드포인트 뒤에 두면, 모델 서버가 죽으면 침묵하는 대신 읽을 수 있는 트랜스크립트로 전환된다는 뜻이다.

OrcaRouter는 200개 이상의 호스팅 모델을 아우르는 0% 마크업의 단일 API이며, 공급자 정가는 아무것도 더하지 않고 그대로 전달됩니다. 라우팅 DSL은 폴백 규칙을 표현하는 방식으로, 별도의 통합이 필요 없습니다. 여기서 중요한 부분은 자동 장애 조치입니다. 규칙은 사람이 자막이 멈춘 것을 알아차릴 때가 아니라 업스트림 장애가 발생하면 발동합니다.

그럼 어느 파일인가요?

그 이름들이 무엇을 가리키는지 알게 되면 대립 구도는 사라지고, 남는 것은 세 가지 정직한 답이 있는 패키징 결정입니다.

음성 제품을 만들고 있다면 — 회의 통역, 콜센터 오버레이, 출력이 오디오인 모든 경우 — Hy-SimulMT-30B-A3B를 선택하거나, 단일 80GB 카드가 제약이라면 FP8 빌드를 선택하세요. 전사본은 필요 없고, 전사본 생성 비용을 지불하고 싶지도 않으며, 기본 체크포인트가 지연 시간 측면에서 더 깔끔한 경로입니다.

사람이 출력을 읽을 예정이라면 다음을 선택하세요: Hy-SimulMT-30B-A3B-Interleave. 자막, 이중 언어 회의록, 규정 준수 캡처 및 검토 워크플로에는 모두 원문이 필요하며, 번역기와 별도로 인식기를 실행하면 문장이 어디서 끝났는지에 대해 서로 불일치하는 두 개의 전사본이 생깁니다.

배포가 아니라 평가 중이라면 Hy-SimulMT-30B-A3B-Interleave-GGUF의 Q4_K_M 버전을 택하고, 19.7 GB 파일과 병합되지 않은 llama.cpp 의존성을 감수하며, 이미 보유한 하드웨어에서 모델을 들어보는 방법으로 여기세요. 품질이 카드 값을 한다고 판단한 뒤에만 FP8 vLLM 경로로 업그레이드하세요.

쟁점은 어느 파일이 더 나은가가 아니다. 공개된 점수가 당신이 고른 파일을 설명하는지 여부다. Tencent에는 하루 만에 답할 수 있는 하드웨어가 있으며, 그렇게 하기 전까지 90.3이나 84.7을 인용하는 사람은 누구든 여섯 체크포인트 중 어느 것이 그것을 만들어냈다고 보는지 말해야 한다.