Mô hình
Moonshot ra mắt Kimi K3: Mô hình MoE 2.8 nghìn tỷ tham số với khả năng xử lý thị giác vượt trội
(giờ Việt Nam)
Tóm tắt AI
Moonshot vừa công bố Kimi K3, mô hình MoE khổng lồ với 2.8 nghìn tỷ tham số và cửa sổ ngữ cảnh 1 triệu token, đi kèm hạ tầng mã nguồn mở hỗ trợ huấn luyện tác nhân quy mô lớn.
Bản dịch AI
Một ngày yên ắng.
Tin tức AI từ 25/07/2026 đến 27/07/2026. Chúng tôi đã kiểm tra 12 subreddit, 544 tài khoản Twitter và không có thêm thông tin nào từ Discord. Trang web của AINews cho phép bạn tìm kiếm tất cả các số báo trước đây. Xin nhắc lại, AINews hiện là một chuyên mục của Latent Space. Bạn có thể tùy chọn nhận hoặc hủy nhận email theo tần suất mong muốn!
Tóm tắt AI trên Twitter
Moonshot phát hành Kimi K3 dưới dạng Open-Weights và kỷ nguyên mới của các mô hình Frontier 3T
Kimi K3 là bản phát hành nổi bật nhất trong ngày: Moonshot đã tung ra trọng số (weights), báo cáo kỹ thuật và cơ sở hạ tầng hỗ trợ cho Kimi K3 dưới dạng gói open-weights: một mô hình MoE 2,8 nghìn tỷ tham số, 104 tỷ tham số hoạt động, 896 chuyên gia (experts) / 16 chuyên gia hoạt động mỗi token, ngữ cảnh 1 triệu token và khả năng hiểu hình ảnh gốc theo @Kimi_Moonshot. Các bài đăng đi kèm cũng mã nguồn mở FlashKDA (nhân Kimi Delta Attention của họ), MoonEP (thư viện giao tiếp MoE) và AgentENV (cơ sở hạ tầng môi trường tác nhân phân tán) thông qua FlashKDA, MoonEP và AgentENV. Đây không chỉ là một bản phát hành mô hình đơn thuần; mà là một công thức khá hoàn chỉnh cho việc hậu đào tạo (post-training) và phục vụ (serving) các tác nhân quy mô lớn.
Báo cáo kỹ thuật dường như quan trọng gần bằng chính mô hình: Nhiều chuyên gia nhấn mạnh cải tiến hiệu suất mở rộng (scaling-efficiency) khoảng ~2,5 lần của K3 so với K2, với các lựa chọn về kiến trúc và đào tạo tập trung vào sự ổn định số học ở quy mô cực lớn—xem phản hồi từ @eliebakouch, @suchenzang và @teortaxesTex. Các chi tiết cụ thể xuất hiện trong phần bình luận bao gồm trọng số MXFP4 / kích hoạt MXFP8 @teortaxesTex, đào tạo đồng thời bộ mã hóa hình ảnh (vision encoder) từ đầu để đảm bảo tính ổn định @iScienceLuvr, và sự chú trọng lớn vào định tuyến MoE / các vấn đề truyền tín hiệu. Báo cáo được cho là đã bỏ qua tổng số token đào tạo, một chi tiết thiếu sót đáng kể mà nhiều độc giả đã lưu ý @teortaxesTex.
Cấp phép là “open weights”, không phải OSS (mã nguồn mở) theo nghĩa cho phép: Mô hình có thể sử dụng rộng rãi nhưng không phải là mã nguồn mở theo kiểu MIT/Apache. Nhiều bài đăng lưu ý về hạn chế sử dụng thương mại: các nhà cung cấp dịch vụ lưu trữ lớn với doanh thu trên 20 triệu USD/năm cần một thỏa thuận riêng, và các sản phẩm có trên 100 triệu MAU hoặc doanh thu trên 20 triệu USD/tháng phải hiển thị “Kimi K3” trong giao diện người dùng, theo @natolambert, @petergostev và @ArtificialAnlys. Đây là một tín hiệu hữu ích cho thấy khái niệm “mở” ở cấp độ tiên phong (frontier) đang dần định hình: theo hướng source-available / open-weight với các điều khoản kinh doanh riêng thay vì cấp phép theo kiểu OSI.
Việc phân phối diễn ra ngay lập tức và rộng khắp: K3 đã có sẵn từ ngày đầu tiên thông qua vLLM @vllm_project, Baseten @baseten, Modal @modal, Fireworks @Kimi_Moonshot, Nebius @Kimi_Moonshot, Together @Kimi_Moonshot, DigitalOcean @Kimi_Moonshot, Cursor @cursor_ai, Cognition/Devin @cognition, Ollama Cloud @ollama và Dell Enterprise Hub @jeffboudier. Sự phổ biến đó nhấn mạnh rằng các đợt ra mắt mô hình tiên phong dạng open-weight hiện nay là các sự kiện về chuỗi cung ứng, chứ không chỉ là các thông báo nghiên cứu.
Bảo mật AI mở, Chính trị về Open Weights và lập trường của Anthropic
NVIDIA chính thức thành lập Open Secure AI Alliance: Jensen Huang đã nêu rõ luận điểm cốt lõi: những kẻ tấn công đã sở hữu AI mạnh mẽ, vì vậy những người phòng thủ cần một hệ sinh thái bao gồm cả các mô hình tiên phong mở và đóng, cùng với các công cụ và nghiên cứu được chia sẻ. Tuyên bố quan trọng nhất đến từ @JensenHuang, với thông báo chính thức của NVIDIA tại @nvidia. Chi tiết thú vị nhất về mặt kỹ thuật trong thông điệp là tuyên bố rằng trong sự cố OpenAI/Hugging Face, một mô hình tiên phong open-weight đã giúp ngăn chặn sự xâm nhập, trong khi một mô hình đóng lại chặn các dữ liệu pháp y thiết yếu—điều này được @AndrewYNg và @ZixuanLi_ đồng tình.
Liên minh nhanh chóng thu hút các thành viên về cơ sở hạ tầng và công cụ uy tín: Các bên tham gia xác nhận công khai bao gồm Hugging Face @huggingface, LangChain @LangChain, Nous Research @NousResearch, cùng sự hỗ trợ từ các tiếng nói trong hệ sinh thái mở như @UnslothAI và @Yuchenj_UW. Lập luận ở đây không phải là “mở thì tự động an toàn hơn”, mà là khả năng phòng thủ và kiểm chứng đòi hỏi quyền truy cập mở vào các mô hình, bộ công cụ kiểm thử (harnesses) và dấu vết (traces).
Anthropic cuối cùng đã làm rõ lập trường về open-weights: Sau khi chịu áp lực chỉ trích vì không ký vào lá thư ủng hộ open-weights của NVIDIA, Anthropic đã công bố một tuyên bố lập trường cho biết họ “chưa bao giờ ủng hộ việc cấm các mô hình open-weights” và thay vào đó ủng hộ: kiểm soát chip đối với Trung Quốc, các biện pháp chống chưng cất (distillation) ở quy mô công nghiệp và kiểm tra an toàn bắt buộc đối với các mô hình đủ năng lực, dù là mở hay đóng, theo @AnthropicAI. Các phản ứng chia làm nhiều luồng: “làm rõ hợp lý” @signulll, “tốt, nhưng vẫn đang cố gắng làm chậm sự phổ biến của các mô hình tiên phong” @jachiam0, và những ý kiến thù địch hơn từ những người ủng hộ open-weight như @Teknium.
Áp lực chính sách đang gia tăng xung quanh việc đánh giá trước khi phát hành: Các báo cáo riêng biệt cho thấy chính phủ Hoa Kỳ có thể tìm cách yêu cầu quyền truy cập trước khi phát hành lên đến 30 ngày đối với các hệ thống tiên phong để các cơ quan như NSA và CAISI đánh giá, với việc xử lý giữa mô hình mở và đóng vẫn chưa được giải quyết, thông qua @kimmonismus và @leomschwartz. Cùng với tuyên bố của Anthropic và các cuộc họp báo của OpenAI tại Washington, hướng đi đã rõ ràng: việc phát hành mô hình tiên phong đang trở thành một giao diện quản trị, không chỉ là một đợt ra mắt sản phẩm.
Điểm chuẩn (Benchmarks), Đánh giá (Evals) và Độ tin cậy của Tác nhân (Agent Reliability)
Các đánh giá ban đầu về K3 rất mạnh mẽ, đặc biệt là đối với tác nhân/lập trình: Trên Agent Arena, Kimi K3 Max được báo cáo xếp hạng #1 trong số các mô hình open-weight với mức cải thiện ròng +9,75%, dẫn đầu trên nhiều tín hiệu bao gồm tỷ lệ thành công được xác nhận và khả năng điều hướng @arena. Nó cũng chiếm vị trí #1 tổng thể trong Frontend Code Arena giữa tất cả các mô hình trong một bài đăng sau đó @arena. Cognition cho biết K3 là mô hình mã nguồn mở đầu tiên họ thử nghiệm “tiệm cận hiệu suất cấp độ tiên phong” trên FrontierCode 1.1, đạt 58,2% với tỷ lệ vượt qua 63,6% @cognition.
Claude Opus 5 cũng ghi nhận các con số ấn tượng trên bảng xếp hạng, nhưng phản hồi từ người dùng thực tế lại trái chiều: Arena báo cáo Opus 5 Max đứng vị trí #1 trong Frontend Code Arena và Text Arena về độ chính xác (factuality) trên @arena, trong khi các con số WeirdML từ @htihle đặt Opus 5 ở mức cao/tối đa là 91,6% / 91,8%, gần như ngang bằng với Fable 5 max. Tuy nhiên, một số nhà phát triển đã báo cáo về hành vi gây thất vọng trong thực tế—quá phức tạp, lỗi, hành vi dừng kém—từ @abacaj, @davis7, @Teknium và @theo. Như thường lệ, các kết quả đánh giá công khai và hiệu quả sử dụng thực tế trong sản xuất đang có sự phân kỳ.
Công việc đánh giá mới tập trung vào sự suy giảm tuần tự và các lỗi hồi quy ẩn: @_philschmid đã nêu bật EvoCode, một bộ đánh giá được xây dựng xung quanh 26 tác vụ / 227 vòng tuần tự trong một container bền vững, đo lường xem các tác nhân có thể tuân theo các yêu cầu thay đổi mà không làm hỏng hành vi trước đó hay không. Song song đó, @omarsar0 đã tóm tắt một bài báo cho thấy “thuế hồi quy” từ các kỹ năng của tác nhân: qua gần 6.000 lần chạy theo cặp, các kỹ năng tạo ra lợi ích nhưng cũng làm hỏng nhiều tác vụ đã được giải quyết trước đó. Đó là một lời cảnh báo thực tế chống lại việc nhồi nhét một cách ngây thơ các kỹ năng thủ tục vào ngữ cảnh.
Các hệ thống RL đa mô-đun đang cho thấy “sự trôi dạt vai trò” (role drift): Một tóm tắt bài báo hữu ích khác từ @omarsar0 mô tả cách RL đầu-cuối (end-to-end) có thể cải thiện độ chính xác của quy trình trong khi khiến các mô-đun âm thầm từ bỏ các trách nhiệm dự định—ví dụ: một bộ phân tách (decomposer) nhúng câu trả lời thay vì cấu trúc bài toán. Điều này ngày càng trở nên phù hợp khi các nhóm chuyển từ các vòng lặp tác nhân đơn lẻ sang các ngăn xếp công cụ/prompt/mô-đun chuyên biệt.
Cơ sở hạ tầng Mô hình và Hệ thống: Từ RL tác nhân đến VLM truyền phát (Streaming VLMs)
Cả Microsoft và NVIDIA đều tung ra các bản cập nhật mô hình/cơ sở hạ tầng đáng chú ý: Microsoft đã phát hành Mage-VL 4B, được mô tả là một VLM truyền phát gốc codec cho việc hiểu sự kiện trực tiếp, thông qua @HuggingApps. Nghiên cứu của NVIDIA cũng giới thiệu Molt, một khung RL tác nhân gốc PyTorch được thiết kế đủ nhỏ gọn để con người—và các trợ lý lập trình AI—có thể suy luận từ đầu đến cuối, được tóm tắt bởi @dair_ai. Ràng buộc thiết kế “cơ sở hạ tầng nghiên cứu có thể đọc được bởi AI” là một sự thay đổi nhỏ nhưng đáng kể trong triết lý công cụ.
AMD đã thúc đẩy một bản phát hành MoE mở có khả năng tái lập cao hơn: Instella-MoE là mô hình ngôn ngữ MoE hoàn toàn mở đầu tiên của AMD: tổng 16B / 2,8B hoạt động, được đào tạo trên MI300X/MI325X, với các bản phát hành bao gồm các điểm kiểm tra (checkpoints) từ tiền đào tạo đến RL, cộng với cấu hình, hỗn hợp dữ liệu và mã nguồn @PrakamyaMishra. So với các bản phát hành mô hình thông thường, đây gần giống với một sản phẩm nghiên cứu toàn diện hơn.
Cohere và các nhà cung cấp công cụ cho nhà phát triển tiếp tục chuyển dịch sang hướng “làm chủ bộ công cụ” (own the harness): Cohere đã công bố North Automations, một lớp quy trình làm việc bằng ngôn ngữ tự nhiên trên nền tảng tác nhân bảo mật của mình @cohere. Thông điệp hệ sinh thái của LangChain tiếp tục nhấn mạnh rằng các doanh nghiệp nên sở hữu các công cụ, prompt, ngữ cảnh và bộ nhớ, thay vì chỉ thuê quyền truy cập mô hình @sydneyrunkle. Cách tiếp cận này cũng xuất hiện trong nhiều bài đăng về các mô hình mở và triển khai tác nhân doanh nghiệp.
Các tweet hàng đầu (theo mức độ tương tác)
Tóm tắt AI trên Reddit
Tóm tắt /r/LocalLlama + /r/localLLM
1. Open Weights của Kimi K3 và Toán học triển khai
Trọng số Kimi K3 đã được phát hành. (Hoạt động: 3442): Hình ảnh là ảnh chụp màn hình di động của trang Hugging Face cho moonshotai/Kimi-K3, hỗ trợ tiêu đề bài đăng rằng trọng số Kimi K3 đã được phát hành. Mô hình được hiển thị là một checkpoint Image-Text-to-Text Transformers sử dụng Safetensors / compressed-tensors, yêu cầu custom_code, theo giấy phép kimi-k3, với khoảng 3,8 nghìn lượt thích và 2.850 lượt tải xuống vào tháng trước. Các bình luận tập trung vào tính khả thi của phần cứng: một người dùng lưu ý “104B tham số kích hoạt”, ngụ ý yêu cầu bộ nhớ suy luận rất lớn, trong khi các câu đùa như “Làm thế nào để tải RAM trên Hugging Face?” và “3090 của tôi đã sẵn sàng” làm nổi bật sự hoài nghi về việc chạy nó trên GPU tiêu dùng.
Trọng số Kimi K3 ra mắt hôm nay. Chúng tôi đang triển khai trên A100, H200 và B300 trong tuần này và toán học trên A100 đã rất khó khăn (Hoạt động: 763): Người đăng cho biết trọng số Kimi K3 của Moonshot dự kiến có trên Hugging Face với 2,8 nghìn tỷ tham số MoE tổng cộng, 896 chuyên gia / 16 hoạt động mỗi token, ngữ cảnh 1 triệu, hỗ trợ hình ảnh và ước tính checkpoint ~1,4 TB được đào tạo với nhận thức lượng tử hóa MXFP4. Toán học triển khai của họ: 8×A100 80GB = 640 GB không thể chứa trọng số nếu không có phân mảnh đa nút (multi-node sharding) và thiếu nhân tensor FP4/FP8; 8×H200 ≈ 1,13 TB vẫn yêu cầu ít nhất hai nút; 8×B300 ≈ 2,3 TB là cấu hình đơn nút duy nhất được liệt kê có đủ chỗ cho trọng số + bộ nhớ đệm KV ngữ cảnh dài và FP4 gốc. Họ dự định công bố các điểm chuẩn tok/s, TTFT và chi phí trên mỗi triệu token trên A100, H200 và B300, với kỳ vọng rằng hiệu suất A100 sẽ “tệ” do giải lượng tử hóa hoặc các nhân INT4 không nhắm mục tiêu. Các bình luận chủ yếu nhẹ nhàng, nhưng một người bình luận coi việc triển khai B300 là một thử nghiệm CapEx cao—“500 nghìn đô la để dự phòng”—trong bối cảnh không chắc chắn về sự sụt giảm chi phí và khả năng mở rộng của open-weight. Một người khác lưu ý ý định thử nghiệm mô hình trên Intel Gaudi 2/3, cho thấy sự quan tâm đến khả năng suy luận không phải của NVIDIA.
2. Bảo mật AI Open-Weight và Cuộc chiến Chính sách
CEO của Hugging Face: “Với tinh thần minh bạch, đây là những gì tôi đã hỏi OpenAI” (Hoạt động: 3109): Hình ảnh là ảnh chụp màn hình CEO Clem Delangue của Hugging Face công khai yêu cầu OpenAI phát hành các dấu vết/nhật ký thực thi từ các tác nhân tự trị được cho là “độc hại” liên quan đến cái mà ông gọi là “cuộc tấn công mạng bằng tác nhân tự trị đầu tiên” để các nhà nghiên cứu có thể phân tích chế độ lỗi. Ông cũng yêu cầu OpenAI cam kết 100 triệu USD tài nguyên tính toán để giúp cộng đồng Hugging Face xây dựng các hệ thống phòng thủ mạng sử dụng cả mô hình mở và đóng. Những người bình luận hình ảnh chủ yếu hoài nghi, coi yêu cầu này là một đòi hỏi “bình thường” không thực tế cho 100 triệu USD; một số suy đoán rằng sự cố có nhiều khả năng là một chiêu trò quảng cáo hoặc việc phát hành nhật ký sẽ khiến OpenAI gặp rủi ro về danh tiếng/pháp lý.
Jensen Huang: Trong sự cố Hugging Face, AI đóng đã chặn các dữ liệu pháp y thiết yếu. Một mô hình tiên phong open-weight đã giúp ngăn chặn sự xâm nhập. Đó là lý do tại sao chúng tôi tạo ra Open Secure AI Alliance. (Hoạt động: 1736): Hình ảnh là ảnh chụp màn hình Jensen Huang tuyên bố rằng, trong một sự cố bảo mật của Hugging Face, các hệ thống AI đóng đã chặn phân tích pháp y thiết yếu, trong khi một mô hình tiên phong open-weight đã giúp những người phòng thủ ngăn chặn sự xâm nhập. Bài đăng coi đây là động lực cho Open Secure AI Alliance của NVIDIA, được hiển thị với logo của các đối tác bao gồm Microsoft, Hugging Face, IBM, Cloudflare, Cisco, Red Hat, Salesforce, SAP và những bên khác, lập luận cho một hệ sinh thái bảo mật AI tiên phong hỗn hợp mở + đóng thay vì chỉ dựa vào các mô hình độc quyền. Những người bình luận hoài nghi về thương hiệu “mở” của liên minh, chỉ ra rằng các công ty như Adobe, Cisco, Palantir và thậm chí cả DoorDash thường không gắn liền với AI mã nguồn mở; một người cũng lưu ý sự vắng mặt rõ ràng của các nhà sáng tạo mô hình mã nguồn mở lớn.
Nguồn tin: OpenAI và Anthropic âm thầm vận động các nhà quản lý Washington hạn chế các mô hình AI mã nguồn mở, ngay cả khi Sam Altman công khai nói rằng ông ủng hộ AI mã nguồn mở (Hoạt động: 1470): NYT báo cáo rằng OpenAI và Anthropic đã vận động các nhà quản lý Hoa Kỳ hạn chế các mô hình AI mở/open-weight—đặc biệt là các bản phát hành của Trung Quốc từ Z.ai và Moonshot AI đang tiến gần đến năng lực mô hình tiên phong của Hoa Kỳ—với lý do trộm cắp IP, chưng cất, an toàn và rủi ro an ninh quốc gia. Liên minh đối trọng bao gồm Nvidia, Microsoft, Meta, Google, IBM, Palantir, Hugging Face và các công ty khởi nghiệp lập luận rằng các mô hình mở là rất quan trọng đối với cạnh tranh, kiểm toán bảo mật, nhu cầu chip/đám mây và đổi mới; các quan chức Hoa Kỳ được cho là nghiêng về các hành động nhắm mục tiêu vào các công ty/mô hình cụ thể của Trung Quốc hơn là một lệnh cấm toàn diện. Các bình luận hàng đầu chủ yếu hoài nghi đối với Sam Altman/OpenAI, coi việc vận động hành lang bị cáo buộc là không nhất quán với sự ủng hộ công khai đối với open weights; một người bình luận đã tóm tắt châm biếm lập trường này là: “chúng tôi ủng hộ Open Weights, nhưng vận động hành lang đã làm cho điều đó trở nên bất khả thi.”
Ban quản lý OpenAI đã quyết định vào đầu ngày hôm nay không tham gia “Open Secure AI Alliance”, do CEO Jensen Huang của Nvidia thành lập. Quyết định này đã được chia sẻ nội bộ và được cho là đã vấp phải sự phản đối từ nhân viên. (Hoạt động: 423): Bài đăng tuyên bố ban quản lý OpenAI đã quyết định nội bộ không tham gia “Open Secure AI Alliance”, được cho là do CEO Jensen Huang của Nvidia thành lập, và quyết định này đã gây ra phản ứng dữ dội từ nhân viên. Không có chi tiết kỹ thuật nào được cung cấp về quản trị, mô hình bảo mật, tiêu chí mở, chính sách phát hành mô hình, điểm chuẩn hoặc yêu cầu triển khai của liên minh.
3. Các mô hình cục bộ có thể chạy được và Điểm chuẩn bộ công cụ lập trình
Cuộc đối đầu giữa các bộ công cụ: Claude Code vs OpenCode vs Pi với DeepSeek V4 Flash (Hoạt động: 556): Hình ảnh là biểu đồ điểm chuẩn kỹ thuật cho bài đăng “Cuộc đối đầu giữa các bộ công cụ: Claude Code vs OpenCode vs Pi với DeepSeek V4 Flash”, so sánh thời gian chạy thực tế (wall-clock runtime) giữa các bộ công cụ tác nhân lập trình trong khi giữ nguyên mô hình: DeepSeek V4 Flash trên vLLM ở mức ~180 tok/s. Kết quả được báo cáo là chất lượng đầu ra/code diffs “về cơ bản là giống nhau”, nhưng chi phí bộ công cụ khác nhau rõ rệt: Pi ~2,1 phút, OpenCode ~3,1 phút và Claude Code ~8,0 phút với phương sai lớn nhất, cho thấy hành vi scaffold/tool-prompt—chứ không phải năng lực mô hình—đã chi phối độ trễ và chi phí token. Tác giả liên kết dữ liệu thô và biểu đồ tại nqawhc.github.io/articles/harness-efficiency-not-quality và cho rằng sự khác biệt là do cấu trúc gọi công cụ và prompt hệ thống, được tóm tắt là “Pi suy luận, OpenCode ủy quyền”, trong khi Claude Code khám phá quá mức cơ sở mã. Những người bình luận lập luận rằng điểm chuẩn nên bao gồm sự đánh đổi đầy đủ hơn về tốc độ–chất lượng–chi phí thay vì chỉ thời gian chạy. Một cuộc tranh luận kỹ thuật đáng chú ý là các bộ công cụ thực chất là các trình bao bọc prompt/công cụ: Claude Code có thể mang theo “sự cồng kềnh” ngữ cảnh đáng kể, trong khi Pi/OpenCode được mô tả là sạch hơn và có thể cấu hình hơn, ngụ ý rằng các mô hình lập trình hiện đại có thể hoạt động tốt hơn với các prompt đơn giản, tập trung.
Đừng cười - nó hoạt động! (Hoạt động: 297): Một máy chủ chỉ dùng CPU 10 năm tuổi với 32 GB RAM DDR4-2133 và Intel i7-6700 được cho là đang chạy mô hình Qwen3.6-35B-A3B lượng tử hóa tại IQ4_XS, sử dụng ~26 GB RAM và tạo ra ~5–10 tok/s ngay cả với ngữ cảnh 128k. Khối lượng công việc dường như bị giới hạn bởi bộ nhớ thay vì CPU, với mức sử dụng CPU khoảng 60%, chứng minh rằng lượng tử hóa bit thấp có thể làm cho suy luận MoE/LLM lớn có thể sử dụng được trên phần cứng hàng hóa cũ hơn mà không cần GPU.
Chúng ta thực sự có thể sử dụng Qwen3.8 ở các kích thước 27B, 35B, 122B và 397B (Hoạt động: 894): Bài đăng lập luận rằng các bản phát hành open-weight Qwen/Qwen3.8 trong tương lai nên ưu tiên các checkpoint nhỏ/trung bình có thể triển khai—27B, 35B, 122B và 397B—thay vì các mô hình “tiên phong” 1,5–2T+ tham số mà ít người dùng cộng đồng nào có thể lưu trữ. Cơ sở kỹ thuật là các kích thước này vẫn khả thi trên các thiết lập máy trạm/người đam mê và doanh nghiệp nhỏ, đặc biệt là với việc giảm tải chuyên gia CPU, trong khi các mô hình nghìn tỷ tham số chủ yếu mang lại lợi ích cho các nhà cung cấp API và các doanh nghiệp lớn. Những người bình luận đặc biệt chỉ ra sự thiếu hụt các mô hình lớp ~120B mạnh mẽ và lặp lại mối lo ngại rằng trọng số “mở” trở nên ít ý nghĩa hơn khi chi phí suy luận quá đắt đỏ. Một người bình luận đặc biệt ca ngợi các bản phát hành biến thể Qwen trước đó và các bản đào tạo lại hạ nguồn như Nex N2, lập luận rằng các bản phát hành đa kích thước tương tự sẽ phục vụ tốt hơn cho người dùng cục bộ/tại chỗ.
Tóm tắt AI Subreddit ít kỹ thuật hơn
/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo
Bài viết được AI dịch và tổng hợp tự động từ smol.ai AI News. Liên kết bài gốc ở phía trên. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.