Hy-SimulMT so với NLLB-200: Một trình thông dịch theo luồng không phải là một trình dịch 200 ngôn ngữ

Hai tên benchmark chỉ khác nhau một chữ cái, và chữ cái đó là toàn bộ bài viết. Hy-SimulMT, trình phiên dịch thời gian thực Trung↔Anh của Tencent Hunyuan ra mắt ngày 26 tháng 10 năm 2026, công bố điểm 90.3 trên một thứ gọi là FLEURS. NLLB-200, trình dịch văn bản 200 ngôn ngữ của Meta AI từ tháng 7 năm 2022, được đánh giá trên một thứ gọi là FLORES-200. Chúng có liên quan — FLEURS được xây dựng từ các câu FLORES được đọc thành tiếng — nhưng chúng không phải cùng một bài kiểm tra, không được chấm điểm theo cùng một cách, và chưa từng có ai chạy hai mô hình này đối đầu nhau. Tìm kiếm cặp đối đầu này sẽ trả về bài đưa tin ra mắt của một mô hình và tài liệu của mô hình kia, không có gì ở giữa. Sự vắng mặt đó là điểm khởi đầu trung thực: đây không phải những đối thủ cạnh tranh, và câu hỏi hữu ích là mỗi mô hình thực sự dành cho công việc nào.

Một chữ cái, hai chuẩn mực

FLORES-200 là một bộ đánh giá văn bản. Meta đã xây dựng nó như một phần của dự án No Language Left Behind: các câu được dịch chuyên nghiệp trên 200 ngôn ngữ, dùng để đo mức độ một hệ thống dịch chuyển văn bản viết từ ngôn ngữ này sang ngôn ngữ khác. Chỉ số chính là spBLEU, một biến thể của BLEU được tính trên một bộ tách từ cố định, cân bằng ngôn ngữ để điểm số có thể so sánh giữa các ngôn ngữ dùng các hệ chữ khác nhau. Bài báo NLLB cũng báo cáo chrF++ và một đánh giá con người gọi là XSTS.

FLEURS là phiên bản nói tương ứng. Nó lấy các bộ câu FLORES, cho người bản ngữ đọc to chúng, và đánh giá dịch giọng nói — đầu vào là âm thanh, đầu ra là văn bản. Nó bao phủ 102 ngôn ngữ thay vì 200. Khi Tencent báo cáo 90,3 trên FLEURS cho Hy-SimulMT, con số đó bao gồm toàn bộ quy trình: nghe âm thanh, nhận dạng từ và dịch chúng. Khi Meta báo cáo spBLEU trên FLORES-200 cho NLLB-200, văn bản đã chính xác và được tách token, và thứ duy nhất được đo là bước dịch.

Đặt hai con số đó cạnh nhau, và bạn không hề so sánh hai mô hình. Bạn đã so sánh một hệ thống giọng nói đầu-cuối với một trình dịch văn bản trên dữ liệu khác nhau, với các chỉ số khác nhau, ở các ngôn ngữ khác nhau. Đây là sai lầm mà sự tương đồng một chữ cái mời gọi, và đáng được gọi tên trước bất kỳ so sánh nào khác trong bài viết này.

NLLB-200 thực sự là gì, sau bốn năm nhìn lại

NLLB-200 được phát hành vào tháng 7 năm 2022 và chưa được chỉnh sửa kể từ đó. Các checkpoint bạn tải xuống hôm nay chính là các checkpoint của năm 2022. Đó không phải là một lời chỉ trích — mà là một nhận định về việc đây là loại sản phẩm gì: một bản phát hành nghiên cứu đã định nghĩa nên một benchmark và một tập dữ liệu, rồi sau đó dừng lại.

Dòng sản phẩm có đủ năm kích cỡ, và chính sự đa dạng đó là điểm mấu chốt:

• NLLB-200-distilled-600M — checkpoint nhỏ nhất còn dùng được, đủ nhỏ để chạy trên GPU của máy tính xách tay.

• NLLB-200-distilled-1.3B và NLLB-200-1.3B — cặp tầm trung, một bản được chưng cất để tăng tốc và một bản được huấn luyện trực tiếp.

• NLLB-200-3.3B — mô hình dense chủ lực, kích thước mà hầu hết mọi người thực sự triển khai.

• NLLB-200-54.5B — mô hình thưa chủ lực: 128 chuyên gia với cơ chế gating top-2, một lớp hỗn hợp chuyên gia trong mỗi khối transformer thứ tư, và chi phí tính toán trên mỗi token gần tương đương với mô hình dày đặc 3,3B. Đây là mô hình dịch mở lớn nhất của thế hệ đó và vẫn là lý do dòng mô hình này được trích dẫn.

Tập huấn luyện gồm khoảng 18 tỷ cặp câu song song, và tuyên bố nổi bật của bài báo là mức cải thiện BLEU 44% so với trình độ tiên tiến trước đó, được đo trên hơn 40.000 hướng dịch. Kiến trúc là một transformer encoder-decoder được xây dựng cho dịch một câu. Không có chế độ truyền phát, không có đầu vào âm thanh và không có khái niệm đầu ra từng phần — nó nhận một câu và trả về một câu.

Giấy phép là CC-BY-NC 4.0, và thẻ mô hình nói thẳng về ý định: không phát hành để triển khai trong sản xuất, không dành cho dịch theo miền chuyên biệt, theo độ dài tài liệu, với đầu vào dài hoặc dịch được chứng nhận. Phần mã xung quanh trọng số là MIT, nhưng trọng số thì không, và đó chính là sự nhầm lẫn đã theo bản phát hành này suốt bốn năm.

Hy-SimulMT thực sự là gì, tính đến tuần này

Hy-SimulMT là một sản phẩm có đặc điểm trái ngược ở gần như mọi khía cạnh. Đây là một mô hình giọng nói: âm thanh được truyền vào ở 16 kHz theo các cửa sổ 30 giây, và mô hình phát ra văn bản đã dịch trong khi người nói vẫn đang nói. Kiến trúc là một hỗn hợp chuyên gia thưa 30,4 tỷ tham số với khoảng 3 tỷ tham số hoạt động trên mỗi token, được bao bọc quanh một bộ mã hóa âm thanh 24 lớp. Cặp ngôn ngữ được ghi nhận là tiếng Trung và tiếng Anh, theo cả hai chiều.

Tuyên bố cốt lõi của nó là độ trễ, không phải độ bao phủ. Tencent báo cáo StreamLAAL khoảng ba giây trên âm thanh RealSI dài, mô tả đây là mức thấp nhất trong số các hệ thống mà nó so sánh. Đó là một kiểu tuyên bố khác với bất kỳ điều gì trong bài báo NLLB, vốn không có phép đo độ trễ nào cả vì không có gì để đo: một trình dịch văn bản theo lô không có độ trễ so với người nói.

Bản phát hành này theo Apache-2.0 và không bị giới hạn truy cập, với sáu checkpoint bao gồm hai dạng đầu ra — chỉ bản dịch và văn bản nguồn kèm bản dịch — mỗi dạng đều ở độ chính xác đầy đủ, FP8 và GGUF. Bản dựng độ chính xác đầy đủ khoảng 61 GB, còn bản dựng GGUF Q4_K_M là 19.7 GB. Đầu ra giọng nói và nhân bản giọng nói yêu cầu một dịch vụ TTS riêng; bản thân mô hình tạo ra văn bản.

Và giống như NLLB-200, nó không có API được host sẵn và không có mức giá được công bố. Sản phẩm hướng tới người dùng cuối của Tencent là ứng dụng Hy Translate, ứng dụng này có gói miễn phí. Mọi thứ còn lại đều đồng nghĩa với việc tự chạy các trọng số.

Tại sao các điểm số không thể dùng chung một cột

Cám dỗ là đem bốn điểm số của Hy-SimulMT đặt ngang với bất kỳ con số NLLB-200 nào gần nhất trong tầm tay. Hãy cưỡng lại, và không chỉ vì sự khác biệt FLEURS/FLORES. Hai mô hình đang được hỏi những câu hỏi khác nhau.

• Phương thức đầu vào — Hy-SimulMT nhận âm thanh, nên điểm của nó bao gồm lỗi nhận dạng. NLLB-200 nhận văn bản đã được loại bỏ lỗi nhận dạng. Một mô hình giọng nói và một mô hình văn bản xử lý cùng các câu không ở cùng vạch xuất phát.

• Chỉ số — Hy-SimulMT báo cáo điểm thuộc họ BLEU trên các bộ dữ liệu dịch tiếng nói; NLLB-200 báo cáo spBLEU, chrF++ và XSTS trên FLORES-200. Bộ tách token của spBLEU tồn tại specifically nhằm giúp so sánh giữa các ngôn ngữ được công bằng, nghĩa là nó không thể dùng thay thế cho một con số BLEU thông thường ngay cả khi cả hai đều được gọi là BLEU.

• Đơn vị công việc — NLLB-200 được đánh giá từng câu trên văn bản đã căn chỉnh. Hy-SimulMT được đánh giá trên âm thanh dạng luồng, nơi lỗi đáng chú ý không phải là một từ bị dịch sai mà là một câu đến quá muộn để có thể hữu ích.

• Số lượng hướng dịch — Hơn 40.000 hướng dịch của NLLB-200 được lấy trung bình vào chỉ số tiêu đề của nó; bốn bộ đánh giá của Hy-SimulMT chỉ bao gồm tiếng Trung↔tiếng Anh. Một mức trung bình trên phần đuôi dài và một điểm số trên một cặp ngôn ngữ có nguồn tài nguyên dồi dào mô tả những kiểu thành tựu khác nhau.

Trong bảng của chính mình, Hy-SimulMT cũng không vượt trội một cách đồng đều. Nó đạt 75,5 trên CoVoST2 so với 82,1 của Qwen3.8-LiveTranslate, và kém Gemini3.5-LiveTranslate trên FLEURS (90,3 so với 92,4) và ACL6060 (81,2 so với 82,6). Chiến thắng rõ ràng nhất của nó là RealSI-Sentence với 84,7. Tất cả những con số đó đều do nhà cung cấp tự chạy, được thực hiện trên bộ khung do Tencent lựa chọn, và chưa được tái lập độc lập. Thẻ mô hình cũng không nói biến thể đầu ra nào trong hai biến thể của nó đã tạo ra chúng.

Độ trễ được đo bằng một đơn vị mà NLLB không có

Đây là phần quyết định việc triển khai, và nó không liên quan gì đến điểm số benchmark.

Một phiên dịch viên đồng thời phải thực hiện một sự đánh đổi mà một dịch giả theo lô không bao giờ gặp phải: chờ lâu hơn để dịch tốt hơn, hay nói sớm hơn và có nguy cơ sai. StreamLAAL đo lường sự đánh đổi đó — đại khái là mức độ đầu ra trễ so với đầu vào tính trung bình. Con số ba giây của Hy-SimulMT là một tuyên bố về sự đánh đổi đó. Nó rõ ràng không giống với thời gian đến đầu ra giọng nói đầu tiên, và Tencent nói như vậy trên thẻ mô hình. Khi bạn thêm một dịch vụ TTS bên ngoài, trải nghiệm của người nghe cũng bao gồm độ trễ của dịch vụ đó, điều mà con số ba giây không bao gồm.

NLLB-200 không có con số tương đương vì nó không có đường xử lý luồng. Bạn có thể gắn thêm một đường như vậy: chia nhỏ âm thanh, chạy nhận dạng giọng nói, đưa các mảnh câu vào NLLB và phát ra bản dịch khi chúng hoàn tất. Kiến trúc đó hiệu quả, và các nhóm đã xây dựng nó. Nhưng việc chia nhỏ phá hủy ngữ cảnh mà một trình dịch cấp độ câu dựa vào, và chất lượng thu được không phải là chất lượng được đo trên FLORES-200 với các câu hoàn chỉnh, đúng ngữ pháp. Khoảng cách giữa "NLLB-200 đạt điểm X trên FLORES" và "NLLB-200 bên trong một pipeline trực tiếp được chia nhỏ nghe như Y" chính là nơi phần lớn công sức kỹ thuật thực sự được đổ vào.

Đây mới là sự bất đối xứng thực sự. Hy-SimulMT được thiết kế cho trường hợp truyền phát và phải đánh đổi bằng độ phủ ngôn ngữ cùng kích thước thuộc lớp 30B. NLLB-200 được thiết kế để bao phủ rộng và phải đánh đổi bằng giao diện chỉ xử lý theo lô. Không bên nào là kém hơn. Chúng được tối ưu hóa cho những ràng buộc khác nhau.

Độ phủ theo độ sâu

Lợi thế bền vững của NLLB-200 nằm ở phần đuôi dài. Hai trăm ngôn ngữ, bao gồm cả những ngôn ngữ ít tài nguyên mà hầu hết các mô hình năm 2026 không xử lý được chút nào, trong một họ mô hình mở rộng từ checkpoint 600M đến mixture of experts 54.5B. Nếu vấn đề của bạn là một tài liệu bằng một ngôn ngữ chỉ có vài triệu người nói và không có API thương mại nào hỗ trợ nó, thì NLLB-200 vẫn là một trong số ít lựa chọn mở, và checkpoint dense 3.3B chạy trên một GPU khiêm tốn duy nhất.

Hy-SimulMT hoàn toàn không thể làm công việc đó. Nó chỉ ghi nhận tiếng Trung và tiếng Anh. Siêu dữ liệu Hugging Face của nó có thẻ 36 ngôn ngữ, nhưng không có danh sách nào của 34 ngôn ngữ còn lại được công bố, và mọi ví dụ trong kho lưu trữ đều dùng en-zh hoặc zh-en. Lập kế hoạch triển khai đa ngôn ngữ chỉ dựa vào thẻ đó sẽ là một sai lầm.

Phần tính toán trên phần cứng lại diễn ra theo chiều ngược lại. Mô hình dense 3,3B của NLLB-200 chỉ vài gigabyte ở FP16 và vừa vặn thoải mái trên một card 16–24 GB. Mô hình flagship 54,5B của nó vào khoảng 108 GB ở FP16 — tức là phải dùng nhiều GPU. Hy-SimulMT vào khoảng 61 GB ở BF16 và cần một accelerator 80 GB để phục vụ đúng như cấu hình xuất xưởng, hoặc 19,7 GB ở Q4_K_M thông qua một đường GGUF mà llama.cpp chưa hỗ trợ chính thức (upstream). Vì vậy NLLB-200 rẻ hơn ở phân khúc nhỏ và tương đương ở phân khúc cao nhất; chi phí của Hy-SimulMT tập trung ở phân khúc giữa, và đổi lại nó mang đến khả năng streaming.

Các giấy phép chỉ về hai hướng đối lập.

Đây không phải là xương sống của phép so sánh — phương thức mới là — nhưng đó là cách nhanh nhất để loại một trong số chúng cho một sản phẩm thương mại.

Trọng số của NLLB-200 là CC-BY-NC 4.0. Phi thương mại. Phần mã xung quanh dùng giấy phép MIT, đó chính là nguồn gốc của sự nhầm lẫn, nhưng thứ bạn sẽ phục vụ là trọng số, và thẻ của Meta nói rõ rằng các mô hình không được phát hành để triển khai trong môi trường sản xuất. Một triển khai thương mại cần hoặc một mô hình khác hoặc một thỏa thuận cấp phép.

Hy-SimulMT dùng Apache-2.0, không bị hạn chế truy cập, cho phép sử dụng thương mại, sửa đổi và phân phối lại. Tencent phát hành kèm một bộ công cụ huấn luyện bên cạnh máy chủ suy luận, nên việc tiếp tục huấn luyện là một mục đích sử dụng dự kiến. Nếu chỉ xét riêng về giấy phép để chọn giữa hai lựa chọn này, thì không có gì phải bàn.

Nơi chúng thuộc về trong cùng một stack

Lý do cặp so sánh này liên tục được tìm kiếm là vì các đội ngũ gặp phải cả hai vấn đề trong cùng một sản phẩm. Một công ty có hoạt động bằng tiếng Trung và tiếng Anh cần phiên dịch trực tiếp cho các cuộc họp và một pipeline văn bản cho luồng tài liệu bằng 200 ngôn ngữ đến qua email, hợp đồng và phiếu hỗ trợ. Đó là hai công việc khác nhau, và một kiến trúc trung thực sẽ dùng hai mô hình khác nhau.

NLLB-200, hoặc một phiên bản kế nhiệm hiện đại, xử lý tuyến văn bản ngoại tuyến: dịch theo lô, nhận dạng ngôn ngữ, sàng lọc kho ngữ liệu, phần đuôi dài. Hy-SimulMT xử lý tuyến giọng nói trực tiếp Trung↔Anh, nơi độ trễ chi phối và độ phủ không quan trọng vì chỉ có hai ngôn ngữ trong phòng. Ranh giới giữa chúng là một quyết định định tuyến, và đáng nêu rõ thay vì để ứng dụng suy ra từ loại tệp.

Cả hai mô hình đều không nằm trong danh mục của OrcaRouter, nên chúng tôi không phải là tuyến dẫn đến bất kỳ mô hình nào trong hai. Điều mà một router thực sự cung cấp là mối nối xung quanh chúng: một API duy nhất đứng trước hơn 200 mô hình được host với mức phụ phí 0%, giá niêm yết của nhà cung cấp được chuyển nguyên vẹn không cộng thêm gì, và một DSL định tuyến quyết định yêu cầu sẽ đi theo đường nào. Phần cuối đó thì bình thường mà hữu ích — các yêu cầu văn bản rơi xuống một mô hình tổng quát được host, yêu cầu giọng nói đi đến interpreter tự lưu trữ của bạn, và ứng dụng không cần biết cái nào là cái nào. Cơ chế chuyển đổi dự phòng tự động bao phủ trường hợp nhánh được host không khả dụng mà yêu cầu vẫn phải trả về thứ gì đó.

Vì phần được host được định giá theo giá niêm yết của nhà cung cấp và không cộng thêm gì, nên khi nhà cung cấp giảm giá ở phía văn bản, phía chúng tôi cũng có hiệu lực ngay trong ngày. Đó là chuyện nhỏ cho đến khi bạn phải định tuyến lưu lượng tài liệu với khối lượng lớn và phương án thay thế là đàm phán lại hợp đồng mỗi lần nhà cung cấp thay đổi bảng giá.

Cần hỏi gì trước khi chọn một trong hai

Câu hỏi không phải là mô hình nào tốt hơn. Mà là hai câu hỏi, và chúng có những câu trả lời khác nhau.

Nếu đầu vào là âm thanh vẫn đang đến, và các ngôn ngữ là tiếng Trung và tiếng Anh, câu trả lời là Hy-SimulMT — và câu hỏi triển khai trở thành nên dùng checkpoint nào trong sáu checkpoint của nó, một quyết định về hình dạng đầu ra và độ chính xác thay vì chất lượng. Nếu đầu vào là văn bản bằng một ngôn ngữ bạn chưa xác định được, trong một tập hợp bao gồm các ngôn ngữ ít tài nguyên, NLLB-200 vẫn là một baseline mở hợp lệ sau bốn năm, miễn là giấy phép phi thương mại phù hợp và bạn chấp nhận một giao diện theo lô.

Điều mà chưa ai công bố là cầu nối: nhận dạng giọng nói đưa vào NLLB-200 trên âm thanh tiếng Trung↔tiếng Anh, được đánh giá trên cùng một chuẩn đánh giá truyền phát như Hy-SimulMT, với độ trễ và chất lượng được báo cáo cùng nhau. Thí nghiệm đó sẽ cho bạn biết liệu một trình dịch văn bản năm 2022 được bọc trong một khung truyền phát năm 2026 có thể cạnh tranh với một trình phiên dịch chuyên dụng hay không. Đây cũng sẽ là so sánh trung thực đầu tiên giữa hai mô hình này, và nó vẫn chưa tồn tại.

Một điều cuối cùng đáng nói thẳng, vì sự giống nhau chỉ khác một chữ cái giữa tên các benchmark sẽ tiếp tục tạo ra những so sánh sai lệch: một mô hình thắng trên FLEURS đã chứng minh được điều gì đó về dịch lời nói trong một bộ khung đánh giá cụ thể. Một mô hình đạt điểm cao trên FLORES-200 đã chứng minh được điều gì đó về dịch văn bản qua 200 ngôn ngữ. Không kết quả nào chuyển sang được công việc của kết quả kia, và nhà cung cấp nào công bố cả hai trên cùng một âm thanh, với cùng một thước đo và cùng cách tính độ trễ, sẽ là bên đầu tiên khiến so sánh này có ý nghĩa.