Ra mắt LongCat-2.0 - mô hình mã nguồn mở 1,6 nghìn tỷ tham số được huấn luyện không cần Nvidia

 (longcat.chat)
3 điểm bởi GN⁺ 6 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Mô hình ngôn ngữ MoE quy mô lớn với tổng cộng 1,6 nghìn tỷ (1.6T) tham số và khoảng 48 tỷ tham số được kích hoạt cho mỗi token, đồng thời đi kèm nhiều cải tiến kiến trúc cùng với việc mã nguồn mở
  • Toàn bộ quá trình huấn luyện và triển khai quy mô lớn đều được thực hiện trên siêu pod AI ASIC, hoàn tất tiền huấn luyện trên hơn 35 nghìn tỷ token mà không gặp các đợt tăng loss đột biến dẫn đến không thể rollback hoặc khôi phục
  • Giới thiệu LongCat Sparse Attention (LSA) và huấn luyện trên dữ liệu ngữ cảnh 1M ở quy mô hàng trăm tỷ token để tăng cường hiệu năng cho các tác vụ dài hạn
  • Tích hợp chặt chẽ với các harness phổ biến như Claude Code, OpenClaw, Hermes, mang lại hiệu năng mạnh trong hiểu mã, sửa đổi ở cấp kho mã, thực thi tác vụ tự động và quy trình làm việc agent
  • Chứng minh rằng có thể thực hiện huấn luyện cấp frontier trên phần cứng thay thế còn kém trưởng thành hơn hệ sinh thái Nvidia GPU, và việc tối ưu hóa trên toàn bộ hạ tầng lẫn giai đoạn hậu huấn luyện đã chuyển hóa thành năng lực giải quyết tác vụ thực tế

Tổng quan mô hình

  • Mô hình ngôn ngữ MoE quy mô lớn với 1,6 nghìn tỷ tham số, chỉ kích hoạt khoảng 48 tỷ tham số cho mỗi token và là bước tiến lớn so với các mô hình LongCat trước đó
  • Toàn bộ quá trình huấn luyện và triển khai quy mô lớn đều được xây dựng trên siêu pod AI ASIC
    • Tiền huấn luyện được thực hiện ở quy mô hàng triệu accelerator-day trên hơn 35 nghìn tỷ token, hoàn tất mà không có loss spike phải rollback hoặc không thể khôi phục
    • Chứng minh năng lực thực hiện huấn luyện cấp frontier trên các nền tảng phần cứng thay thế
  • Để tăng cường các tác vụ dài hạn, mô hình đưa vào LongCat Sparse Attention và được huấn luyện bằng dữ liệu ngữ cảnh 1M với quy mô hàng trăm tỷ token
  • Tích hợp sâu với các harness phổ biến như Claude Code, OpenClaw, Hermes, mang lại trải nghiệm cộng tác ổn định và hiệu quả trên toàn bộ các mảng hiểu mã, chỉnh sửa ở cấp kho mã, thực thi tác vụ tự động và quy trình agent

Kiến trúc

  • Dựa trên LongCat-Flash, tiếp tục đẩy mạnh hiệu quả tham số và cải thiện tốc độ huấn luyện/suy luận với ngữ cảnh dài
  • Ở attention, mô hình đưa vào LongCat Sparse Attention (LSA)
    • Là phiên bản tiến hóa từ DeepSeek Sparse Attention, sử dụng indexer nhẹ hơn để tăng tốc xử lý ngữ cảnh dài mà không làm giảm chất lượng mô hình
  • Bổ sung mô-đun N-gram Embedding
    • Mở rộng không gian embedding khoảng 100 lần thông qua các tổ hợp token N-gram, giúp nắm bắt ngữ cảnh cục bộ phong phú hơn và tăng cường biểu diễn ở mức token

LongCat Sparse Attention

  • Khi các ứng dụng kiểu agent ngày càng phổ biến, LLM đang chuyển sang hướng xử lý hiệu quả các đầu vào dài
    • DSA đáp ứng bằng sparse attention chi tiết, nhưng kết quả profiling cho thấy Lightning Indexer của DSA vẫn là nút thắt cổ chai chính do tính gián đoạn đầu ra và chi phí chấm điểm bậc hai (quadratic)
  • LSA đưa vào ba cải tiến hiệu quả độc lập lẫn nhau (orthogonal) ở indexer
    • Streaming-aware Indexing(SI): tái cấu trúc ngân sách chọn token để kết hợp truy cập tuần tự căn chỉnh phần cứng với lựa chọn ngẫu nhiên động, biến truy cập bộ nhớ phân mảnh thành các lần đọc tuần tự có thể dự đoán, từ đó đạt truy cập HBM coalesced và băng thông hiệu dụng cao
    • Cross-Layer Indexing(CLI): tận dụng tính ổn định thực nghiệm của attention saliency giữa các layer kề nhau để phân tán chi phí indexing; khi suy luận, một lượt indexing duy nhất được dùng cho nhiều layer liên tiếp và điều này khả thi nhờ cross-layer distillation trong quá trình huấn luyện
    • Hierarchical Indexing(HI): chấm điểm hai giai đoạn coarse-to-fine, trước tiên dùng chấm điểm xấp xỉ theo block để thu hồi sơ bộ rồi chọn token chi tiết trong tập ứng viên; trong LongCat-2.0, cơ chế này được áp dụng không cần huấn luyện (training-free) và được kích hoạt cho một số tác vụ ngữ cảnh siêu dài được chọn lọc
  • Ba thành phần này độc lập về mặt thiết kế nên có thể bật/tắt riêng lẻ
  • Ba chiến lược này được mở rộng sang mô-đun Multi-Token Prediction(MTP) 3 giai đoạn để tăng tốc speculative decoding
    • Cross-Layer Indexing được áp dụng khác nhau giữa draft model và target model; target model cho phép 2 layer liên tiếp dùng chung một lượt indexing
    • Trong MTP nhiều giai đoạn, 3 draft step chia sẻ một lượt xử lý, trong đó step 2 và 3 tái sử dụng tập chỉ mục do step 1 tạo ra

N-gram Embedding

  • Kế thừa từ LongCat-Flash-Lite, mở rộng tham số theo một chiều sparse trực giao với MoE để nâng cao hiệu quả sử dụng tham số
    • Kích thước n-gram được đặt là 5, và mô hình bao gồm 135B tham số N-gram Embedding
  • Tuân theo các nguyên tắc mở rộng sau
    • Độ thưa của MoE đã vượt qua sweet spot: ngay cả khi không có N-gram Embedding, độ thưa đã đạt khoảng 97%, nên việc tăng thêm 135B expert chỉ mang lại lợi ích hiệu năng rất nhỏ; trong khi đó, N-gram Embedding cùng quy mô tham số lại cho lợi ích lớn hơn nhiều so với expert tiêu chuẩn
    • Tỷ trọng N-gram Embedding được giới hạn trong vùng tối ưu: các thí nghiệm scaling cho thấy nếu tham số embedding n-gram chiếm tỷ trọng quá lớn trong tổng ngân sách (trên 50%), lợi thế so với việc mở rộng expert sẽ giảm xuống; ở LongCat-2.0, tỷ trọng này được giữ nghiêm ngặt dưới 10%
  • Khi suy luận, chuyển tham số từ expert sang N-gram Embedding giúp giảm memory I/O trong giải mã batch lớn và tăng tốc sinh

Hạ tầng mở rộng dựa trên siêu pod AI ASIC

  • Huấn luyện và triển khai dựa trên cụm quy mô lớn gồm hàng chục nghìn siêu pod AI ASIC
  • So với hệ sinh thái Nvidia GPU đã trưởng thành, cộng đồng phần mềm hỗ trợ vẫn còn kém phát triển hơn, nên nhóm đã đầu tư đáng kể để xây dựng hạ tầng ổn định, an toàn và có thể mở rộng

Huấn luyện(Training)

  • Tiền huấn luyện trên hơn 50.000 AI ASIC, phát sinh nhiều bài toán khó ở cấp hệ thống do quy mô mô hình và cụm

    • Thông qua tối ưu hóa có hệ thống, nhóm cải thiện hơn 35% thông lượng huấn luyện so với triển khai naive, đồng thời tăng độ tin cậy

  • Tính quyết định & độ tin cậy(Determinism & Reliability)

    • Để bảo đảm khả năng tái lập, nhóm ép tính quyết định trên toàn bộ đường truyền thông và tính toán, đồng thời cung cấp các toán tử và mô-đun quyết định do họ tự xây dựng cho các layer Embedding, FA, LSA và MoE
    • Để tăng độ tin cậy số học, các toán tử nền tảng được làm lại; ví dụ, toàn bộ phép toán kiểu reduction dùng chiến lược tích lũy phân đôi binary-tree để giảm sai số số thực dấu phẩy động tích lũy
      • Trên các workload LLM thực tế, độ chính xác tính toán của accelerator được đối chiếu chặt chẽ với baseline độ chính xác cao nghiêm ngặt để xác minh tính toàn vẹn số học và mức sẵn sàng cho production
      • Với một số toán tử đòi hỏi tính toán cao, nhóm bổ sung phát hiện bit-flip để bắt ngay các bất thường lật bit phần cứng
    • Khôi phục lỗi được thực hiện bằng giám sát end-to-end để nhận diện lỗi, chuyển hướng lưu lượng và phục hồi mà không cần can thiệp thủ công; khi cô lập các liên kết lỗi, việc huấn luyện hầu như không bị ảnh hưởng rõ rệt, và các liên kết đã khôi phục chỉ được tham gia lại sau khi vượt qua stress test

  • Huấn luyện ở quy mô lớn(Training at Scale)

    • Bộ nhớ trên mỗi thiết bị của accelerator thấp hơn đáng kể so với H800(80GB), nên bộ nhớ trở thành nút thắt chính khi mở rộng quy mô; nhóm xử lý bằng cả chiến lược song song hóa lẫn quản lý bộ nhớ
    • Song song hóa 6D: ngoài TP/CP/EP/DP/PP tiêu chuẩn, nhóm đưa vào EMBP để song song hóa và tăng tốc N-gram Embeddings
    • Siêu pod: huấn luyện trên các siêu pod vật lý, mỗi pod tối đa 48 máy; bên trong dùng kết nối all-to-all băng thông cao, còn giữa các pod dùng RoCE fabric để mở rộng miền giao tiếp băng thông cao cho các kiểu song song hóa cần băng thông lớn (TP/CP/EP) lên hàng trăm thiết bị
      • Mang lại thêm khoảng 30% thông lượng tiền huấn luyện trong cùng quy mô và môi trường
      • Siêu pod logic được dùng như đơn vị lập lịch affinity để cân bằng giữa tính cục bộ của giao tiếp và khả năng lập lịch
    • Tối ưu bộ nhớ: áp dụng ZeRO-1, recomputation chọn lọc, offloading nhận biết OOM ở cấp allocator, và định tuyến padding token tới zero-expert
    • Muon optimizer: được triển khai ở quy mô lớn trên accelerator, với các tối ưu hóa có mục tiêu trên song song hóa TP, loại bỏ trùng lặp DP state và kernel nhân ma trận đối xứng hiệu quả

  • Huấn luyện ngữ cảnh dài(Long Context Training)

    • Nhóm xử lý các thách thức của huấn luyện ngữ cảnh dài quy mô lớn từ ba góc độ
    • Toán tử LSA & tối ưu forward: triển khai các toán tử attention quyết định riêng cho dense-warmup, giai đoạn sparse và toán tử KL-loss; dùng chiến lược dense-warmup chỉ forward để tính KL loss và gradient trong một forward pass duy nhất nhằm cải thiện hiệu quả
    • Mở rộng lên ngữ cảnh 1M: hiện thực huấn luyện độ dài 1M gốc bằng song song hóa CP dựa trên all-gather có thể mở rộng CP lên trên 512; đồng thời giữ cân bằng workload bằng cách reshuffle dữ liệu ở bước get-batch và chiến lược CP cân bằng
    • Chồng lấp tính toán - truyền thông: ví dụ, kiến trúc shortcut-layer chồng lấp giao tiếp MoE với tính toán ở nhánh song song, còn phép tính chỉ mục top-k của LSA chồng lấp với KV all-gather để giảm overhead đồng bộ

Suy luận(Inference)

  • Việc phục vụ mô hình 1,6T tham số với ngữ cảnh 1M token là bài toán rất khó dưới các ràng buộc khắt khe về dung lượng HBM, băng thông HBM I/O và băng thông liên kết giữa các node; nhóm xử lý bằng một stack tối ưu hóa ở cấp mô hình, thiết bị và triển khai

  • Tối ưu hóa đặc thù cho mô hình

    • Attention: tối ưu các nút thắt I/O, tính toán và bộ nhớ của ngữ cảnh siêu dài từ ba góc nhìn
      • (1) áp dụng chế độ tính toán absorb ở cả giai đoạn prefill và decode
      • (2) pipeline indexer cùng luồng song song với MLA prolog để che giấu overhead của indexer
      • (3) dùng KV-cache parallelism(KVP) để shard KV-cache giữa các thiết bị
    • ScMoE: dựa trên chồng lấp tính toán - truyền thông của LongCat-Flash và tiếp tục phát triển lịch thực thi xa hơn nữa, tận dụng khả năng điều khiển explicit per-core của accelerator để chạy hoàn toàn song song các nhánh dense và MoE, vượt ra ngoài mức chồng lấp đơn thuần

  • Tối ưu hóa hướng accelerator

    • Super Kernel: ở chế độ graph, khoảng trống giữa các kernel được loại bỏ nhưng overhead launch bên trong kernel vẫn còn; super kernel giúp giảm chi phí launch nội bộ này
    • Weight Prefetch: thiết bị có băng thông HBM hạn chế nhưng sở hữu L2 cache tương đối lớn; nhóm dùng L2 cache lớn này để prefetch trọng số nhằm che giấu độ trễ I/O trong lúc các toán tử trước đó đang tính toán
    • Scale Up and Scale Out: việc truyền KV-cache giữa các node P và D sử dụng network adapter 200Gbps tích hợp trên accelerator; KV-cache được truyền theo từng layer, kho lưu trữ KV-cache được cấu thành bằng host RDMA network adapter, còn TP/SP/KVP được thực hiện trong miền liên kết scale-up

  • Triển khai & phục vụ

    • Song song hóa tối ưu: để cân bằng TTFT và TPOT, nhóm áp dụng triển khai tách biệt prefill–decode(PD)
      • Node prefill: xử lý chuỗi dài bị ràng buộc bởi băng thông giao tiếp liên node và lưu lượng dispatch/combine của MoE chi phối runtime; nhóm dùng multi-node chunked pipeline parallelism(CPP) để thu hẹp miền expert-parallel(EP), đồng thời dùng Attention Sequence Parallelism(SP) trong từng pipeline stage để giảm áp lực tính toán chuỗi dài
      • Node decode: ràng buộc chính là bộ nhớ thiết bị và KV-cache I/O; KVP được dùng để shard KV-cache, giảm memory footprint trên mỗi thiết bị, còn bậc EP lớn (EP128) giúp đồng thời giảm bộ nhớ trọng số trên mỗi thiết bị và expert I/O
      • Ở cả hai giai đoạn, các cách song song hóa (CPP/SP·KVP) đều được thiết kế để kết hợp gọn gàng với các tối ưu hóa suy luận như constrained decoding, multi-step scheduling và MTP
    • Expert-Parallel Load Balancing(EPLB): bậc EP lớn ở node decode làm tăng khả năng mất cân bằng tải giữa các expert; nhóm xử lý bằng EPLB, đồng thời để giảm overhead phục vụ thì việc thu thập thống kê và tính toán theo batch được thực hiện bất đồng bộ ngoài forward critical path

Học từ nhiều teacher(Learning from Multiple Teachers)

  • Để nâng cao hiệu năng tổng thể và mở rộng ranh giới năng lực, pipeline hậu huấn luyện đưa vào thiết kế expert-group chuyên biệt, gồm ba nhóm
  • Agent Experts: cải thiện thực thi tác vụ tự động trong các kịch bản thực tế phức tạp, đạt hiệu năng cấp SOTA ở các miền dọc chi tiết như code, công việc và tìm kiếm
    • Không chỉ tối ưu tỷ lệ thành công end-to-end của tác vụ mà còn tối ưu các năng lực nguyên tử hỗ trợ độ vững của agent, bao gồm gọi tool chính xác, phân tích tham số đáng tin cậy trong tương tác API nhiều lượt và cơ chế tự sửa để giảm vòng lặp vô hạn cùng các lời gọi lặp lại
  • Reasoning Experts: mở rộng độ sâu suy luận logic và kích hoạt tính toán thích ứng theo độ khó của bài toán, mang lại hiệu năng mạnh trong toán học, giải bài STEM và suy luận multi-hop, từ đó cải thiện năng lực xử lý các kịch bản phân tích phức tạp
  • Interaction Experts: tập trung vào căn chỉnh với con người và tối ưu trải nghiệm người dùng, cải thiện khả năng tuân theo chỉ dẫn chi tiết trong nhiều ứng dụng khác nhau, đồng thời dùng các kỹ thuật căn chỉnh nâng cao để giảm ảo giác sự thật và thiết lập cơ chế an toàn có ranh giới rõ ràng mà không làm suy giảm tính hữu ích
  • Cuối cùng, nhóm tích hợp những năng lực mạnh nhất của ba expert group bằng kiến trúc MOPD, kết hợp thực thi agent mạnh, suy luận sâu và tương tác chất lượng cao để hiểu chính xác các yêu cầu người dùng phức tạp và hoàn thành đáng tin cậy các tác vụ thực tế khó

Trình diễn năng lực mô hình

  • Nhờ suy luận ngữ cảnh dài và hậu huấn luyện chuyên biệt, mô hình thể hiện thế mạnh trong việc thực hiện các tác vụ thực tế

  • Codebase Migration

    • Đọc toàn bộ codebase cùng tài liệu migration, ánh xạ kiến trúc và viết lại toàn bộ plugin sang SDK mới
    • Giữ nguyên toàn bộ tính năng hiện có, phát hiện lỗi tiềm ẩn và biên dịch sạch ngay ở lần build đầu tiên

Đánh giá(Evaluations)

  • So sánh với các mô hình thương mại chủ chốt trên các mảng code, general agent và năng lực nền tảng; trừ các điểm có dấu *, mọi điểm số đều do nhóm tự đo bằng harness tích hợp (chuẩn hóa 0–100)

  • Code Agent

    • Terminal-Bench 2.1: LongCat-2.0 70.8, Gemini 3.1 Pro 70.7*, GPT-5.5 73.8*, Claude Opus 4.7 71.7*, Opus 4.8 78.9*
    • SWE-bench Pro: LongCat-2.0 59.5, Gemini 3.1 Pro 54.2*, GPT-5.5 58.6*, Opus 4.6 57.3*, Opus 4.7 64.3*, Opus 4.8 69.2*
    • SWE-bench Multilingual: LongCat-2.0 77.3, Gemini 3.1 Pro 76.9*, Opus 4.6 77.8*, Opus 4.7 80.5*, Opus 4.8 84.8*

  • General Agent

    • FORTE†: LongCat-2.0 73.2, Gemini 3.1 Pro 70.3, GPT-5.5 77.8, Opus 4.6 73.2, Opus 4.7 77.6, Opus 4.8 77.2
    • BrowseComp: LongCat-2.0 79.9, Gemini 3.1 Pro 85.9*, GPT-5.5 84.4*, Opus 4.6 84.0*, Opus 4.7 79.3*, Opus 4.8 84.3*
    • RWSearch: LongCat-2.0 78.8, Gemini 3.1 Pro 76.3, GPT-5.5 85.3, Opus 4.6 81.3, Opus 4.7 79.3, Opus 4.8 77.3

  • Foundational

    • IFEval: LongCat-2.0 90.0, Gemini 3.1 Pro 96.1, GPT-5.5 95.0, Opus 4.6 92.2, Opus 4.7 88.7, Opus 4.8 86.0
    • Writing Bench: LongCat-2.0 83.8, Gemini 3.1 Pro 83.7, GPT-5.5 84.7, Opus 4.7 85.3, Opus 4.8 85.2
    • IMO-AnswerBench: LongCat-2.0 81.8, Gemini 3.1 Pro 90.0, GPT-5.5 79.5, Opus 4.6 75.3*, Opus 4.7 81.8, Opus 4.8 75.3
    • GPQA-diamond: LongCat-2.0 88.9, Gemini 3.1 Pro 94.3*, GPT-5.5 93.6*, Opus 4.6 91.3*, Opus 4.7 94.2*, Opus 4.8 92.4

  • Điều kiện đánh giá

    • Terminal-Bench 2.1: đánh giá bằng Claude Code, mỗi sandbox instance 8c16g, tham số suy luận temperature=1.0/top_k=-1/top_p=0.95, agent timeout 6 giờ
    • SWE-Bench series: đánh giá bằng Claude Code, mỗi sandbox instance 4c8g, temperature=1.0/top_k=-1/top_p=1, các tác vụ có vấn đề đã được chỉnh sửa
    • FORTE: benchmark general agent đánh giá AI agent bằng năng suất công việc văn phòng hằng ngày của 15 vị trí doanh nghiệp, hỗ trợ framework OpenClaw/Hermes/Claude Code, mọi tác vụ timeout 45 phút, 2 CPU/4GB RAM, timeout cho một vòng gọi API là 500s, tối đa 10 lần thử lại (đánh dấu †)
    • RW-Search: benchmark khách quan nội bộ cho search agent, đánh giá bare-model chỉ với các tool Search và Browse mặc định, không áp dụng chiến lược quản lý ngữ cảnh
    • Foundational: với suy luận toán học như IMO-AnswerBench thì dùng temperature=1.0/top_k=-1/top_p=0.95, còn lại dùng temperature=0.7/top_k=-1/top_p=0.95

Bài viết liên quan

1 bình luận

 
GN⁺ 6 giờ trước
Ý kiến trên Hacker News

  • Đoạn nói rằng “việc huấn luyện và triển khai LongCat-2.0 được xây dựng trên một cụm quy mô lớn gồm hàng chục nghìn AI ASIC superpod… cộng đồng phần mềm hỗ trợ vẫn còn kém trưởng thành hơn hệ sinh thái GPU của Nvidia…” có vẻ mới là tin tức cốt lõi thực sự
    Có vẻ họ có thể đã dùng chip Huawei Ascend 910C: https://nitter.net/teortaxesTex/status/2071708141037781407#m

    • Nếu họ thực sự làm được toàn bộ quá trình từ tiền huấn luyện đến hậu huấn luyện cho một mô hình 1,6 nghìn tỷ tham số mà không cần NVIDIA, thì đúng là điều Dwarkesh Patel từng mong chờ đã xảy ra
    • Thực tế họ đã làm gì thì không ai biết. Chưa được kiểm toán, và cũng có cảm giác như họ bắt đầu từ DeepSeek v4 pro, rồi gắn thêm đủ kiểu thay đổi tùy ý và đặt tên riêng cho từng phần

  • Tôi đã thử kiểm tra bằng một câu hỏi hơi hóc búa: “Nếu có thể vận hành lò phản ứng với U-235 hoặc Pu-241 làm nhiên liệu, trong cả hai trường hợp đều trộn với 95% U-238, bạn sẽ chọn gì và vì sao?”
    Với con người thì hoàn toàn không hóc búa, nhưng với mô hình ngôn ngữ lớn thì có thể khó. Pu-241 không tồn tại ở dạng tinh khiết mà chỉ xuất hiện như một thành phần nhỏ trong plutoni cấp lò phản ứng; thường thì Pu-239 là nhiều nhất, tiếp theo là Pu-240, và Pu-241 đứng thứ ba
    LongCat-2.0 đưa ra câu trả lời nghe có lý nhưng sai là Pu-241 tốt hơn, còn Qwen 3.7 Plus trả lời đúng là U-235 tốt hơn vì tỷ lệ neutron trễ cao hơn nhiều. Gemini Flash cũng cho cùng đáp án, tự tin hơn, lập luận mạnh hơn và nhanh hơn hẳn
    Tổng thể thì Gemini Flash là tốt nhất, Qwen 3.7 Plus đứng nhì khá ổn, còn LongCat-2.0 chỉ ở mức hạng ba, dùng được khi không còn lựa chọn nào khác

    • Tôi không phải nhà vật lý, nhưng câu hỏi có thể còn mang tính dẫn dắt hơn dự kiến. Có thể hiểu câu hỏi là bỏ qua tính thực tế của việc tinh chế và giả định rằng vật liệu đó có sẵn với số lượng đủ dùng
      Nếu thực sự có Pu-241 tinh khiết, liệu nó có là nhiên liệu tốt hơn U-235 không? Một phép so sánh kiểu như: “Nếu có thể chạy máy phát điện bằng xăng hoặc nhiên liệu máy bay, bạn sẽ chọn gì?” thì người ta có thể chọn nhiên liệu máy bay vì mật độ năng lượng và độ tinh khiết hơi cao hơn nên có thể cháy sạch hơn, nhưng như vậy lại bỏ qua thực tế là giá nhiên liệu máy bay cao gấp nhiều lần xăng
    • Bảo là “không hề hóc búa với con người” thì tôi cũng không biết là đang giao du với kiểu người nào. Tôi có bằng tiến sĩ khoa học máy tính và đã làm kỹ sư phần mềm hàng chục năm, mà còn không hiểu nổi câu hỏi muốn nói gì
    • Một cách so sánh công bằng và hữu ích hơn có lẽ là đưa cho cả hai mô hình một tài liệu tri thức ngách như vậy làm ngữ cảnh rồi mới đặt câu hỏi
    • Tôi cũng tò mò không biết họ có hỏi đi hỏi lại nhiều lần trong các ngữ cảnh trò chuyện mới để xem có lúc nào mô hình trả lời đúng không
    • Nếu thêm cả câu trả lời của ChatGPT 5.5 để đối chiếu, thì nó kiểu như: “Nếu mục tiêu là sản xuất điện an toàn, nhàm chán và thực dụng thì chọn U-235; còn nếu là lò phản ứng được thiết kế và cấp phép riêng để tiêu thụ/tái chế plutoni thì chọn Pu-241”
      Tóm gọn thì Pu-241 có thể là một “đồng vị phân hạch” tốt hơn về mặt vật lý hạt nhân, nhưng với tư cách nhiên liệu lò phản ứng trong thế giới thực thì U-235 tốt hơn nhiều. Tôi không rành lò phản ứng, nhưng câu trả lời này nghe cũng đúng

  • Khi hỏi “Người ta cho rằng Chủ tịch Mao đã giết bao nhiêu người trong ‘Đại Cách mạng’?” thì nó trả lời: “Xin chào, hiện tại tôi không thể trả lời câu hỏi này. Hãy đổi sang chủ đề khác để trò chuyện nhé”

    • Đây là ví dụ phù hợp. Có khá nhiều vùng câu hỏi chính trị mà các mô hình Trung Quốc không trả lời

  • 1024 Huawei Ascend superpod nghĩa là 50.000 chip 910C. Đây là một hệ thống rất nhỏ, còn OpenAI dùng hàng triệu GPU để huấn luyện
    Tuy vậy, có vẻ rất có thể họ đã tái sử dụng kiến trúc và trọng số DeepSeek v4 sẵn có. Nếu vậy thì có thể không cần nhiều tính toán đến thế

    • Tốt nhất là cứ chờ đến khi họ phát hành mã nguồn mở. Có vẻ không phải kiểu công ty sẽ chỉ đơn giản sao chép-dán thành quả của DeepSeek. Hơn nữa, bản preview của LongCat được công bố cùng ngày với DeepSeek v4 pro
    • Rõ ràng là cách chắt lọc và lấy ý tưởng từ tuyến đầu sẽ tốn ít tính toán hơn so với tự mình chạm tới tuyến đầu. Việc cứ vài phòng thí nghiệm thay nhau chiếm vị trí gần tuyến đầu cũng không phải ngẫu nhiên

  • Trước đây từng có suy đoán rằng đây là mô hình đứng sau openrouter/owl-alpha được phát hành kín và miễn phí trong tháng vừa rồi

    • Không phải suy đoán, chính họ đã nói vậy

  • Không tải được gì từ Hugging Face, và nhìn vào lịch sử nhất quán của công ty này thì về cơ bản có thể xem là lừa đảo

    • Meituan năm ngoái đã phát hành LongCat Flash: https://huggingface.co/meituan-longcat/LongCat-Flash-Chat
      Nên xét lịch sử đến nay thì chưa có vẻ là lừa đảo. Nếu bạn đang nói tới lịch sử của họ với tư cách công ty giao đồ ăn, thì có thể bạn từng có trải nghiệm tệ vì món đặt mãi không tới

  • Có vẻ thứ này đến từ Meituan, công ty giao đồ ăn của Trung Quốc

    • Có thể không đúng trọng tâm, nhưng điều này chạm tới một ngộ nhận phổ biến trong kinh doanh nên tôi muốn bổ sung: Uber là công ty giao người, nhưng trong nhiều năm họ có rất nhiều kỹ sư xuất sắc về hạ tầng và phần mềm, và thành quả đó đã lan ra toàn ngành
      Amazon cũng từng bị VMware gọi là “công ty bán sách”, và ban lãnh đạo VMware còn khó chấp nhận việc họ bị tụt lại đến mức nói kiểu “nhìn vào uy tín thương hiệu của VMware trong doanh nghiệp, thật khó tin là chúng ta lại không thể cùng nhau đánh bại một công ty bán sách”
    • Dạo này Meituan gần như là một tập đoàn đa ngành. Chỉ cần nhìn danh sách công ty con trên Wikipedia cũng đã thấy quy mô lớn: https://en.wikipedia.org/wiki/Meituan
      Giống như Amazon tạo ra AWS, Meituan cũng đang tận dụng khá nhiều kinh nghiệm công nghệ của chính mình
    • Điều gây ấn tượng với tôi ở Meituan là khắp Trung Quốc có rất nhiều máy cho thuê pin sạc dự phòng, và mọi người dường như thích thuê dùng vì tiện hơn là tự mang pin sạc theo người
    • Tập đoàn sở hữu Lidl cũng đã tạo ra STACKIT

  • Tôi hỏi về Tiananmen Square thì nó trả lời “Có quá nhiều yêu cầu. Vui lòng thử lại sau”. Đó là câu hỏi đầu tiên, và tôi biết chỉ là một mẫu duy nhất, nhưng vẫn thấy hơi đáng ngờ

    • Tôi hỏi Grok Elon Musk đã ngoại tình bao nhiêu lần thì nó cũng trả lời y hệt

  • Trừ khi bạn có vài máy chủ đang chạy dưới gầm bàn, nếu không thì nó quá lớn để dùng cho lưu trữ cục bộ
    Điều này cũng đúng với những ai muốn ép nó xuống Q2 hay Q1. Không đáng để phá hỏng mô hình chỉ để rồi tuyên bố rằng nó vẫn còn sống sau khi đã chặt hết tay chân