- Chris Lattner là nhà phát triển chủ chốt của LLVM và ngôn ngữ Swift, hiện đang phát triển ngôn ngữ mới Mojo để khai thác tối đa hiệu năng của phần cứng ML hiện đại
- Mojo được thiết kế với mục tiêu vừa dễ sử dụng vừa cho phép kiểm soát chi tiết phần cứng, đồng thời hỗ trợ xử lý hiệu quả các chi tiết phần cứng thông qua metaprogramming an toàn kiểu dữ liệu
- Bối cảnh cốt lõi là xây dựng một nền tảng điện toán hợp nhất nhằm giải quyết vấn đề phân mảnh của hệ sinh thái bộ tăng tốc AI như GPU, TPU, ASIC, đồng thời giảm sự phụ thuộc vào từng nhà cung cấp cụ thể
- Do các vấn đề về khả năng tương thích và độ phức tạp của các stack phần mềm GPU hiện có (CUDA, ROCm, XLA, v.v.), việc phát triển một ngôn ngữ thế hệ mới có hiệu năng cao và tính di động là điều thiết yếu
- Modular đang theo đuổi mô hình kinh doanh tập trung vào giải quyết các vấn đề thực tế như hỗ trợ phần cứng hợp nhất và dịch vụ doanh nghiệp, đồng thời cung cấp Mojo miễn phí
Giới thiệu về Chris Lattner và sự nghiệp
- Chris Lattner có kinh nghiệm dẫn dắt nhiều dự án cốt lõi trong lĩnh vực điện toán như LLVM, Clang, MLIR, Swift và Mojo
- Ông từng làm việc tại nhiều tổ chức như Apple, Tesla, Google, SiFive và Modular, tích lũy kinh nghiệm thực chiến sâu rộng về trình biên dịch và thiết kế ngôn ngữ lập trình
- Ban đầu ông xuất phát từ các ngôn ngữ đơn giản như BASIC và môi trường PC, rồi dần quan tâm đến việc tối đa hóa hiệu năng phần cứng thông qua game và đồ họa
- Thời đại học, ông tình cờ chịu ảnh hưởng từ một giáo sư chuyên ngành trình biên dịch và từ đó bị cuốn hút bởi hệ thống cũng như cấu trúc phần mềm quy mô lớn
Qua lại giữa trình biên dịch và thiết kế ngôn ngữ
- Chris Lattner đã trải nghiệm cả kỹ thuật trình biên dịch lẫn thiết kế ngôn ngữ, và đạt được nhiều thành tựu lớn tại điểm giao giữa hai lĩnh vực này
- Ví dụ, LLVM là một ngôn ngữ trung gian có thể được nhiều ngôn ngữ sử dụng, tạo ra các ứng dụng rộng khắp không chỉ với triển khai C++ mà còn với Rust, Julia và nhiều trường hợp khác
- Việc phát triển Swift cũng bắt đầu như một nỗ lực để vượt qua giới hạn và sự mệt mỏi từ triển khai C++ hiện có, đồng thời nhấn mạnh nhu cầu về các tính năng thực dụng như pattern matching
- Ông ưa chuộng cách tiếp cận thiết kế đổi mới ngôn ngữ lập trình dựa trên giải quyết vấn đề thực tế và tính hữu dụng hơn là lý thuyết toán học thuần túy
Lý thuyết ngôn ngữ lập trình và tính thực dụng
- Chris theo đuổi tư duy lấy giải quyết vấn đề làm trung tâm hơn là sự nghiêm ngặt toán học, và trong các bài báo PL ông quan tâm đến ví dụ thực tiễn cùng các trường hợp ứng dụng hơn là bản thân lý thuyết
- Ông thừa nhận các tính năng ngôn ngữ có nền tảng toán học vững chắc có ưu điểm về tính nhất quán và khả năng kết hợp, nhưng động lực thực sự cho việc áp dụng trong thực tế là lợi ích rõ ràng khi sử dụng
- Ông nhấn mạnh rằng khi thiết kế ngôn ngữ hay công nghệ mới, điều quan trọng là giảm tối đa “hạt cát (grain of sand)” của độ phức tạp để hướng tới sự đơn giản trong thiết kế và khả năng mở rộng
Vấn đề cấu trúc của hệ sinh thái phần cứng AI
- Hạ tầng trình biên dịch truyền thống như LLVM vốn lấy CPU làm trung tâm, nhưng AI/machine learning lại đòi hỏi nhiều loại phần cứng chuyên dụng như GPU, TPU, ASIC và FPGA
- Mỗi nhà cung cấp phát triển stack phần mềm riêng (CUDA, ROCm, XLA, v.v.), dẫn đến thiếu khả năng tương thích và phân mảnh hệ sinh thái
- Phần mềm ML (ví dụ: PyTorch) cần tối ưu hóa riêng cho từng nhà cung cấp phần cứng, khiến việc bảo trì và mở rộng trở nên rất khó khăn
- Do mỗi loại phần cứng có stack, ngôn ngữ và hệ sinh thái công cụ khác nhau, năng suất và tính di động của nhà phát triển phần mềm bị suy giảm trên diện rộng
Vai trò của Modular và Mojo
- Đội ngũ Modular tập trung vào việc xây dựng một nền tảng phần mềm phổ quát và hợp nhất để giải quyết các vấn đề này
- Mojo được thiết kế không chỉ để tối ưu hiệu năng cho các kiến trúc GPU hiện đại (như tensor core) mà còn hướng tới việc viết kernel có thể di động trên nhiều loại phần cứng khác nhau
- Thông qua cấu trúc nhiều tầng như Mojo, MAX (phục vụ LLM hiệu năng cao, v.v.) và Mammoth (quản lý cluster/Kubernetes), họ cung cấp một hạ tầng AI tích hợp
Bối cảnh cần đến Mojo và các quyết định thiết kế ngôn ngữ
- Với các ngôn ngữ hiện có, rất khó đồng thời đáp ứng hai yêu cầu là tính di động của kernel ML hiệu năng cao và tối ưu hóa theo từng nhà cung cấp
- Mojo cần có khả năng thích ứng động với các thay đổi phần cứng nhanh chóng và mang tính đột phá, chẳng hạn như cấu trúc chi tiết của phần cứng, các kiểu dữ liệu mới (như số thực dấu phẩy động 8 bit) và tensor core
- Mojo chuyển việc điều khiển phần cứng phức tạp sang một phương thức hiệu quả và dễ chia sẻ hơn bằng mô hình metaprogramming an toàn kiểu dữ liệu
Những thay đổi trong thiết kế phần cứng và kernel
- CPU trong các trung tâm dữ liệu hiện đại đã mở rộng theo hướng nhiều lõi, còn GPU thì phát triển mạnh theo thiết kế chuyên cho xử lý song song như cấu trúc SM (Streaming Multiprocessor) và Warp (32 luồng hoạt động)
- Khi các đơn vị tính toán chuyên cho AI như tensor core được tích hợp vào phần cứng, đã xuất hiện nhu cầu về một paradigm lập trình phần cứng hoàn toàn khác so với CUDA truyền thống
- Ngay cả trong cùng một nhà cung cấp, khả năng tương thích giữa các thế hệ kiến trúc cũng thay đổi thường xuyên (ví dụ: Nvidia Volta/Hopper/Blackwell), trong khi stack phần mềm không theo kịp
Mô hình kinh doanh và chiến lược hệ sinh thái mở
- Modular không tập trung vào việc bán ngôn ngữ, mà công bố Mojo miễn phí
- Mô hình doanh thu cốt lõi dựa trên cung cấp nền tảng/dịch vụ cho doanh nghiệp và quản lý phần cứng hợp nhất
- Qua đó, họ thách thức việc xây dựng một hệ sinh thái dùng chung không bị vendor lock-in, đồng thời theo đuổi cả hỗ trợ đa phần cứng lẫn quản lý hạ tầng hiệu quả
Kết luận
- Dự án Mojo của Chris Lattner và Modular có ý nghĩa như một nỗ lực xây dựng ngôn ngữ lập trình và nền tảng mới để đáp ứng sự phát triển nâng cao của machine learning, đổi mới phần cứng AI và vượt qua sự phân mảnh của hệ sinh thái
- Thông qua thiết kế ngôn ngữ đổi mới và việc mở rộng hệ sinh thái mở, đây là một chiến lược có thể góp phần vào dân chủ hóa hệ sinh thái AI và nâng cao năng suất
1 bình luận
Ý kiến trên Hacker News
Muốn gửi lời cảm ơn vì rất nhiều người đã quan tâm đến Mojo và podcast. Nếu muốn tìm hiểu thêm về Mojo, có thể xem các câu hỏi thường gặp trong FAQ (cũng có câu trả lời cho câu hỏi “tại sao không làm Julia tốt hơn”). Tài liệu cũng có thể xem tại đây, và mã nguồn mở cũng đã được công khai với quy mô hàng trăm nghìn dòng. Cộng đồng Mojo cũng thực sự rất tuyệt, nên rất mong mọi người tham gia cùng trên diễn đàn Discourse hoặc chat Discord - đây là ý kiến của Chris Lattner
Xin nói trước là tôi là fan. Tôi đã xem nhiều bài trình bày về Mojo, và dù Mojo nói rằng mình tận dụng công nghệ trình biên dịch tiên tiến, tôi chưa từng thấy ví dụ cụ thể nào. Dù không phải là người làm compiler, chỉ cần hiểu được khoảng 20% thôi tôi cũng muốn cảm nhận được bản chất của những kỹ thuật tiên tiến đó, nên rất mong có một bài blog thật sâu và thật kỹ thuật về chủ đề này
Trong FAQ có câu hỏi "Mojo Playground vẫn còn dùng được không?" rồi dẫn đến playground đó, nhưng ngay tại đó lại ghi rằng 'Playground sẽ bị gỡ ở bản phát hành 25.6 tiếp theo'. Một câu trả lời FAQ cho câu hỏi 'có còn dùng được không' mà lại dẫn đến tính năng sắp bị xóa thì có vẻ đã bỏ lỡ trọng tâm. Trên thực tế, câu trả lời có vẻ là 'không dùng được lâu nữa'
Chris, rất vui được gặp anh ở đây. Trước đây tôi còn đầu tư thông qua Light Table nên muốn hỏi xem có cập nhật gì không. (Không phải hỏi nghiêm túc đâu, Mojo trông vẫn rất ngầu.) Tôi muốn biết tính bền vững lâu dài của những dự án kiểu này ra sao, và có cơ sở đáng tin nào để tin tưởng hay không
Python thống trị lĩnh vực ML vì các ứng dụng ML hiện đại không chỉ là script tính toán đơn thuần mà đòi hỏi phạm vi chức năng rộng và một hệ sinh thái vững chắc. Từ tiền xử lý dữ liệu các loại (ETL), xử lý dữ liệu ở nhiều định dạng, xử lý phân tán trên các cụm tính toán hiệu năng cao, đến trực quan hóa và tích hợp GUI/DB, không có ngôn ngữ nào ngoài Python bao quát được tất cả những thứ đó. Phần tính toán số thì bên trong các thư viện như NumPy, PyTorch, JAX đã dùng C/C++/FORTRAN nên rất nhanh, và cũng rất dễ tách riêng những đoạn mã quan trọng về hiệu năng để viết bằng C/C++. Hệ thống FFI C/C++ của Python cũng đủ thực dụng so với các ngôn ngữ khác. So với việc phải xây lại toàn bộ hệ sinh thái ở ngôn ngữ khác như Julia, điều này có lợi thế lớn hơn nhiều
Hệ sinh thái Python là vô đối, nhưng tổ hợp Elixir/Nx cũng đã làm được khá nhiều điều mà Mojo hứa hẹn. Qua EXLA có thể biên dịch sang GPU/TPU, làm việc với dataframe bằng Explorer/Polars, và nhúng thư viện Python bằng Pythonx. Điểm khác biệt là Elixir ngay từ đầu đã hướng đến xây dựng hệ thống phân tán, nên BEAM/OTP có thể xử lý lượng yêu cầu đồng thời khổng lồ cũng như điều phối giữa các node GPU. Nếu thực sự xây dựng dịch vụ ML, thì việc có một stack vững chắc duy nhất gồm Phoenix, LiveView và Nx để đạt khả năng chịu lỗi cực cao và mở rộng tốt có thể còn quan trọng hơn một chút hiệu năng phần cứng
Tôi hơi có quan điểm khác ở phía suy luận (inference). Việc tự chỉnh sửa trực tiếp để viết các CUDA kernel là khá dễ, và CUTLASS 3 mới cùng C++ hiện đại đã tiện hơn nhiều. Torch nằm mỏng bên trên lớp đó, nhưng phần này vừa khó build vừa chỉ làm tăng độ phức tạp do reference counting và nhiều vấn đề khác. Phần triển khai cốt lõi thực sự nằm ở các kernel bên dưới, nên tôi đang nghĩ sớm muộn sẽ gỡ lớp ‘vỏ torch’ đó ra và dùng một chương trình C++ sạch sẽ hơn, nối vào rõ ràng hơn
Vấn đề này là nỗi lo về GPU kernel, mà các kernel như vậy ngay từ đầu đã không được viết bằng Python. Python là ngôn ngữ ‘keo dán’ cho ML. Tôi đồng ý với nhận định rằng “chỉ Python mới cung cấp đủ mọi thứ”, nhưng cũng hơi tiếc khi hệ sinh thái lại phát triển xoay quanh Python thay vì một ngôn ngữ tốt hơn
Python trở thành ngôn ngữ tiêu biểu cho ML là nhờ một ‘vòng lặp tích cực’. Hệ sinh thái chỉ lớn lên vì nó đã được chọn từ trước, nhưng lý do tại sao ban đầu lại chọn Python thì vẫn cần được giải thích riêng. Bây giờ nó đã lớn đến mức gần như không thể vượt qua, nhưng lấy điều đó làm lập luận cho việc vì sao ngay từ đầu lại là Python thì vẫn chưa đủ
Trớ trêu là Python lại là ngôn ngữ tệ nhất cho tất cả các công việc vừa nêu. Từ packaging đến binary wheel đều đau khổ, và lúc nào cũng có cái gì đó bị hỏng. Với script đơn lẻ thì ổn, nhưng nếu Python được thiết kế với mục tiêu trở thành ngôn ngữ chính cho ML, chắc không ai muốn nó trông như thế này
Tôi bị sốc sau khi nghe tập này. Thật bất ngờ khi đến tận tháng 9 năm 2025 mà việc hỗ trợ class vẫn còn là mục tiêu trung hạn. Trước đây Mojo từng được quảng bá khá nhiều là ‘siêu tập của Python’, nhưng với tốc độ hiện tại thì điều đó có vẻ chỉ là một mục tiêu lý tưởng
Thực ra mục tiêu chưa bao giờ là ‘siêu tập của Python’. Đó chỉ là khẩu hiệu để thu hút sự chú ý, được nhấn mạnh ở giai đoạn đầu rồi âm thầm rút lại
Có khi không phải vì vấn đề tốc độ mà là vì họ vốn không thích OOP
Từ trước đến nay đó vẫn luôn là mục tiêu dài hạn
Có thể đây là câu hỏi hơi phổ biến, nhưng tôi thắc mắc vì sao lại không phải Lisp. Nếu giả định rằng mã ML trong tương lai cuối cùng sẽ do máy móc (hoặc hệ thống tự động chuyển đổi dựa trên ngôn ngữ tự nhiên) viết ra, thì Lisp S-Expression về cơ bản gần như AST, nên là ngôn ngữ tự nhiên nhất cho máy. Môi trường REPL cũng thường đầy đủ, nên có vẻ cũng rất phù hợp để thay thế Python
Yann LeCun và những người khác từng tạo ra một Lisp cho ML tên là Lush. Vào thập niên 2000 nó là tốt nhất, và trước khi có Python (Theano) hay Lua (Torch) thì gần như không có lựa chọn thay thế nào. Đến giờ tôi vẫn mong Lisp sẽ lại được chú ý nhiều hơn. Thư viện của Python thì rất tuyệt, nhưng bản thân ngôn ngữ này vẫn còn nhiều chỗ cần cải thiện
LLM (mô hình ngôn ngữ lớn) vẫn chưa giỏi đếm số lượng dấu ngoặc ;)
Do từng có trải nghiệm bị Lisp phớt lờ trong các đợt bùng nổ AI trước đây, nên nhiều lập trình viên đến giờ vẫn chỉ dùng Emacs + SBCL. Thực ra còn có các triển khai Lisp cao cấp khác như LispWorks, Allegro, Clozure, nhưng nhiều người chưa từng thử qua
Ngay cả giấy phép của Mojo cũng đã khiến tôi không thích rồi
Tôi cũng đã kiểm tra, và giấy phép Mojo nói rõ rằng họ phân biệt giữa mục đích dùng cho CPU hoặc Nvidia và các ‘accelerator’ khác (TPU, AMD, v.v.); nếu là mục đích thương mại thì cần giấy phép riêng xem bài blog
Theo góc nhìn của tôi, nếu đó là một ngôn ngữ bị một công ty cụ thể kiểm soát tuyệt đối như Mojo, thì hoàn toàn không có lý do gì để đưa nó vào kinh doanh. Đã có nhiều doanh nghiệp gặp rắc rối khi giấy phép Java thay đổi. Xây dựng hoạt động kinh doanh trên Mojo thay vì Python là quá rủi ro
Xem FAQ của Mojo thì dường như họ nhắm tới việc trở thành siêu tập của Python theo nghĩa nghiêm ngặt, nhưng trong roadmap lại nói rằng “cung cấp mã Python và sự quen thuộc với Python, nhưng không thể là siêu tập hoàn chỉnh”, khiến mọi thứ càng rối hơn. Nếu tương thích Python không phải mục tiêu, thì tôi không hiểu vì sao họ cứ tiếp tục nhắc đến Python. Ngoài ra, tôi cũng muốn biết chuyện dùng emoji làm phần mở rộng tệp có phải là thật không
Theo tôi biết, Mojo chỉ nhắm đến cú pháp kiểu Python và khả năng tương tác với Python. Việc quảng bá rằng nó giống Python hơn mức đó phần lớn là marketing
Về phần mở rộng emoji thì đúng là thật. Đó là U+2615 (emoji cà phê)
Tôi muốn biết Mojo hơn Julia ở điểm nào, vì Julia tuy có giới hạn về interface hay hệ sinh thái nhưng cũng tương tác với Python khá tốt, nên tôi không thấy Mojo có gì vượt trội rõ rệt
Đặc biệt là Julia có hệ sinh thái GPU khá hoàn chỉnh như JuliaGPU hay Reactant xem Reactant.jl
Khả năng tương thích với Python có thể Mojo tốt hơn một chút, nhưng trên thực tế ở Julia cũng có thể gọi thư viện Python khá ổn định qua PythonCall.jl. Các framework ML như Lux.jl, Flux.jl cũng chạy tốt trong Julia. Có vẻ Mojo vẫn chưa có framework ML native ở mức tương đương
Mojo có vẻ nhắm đến cảm giác ngôn ngữ cấp thấp hơn, nhiều quyền kiểm soát hơn và độ vững chắc cao hơn. Julia thì không đủ khả năng dự đoán về ngữ nghĩa hay hiệu năng nên không phù hợp làm nền tảng phần mềm cốt lõi, còn Mojo có ưu thế ở điểm đó
Tôi từng muốn tạo module Python bằng Julia nhưng cảm thấy hỗ trợ vẫn chưa đủ. Còn với Mojo thì đây lại là tính năng cốt lõi
Julia vẫn còn thiếu khả năng biên dịch mã Julia thành binary native hoàn toàn (kiểu như Rust hay C++)
Tôi cảm thấy việc Mojo không thu hút được sự chú ý quá lớn và việc PyTorch vẫn tiếp tục được dùng rộng rãi có thể là dấu hiệu cho thấy vấn đề giấy phép thực tế còn lớn hơn kỳ vọng
Có vẻ Mojo đã quá lạc quan về phạm vi lãnh địa mà họ nhắm tới. Julia cũng đang dần tăng mức sử dụng thương mại và hỗ trợ GPU cũng tốt. Dù JIT compiler của Python còn yếu, Nvidia, Intel và những bên khác vẫn đang tối ưu hóa lập trình GPGPU bằng Python DSL đến mức có thể dùng trong Python gần với cấp độ C++. Cuối cùng, điểm khác biệt của Mojo khá yếu
Từ góc nhìn hệ thống, nỗ lực của Chris và đội ngũ nhằm giải quyết triệt để vấn đề FFI đa ngôn ngữ bằng Mojo là điều gây ấn tượng. Tuy vậy, trước khi nó trở thành mã nguồn mở thì tôi chưa thể bắt đầu bất kỳ cuộc thảo luận nào về đầu tư
Nó vẫn chưa sẵn sàng để dùng như một ngôn ngữ lập trình đa dụng. Modular cũng đã thử áp dụng API Mojo cho engine MAX nhưng từ bỏ đầu tư vì ngôn ngữ thay đổi quá nhanh. Chỉ sau khi hoàn thành giai đoạn 1 trong roadmap thì mới có thể kỳ vọng áp dụng nghiêm túc
Tôi không chắc nó có thực sự được công khai đúng nghĩa hay không. Cho đến gần đây nó vẫn chưa được mã nguồn mở, nên tôi ngại phụ thuộc vào phần mềm độc quyền thương mại
Ngay đầu bài có nói rằng có thể dùng ‘kernel tối tân’. Rốt cuộc thì Mojo dường như đang muốn cạnh tranh với C++ trong mảng phát triển kernel. Còn với PyTorch hay Julia thì người ta thường không tự viết kernel mà chủ yếu lập trình ở mức cao
Có các tập podcast của Lex Fridman có Chris Lattner tham gia:
Bản thân việc thử làm Mojo là táo bạo và thú vị, nhưng nếu nó là một ngôn ngữ đóng như Matlab thì với tôi cũng như nhiều người khác, đó là một khuyết điểm nghiêm trọng