- Mercury là một mô hình ngôn ngữ lớn (LLM) thương mại mới sử dụng phương pháp khuếch tán (Diffusion)
- Mô hình này dựa trên kiến trúc Transformer và có đặc điểm dự đoán song song nhiều token
- Mercury Coder là bộ LLM diffusion đầu tiên, được phát triển cho việc viết mã và có hai kích cỡ là Mini và Small
- Trên GPU NVIDIA H100, mô hình ghi nhận thông lượng 1109 (Mini) và 737 (Small) token/giây, cho hiệu năng nhanh hơn tối đa 10 lần so với các mô hình hiện có thiên về tốc độ ở cùng chất lượng
- Trong các benchmark sử dụng thực tế và các đánh giá từ nhà phát triển như Copilot Arena, mô hình đạt chất lượng hạng 2 và tốc độ cao nhất, đồng thời cung cấp API công khai và playground
Tổng quan
- Mercury là một dòng mô hình ngôn ngữ lớn mới dựa trên diffusion, thuộc thế hệ LLM mới hoạt động ở quy mô thương mại
- Tất cả các mô hình đều được tham số hóa theo kiến trúc Transformer và được huấn luyện để dự đoán song song nhiều token
- Báo cáo này chủ yếu giới thiệu dòng sản phẩm đầu tiên của Mercury Coder, được thiết kế cho các ứng dụng sinh mã
- Mercury Coder hiện có hai kích cỡ mô hình là Mini và Small
Đóng góp chính
- Mercury Coder đạt mức state-of-the-art mới về cân bằng giữa tốc độ và chất lượng
- Theo tổ chức đánh giá độc lập Artificial Analysis:
- Mercury Coder Mini: 1109 token/giây
- Mercury Coder Small: 737 token/giây trên GPU NVIDIA H100
- Nhanh hơn trung bình tối đa 10 lần so với các mô hình frontier nhanh nhất, trong khi vẫn giữ chất lượng tương đương
- Báo cáo cũng cung cấp thêm kết quả đánh giá trên các benchmark mã cho nhiều ngôn ngữ lập trình và trường hợp sử dụng khác nhau
- Trong môi trường nhà phát triển thực tế (Copilot Arena), mô hình cũng đạt:
- Hạng 2 về chất lượng
- Hạng 1 toàn bộ về tốc độ
- Hỗ trợ API công khai ( platform.inceptionlabs.ai ) và chat playground miễn phí ( chat.inceptionlabs.ai ) để mọi người đều có thể sử dụng
Giải thích cấu trúc mục lục
- Introduction (giới thiệu)
- Contributions (đóng góp chính)
- Inception Mercury Model Family (giải thích họ mô hình)
- Training (huấn luyện)
- Inference (suy luận)
- Capabilities (năng lực mô hình)
- Baselines (hiệu năng cơ sở)
- Coding Capabilities (khả năng sinh mã)
- Evaluation Benchmarks (benchmark đánh giá)
Tổng kết
- Mercury kết hợp thiết kế LLM dựa trên diffusion mang tính đột phá với cấu trúc dự đoán song song để hiện thực hóa tốc độ vượt trội và chất lượng cao trong lĩnh vực sinh mã
- Với nhiều kích cỡ mô hình, benchmark dịch vụ thực tế mạnh mẽ và khả năng tiếp cận dễ dàng, đây là một lựa chọn cạnh tranh cho cả môi trường thương mại lẫn phát triển
1 bình luận
Ý kiến Hacker News
Nhấn mạnh rằng khi các agent LLM được áp dụng, hiệu năng kiểm thử sẽ dẫn đến nút thắt CPU còn nghiêm trọng hơn, và ngay lúc này mọi đội ngũ đã đang bị nghẽn vì tốc độ CI
Dù agent có viết code nhanh hơn con người 100 lần, nếu test mất một giờ thì cũng không có ý nghĩa
Trong nhiều dự án tôi từng làm, rất nhiều thời gian của lập trình viên bị lãng phí vì phải chờ thay đổi được phản ánh, và nhiều lần chạy bị nghẽn bởi I/O hoặc thiếu worker
Khi agent lập trình nhanh chóng biến ticket đơn giản thành PR và phản ứng với lỗi test để sửa theo thời gian thực, nút thắt CI sẽ còn tệ hơn
Môi trường test của phần lớn dự án còn rất nhiều chỗ để cải thiện, nhưng thực tế là người ta đã quen coi CI chậm và chi phí cao là chuyện bình thường suốt nhiều năm mà hầu như không có tiến triển
CI thậm chí còn chậm hơn khi tắt cache để cô lập build hoàn toàn, hoặc khi chuyển từ on-premise sang cloud VM chậm hơn
Tốc độ của Mercury nhanh đến mức điên rồ, và sau vài lần thử thì chất lượng code cũng rất tốt và chính xác, nhưng giờ bài toán còn lại là làm sao để việc chạy test theo kịp tốc độ này
Tôi không thấy thuyết phục lắm với ý rằng ở phần lớn dự án tôi từng làm, thời gian của lập trình viên bị lãng phí vì chờ PR được duyệt
Từ góc nhìn doanh nghiệp, thời gian của lập trình viên đắt hơn rất nhiều so với thời gian máy, nên nếu lập trình viên phàn nàn thì đây là vấn đề có thể giải quyết bằng cách tăng gấp đôi số CI worker
Ở Google, khi debug tính không ổn định của test, có khi họ chạy một bài test 10.000 lần trên 10.000 máy để tìm ra lỗi hiếm gặp
Nơi tôi đang làm cũng cung cấp cách làm tương tự, với mục tiêu chỉ bằng một lệnh có thể chạy song song toàn bộ test trên 1.000 worker để nhận phản hồi trong vòng 5 phút ngay cả với dự án 1M LOC
Cô lập build hoàn toàn và không dùng cache là hai chuyện khác nhau; cần vừa cô lập build hoàn toàn vừa tận dụng tối đa mọi cache có thể
Khi tốc độ triển khai tăng lên, nút thắt sẽ chuyển sang phía PM, và trong trường hợp đó có thể sẽ xuất hiện hiện tượng xung đột giảm mạnh do thay đổi bị xử lý tuần tự hơn
Cũng có khả năng các ngôn ngữ đặc tả (như TLA+) sẽ hồi sinh, vì agent có thể nhanh chóng viết và kiểm chứng chúng, từ đó giảm tổng số integration test
Khi agent chạy nền dọn dẹp code trùng lặp, cũng có thể dọn luôn cả test trùng lặp
AI có vẻ sẽ làm việc hiệu quả hơn trong kiến trúc monolithic so với đội ngũ kỹ sư con người; nếu vậy, phạm vi test có thể chạy cục bộ sẽ tăng, giúp giảm flaky và giảm tải cho CI
Ngay cả khi AI nâng cao hiệu suất, nó cũng sẽ tạo ra thêm nhiều code hơn, sinh code và chạy code nhanh hơn, nên chắc chắn các vấn đề mới vẫn sẽ liên tục xuất hiện để kỹ sư con người giải quyết
LLM có thể ổn cho các chỉnh sửa nhanh dưới 100 dòng, hoặc đóng vai trò rubber duck, nhưng nếu đưa LLM trực tiếp vào pipeline CI của dự án lớn thì có thể gây sụt giảm năng suất đến hàng trăm giờ
Nếu rốt cuộc chỉ dành thời gian để tinh chỉnh prompt và điều chỉnh context thay vì nâng cao kỹ năng viết code thực sự thì chẳng có ý nghĩa gì
Tôi cảm thấy sự tự tin dành cho tooling LLM đang bị thổi phồng quá mức, và cho rằng nó không áp dụng tốt cho các hệ thống phức tạp
Mức độ mất lòng tin mạnh đến mức cho rằng sẽ không thể có chuyện đưa LLM không giám sát vào kho mã quan trọng, “trừ khi bị dí súng vào đầu”
Cuối cùng thì vẫn phải sửa lại kha khá đầu ra của LLM, mà như thế thì tự làm còn hơn
Trước khi có ô tô, người ta gần như không tốn tiền cho xăng, dầu hay bảo dưỡng, nhưng khi hệ thống phát triển thì hạ tầng phụ trợ và chi phí tương ứng cũng đi theo
Đó là một vòng lặp: dùng AI để giải quyết nút thắt hoặc tạo thêm tính năng nhằm tối đa hóa doanh thu, rồi dùng phần doanh thu tăng thêm đó để có thêm tài nguyên CI
AI cũng chẳng khác gì tăng thêm 10 lập trình viên, nên đương nhiên chi phí hỗ trợ sẽ tăng
Đây cũng là góc nhìn nhắc lại xem liệu bạn có thể thuyết phục một cách hợp lý về hiệu suất để xin thêm tài nguyên CI hoặc chỉ ra hướng tối ưu hóa hay không
Tôi cũng tò mò chi phí cho mỗi máy tài nguyên CI là bao nhiêu
Tôi từng tăng tốc CI đáng kể cho ứng dụng Python bằng toolchain của astral.sh cùng với cài đặt gói bằng uv và tận dụng cache
Sắp tới tôi dự định chuyển từ mypy sang type checker của astral, và như vậy có lẽ còn nhanh hơn nữa
Với ứng dụng có frontend thì phần chậm nhất có lẽ là test Playwright, nhưng ngay cả điều đó cũng không đúng với các ứng dụng khác
(Tái bút: nếu đúng là Mike đó, thì tôi nhớ là một SRE từng làm cùng ở Google Maps đầu những năm 2000, nên đây là ý kiến đáng tin)
Khi tôi yêu cầu một mẫu regular expression trong Mercury playground, mô hình đã tự lập kế hoạch, viết pattern rồi bắt đầu sinh test
Nhưng sau đó nó cứ tăng số lượng test vô tận, rồi khi chạm giới hạn ngữ cảnh thì phản hồi bị cắt ngang
Qua khoảng 30 test thì nó bắt đầu gắn sai chú thích kết quả test, và sau hơn 120 test thì chính input của test cũng trở nên kỳ quặc với đầy ký tự ngẫu nhiên
Bản thân pattern cũng không đúng, nhưng hiện tượng “vòng lặp vô hạn” này mới là điểm thú vị hơn
Nhân tiện thì tôi nhớ là cách đây không lâu, các LLM thông thường cũng từng tạo ra kiểu đầu ra lặp lại trông như “gần vô hạn” như vậy
Bị kẹt trong một mẫu mà đầu ra chỉ thay đổi rất nhỏ
Tôi nghĩ đây là bằng chứng tiêu biểu cho thấy “chỉ dự đoán token thì không thể tạo code chính xác”
Đánh giá là LLM vốn không được thiết kế phù hợp cho tư duy về code ngay từ đầu
Sau khi đọc báo cáo kỹ thuật, tôi xác nhận Mercury dựa trên bài báo Lou et al. 2023, SEDD
Có lẽ tôi là người đầu tiên tái hiện SEDD từ đầu, và đây là mã nguồn công khai
Tôi cũng tự triển khai phương pháp denoising phức tạp
Thiết kế sạch hơn và dễ đọc hơn SEDD gốc, và có thể chạy trong vài giờ trên một GPU với bộ dữ liệu đồ chơi
Nhân tiện, DeepMind cũng có mô hình Gemini dựa trên diffusion (link)
Khi tự thử, tôi thấy nó nhanh điên rồ như Mercury, nhưng chất lượng câu trả lời kém hơn khá nhiều so với các Gemini khác
Sau khi dùng thử ngắn gọn, tôi đồng ý rằng tốc độ rất ấn tượng nhưng độ chính xác giảm khá nhiều
Tôi tò mò không biết demo Gemini Diffusion có miễn phí không
Tôi đã nằm trong danh sách chờ mấy ngày rồi nên tiếc là vẫn chưa có cơ hội dùng thử thực tế
Cá nhân tôi rất háo hức với kiểu tiến bộ này
Gần đây trong một game jam, tôi đã dùng AI để code một game đơn giản, và hơn một nửa thời gian là để chờ kết quả
Nếu thay vì mất 1–2 phút cho mỗi prompt mà chỉ cần chờ 10 giây, thì trong lúc trước đây chỉ thử được một lần, giờ có thể thử nghiệm năm đến mười lần
Mercury vẫn chưa đủ trưởng thành để dùng thực tế, nhưng Claude 3.0 một năm trước cũng còn thiếu sót, nên về sau có lẽ sẽ tốt hơn
Đây thật sự là thời điểm khiến tôi rất mong chờ tương lai
Dùng thử Mercury playground thì thấy tốc độ thực sự rất ấn tượng
Phần trực quan hóa diffusion mode cũng mới lạ, nhưng về thực chất có vẻ đang cho thấy quá trình tinh chỉnh dần từ những đường nhiễu được trực quan hóa sang trạng thái ngày càng chính xác hơn
Trong thực tế, có thể xem đó là quá trình hội tụ dần về các token chắc chắn hơn trong một không gian vector ngẫu nhiên
Một số mô hình diffusion cho văn bản dùng latent space liên tục, nhưng hiệu năng không mấy tốt
Gần đây đa số tập trung vào dự đoán đầu ra token thực tế rồi sửa giá trị trước đó qua từng bước để hội tụ về kết quả cuối cùng
Tôi khuyên xem liên kết giải thích cách text diffusion hoạt động mà tôi đã viết
Link: https://chat.inceptionlabs.ai/
Nhanh thật sự vô lý
Phần lớn code sát với GPU vẫn còn rất nhiều dư địa để tối ưu hiệu năng
Nhưng có nghi vấn rằng bài báo trên arXiv mang tính marketing nhiều hơn là nghiên cứu thực sự
Rất hoan nghênh các ý kiến khác
Chính sách giá của mô hình Mercury
1 USD cho mỗi 1 triệu token đầu ra, 0,25 USD cho mỗi 1 triệu token đầu vào
Xem chi tiết giá tại đây
Nếu nhạy cảm về hiệu năng, khi so Mercury với Groq (Llama 3.1 8b, Llama 4 Scout) thì hiệu năng tương tự, nhưng giá của Groq có lợi hơn nhiều
Tôi đang theo dõi với sự quan tâm, hy vọng sẽ có mô hình diffusion mã nguồn mở xuất hiện
Trong code của playground và phản hồi API có xuất hiện
gpt-3.5-turbovà mục"openai": true, nên tôi thắc mắc không biết họ có thực sự gọi OpenAI thay vì dùng dLLM tự xây hay khôngTính năng diffusion effect ở góc trên bên phải có vẻ chỉ là hiệu ứng hoạt họa đơn thuần
Mọi thứ nghe có vẻ rất hay, nhưng
điều khoản quy định rằng khi gửi bài đăng của người dùng lên dịch vụ, bạn cấp cho Inception một giấy phép không độc quyền trên toàn cầu, vĩnh viễn, miễn phí bản quyền, miễn phí sử dụng và có thể chuyển nhượng toàn phần
Nói cách khác, nội dung của người dùng có thể bị dùng để huấn luyện mô hình AI
(Tuy nhiên có điều khoản ngoại lệ là lưu lượng truy cập qua OpenRouter sẽ không bị dùng cho huấn luyện)