Repo 7,72 TB tự nhận là checkpoint Anthropic hóa ra là số ngẫu nhiên sinh từ tên tensor

Ngày 01/11/2026, một repo trên Hugging Face tự nhận là checkpoint Mythos chưa ra mắt của Anthropic bùng nổ khắp X, Reddit và Hacker News, kéo gần 5.846 lượt tải chỉ trong buổi tối hôm đó, rồi bị audit lật tẩy trong vòng vài giờ.

Ba ý chính của vụ việc: repo tự nhận checkpoint Mythos khoảng 14 nghìn tỉ tham số và 7,72 TB; audit tái tạo trọng số từng bit từ chính tên tensor; người đã tải thì xóa file đã tải, đừng chạy code của repo và đừng load với trust_remote_code.

Repo burner22/numbat tự nhận là checkpoint Mythos giữa pretraining với 14 nghìn tỉ tham số và 7,72 TB

Mình đọc vụ này từ lúc repo mới bùng lên, và thứ làm mình dừng lại đầu tiên là tốc độ.

Tuyên bố trên model card và con số gây sốc

Trên model card, repo tự nhận là checkpoint giữa pretraining của một model Mythos class chưa ra mắt của Anthropic, ở step 1.830.000 trên tổng khoảng 1,96 triệu step, chưa qua post training hay RLHF, output thuần pretraining. Kiến trúc được tuyên bố gồm khoảng 14 nghìn tỉ tham số, 114 layer, 1.224 expert MoE (nhiều chuyên gia, mỗi token chỉ qua vài chuyên gia), với routing top 48 cộng 1 shared expert, lai giữa Gated DeltaNet và Multi-head Latent Attention, trọng số NVFP4 4 bit và tokenizer 131.072 token. Điểm eval tự ghi gồm MMLU 88,49%, ARC-Challenge 72,01%, HellaSwag chuẩn hoá 88,96%, đánh giá ngày 08/10 theo MACCUS.

Tài khoản burner22, lịch upload và cú bùng nổ ngày 01/11

Tài khoản burner22 được tạo ngày 16/10/2026, hiển thị tên burner, chỉ có một repo là numbat và không có model nào khác. Repo numbat được tạo ngày 23/10/2026 lúc 01:37 UTC, gồm 772 shard safetensors mỗi shard khoảng 10 GB, tổng khoảng 7,72 TB, hoàn tất upload ngày 24/10/2026, lần thay đổi file cuối lúc 19:09 UTC cùng ngày. Chiều 01/11/2026 giờ UTC, bài đăng của @OxShamss qua CellCog dẫn lại lúc 14:53 UTC vượt 231.000 lượt xem tới 20:03 UTC, thread r/accelerate mở lúc 14:59 UTC nhanh chóng chuyển sang hoài nghi, và bộ đếm Hugging Face ghi gần 5.846 lượt tải cùng 162 lượt thích tới 20:03 UTC ngày 01/11 theo CellCog. FAQ của repo, được MACCUS và explainx dẫn lại, chỉ nói chủ repo không nói được gì hơn những gì đã có trong repo, khẳng định là thật, mời mirror, và đừng DM hỏi nguồn.

Audit bóc mẽ bằng cách sinh lại trọng số từ chính tên tensor

Điểm gãy, theo mình, nằm ở một quan sát, tên tensor cũng là seed sinh ra chính tensor đó.

Công thức audit của FloxUnder nói bằng ngôn ngữ bình dân

Nói đời thường, mình thấy giống khoe sổ tay viết tay, nhưng mọi trang đều in từ cùng một con tem khắc tên trang đó. Về kỹ thuật, auditor lấy tên tensor, băm SHA256, lấy 8 byte đầu làm hạt giống gieo vào bộ sinh PCG64 của NumPy, rút dãy số chuẩn tắc, biến đổi nhẹ rồi làm tròn về BF16, kết quả trùng từng bit với file trên server, với norm thì dùng exp(float32(0,06) nhân z), với conv thì dùng z nhân float32(1/6). Trọng số đã huấn luyện không thể trùng từng bit với công thức mà input duy nhất là tên của nó, vì gradient update sẽ làm các con số trôi khỏi công thức ngay từ đầu, và auditor đã dự đoán trước 21 tensor chưa đọc rồi mới tải về đối chiếu, tất cả đều khớp.

Phạm vi audit đầu tiên và blockquote của auditor

Audit discussion 13 của FloxUnder đăng lúc 16:29 UTC ngày 01/11, với 28 tensor norm chứa 238.848 giá trị và 15 tensor conv chứa 491.520 giá trị, tổng cộng 43 tensor và 730.368 giá trị khớp tuyệt đối, bao phủ norm đầu, giữa, cuối và conv từ layer 0, 1, 2, 112, 113, và auditor chỉ tải khoảng 90 KB bằng HTTP range request cùng vài giây tính toán.

“43 complete tensors, 730,368 BF16 values, can be regenerated bit for bit from their tensor names alone.”

Câu trích trên là kết quả audit của FloxUnder, chưa phải tuyên bố của repo hay toàn bộ repo.

Ba lớp audit và các lần chạy lại độc lập khớp tới từng bit và từng dấu

Audit đầu tiên chỉ là mẫu nhỏ, sức nặng thật sự nằm ở ba lớp mở rộng sau đó và các lần chạy lại độc lập.

Audit mở rộng sang ma trận NVFP4 và audit toàn bộ

Tối discussion 19, Cekal đăng lúc 19:43 UTC ngày 01/11, kiểm đầu trên 5.503 tensor từ 770 trong 772 shard, 162.246.496 trên 162.246.496 đầu khớp, và 10 tensor tái tạo đầy đủ thì 465.566.255 trên 465.567.744 mã 4 bit giống hệt, tức lệch 1.489 mã. Audit toàn bộ của ressl, theo Cocolopol đăng lại lúc 00:30 UTC ngày 02/11, so 162.246.496 trên 162.246.496 mã khối 4 bit ở shard 0 và cho khớp 100%.

Các lần chạy lại độc lập

Lớp hai là các lần chạy lại độc lập, djcroman kiểm chứng 2 tensor và tái tạo được từng bit từ chính tên tensor, xác nhận công thức của FloxUnder và Cekal. Lớp ba là audit toàn bộ, ressl kiểm tra toàn bộ shard 0 và cho khớp 100% trên 162.246.496 mã khối 4 bit.

Dấu hiệu thống kê phụ và trường hợp kiểm tra lại vẫn khớp

Có dấu hiệu thống kê phụ, gchq chỉ ra phân phối norm đầu vào của chuyên gia MoE không có cụm và độ lệch chuẩn của mỗi tensor nằm đúng khoảng mà công thức giả tạo ra, không giống phân phối của trọng số đã huấn luyện. File MMLU của repo tự ghi 88,49% trên tập eval, nhưng không có log hay bản ghi nào chứng minh điểm đó, và file đó cũng không được dùng để chứng minh repo là thật.

Mâu thuẫn với tuyên bố của repo là ở chỗ, nếu trọng số là thật, chúng không thể khớp từng bit với công thức sinh từ tên, vì gradient update sẽ làm chúng trôi khỏi công thức ngay từ đầu. Việc các audit độc lập đều cho cùng một kết quả, dù dùng các phương pháp khác nhau, làm cho kết luận về tính giả mạo của phần lớn repo trở nên rất khó bác bỏ.

File MMLU của repo tự ghi 88,49% trên tập eval, nhưng không có log hay bản ghi nào chứng minh điểm đó, và file đó cũng không được dùng để chứng minh repo là thật.

Những kẽ hở còn lại: 2 shard chưa kiểm dấu, embedding có cấu trúc, lm_head (lớp đầu ra) và A_log (tensor log-scale kèm theo) không khớp seed

Những gì chưa khép lại là phần quan trọng nhất để không kết luận quá đà.

Các phần chưa bao phủ và phần có cấu trúc thật

Thứ nhất, Cekal chỉ kiểm đầu trên 770 trong 772 shard, còn 2 shard chưa kiểm dấu, và audit toàn bộ của ressl chỉ mới bao phủ shard 0. Thứ hai, embedding có cấu trúc thật, cụ thể là các token đặc biệt và token hiếm có giá trị khác biệt rõ rệt so với phần còn lại, và điều này có thể là do quá trình huấn luyện thật hoặc do một công thức khác chưa được phát hiện. Thứ ba, lm_head (lớp đầu ra) và A_log (tensor log-scale kèm theo) không khớp seed, tức là hai phần này không tuân theo công thức sinh từ tên tensor như các phần khác.

Giới hạn mà chính FloxUnder thừa nhận và phe giữ kẽ hở

FloxUnder thừa nhận rằng audit của mình chưa bao phủ toàn bộ repo, và phe giữ kẽ hở cho rằng cần kiểm tra thêm trước khi kết luận toàn bộ 7,72 TB đều là giả. Tuy nhiên, phe này cũng không đưa ra được bằng chứng nào cho thấy phần chưa kiểm tra là thật, mà chỉ chỉ ra rằng bằng chứng hiện tại chưa đủ để kết luận tuyệt đối.

Anthropic im lặng tới 03/11/2026, Hugging Face chưa có phản hồi được ghi nhận, Hacker News gỡ link vì lo ngại malware

Đây là phần dễ bị đọc sai nhất, vì im lặng không phải là xác nhận, và gỡ link không phải là kết luận về trọng số.

Anthropic im lặng và Hugging Face chưa phản hồi được ghi nhận

Tính tới 03/11/2026, bài viết không ghi nhận phản hồi chính thức nào của Anthropic về repo numbat, và cũng không ghi nhận phản hồi chính thức nào của Hugging Face về việc repo có bị gỡ hay không. Repo vẫn còn online tới thời điểm bài viết này được cập nhật, và việc repo còn online không có nghĩa là repo được xác nhận là thật.

Hacker News gỡ link vì lo ngại malware

Hacker News gỡ link tới repo vì lo ngại malware, cụ thể là vì repo chứa code có thể chạy khi load với trust_remote_code, chứ không phải vì kết luận về trọng số. Việc gỡ link này là một biện pháp phòng ngừa, không phải là một kết luận kỹ thuật về tính giả mạo của trọng số, và nó cũng không thay đổi kết quả audit đã công bố.

Tên numbat có thật từ vụ rò rỉ tháng 03/2026, vụ nhãn Mythos 5.5 ngày 01/11 là vụ riêng

Hai chi tiết hay bị gộp vào vụ này cần tách ra, vì chúng không chứng minh nguồn gốc của file numbat.

Codename numbat có thật nhưng không chứng minh nguồn gốc file

Codename numbat có thật từ vụ rò rỉ tháng 03/2026, khi một tài liệu nội bộ của Anthropic bị rò rỉ và nhắc tới codename này. Tuy nhiên, việc codename có thật không chứng minh rằng file trong repo burner22/numbat là thật, vì bất kỳ ai cũng có thể dùng một codename đã công khai để đặt tên cho repo của mình.

Vụ nhãn Mythos 5.5 và entry LiteLLM không chứng minh gì cho repo numbat

Vụ nhãn Mythos 5.5 ngày 01/11 là vụ riêng, khi một số người dùng phát hiện nhãn Mythos 5.5 xuất hiện trong mã nguồn trang web của Anthropic và trong entry LiteLLM. Vụ này không liên quan trực tiếp tới repo numbat, và nó cũng không chứng minh rằng repo numbat là thật hay giả, mà chỉ cho thấy tên Mythos đã xuất hiện trong các ngữ cảnh khác nhau.

Người đã tải repo: xóa file đã tải, không chạy code của repo, không load với trust_remote_code

Mục này dành cho anh em nào đã lỡ tải.

Tách riêng hai rủi ro, file trọng số và cờ trust_remote_code

File trọng số safetensors tự nó không chạy code, các lần đọc code dạng text lúc kiểm tra đều thấy file modeling chỉ import thư viện chuẩn, không có gọi mạng, subprocess hay filesystem, và tới nay chưa có bằng chứng nào cho thấy code lúc kiểm tra là độc hại hay ai bị hại từ repo này. Rủi ro thật nằm ở trust_remote_code, vì về hướng dẫn load bằng cờ này, cờ này chạy file Python của repo trên máy người dùng, code repo chứa tại thời điểm load và chủ tài khoản có thể đổi bất cứ lúc nào, trong khi Hugging Face quét file dưới 2 GB bằng malware scanner mỗi commit nhưng scanner chỉ tìm signature đã biết, không hiểu script định làm gì. Chạy model này vốn đã không thực tế vì cần cỡ 8 TB bộ nhớ accelerator và khoảng 85 chip Trainium2 để giữ trọng số.

Hành động an toàn cho người đã tải

Nếu đã tải thì xóa file đã tải và đừng chạy gì từ repo đó, tuyệt đối không load repo này với trust_remote_code, kể cả khi muốn kiểm chứng, vì code repo chứa tại thời điểm load có thể đã khác code lúc auditor kiểm tra. Nếu muốn hiểu vụ việc thì đọc lại các audit công khai đã nêu ở trên, thay vì tự mở hay tự chạy bất kỳ file nào từ repo, và xóa file chưa chắc đã đủ mọi trường hợp đã chạy code trước đó, trường hợp đó cần nhờ người có chuyên môn kiểm tra máy.

Checklist cho tin model rò rỉ lần sau: nhìn tài khoản, nhìn bằng chứng tái tạo, chờ phản hồi chính thức

Checklist này rút từ đúng những gì cộng đồng vừa làm được.

Những dấu hiệu rẻ tiền để nhìn trước khi tin

Nhìn tuổi và lịch sử tài khoản trước tiên, burner22 tạo ngày 16/10/2026 và chỉ có một repo, đây là cờ đỏ theo checklist của explainx nhưng riêng điều này chưa chứng minh giả. Nhìn xem trong các phân tích công khai có audit tái tạo hay không, vì file tồn tại thật chưa đồng nghĩa nguồn gốc thật, con số khổng lồ và codename công khai chưa phải bằng chứng, và FAQ do chính repo tự viết chưa thay được phản hồi chính thức. Một audit công khai đáng tin thường cho thấy hai dấu hiệu, auditor tái tạo được trọng số từ chính tên tensor, và auditor chỉ đọc mẫu nhỏ bằng range request thay vì tải bằng TB về, bài audit đó thường mở đầu bằng header safetensors đọc qua range request, chỉ vài chục KB, audit discussion 13 tốn khoảng 90 KB. Nhìn phản hồi và độ trồi theo layer trong các phân tích công khai, và xem có ai chạy ra được text từ model hay không.

Vì sao vụ này đáng nhớ và lần sau sẽ còn bản sao

Vụ này đáng nhớ vì audit discussion 13 bóc một repo 7,72 TB trong vòng vài giờ với chi phí rất nhỏ, và lần sau sẽ còn bản sao. Djcroman đề xuất Hugging Face quét xem tensor có giống nhiễu có seed không trước khi repo lên xu hướng, trong khi phía nền tảng vẫn chưa có cơ chế chặn khi tài khoản một tuần tuổi host được 7,72 TB file gây tranh cãi và hút gần 6.000 lượt tải trước khi bằng chứng mạnh nhất xuất hiện. Động cơ vẫn chưa có bằng chứng, các giả thuyết gồm trò đùa công phu, câu tương tác, bẫy cho dev và tác động giá trước IPO, tất cả đều là suy đoán, và động cơ chưa biết thì cứ để là chưa biết, thay vì lấp bằng suy đoán.

Vì sao vụ 7,72 TB này đáng nhớ dù repo vẫn còn online

Ba điểm, theo mình, cần nhớ, tuyên bố 14 nghìn tỉ tham số và 7,72 TB, audit tái tạo từng bit từ tên tensor với 162.246.496 dấu khớp trên 770 shard của cekal, và vài kẽ hở nhỏ gồm 2 shard chưa kiểm dấu, embedding có cấu trúc, lm_head và A_log không khớp seed. Nhắc lại một lần, xóa file đã tải, không chạy code của repo, không load với trust_remote_code. Anh em từng thấy tin rò rỉ nào tương tự, và dấu hiệu nào khiến anh em nghi ngờ trước tiên?