Hy-SimulMT kontra NLLB-200: tłumacz strumieniowy nie jest tłumaczem 200 języków

Nazwy dwóch benchmarków różnią się jedną literą i ta litera to cały artykuł. Hy-SimulMT, tłumacz chińsko-angielski w czasie rzeczywistym od Tencent Hunyuan wydany 26 października 2026 r., publikuje wynik 90,3 w czymś, co nazywa się FLEURS. NLLB-200, translator tekstu Meta AI na 200 języków z lipca 2022 r., jest oceniany w czymś, co nazywa się FLORES-200. Są powiązane — FLEURS powstaje z czytań na głos zdań FLORES — ale to nie ten sam test, nie są oceniane w ten sam sposób i nikt nigdy nie porównał tych dwóch modeli bezpośrednio. Wyszukiwanie tego zestawienia zwraca materiały z premiery jednego modelu i dokumentację drugiego, a pomiędzy nimi nic. Ten brak to uczciwy punkt wyjścia: to nie konkurenci, a użyteczne pytanie brzmi, do jakiego zadania naprawdę służy każdy z nich.

Jedna litera, dwa benchmarki

FLORES-200 to benchmark tekstowy. Meta stworzyła go w ramach projektu No Language Left Behind: profesjonalnie przetłumaczone zdania w 200 językach, używane do pomiaru, jak dobrze system tłumaczeniowy przenosi tekst pisany z jednego języka na drugi. Główną metryką jest spBLEU, wariant BLEU obliczany na stałym, zrównoważonym językowo tokenizatorze, dzięki czemu wyniki są porównywalne między językami używającymi różnych pism. W artykule NLLB podano również chrF++ oraz ocenę ludzką o nazwie XSTS.

FLEURS to mówiony odpowiednik. Przyjmuje zestawy zdań FLORES, pozwala rodzimym użytkownikom przeczytać je na głos i ocenia tłumaczenie mowy — dźwięk na wejściu, tekst na wyjściu. Obejmuje 102 języki, a nie 200. Gdy Tencent podaje 90,3 na FLEURS dla Hy-SimulMT, ta liczba obejmuje cały potok: usłyszenie dźwięku, rozpoznanie słów i przetłumaczenie ich. Gdy Meta podaje spBLEU na FLORES-200 dla NLLB-200, tekst jest już poprawny i stokenizowany, a mierzy się wyłącznie etap tłumaczenia.

Zestaw te dwie liczby obok siebie, a nie porównałeś dwóch modeli. Porównałeś system mowy typu end-to-end z tłumaczem tekstu na różnych danych, przy użyciu różnych metryk, w różnych językach. To błąd, do którego skłania podobieństwo jednej litery, i warto go nazwać przed wszelkim innym porównaniem w tym tekście.

Czym właściwie jest NLLB-200 po czterech latach

NLLB-200 został wydany w lipcu 2022 r. i od tego czasu nie był aktualizowany. Checkpointy, które pobierasz dziś, to checkpointy z 2022 r. To nie jest krytyka — to stwierdzenie, jakiego rodzaju artefaktem to jest: wydanie badawcze, które zdefiniowało benchmark i zbiór danych, a potem się zatrzymało.

Rodzina obejmuje pięć rozmiarów, a cały sens tkwi w tej rozpiętości:

• NLLB-200-distilled-600M — najmniejszy użyteczny checkpoint, wystarczająco mały dla GPU klasy laptopa.

• NLLB-200-distilled-1.3B i NLLB-200-1.3B — para średniej klasy: jedna destylowana dla szybkości, a druga trenowana bezpośrednio.

• NLLB-200-3.3B — gęsty koń roboczy, rozmiar, który większość ludzi faktycznie wdraża.

• NLLB-200-54.5B — flagowy model rzadki: 128 ekspertów z bramkowaniem top-2, warstwa mieszaniny ekspertów w co czwartym bloku transformatora oraz obliczenia na token w przybliżeniu porównywalne z gęstym modelem 3,3B. To największy otwarty model tłumaczeniowy swojej generacji i wciąż powód, dla którego ta rodzina jest cytowana.

Zbiór treningowy liczył około 18 miliardów par zdań równoległych, a głównym twierdzeniem artykułu była poprawa BLEU o 44% względem poprzedniego stanu sztuki, zmierzona w ponad 40 000 kierunków tłumaczenia. Architektura to transformer enkoder-dekoder zbudowany do tłumaczenia pojedynczych zdań. Nie ma trybu strumieniowego, wejścia audio ani pojęcia częściowego wyniku — przyjmuje zdanie i zwraca zdanie.

Licencja to CC-BY-NC 4.0, a karta modelu mówi wprost o intencji: nie wydano go do wdrożeń produkcyjnych, nie jest przeznaczony do tłumaczenia specjalistycznego, dokumentów, długich tekstów wejściowych ani tłumaczeń certyfikowanych. Kod towarzyszący wagom jest objęty licencją MIT, ale same wagi już nie, i to właśnie to zamieszanie towarzyszy temu wydaniu od czterech lat.

Czym Hy-SimulMT właściwie jest według stanu na ten tydzień

Hy-SimulMT to artefakt o przeciwnej charakterystyce pod niemal każdym względem. To model mowy: dźwięk jest przesyłany strumieniowo z częstotliwością 16 kHz w 30-sekundowych oknach, a model generuje przetłumaczony tekst, podczas gdy mówca wciąż mówi. Architektura to rzadka mieszanina ekspertów o 30,4 mld parametrów, z około 3 mld parametrów aktywnych na token, opakowana w 24-warstwowy enkoder audio. Udokumentowana para językowa to chiński i angielski, w obu kierunkach.

Jego główna teza dotyczy opóźnienia, a nie pokrycia. Tencent podaje StreamLAAL wynoszący około trzech sekund dla długich nagrań audio RealSI, określając go jako najniższy wśród porównywanych systemów. To twierdzenie innego rodzaju niż cokolwiek w pracy NLLB, która w ogóle nie zawiera pomiaru opóźnienia, ponieważ nie ma czego mierzyć: wsadowy tłumacz tekstu nie ma opóźnienia względem mówcy.

Wydanie jest objęte licencją Apache-2.0 i dostępne bez ograniczeń, z sześcioma checkpointami obejmującymi dwie formy wyjściowe — tylko tłumaczenie oraz tekst źródłowy plus tłumaczenie — każda w pełnej precyzji, FP8 i GGUF. Wersja w pełnej precyzji ma około 61 GB, a wersja GGUF Q4_K_M — 19,7 GB. Generowanie mowy i klonowanie głosu wymagają osobnej usługi TTS; sam model generuje tekst.

Podobnie jak NLLB-200 nie ma hostowanego API ani opublikowanej ceny. Produktem konsumenckim Tencenta jest aplikacja Hy Translate, która oferuje darmowy plan. Wszystko inne oznacza uruchamianie wag.

Dlaczego wyniki nie mogą być w tej samej kolumnie

Pokusa polega na zestawieniu czterech wyników Hy-SimulMT z dowolną liczbą NLLB-200, jaka jest pod ręką. Oprzyj się jej — i to nie tylko z powodu rozróżnienia FLEURS/FLORES. Tym dwóm modelom zadaje się różne pytania.

• Modalność wejściowa — Hy-SimulMT otrzymuje dźwięk, więc jego wynik obejmuje błąd rozpoznawania. NLLB-200 otrzymuje tekst z już usuniętym błędem rozpoznawania. Model mowy i model tekstowy na tych samych zdaniach nie startują z tego samego punktu.

• Metryka — Hy-SimulMT podaje wyniki z rodziny BLEU na zbiorach tłumaczenia mowy; NLLB-200 podaje spBLEU, chrF++ i XSTS na FLORES-200. Tokenizator spBLEU powstał specjalnie po to, aby porównanie międzyjęzykowe było sprawiedliwe, co oznacza, że nie można go stosować wymiennie ze zwykłym wynikiem BLEU, nawet gdy oba nazywa się BLEU.

• Jednostka pracy — NLLB-200 jest oceniany zdanie po zdaniu na wyrównanym tekście. Hy-SimulMT jest oceniany na strumieniowym audio, gdzie interesującym niepowodzeniem nie jest błędnie przetłumaczone słowo, lecz zdanie, które dociera zbyt późno, aby było użyteczne.

• Liczba kierunków — ponad 40 000 kierunków NLLB-200 jest uśrednianych w jego głównym wyniku; cztery benchmarki Hy-SimulMT obejmują wyłącznie chiński↔angielski. Średnia z długiego ogona i wynik na jednej parze wysokozasobowej opisują różne rodzaje osiągnięć.

Również we własnej tabeli Hy-SimulMT nie wypada konsekwentnie lepiej. Uzyskuje 75.5 na CoVoST2 wobec 82.1 Qwen3.8-LiveTranslate i ustępuje Gemini3.5-LiveTranslate na FLEURS (90.3 versus 92.4) oraz ACL6060 (81.2 versus 82.6). Jej najwyraźniejsze zwycięstwo to RealSI-Sentence z wynikiem 84.7. Wszystkie te liczby pochodzą z testów przeprowadzonych przez dostawcę, na wybranym przez Tencent środowisku testowym, i nie zostały niezależnie odtworzone. Karta modelu nie mówi też, który z jego dwóch wariantów wyjściowych je wygenerował.

Opóźnienie jest mierzone w jednostce, której NLLB nie ma.

To jest ta część, która decyduje o wdrożeniach, i nie ma ona nic wspólnego z wynikami benchmarków.

Tłumacz symultaniczny musi dokonać wyboru, przed którym tłumacz wsadowy nigdy nie staje: czekać dłużej i tłumaczyć lepiej albo odezwać się szybciej i ryzykować błąd. StreamLAAL mierzy ten kompromis — w przybliżeniu, o ile średnio wyjście pozostaje w tyle za wejściem. Trzy sekundy w Hy-SimulMT to twierdzenie dotyczące tego kompromisu. To wyraźnie nie to samo co czas do pierwszego wyjścia głosowego, i Tencent mówi o tym na karcie modelu. Po dodaniu zewnętrznej usługi TTS na doświadczenie słuchacza wpływa także opóźnienie tej usługi, czego liczba trzy sekundy nie uwzględnia.

NLLB-200 nie ma odpowiednika tej liczby, ponieważ nie ma ścieżki strumieniowej. Można ją dorobić: dzielić audio na fragmenty, uruchomić rozpoznawanie mowy, podawać fragmenty zdań do NLLB i emitować tłumaczenia, gdy tylko są gotowe. Ta architektura działa i zespoły ją zbudowały. Jednak dzielenie niszczy kontekst, na którym opiera się tłumacz na poziomie zdania, a uzyskana jakość to nie ta jakość, którą mierzy się na FLORES-200 przy użyciu kompletnych, poprawnie sformułowanych zdań. Luka między „NLLB-200 osiąga X na FLORES” a „NLLB-200 w strumieniowym potoku dzielonym na fragmenty brzmi jak Y” to miejsce, w które tak naprawdę idzie większość pracy inżynierskiej.

To jest prawdziwa asymetria. Hy-SimulMT został zaprojektowany z myślą o przypadku strumieniowym i płaci za to pokryciem językowym oraz rozmiarem klasy 30B. NLLB-200 został zaprojektowany z myślą o szerokim zakresie i płaci za to interfejsem wyłącznie wsadowym. Żaden nie jest w tyle. Są zoptymalizowane pod różne ograniczenia.

Pokrycie w zależności od głębokości

Trwałą przewagą NLLB-200 pozostaje długi ogon. Dwieście języków, w tym te o niskich zasobach, których większość modeli z 2026 roku w ogóle nie obsługuje — w rodzinie, która skaluje się od checkpointu 600M do 54,5B mixture of experts. Jeśli Twoim problemem jest dokument w języku, którym posługuje się kilka milionów osób, a żadne komercyjne API go nie obsługuje, NLLB-200 wciąż jest jedną z niewielu otwartych opcji, a gęsty checkpoint 3.3B działa na jednej skromnej GPU.

Hy-SimulMT w ogóle nie potrafi wykonać tego zadania. Dokumentuje język chiński i angielski. Jego metadane w Hugging Face zawierają tag 36 języków, ale nie opublikowano listy pozostałych 34, a każdy przykład w repozytorium używa en-zh lub zh-en. Planowanie wdrożenia wielojęzycznego w oparciu o ten tag byłoby błędem.

Arytmetyka sprzętowa działa w drugą stronę. Gęsty model NLLB-200 3,3B ma kilka gigabajtów w FP16 i swobodnie mieści się na karcie 16–24 GB. Jego flagowy model 54,5B to około 108 GB w FP16 — wymaga wielu GPU. Hy-SimulMT ma około 61 GB w BF16 i do działania w dostarczanej konfiguracji potrzebuje akceleratora 80 GB, a w Q4_K_M — 19,7 GB przez ścieżkę GGUF, której obsługa w llama.cpp nie trafiła jeszcze do upstreamu. NLLB-200 jest więc tańszy na dolnym końcu i porównywalny na szczycie; koszt Hy-SimulMT koncentruje się w środku, a w zamian daje strumieniowanie.

Licencje wskazują w przeciwnych kierunkach

To nie jest trzon tego porównania — jest nim modalność — ale to najszybszy sposób, by zdyskwalifikować jedno z nich jako produkt komercyjny.

Wagi NLLB-200 są objęte licencją CC-BY-NC 4.0. Niekomercyjną. Otaczający kod jest na licencji MIT i stąd bierze się zamieszanie, ale to wagi byłyby tym, co się udostępnia, a karta Meta mówi wprost, że modele nie zostały udostępnione do wdrożeń produkcyjnych. Wdrożenie komercyjne wymaga albo innego modelu, albo porozumienia licencyjnego.

Hy-SimulMT jest objęty licencją Apache-2.0, bez ograniczeń dostępu, z dozwolonym wykorzystaniem komercyjnym, modyfikacją i redystrybucją. Tencent udostępnia zestaw narzędzi do trenowania wraz z serwerem wnioskowania, więc kontynuacja trenowania jest zamierzonym zastosowaniem. Jeśli wybór między tymi dwoma ma opierać się wyłącznie na licencji, to nie jest to nawet bliskie.

Gdzie jest ich miejsce w tym samym stosie

Powodem, dla którego to zestawienie wciąż jest wyszukiwane, jest to, że zespoły napotykają oba te problemy w tym samym produkcie. Firma prowadząca działalność po chińsku i angielsku potrzebuje tłumacza na żywo na spotkania oraz potoku przetwarzania tekstu do obsługi ruchu dokumentowego w 200 językach, który dociera e-mailem, w umowach i zgłoszeniach do supportu. To dwa różne zadania, a uczciwa architektura wykorzystuje dwa różne modele.

NLLB-200, lub nowoczesny następca, obsługuje ścieżkę tekstową offline: tłumaczenie wsadowe, identyfikację języka, wstępną selekcję korpusu, długi ogon. Hy-SimulMT obsługuje ścieżkę mowy na żywo chiński↔angielski, gdzie dominuje opóźnienie, a pokrycie nie ma znaczenia, ponieważ w pomieszczeniu są tylko dwa języki. Granica między nimi to decyzja o routingu i warto ją wyrazić wprost, zamiast pozwalać aplikacji wnioskować ją na podstawie typu pliku.

Żaden z tych modeli nie znajduje się w katalogu OrcaRouter, więc nie jesteśmy trasą do żadnego z nich. To, co daje router, to szew wokół nich: jedno API przed ponad 200 hostowanymi modelami przy 0% narzutu, cena katalogowa dostawcy przekazywana bez żadnych dodatków, oraz DSL routingu, który decyduje, którą ścieżką trafia żądanie. Ta ostatnia część jest przyziemna i użyteczna — żądania tekstowe trafiają do hostowanego modelu ogólnego, żądania mowy trafiają do Twojego samodzielnie hostowanego interpretera, a aplikacja nie musi wiedzieć, które jest które. Automatyczne przełączanie awaryjne obejmuje przypadek, gdy hostowana odnoga jest niedostępna, a żądanie wciąż musi coś zwrócić.

Ponieważ część hostowana jest wyceniana według cennika dostawcy bez żadnych narzutów, obniżka cen dostawcy po stronie tekstu obowiązuje u nas tego samego dnia. To drobiazg, dopóki nie kierujesz ruchu dokumentowego na dużą skalę, a alternatywą jest renegocjowanie umowy za każdym razem, gdy dostawca zmienia swój cennik.

O co zapytać przed którymkolwiek z nich

Nie chodzi o to, który model jest lepszy. Chodzi o dwa pytania, a ich odpowiedzi są różne.

Jeśli dane wejściowe to dźwięk, który wciąż napływa, a językami są chiński i angielski, odpowiedzią jest Hy-SimulMT — a pytanie o wdrożenie sprowadza się do tego, który z jego sześciu checkpointów wybrać, co jest decyzją dotyczącą kształtu i precyzji wyjścia, a nie jakości. Jeśli dane wejściowe to tekst w języku, którego jeszcze nie zidentyfikowano, spośród zbioru obejmującego języki o niskich zasobach, NLLB-200 pozostaje uzasadnionym otwartym punktem odniesienia cztery lata później, pod warunkiem że licencja niekomercyjna pasuje i akceptujesz interfejs wsadowy.

Nikt nie opublikował pomostu: rozpoznawanie mowy zasilające NLLB-200 na audio chińsko↔angielskim, oceniane na tym samym benchmarku strumieniowym co Hy-SimulMT, z opóźnieniem i jakością raportowanymi łącznie. Ten eksperyment pokazałby, czy translator tekstu z 2022 r. opakowany w strumieniowy harness z 2026 r. może konkurować z interpreterem zbudowanym specjalnie do tego celu. Byłoby to również pierwsze uczciwe porównanie tych dwóch modeli — a ono jeszcze nie istnieje.

Jeszcze jedna rzecz, którą warto powiedzieć wprost, bo podobieństwo nazw benchmarków różniących się jedną literą będzie wciąż rodzić błędne porównania: model, który wygrywa na FLEURS, pokazał coś na temat tłumaczenia mowy w ramach konkretnego środowiska testowego. Model, który dobrze wypada na FLORES-200, pokazał coś na temat tłumaczenia tekstu w 200 językach. Żaden z tych wyników nie przenosi się na zadanie drugiego, a dostawca, który opublikuje oba na tym samym audio, z tą samą metryką i tym samym sposobem rozliczania opóźnień, jako pierwszy sprawi, że to porównanie będzie miało jakikolwiek sens.