
Hy-SimulMT 대 NLLB-200: 스트리밍 통역기는 200개 언어 번역기가 아니다
- OrcaNEWOrcaCyber: MiMo V2.6 Flash Abliterated2026-10-26$0.80 / $1.60 100만 토큰당 · 124 tok/s
- MoonshotNEWMoonshotAI: Kimi K3.1 Pro2026-10-2455지능
- OrcaNEWOrcaCyber: DeepSeek V4.1 Flash Abliterated2026-10-23$0.80 / $1.60 100만 토큰당 · 166 tok/s
- minimaxNEWMiniMax: M3.1 Flash2026-10-1943지능
- OrcaNEWOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 100만 토큰당 · 42 tok/s
- deepseekNEWDeepSeek: DeepSeek V4.1 Flash 10172026-10-1745지능
- DeepSeekNEWDeepSeek: DeepSeek V4.1 Flash2026-10-1740지능
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 100만 토큰당 · 130 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952지능
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856지능
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 100만 토큰당 · 663 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238지능
- OpenAIOpenAI: GPT-6 Sol2026-09-2248지능
- AnthropicAnthropic: Claude Opus 5.52026-09-2258지능
- xiaomiXiaomi: MiMo-V2.6-Flash2026-09-21$0.14 / $0.28 100만 토큰당 · 31 tok/s
- xiaomiXiaomi: MiMo-V2.6-Pro2026-09-21$0.43 / $0.87 100만 토큰당 · 44 tok/s
- xAIGrok 4.72026-09-2146지능
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 100만 토큰당 · 228 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 100만 토큰당 · 1906 tok/s
- OpenAIOpenAI: GPT-6 Astra2026-09-0453지능77코딩
두 벤치마크 이름은 한 글자만 다르고, 그 한 글자가 이 글 전체를 좌우한다. Hy-SimulMT는 2026년 10월 26일 공개된 Tencent Hunyuan의 실시간 중국어↔영어 통역기로, FLEURS라는 벤치마크에서 90.3점을 발표했다. NLLB-200은 2022년 7월 Meta AI가 내놓은 200개 언어 텍스트 번역기이며, FLORES-200이라는 벤치마크에서 평가된다. 둘은 관련이 있다 — FLEURS는 FLORES 문장을 소리 내어 읽은 것으로 구성된다 — 하지만 같은 테스트가 아니고, 점수 산정 방식도 같지 않으며, 이 두 모델을 서로 맞붙여 실행한 사람은 아무도 없다. 이 맞대결을 검색하면 한 모델의 출시 보도와 다른 모델의 문서만 나올 뿐, 그 사이를 잇는 내용은 없다. 그 부재야말로 정직한 출발점이다: 이들은 경쟁자가 아니며, 유용한 질문은 각 모델이 실제로 어떤 작업을 위한 것인가이다.
한 글자, 두 개의 벤치마크
FLORES-200은 텍스트 벤치마크입니다. Meta는 이를 No Language Left Behind 프로젝트의 일환으로 구축했습니다. 200개 언어에 걸쳐 전문적으로 번역된 문장들로, 번역 시스템이 작성된 텍스트를 한 언어에서 다른 언어로 얼마나 잘 옮기는지 측정하는 데 사용됩니다. 핵심 지표는 spBLEU로, 고정된 언어 균형 토크나이저에서 계산되는 BLEU 변형이므로 서로 다른 문자 체계를 사용하는 언어 간에도 점수를 비교할 수 있습니다. NLLB 논문은 chrF++와 XSTS라는 인간 평가도 보고합니다.
FLEURS는 음성 분야의 자매 데이터셋입니다. FLORES 문장 세트를 가져와 원어민이 소리 내어 읽게 하고, 음성 번역을 평가합니다. 즉, 오디오 입력, 텍스트 출력입니다. 200개가 아니라 102개 언어를 다룹니다. Tencent가 Hy-SimulMT에 대해 FLEURS에서 90.3을 보고할 때, 그 수치에는 오디오를 듣고, 단어를 인식하고, 번역하는 전체 파이프라인이 포함됩니다. Meta가 NLLB-200에 대해 FLORES-200에서 spBLEU를 보고할 때는 텍스트가 이미 올바르게 토큰화되어 있으며, 측정되는 것은 번역 단계뿐입니다.
그 두 숫자를 나란히 놓는다고 해서 두 모델을 비교한 것은 아닙니다. 당신은 서로 다른 데이터, 서로 다른 지표, 서로 다른 언어에서 엔드투엔드 음성 시스템과 텍스트 번역기를 비교한 것입니다. 이것이 바로 한 글자 유사성이 초래하는 오류이며, 이 글의 다른 어떤 비교보다 앞서 짚고 넘어갈 가치가 있습니다.
4년이 지난 지금, NLLB-200은 실제로 무엇인가
NLLB-200은 2022년 7월에 출시되었고 그 이후로 개정된 적이 없습니다. 오늘 다운로드하는 체크포인트는 2022년 체크포인트입니다. 이는 비판이 아니라, 이것이 어떤 종류의 산출물인지에 대한 설명입니다. 즉, 벤치마크와 데이터 세트를 정의한 뒤 멈춘 연구용 릴리스입니다.
이 패밀리는 다섯 가지 사이즈에 걸쳐 있으며, 바로 그 폭이 핵심입니다:
• NLLB-200-distilled-600M — 사용 가능한 가장 작은 체크포인트로, 노트북급 GPU에도 충분할 만큼 작습니다.
• NLLB-200-distilled-1.3B 및 NLLB-200-1.3B — 중간급 쌍으로, 하나는 속도를 위해 증류되었고 다른 하나는 직접 학습되었습니다.
• NLLB-200-3.3B — 밀집형 주력 모델로, 대부분의 사람들이 실제로 배포하는 크기입니다.
• NLLB-200-54.5B — 대표적인 희소 모델: 128개의 전문가와 top-2 게이팅, 네 번째 트랜스포머 블록마다 전문가 혼합 계층이 있으며, 토큰당 연산량은 3.3B dense 모델과 대략 비슷합니다. 이는 해당 세대에서 가장 큰 공개 번역 모델이며, 여전히 이 모델군이 인용되는 이유입니다.
훈련 세트는 약 180억 개의 병렬 문장 쌍이었고, 논문의 대표 주장은 4만 개 이상의 번역 방향에서 측정한 결과 기존 최첨단 대비 44% BLEU 향상이었다는 것이었습니다. 아키텍처는 단일 문장 번역을 위해 구축된 인코더-디코더 트랜스포머입니다. 스트리밍 모드도, 오디오 입력도, 부분 출력이라는 개념도 없습니다. 문장을 입력받아 문장을 반환합니다.
라이선스는 CC-BY-NC 4.0이며, 모델 카드는 그 의도를 분명히 밝히고 있습니다. 즉, 프로덕션 배포용으로 공개된 것이 아니고, 도메인별 번역, 문서 길이 번역, 장문 입력, 인증 번역을 위한 것도 아닙니다. 가중치를 둘러싼 코드는 MIT이지만 가중치는 그렇지 않으며, 이것이 이번 릴리스 이후 4년 동안 따라다닌 혼란입니다.
이번 주 기준, Hy-SimulMT가 실제로 무엇인지
Hy-SimulMT는 거의 모든 측면에서 정반대 형태의 아티팩트다. 이것은 음성 모델이다. 오디오는 16kHz로 30초 창 단위로 스트리밍되며, 모델은 화자가 여전히 말하고 있는 동안 번역된 텍스트를 출력한다. 아키텍처는 304억 개 파라미터의 희소 전문가 혼합으로, 토큰당 약 30억 개 파라미터가 활성화되며, 24층 오디오 인코더를 감싸고 있다. 문서화된 언어 쌍은 중국어와 영어이며 양방향이다.
핵심 주장은 지연 시간이지 커버리지가 아니다. Tencent는 긴 형식의 RealSI 오디오에서 StreamLAAL이 약 3초라고 보고하며, 이를 자사가 비교한 시스템 중 가장 낮은 수치라고 설명한다. 이는 NLLB 논문의 어떤 주장과도 다른 종류의 주장이다. NLLB 논문에는 측정할 것이 없기 때문에 지연 시간 측정이 전혀 없다. 배치 텍스트 번역기는 화자를 뒤따르는 지연이 없기 때문이다.
릴리스는 Apache-2.0이며 게이팅 없이 제공됩니다. 두 가지 출력 형태인 번역 전용과 원문 텍스트+번역을 포괄하는 여섯 개의 체크포인트가 있으며, 각각 전체 정밀도, FP8, GGUF로 제공됩니다. 전체 정밀도 빌드는 약 61GB이고 GGUF Q4_K_M 빌드는 19.7GB입니다. 음성 출력과 음성 복제에는 별도의 TTS 서비스가 필요하며, 모델 자체는 텍스트를 생성합니다.
NLLB-200처럼 호스팅 API도 없고 공개된 가격도 없습니다. 텐센트의 소비자용 서비스는 무료 요금제가 있는 Hy Translate 앱입니다. 그 외의 모든 경우에는 모델 가중치를 직접 실행해야 합니다.
점수들이 하나의 열을 공유할 수 없는 이유
Hy-SimulMT의 네 가지 점수를 당장 손에 잡히는 NLLB-200 수치와 나란히 비교하고 싶은 유혹이 든다. 그 유혹을 참아라. FLEURS/FLORES 구분 때문만은 아니다. 두 모델은 서로 다른 질문을 받고 있다.
• 입력 모달리티 — Hy-SimulMT는 오디오를 입력받으므로 점수에 인식 오류가 포함됩니다. NLLB-200은 인식 오류가 이미 제거된 텍스트를 입력받습니다. 동일한 문장에 대한 음성 모델과 텍스트 모델은 같은 출발선에 있지 않습니다.
• 지표 — Hy-SimulMT는 음성 번역 세트에서 BLEU 계열 점수를 보고하고, NLLB-200은 FLORES-200에서 spBLEU, chrF++ 및 XSTS를 보고합니다. spBLEU의 토크나이저는 언어 간 비교를 공정하게 하기 위해 존재하므로, 둘 다 BLEU라고 불리더라도 일반 BLEU 수치와 상호 교환할 수 없습니다.
• 작업 단위 — NLLB-200은 정렬된 텍스트에서 문장 단위로 평가됩니다. Hy-SimulMT는 스트리밍 오디오에서 평가되는데, 여기서 흥미로운 실패는 잘못 번역된 단어가 아니라 유용하게 쓰이기에는 너무 늦게 도착하는 문장입니다.
• 방향 수 — NLLB-200의 40,000개 이상 방향은 대표 수치에 평균으로 반영되며, Hy-SimulMT의 네 가지 벤치마크는 중국어↔영어만을 다룹니다. 긴 꼬리 전반에 걸친 평균과 하나의 고자원 언어 쌍에 대한 점수는 서로 다른 종류의 성과를 보여줍니다.
자체 표 안에서도 Hy-SimulMT가 일률적으로 앞서는 것은 아닙니다. CoVoST2에서는 Qwen3.8-LiveTranslate의 82.1에 맞서 75.5를 기록했고, FLEURS(90.3 대 92.4)와 ACL6060(81.2 대 82.6)에서는 Gemini3.5-LiveTranslate에 뒤처집니다. 가장 분명한 승리는 RealSI-Sentence의 84.7입니다. 이 수치는 모두 벤더가 실행한 것으로, Tencent가 선택한 하네스에서 산출되었으며 독립적으로 재현되지 않았습니다. 모델 카드에도 두 출력 변형 중 어느 것이 이 수치를 냈는지 나와 있지 않습니다.
지연 시간은 NLLB에 없는 단위로 측정됩니다
배포를 결정하는 부분은 바로 이것이며, 벤치마크 점수와는 전혀 관계가 없습니다.
동시통역사는 배치 번역기가 결코 마주하지 않는 절충을 해야 합니다. 더 오래 기다려 더 잘 번역하거나, 더 빨리 말하고 틀릴 위험을 감수하는 것입니다. StreamLAAL은 그 절충을 측정합니다. 대략 출력이 평균적으로 입력보다 얼마나 뒤처지는지를요. Hy-SimulMT의 3초는 그 절충에 대한 주장입니다. 이는 첫 음성 출력까지 걸리는 시간과 명시적으로 같지 않으며, Tencent는 모델 카드에서 그렇게 밝힙니다. 외부 TTS 서비스를 추가하면 청취자의 경험에는 해당 서비스의 지연도 포함되지만, 3초라는 수치는 그렇지 않습니다.
NLLB-200에는 스트리밍 경로가 없기 때문에 대응하는 수치가 없습니다. 하나를 덧붙일 수는 있습니다. 오디오를 청크로 나누고, 음성 인식을 실행하고, 문장 조각을 NLLB에 공급하고, 완료되는 대로 번역을 내보내면 됩니다. 그 아키텍처는 작동하며 팀들이 실제로 구축해 왔습니다. 하지만 청킹은 문장 단위 번역기가 의존하는 문맥을 파괴하며, 그 결과 품질은 완전하고 잘 형성된 문장으로 FLORES-200에서 측정한 품질과 같지 않습니다. "NLLB-200이 FLORES에서 X점을 받는다"와 "청크 기반 라이브 파이프라인 내부의 NLLB-200은 Y처럼 들린다" 사이의 격차가 바로 실제로 대부분의 엔지니어링 노력이 들어가는 곳입니다.
이것이 진짜 비대칭이다. Hy-SimulMT는 스트리밍 사례를 위해 설계되었고, 그 대가로 언어 지원 범위와 30B급 풋프린트를 감수한다. NLLB-200은 폭넓은 범위를 위해 설계되었고, 그 대가로 배치 전용 인터페이스를 감수한다. 어느 쪽도 뒤처진 것이 아니다. 둘은 서로 다른 제약 조건에 최적화되어 있다.
깊이 대비 커버리지
NLLB-200의 변함없는 강점은 롱테일입니다. 대부분의 2026년 모델이 전혀 처리하지 못하는 저자원 언어를 포함해 200개 언어를 지원하며, 600M 체크포인트에서 54.5B 전문가 혼합(MoE)까지 확장되는 제품군입니다. 수백만 명의 화자가 사용하는 언어로 된 문서를 다루는데 상용 API가 이를 지원하지 않는 상황이라면, NLLB-200은 여전히 몇 안 되는 오픈 옵션 중 하나이며, 3.3B 밀집 체크포인트는 적당한 GPU 한 대에서 실행됩니다.
Hy-SimulMT는 그 작업을 전혀 할 수 없습니다. 이 모델은 중국어와 영어를 문서화합니다. Hugging Face 메타데이터에는 36개 언어 태그가 있지만, 나머지 34개 언어 목록은 공개되지 않았고 저장소의 모든 예시는 en-zh 또는 zh-en을 사용합니다. 그 태그만 믿고 다국어 출시를 계획하는 것은 실수일 것입니다.
하드웨어 계산은 반대 방향으로 전개된다. NLLB-200의 3.3B dense 모델은 FP16에서 몇 기가바이트에 불과해 16–24GB 카드에 넉넉히 들어간다. 54.5B 플래그십은 FP16에서 약 108GB로, 멀티 GPU가 필요한 구성이다. Hy-SimulMT는 BF16에서 대략 61GB이며, 출시된 그대로 서비스하려면 80GB 가속기가 필요하고, llama.cpp 지원이 아직 업스트림되지 않은 GGUF 경로를 통해 Q4_K_M 기준으로는 19.7GB가 필요하다. 따라서 NLLB-200은 소형 쪽에서 더 저렴하고 최상위 쪽에서는 비슷하며, Hy-SimulMT의 비용은 중간에 집중되는 대신 스트리밍을 얻는다.
라이선스들은 서로 반대 방향을 가리킨다.
이것이 이 비교의 척추는 아닙니다 — 척추는 모달리티입니다 — 하지만 상용 제품을 위해 둘 중 하나를 탈락시키는 가장 빠른 방법입니다.
NLLB-200의 가중치는 CC-BY-NC 4.0입니다. 비상업적 용도입니다. 주변 코드는 MIT이며, 혼란은 바로 여기에서 비롯됩니다. 하지만 실제로 서빙하게 될 것은 가중치이고, Meta의 모델 카드에는 해당 모델이 프로덕션 배포용으로 공개된 것이 아니라고 분명히 적혀 있습니다. 상업적 배포에는 다른 모델이나 라이선스 계약이 필요합니다.
Hy-SimulMT는 Apache-2.0이며 게이트가 없고 상업적 사용, 수정 및 재배포가 허용됩니다. Tencent는 추론 서버와 함께 학습 툴킷을 제공하므로 지속적인 학습은 의도된 사용 방식입니다. 라이선스만을 기준으로 둘 중 하나를 선택해야 한다면, 결과는 뻔합니다.
같은 스택에서 그것들이 속해야 할 위치
이 조합이 계속 검색되는 이유는 팀들이 같은 제품에서 두 가지 문제를 모두 겪기 때문이다. 중국어와 영어로 운영되는 회사는 회의를 위한 실시간 통역사와 이메일, 계약서, 지원 티켓으로 들어오는 200개 언어 문서 트래픽을 위한 텍스트 파이프라인이 필요하다. 이는 서로 다른 두 가지 작업이며, 정직한 아키텍처는 서로 다른 두 모델을 사용한다.
NLLB-200 또는 현대적인 후속 모델은 오프라인 텍스트 경로를 처리합니다. 배치 번역, 언어 식별, 코퍼스 트리아지, 롱테일이 여기에 해당합니다. Hy-SimulMT는 실시간 중국어↔영어 음성 경로를 처리하는데, 여기서는 지연 시간이 지배적이며 방 안에 두 언어만 있으므로 커버리지는 중요하지 않습니다. 둘 사이의 경계는 라우팅 결정이며, 애플리케이션이 파일 유형에서 이를 추론하게 두기보다 명시적으로 밝히는 것이 좋습니다.

두 모델 모두 OrcaRouter의 카탈로그에 없으므로, 우리는 어느 쪽으로도 가는 경로가 아닙니다. 라우터가 실제로 제공하는 것은 그 주변의 이음새입니다: 0% 마크업으로 200개 이상의 호스팅 모델 앞에 놓인 단일 API, 공급자 정가가 아무것도 더해지지 않은 채 그대로 전달되며, 요청이 어떤 경로를 택할지 결정하는 라우팅 DSL. 마지막 부분은 평범하지만 유용합니다 — 텍스트 요청은 호스팅된 범용 모델로 넘어가고, 음성 요청은 자체 호스팅 인터프리터로 가며, 애플리케이션은 어느 쪽이 어느 쪽인지 알 필요가 없습니다. 자동 장애 조치는 호스팅 구간을 사용할 수 없는데도 요청은 여전히 무언가를 반환해야 하는 경우를 처리합니다.
호스티드 구간은 제공업체 정가에 아무것도 더하지 않고 책정되므로, 텍스트 측 공급업체의 가격 인하는 같은 날 우리 쪽에도 적용됩니다. 이는 문서 트래픽을 대량으로 라우팅하기 시작하면 작은 일이 아니며, 대안은 공급업체가 요금표를 변경할 때마다 계약을 재협상하는 것입니다.
둘 중 하나를 하기 전에 무엇을 물어봐야 할까?
문제는 어느 모델이 더 나은가가 아니다. 그것은 두 가지 질문이며, 그 답은 서로 다르다.
입력이 아직 도착 중인 오디오이고 언어가 중국어와 영어라면, 답은 Hy-SimulMT이며 — 배포 질문은 그 여섯 체크포인트 중 어느 것인가로 바뀌는데, 이는 품질보다는 출력 형태와 정밀도에 관한 결정이다. 입력이 아직 식별하지 못한 언어의 텍스트이고, 저자원 언어를 포함하는 집합 전반에 걸친 경우라면, NLLB-200은 4년이 지난 지금도 합당한 공개 기준선으로 남아 있다. 단, 비상업적 라이선스가 적합하고 배치 인터페이스를 받아들인다면.
아무도 공개하지 않은 것은 바로 이 연결고리입니다. 음성 인식이 중국어↔영어 오디오에서 NLLB-200에 입력되고, Hy-SimulMT와 동일한 스트리밍 벤치마크에서 평가되며, 지연 시간과 품질이 함께 보고되는 실험입니다. 그 실험은 2026년 스트리밍 하네스로 감싼 2022년 텍스트 번역기가 목적에 맞게 제작된 통역기와 경쟁할 수 있는지를 알려줄 것입니다. 또한 두 모델의 첫 번째 정직한 비교가 될 것이며, 아직 존재하지 않습니다.


마지막으로 분명히 해둘 말이 하나 있습니다. 한 글자만 다른 벤치마크 이름의 유사성 때문에 계속 잘못된 비교가 생길 테니까요. FLEURS에서 이기는 모델은 특정 하네스 아래의 음성 번역에 대해 무엇인가를 입증한 것입니다. FLORES-200에서 좋은 점수를 받는 모델은 200개 언어에 걸친 텍스트 번역에 대해 무엇인가를 입증한 것입니다. 어느 결과도 다른 쪽의 과제로 이어지지 않으며, 동일한 오디오에 동일한 지표와 동일한 지연 시간 계산을 적용해 두 결과를 모두 공개하는 벤더가 이 비교를 처음으로 의미 있게 만들 것입니다.
