4 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Mô hình 1 nghìn tỷ (1T) tham số đầu tiên vượt tốc độ giải mã 1000 tokens/s
  • Đạt được tốc độ này chỉ với commodity GPU thay vì phần cứng chuyên dụng, và hiện thực hóa đầu ra 1000+ tps trên một node 8-GPU tiêu chuẩn duy nhất
  • Công nghệ cốt lõi là thiết kế đồng tối ưu model-hệ thống kết hợp lượng tử hóa FP4DFlash speculative decoding
  • API được cung cấp theo hình thức đăng ký và trong thời gian giới hạn, quảng bá tốc độ sinh nhanh hơn khoảng 10 lần với mức giá gấp 3 lần
  • Việc vượt mốc 1000 tps không chỉ là tăng tốc đơn thuần mà là bước ngoặt làm thay đổi chính bản thân mô hình ứng dụng AI như Coding Agent và ra quyết định thời gian thực

Xiaomi ra mắt MiMo-V2.5-Pro-UltraSpeed

  • Hợp tác với TileRT để lần đầu tiên vượt tốc độ giải mã 1000 tokens/s trên mô hình 1 nghìn tỷ tham số, mang lại tốc độ ở mức cho phép phản hồi thời gian thực và lặp lại gần như tức thì
  • Trong so sánh tốc độ sinh thời gian thực, đạt tối đa khoảng 1200 tokens/s
  • Đưa ra quan điểm rằng khi mô hình đủ nhanh, nó không còn là công cụ để chờ đợi mà trở thành phần mở rộng của tư duy (extension of thinking)

Cung cấp có thời hạn · theo hình thức đăng ký

  • API được phát hành với mức giá khuyến mãi giới hạn, cung cấp tốc độ sinh nhanh hơn khoảng 10 lần với chi phí gấp 3 lần so với MiMo-V2.5-Pro (chỉ dành cho API, không hỗ trợ Token Plan)
  • Do giới hạn tài nguyên suy luận tốc độ cao, dịch vụ vận hành theo hình thức đăng ký và thời gian giới hạn; chỉ người dùng được phê duyệt mới có thể sử dụng API trong khoảng ngày 9 tháng 6 năm 2026 ~ ngày 23 tháng 6 23:59 (UTC+8)
  • Cách đăng ký

    • Nền tảng API là platform.xiaomimimo.com/ultraspeed; việc đăng ký không đảm bảo được phê duyệt, và sẽ ưu tiên doanh nghiệp cùng nhà phát triển chuyên nghiệp có nhu cầu kinh doanh thực tế
    • Quyền truy cập mô hình tiêu chuẩn được cung cấp thông qua dòng MiMo-V2.5
  • Trải nghiệm Chat (miễn phí trong thời gian dùng thử)

    • Người dùng được phê duyệt sẽ được cấp quyền truy cập Chat miễn phí trong 2 tuần, điểm vào là ultraspeed.xiaomimimo.com
    • Mỗi tài khoản được vào hàng đợi tối đa 10 lần mỗi ngày, tối đa 30 phút mỗi phiên, và sẽ tự động bị ngắt nếu nhàn rỗi quá 5 phút

1000 tokens/s — chuyển đổi mô hình vượt lên trên tốc độ

  • Việc vượt mốc 1000 tps ở quy mô 1T không chỉ là một chiếc máy đánh chữ nhanh hơn, mà là thay đổi làm rung chuyển tận gốc chính mô hình ứng dụng AI
  • Khi tốc độ chuyển hóa thành trí tuệ

    • Trong cùng một khoảng thời gian thực tế (wall-clock), có thể chạy song song hàng chục đường suy luận (Best-of-N / Tree Search), tự động kiểm chứng và tự sửa ở nền để trực tiếp cải thiện chất lượng suy luận
    Quảng cáo
  • Gỡ bỏ giới hạn năng suất của Coding Agent

    • Trước đây, độ trễ suy luận (inference latency) là nút thắt khiến nhà phát triển phải ngồi chờ trước màn hình; ở mức 1000 tps, tốc độ sinh mã và hiệu suất làm việc được tăng tốc ở cấp độ thay đổi mô hình
  • Bước vào vòng lặp ra quyết định thời gian thực

    • Với chu kỳ "think-respond" ở mức mili giây, mô hình flagship 1T có thể kết hợp vào các kịch bản nhạy cảm về thời gian như tạo tín hiệu giao dịch định lượng tần suất cao, chặn giao dịch bất thường ngay lập tức, đấu giá thông minh, hội thoại thời gian thực
    • Trong các tình huống sống còn như hỗ trợ phẫu thuật hay phân tích ảnh y khoa, quan điểm được đưa ra là mỗi giây rút ngắn được trong phân tích tổn thương và dự đoán rủi ro sẽ mang lại thêm không gian hành động cho bác sĩ phẫu thuật

Thiết kế đồng tối ưu model-hệ thống ở mức cực hạn

  • 1000+ tps trên mô hình 1T không đến từ một kỹ thuật đơn lẻ mà là thành quả của đội ngũ mô hình MiMo và đội hệ thống TileRT trong quá trình codesign ở mức cực hạn

  • Khác với cách ngành thường dựa vào phần cứng chuyên dụng để đạt tốc độ tương tự như Wafer-Scale của Cerebras hay kiến trúc tùy biến on-chip SRAM của Groq, hệ thống này đạt được mục tiêu chỉ bằng codesign model-hệ thống trên commodity GPU

  • Ở phía mô hình, họ dùng lượng tử hóa FP4 để nhắm vào nút thắt băng thông nhằm giảm kích thước mô hình và gánh nặng truy cập bộ nhớ, đồng thời đưa vào DFlash dựa trên dự đoán song song có che theo khối để tăng số token được chấp nhận trong mỗi bước kiểm chứng

    Quảng cáo
  • Ở phía hệ thống, TileRT cung cấp engine biên dịch và kernel tính toán phù hợp với đặc tính của thuật toán, hiện thực hóa đầu ra 1000+ tps trên một node commodity 8-GPU tiêu chuẩn duy nhất

  • 3.1 FP4 Quantization

    • Ở quy mô 1T, suy luận 8-bit (FP8/INT8) và 16-bit truyền thống gây áp lực quá lớn lên bộ nhớ và băng thông, nên việc giảm độ rộng bit đóng góp trực tiếp vào tốc độ giải mã
    • Chọn định dạng FP4(MXFP4) đã được kiểm chứng là gần như không mất mát, nhưng nếu áp dụng đơn giản cho toàn bộ mô hình sẽ làm suy giảm hiệu năng ở các tác vụ suy luận phức tạp, logic và sinh mã
    • Trong kiến trúc MoE(Mixture of Experts), họ chỉ lượng tử hóa chọn lọc sang FP4 các Experts vốn chiếm phần lớn tham số và có khả năng chịu lượng tử hóa cao nhất, còn các mô-đun khác giữ nguyên độ chính xác ban đầu
    • Với FP4 QAT(Quantization-Aware Training), họ giảm kích thước mô hình và tối đa hóa việc tận dụng băng thông phần cứng, đồng thời duy trì hiệu năng tổng thể gần như tương đương bản gốc
  • 3.2 DFlash Speculative Decoding

    • Speculative decoding truyền thống hoạt động theo cách một draft model nhỏ dự đoán các token tiếp theo rồi mô hình lớn kiểm chứng; chất lượng draft quyết định tỷ lệ chấp nhận, nhưng draft càng mạnh thì chi phí tính toán càng tăng, tạo ra một sự căng thẳng bản chất
    • DFlash cho phép draft model điền cả một khối đã được mask chỉ trong một forward pass, loại bỏ ràng buộc tuần tự của "autoregressive drafting"
    • Sử dụng bộ tối ưu bậc hai Muon và self-distillation của mô hình để nén overhead ở giai đoạn draft xuống gần mức tối thiểu theo lý thuyết
      • Draft model chỉ dùng Sliding Window Attention(SWA), phù hợp tự nhiên với thiết kế SWA của dòng MiMo-V2 và loại bỏ hoàn toàn phụ thuộc prefix, giúp giảm chi phí tính toán mỗi lần dự đoán từ tỷ lệ thuận với độ dài ngữ cảnh xuống hằng số
      • Trong quá trình huấn luyện, việc lấy mẫu mask-signal được hạ xuống shard cục bộ trên GPU, cho phép một chuỗi đơn tạo ra hàng chục nghìn tín hiệu huấn luyện độc lập trong một bước mà vẫn tránh được overhead giao tiếp giữa các thiết bị
    • Giới hạn kích thước khối ở 8 để giảm overhead kiểm chứng và tăng mức đồng thời, từ đó độ dài chấp nhận cao chuyển trực tiếp thành thông lượng suy luận cao
    • Độ dài chấp nhận trung bình (Acceptance Length) theo từng kịch bản
      • Coding 6.30 (một số mẫu đạt tối đa 7.14, chấp nhận 6~7 trên 8 draft token)
      • Math / Reasoning 5.56
      • Agent 4.29
    • Trong các kịch bản hội thoại tổng quát có ngữ nghĩa phân tán hơn và độ bất định cao hơn, tỷ lệ chấp nhận hiện vẫn còn thấp và đang tiếp tục được tối ưu
    Quảng cáo
  • 3.3 Kernel / hệ thống suy luận siêu độ trễ thấp của TileRT

    • Ở tần số vận hành 1000 tokens/s, vòng đời của từng toán tử bị nén xuống mức micro giây, khiến các "operator boundaries" của hệ thống suy luận truyền thống trở thành nút thắt chính
    • Mỗi lần bắt đầu thực thi toán tử, đồng bộ phần cứng hay đi-về bộ nhớ toàn cục đều làm gián đoạn luồng thực thi và tạo ra các "Execution Gaps" rõ rệt
    • Đổi mới mô hình thực thi ở cấp độ thay đổi cuộc chơi của TileRT

      • Persistent Engine Kernel: từ bỏ cách khởi động thực thi theo từng toán tử, giữ toàn bộ pipeline tính toán luôn thường trú và liên tục chảy bên trong GPU để đạt mức chồng lấp (overlap) cực đại giữa di chuyển dữ liệu và tính toán
      • Warp Specialization(hợp tác pipeline dị thể): phân rã vật lý tinh hơn việc giao tiếp, di chuyển dữ liệu và tính toán tensor ở cấp Tile, phá vỡ mô hình lock-step đồng nhất và biến GPU thành một hệ thống thực thi dị thể được điều phối chính xác
    • Hợp nhất sâu phần cứng-phần mềm ở cấp micro giây (Codesign)

      • Ở tầng mô hình, hệ thống áp dụng lượng tử hóa FP4 hỗn hợp cho các MoE Experts và speculative decoding DFlash được căn chỉnh với SWA cho kiến trúc 1 nghìn tỷ tham số; TileRT gắn chặt với các đặc tính thuật toán và phương thức lượng tử hóa này để cung cấp engine biên dịch và kernel tính toán tùy biến
      • Hai đội ngũ cùng tạo ra các đánh đổi kỹ thuật dựa trên vật lý phần cứng để làm cho áp lực thực thi hội tụ mượt mà bên trong các ranh giới phần cứng
      • TileRT là đội kiến trúc hệ thống tập trung vào hạ tầng AI thế hệ tiếp theo và suy luận siêu độ trễ thấp, đạt mức tận dụng tính toán cực hạn trong môi trường dị thể phức tạp thông qua đột phá full-stack với persistent kernel, tile pipeline và hợp tác dị thể

Video demo bổ sung

  • Demo tạo game Snake chỉ trong 10 giây
  • Demo tái tạo giao diện MacOS chỉ trong 1 phút

Mã nguồn mở và triển vọng

  • Công bố mã nguồn mở checkpoint MiMo-V2.5-Pro-FP4-DFlash trên HuggingFace, bao gồm trọng số lượng tử hóa FP4 và tham số mô hình DFlash
  • Đang chuẩn bị hỗ trợ UltraSpeed cho MiMo-V2.5

1 bình luận

 
Ý kiến trên Hacker News
  • AI nhanh thực sự rất thú vị nhưng cũng khá đáng lo. Ngay cả bây giờ Claude đã nhanh hơn tôi trong một số việc, nhưng nhìn chung vẫn còn ở mức tương đương
    Tôi đã chạy một prompt tổng hợp PR suốt 1 tiếng và có lẽ còn mất thêm vài tiếng nữa; thật khó tưởng tượng workflow sẽ thay đổi thế nào nếu việc này gần như xong ngay lập tức. Cũng có lúc vì prompt mất quá lâu nên tôi bắt đầu làm nhiều việc cùng lúc rồi sau đó lại hối hận. Ngược lại, nếu có AI có thể hoàn thành trong vài giây đến vài phút những việc vốn mất hàng giờ hoặc hàng ngày, thì đó là mức thay đổi cuộc chơi, và tôi không biết chúng ta sẽ đứng ở đâu trong bức tranh đó

    • Tôi dùng Deepseek-v4-pro làm model chính nhưng đôi khi nó khá khó chịu. Tôi giao cho nó mấy việc lặt vặt dễ làm và nghĩ kiểu “cứ để agent xử lý rồi mình chợp mắt một lát”, nhưng còn chưa kịp rời khỏi máy thì nó đã viết xong hết code rồi
    • Tôi đã dùng groq và GPT OSS, bản 20B chạy ở 1000 TPS, bản 120B ở 800 TPS nên tốc độ mang lại cảm giác khá kỳ diệu
      Tôi chưa dùng Cerebras ở 3000 TPS, nhưng đã thử một bản demo model 15.000 TPS mà tôi không nhớ tên. Không rõ nó có tạo khác biệt thực sự có ý nghĩa trong công việc hằng ngày hay không, nhưng nhìn văn bản tràn kín màn hình chỉ trong chớp mắt thật sự rất ấn tượng. Nó đặc biệt hữu ích cho các bước kiểm tra nhỏ như xem diff rồi xác nhận thay đổi có đúng ý định hay không, và khi có thể lặp lại các lần kiểm tra này thật nhanh thì sẽ giúp thực hiện được nhiều lượt rà soát tập trung mà không bị gián đoạn
    • Nếu độ trễ đủ thấp thì không còn lý do gì để phải multitask. Cứ giao từng việc một rồi xem kết quả ngay, và đó thực ra là một cách làm việc khá tốt
      Với các tác vụ không quá nặng về tính toán, UI tương tác vốn dĩ đã hoạt động như vậy. Phần lớn thời gian chương trình chỉ đang ngồi chờ người dùng bấm nút. Không nhất thiết chúng ta phải ngồi chờ chương trình, hay tự làm mình bận rộn bằng cách quay nhiều đĩa cùng lúc. Tuy vậy, chỉ có LLM nhanh hơn là chưa đủ, còn cần cả biên dịch và kiểm thử nhanh
    • Nút thắt cổ chai tiếp theo là compiler, nhưng cái này cũng có thể mô hình hóa bằng LLM. Chỉ sai khoảng 15% thôi :)
      Nói nghiêm túc thì dùng Cerebras ở khoảng 2k tokens/s với độ trễ cực thấp cho cảm giác như đang nhìn thoáng qua tương lai. Nó khiến bạn sắp xếp lại workflow theo hướng xoay quanh những việc có thể diễn ra mà không cần review thủ công nặng nề, chẳng hạn bằng cách mô tả rõ điều kiện thành công. Hiện giờ hiếm khi vấn đề tôi gặp phù hợp hẳn với kiểu này, nhưng có vẻ tương lai sẽ đi theo hướng đó. Dĩ nhiên model nhanh thường không phải model có hiệu năng tốt nhất, nhưng nếu có thể suy nghĩ gần như tức thì mà vẫn chất lượng cao, thì đó sẽ là một game changer mà chúng ta thực sự chưa sẵn sàng đón nhận
    • Có hai mặt. Khi nhờ Gemini 3.5 Flash làm gì đó, nó gần như cho kết quả ngay và hoạt động tốt, đến mức đôi khi tốc độ ấy hơi đáng sợ
      Nhưng với một số việc khác, nó cũng có thể đi chệch hướng. Trước đây còn có thể chen vào kiểu “khoan, không phải thế”, nhưng đến lúc bạn nhìn thấy chữ trên màn hình và kịp phản ứng thì nó đã thực hiện các thay đổi quy mô lớn rồi. Trừ khi bắt nó commit sau mỗi lần chỉnh sửa, còn không thì rất khó ngăn việc nó đi sai nhanh y như lúc nó đi đúng, và nếu có nhiều quyền thì nó còn có thể mắc lỗi cả trên các API từ xa
  • Tôi không thật sự hiểu lập luận về năng suất. Với một nhân viên bình thường, việc một thứ trước đây mất 2 ngày giờ chỉ còn 2 tiếng cũng không quan trọng đến thế. Vì thời gian còn lại không phải muốn dùng sao cũng được; bạn vẫn phải làm việc 8 tiếng một ngày
    Trước đây còn có niềm vui đào sâu một vấn đề và tạo ra thứ gì đó trong 2 ngày, còn giờ thì biến thành kiểu kéo máy đánh bạc và hy vọng prompt đúng sẽ cho ra câu trả lời đúng. Theo tôi thì với chúng ta điều này còn tệ hơn. Tất nhiên với doanh nghiệp và lãnh đạo thì hoàn toàn ngược lại, họ chắc sẽ cực kỳ thích tình hình AI hiện nay

    • Nếu chia công việc giao cho AI thành các mảnh nhỏ thì bạn vẫn giữ được quyền kiểm soát kiến trúc và nó sẽ không còn là máy đánh bạc nữa. Tôi vẫn đọc code và thỉnh thoảng cũng tự viết
      Dù không dùng nhiều, đó vẫn là cái giá phải trả để có tốc độ cao hơn. Nếu ném một việc lớn cho AI rồi quay lại sau một tiếng, bạn có thể phát hiện mình đã mất cả tiếng mà chẳng nhận lại được gì
    • Với tôi, model chậm khiến việc quản lý song song ngữ cảnh và tác vụ trở nên khó khăn. Làm xong từng việc một, nghỉ một chút rồi chuyển sang việc tiếp theo sẽ tốt hơn nhiều
      Hiện tôi đang chạy song song ba việc trong ba tab và phải liên tục chuyển ngữ cảnh nên đau đầu hơn rất nhiều. Nếu model nhanh hơn thì sẽ không cần khởi động thêm việc mới trong lúc chờ đợi nữa
    • Với bất kỳ công nghệ nào cũng có cách dùng ngu ngốc và cách dùng thông minh. Đối xử với nó như một “máy đánh bạc cho ra đáp án đúng” là cách dùng ngu ngốc. Có thể hiệu quả trong chốc lát, nhưng vì ai cũng làm như vậy được nên nó sẽ không bền
      Không ai ngăn bạn dùng công nghệ này để đào sâu vấn đề hơn trước. Đó mới là cách dùng thông minh
    • Tôi không biết cái thế giới nào mà nhân viên làm việc 8 tiếng một ngày. Có thể họ chấm công đủ 8 tiếng, nhưng không có nghĩa là họ làm việc suốt quãng thời gian đó
    • Khả năng của chúng ta trong việc đánh giá chất lượng đầu ra đang tụt lại phía sau khả năng tạo ra đầu ra. Không thể xem “đáp án đúng” là kết quả trông có vẻ hợp lý nhất được
  • Nếu tối ưu hóa giá·tốc độ từ các nhà cung cấp Trung Quốc kết hợp với việc tăng giá của các công ty Mỹ, thì cục diện sẽ sớm thay đổi. Nhiều công ty đã đang gặp vấn đề với hóa đơn AI

    • Các mô hình Trung Quốc đủ tốt và rẻ.
      Tôi đang dùng gói đăng ký GitHub Copilot hằng năm, và gần đây Microsoft đã chuyển cách tính phí sang dựa trên token. Hiện vẫn tính theo đơn vị yêu cầu premium, nhưng GPT 5.4 giờ đã là 6x thay vì 1x như trước
    • Vì không dư dả tiền bạc, gần đây tôi cố dùng DeepSeek v4 Flash, GLM 5.1, v.v. nhiều nhất có thể thay cho Claude hay GPT
    • Một vấn đề khác là các mô hình Mỹ đều là mã nguồn đóng. Nếu là doanh nghiệp lớn, có thể họ không muốn tổ chức của mình bị OpenAI hay Anthropic bắt làm con tin.
      Tôi thực sự không hiểu các phòng nghiên cứu mô hình ở Mỹ có “hào lũy” gì. Nếu họ nói tự cải tiến đệ quy đã ở ngay trước mắt, trong khi các phòng nghiên cứu Trung Quốc chỉ chậm hơn đôi chút so với các mô hình hàng đầu của Mỹ, thì hào lũy của các phòng nghiên cứu Mỹ là gì? Có phải mô hình Mỹ tự cải tiến đệ quy tốt hơn các mô hình mã nguồn mở của Trung Quốc không? Có thể tôi sai hoàn toàn, nhưng nếu tôi đã rót tiền vào OpenAI hay Anthropic thì lúc này tôi sẽ muốn rút hết. Tôi thấy khả năng giá trị của chúng tiến gần về 0 trong vài năm tới là khá lớn
    • Vấn đề lớn hơn là độ nhất quán của mô hình. Không rõ liệu Anthropic có thể thu giá Opus nhưng lại định tuyến yêu cầu sang mô hình rẻ hơn hay không.
      Vì vậy không thể dự đoán chi phí công việc, do có thể phải khởi động lại nhiều lần và trả tiền mỗi lần. Thêm nữa, còn phải gửi thêm prompt để đoán xem mô hình là thật hay giả, nên lượng token sử dụng cũng tăng lên
    • Tôi tò mò về cấu trúc kinh tế đang dẫn dắt những quyết định giá này. Tôi không biết các công ty Trung Quốc đang trợ giá mô hình nhiều hơn Mỹ, hay đây là kết quả của khác biệt về chính sách năng lượng giữa các quốc gia
  • Nếu MiMo rẻ như Deepseek, thì theo thảo luận trước đó https://news.ycombinator.com/item?id=48282814, ngay cả khi nhân giá lên 3 lần để đổi lấy tốc độ siêu cao thì nó vẫn rẻ đến mức gây sốc

    • Không phải MiMo và DeepSeek rẻ, mà là Anthropic và OpenAI đắt so với giá trị họ cung cấp
  • Bản tốc độ thường của MiMo V2.5 Pro vẫn là mô hình coding kiểu agent có trọng số mở mạnh nhất mà chúng tôi đã thử nghiệm. Thật thú vị khi nó lại nhận được ít chú ý hơn nhiều so với các bản phát hành có hiệu năng thấp hơn.
    Giá cho “fast mode” ở đây cũng rất cạnh tranh. Dữ liệu có tại https://gertlabs.com/rankings

    • Tại sao deepseek v4 pro lại xếp thấp hơn flash rất nhiều? mimo 2.5 ở đâu?
  • Nghe có thể giống quảng bá, nhưng tăng trưởng theo cấp số nhân là có thật. Chúng ta sẽ tiến tới giai đoạn gần như ngay lập tức tạo ra nhiều phần mềm từ prompt rồi chọn cái tốt nhất trong số đó.
    Những cuộc tranh luận về việc chọn thư viện có tên phương thức “syntactic sugar” hay nhất sẽ trông kỳ quặc chẳng khác gì đề xuất nhập liệu bằng assembly

    • Nghe như tăng trưởng theo cấp số nhân của phần mềm tồi. Trước đây kỹ nghệ phần mềm cũng không phải chưa từng có rác sản xuất hàng loạt, nhưng giờ nó sẽ bùng nổ tràn ngập
    • Đã từng có thời cứ 3 tháng lại có một framework frontend mới xuất hiện. Giờ chuyện đó gần như dừng lại và chẳng còn ai quan tâm
    • Tôi không chắc. Kỹ sư vẫn có thể làm phần mềm theo cách cũ. Ví dụ như dành hàng tháng để làm những thứ như Obsidian hay Ghostty, chăm chút từng dòng code, dependency và kiến trúc tốt.
      Đó là cách làm cũ thật sự, và nếu sản phẩm tốt thì nó sẽ thành công
    • Tôi nhìn tích cực hơn. Khi AI tốt hơn và nhanh hơn, ta có thể cải thiện code nhanh hơn và lặp đi lặp lại nhiều hơn ở những phần trước đây né tránh vì khối lượng công việc.
      Thực tế nhờ AI mà tôi đã thực hiện nhiều đợt refactoring ở mức độ mà bình thường sẽ là vô lý. Không chỉ vì khối lượng công việc, mà còn có ma sát kép vì đôi khi ta còn không biết nó có thành công hay không. Có AI, bạn có thể quăng một đợt refactor vào đó trong lúc đi uống cà phê rồi quay lại xem nó mắc ở đâu. Nhìn chung AI sẽ khiến loài người bộc lộ bản thân một cách cực đoan hơn. Theo cả hướng tốt lẫn hướng xấu. Chỉ là tôi nghĩ hướng xấu sẽ nhiều hơn
    • Xu hướng theo cấp số nhân trong vài năm tới sẽ dẫn đến tính toán hoàn toàn trong bộ nhớ, hiệu quả hơn 100 lần. Điều đó có nghĩa là có thể chạy các mô hình lớn hơn ít nhất 10 lần, thông minh hơn nhiều mà vẫn rất nhanh.
      Với doanh nghiệp nhỏ, họ sẽ bỏ qua code hoàn toàn và render UI trực tiếp ở tốc độ hội thoại từ dữ liệu ngữ cảnh và prompt. Nó sẽ giống những gì Google Genie làm trong game, nhưng chính xác hơn rất nhiều
  • Điều này sẽ thực sự mạnh trong giọng nói. Nhờ khả năng suy luận, LLM sẽ thông minh hơn nhiều, nhưng giọng nói có ngân sách độ trễ quá chặt nên thường không thể dành thời gian cho phần đó

  • Cerebras đang thử nghiệm Kimi K2.6 ở 3000t/s, chỉ dành cho người được mời. Tôi mong chờ thời điểm phần cứng nhanh hơn trở nên phổ biến hơn ở các mô hình frontier.
    Những mô hình được Nvidia thiết kế xoay quanh tốc độ có thể là phần bổ sung tốt để lấp khoảng trống đó

    • Bài gốc nói rằng từ trước đến nay để đạt tốc độ như vậy cần phần cứng chuyên dụng và rất đắt như Cerebras.
      Điểm mới của kết quả lần này là đã vượt 1000 token/s trên mô hình hơn 1 nghìn tỷ tham số chỉ với phần cứng tiêu chuẩn, tức một máy chủ gồm 8 GPU
    • Tôi tò mò về nguồn. Trên website Cerebras ghi là 1000t/s https://www.cerebras.ai/blog/which-is-faster-gemini-3-5-flas...
    • Cerebras đã may mắn khi lên sàn vào tháng trước. Nếu là lúc này thì có lẽ đã khác
    • Cerebras hiện không cung cấp chiết khấu prefix caching, nên với workload kiểu agent, chi phí sử dụng sẽ đắt hơn theo sqr(n_turns)
  • Thú vị đấy. Các mô hình frontier đã trở nên khá ấn tượng, nhưng tất cả đều hơi chậm cho lập trình tương tác có con người trong vòng lặp. Vì thế điều đó dẫn tới hướng làm vibe coding và chạy song song nhiều agent. Agent nhanh tạo cảm giác gần giống một đối tác hơn.
    Tôi đã dùng Cerebras GLM 4.7 cho nhiều tác vụ một thời gian. Nó không phải là mô hình quá thông minh, nhưng trải nghiệm mở một prototype trực tiếp của trang web rồi nhập kiểu “tăng cỡ font lên chút. Không, đừng nhiều thế” và thấy nó thay đổi theo thời gian thực thì rất tuyệt. Và MiMo 2.5 có năng lực hơn GLM 4.7 rất nhiều

    • Tôi đã thử dùng GLM 4.7 làm agent viết mã, và nó cực kỳ tệ ngay cả với các script đơn giản dài 200~1000 dòng. Tôi đã phải từ bỏ các mô hình do Cerebras cung cấp, còn các mô hình thông minh hơn thì chỉ có trong gói enterprise
    • MiMo 2.5 không phải là cùng một mô hình với MiMo 2.5 Pro
      GLM 5.1 là bản lặp mới nhất của z.ai và là một trong những mô hình coding open-weight phổ biến. Nếu đã dùng thử, tôi khá tò mò GLM 5.1 — hiện còn đắt hơn MiMo 2.5 Pro ngay cả sau đợt giảm giá 70% gần đây — so sánh ra sao
  • 1k TPS cũng rất ấn tượng, nhưng điều thú vị hơn là có bao nhiêu bình luận trong thread này do AI tạo ra