# Tối ưu hóa mã nguồn Rust nhanh gấp 2-20 lần nhờ quy trình lặp lại bằng AI Agent

- Nguồn: Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung)
- Thời gian phát hành: 2026-09-23 17:04 (giờ Việt Nam)
- Điểm AI: 72/100
- Link AIHOT.vn: https://aihot.vn/items/06bdd6c86f9719e3
- Nguồn dữ liệu AI HOT: https://aihot.news/items/cmudyft3e0cisrogh4g0ne2ry
- Link gốc: https://minimaxir.com/2026/09/agentic-iteration

## Tóm tắt AI

Tác giả chia sẻ phương pháp sử dụng các AI Agent với bộ quy tắc kiểm soát chặt chẽ để tinh chỉnh mã nguồn Rust, giúp đạt hiệu suất vượt trội so với các tiêu chuẩn hiện tại.

## Thân bài

![Writing Rust code that's faster than state-of-the-art libraries by asking agents to make the code faster](https://minimaxir.com/2026/09/agentic-iteration/featured.webp)

Vào tháng 1 năm 2025, tôi có một giả thuyết thú vị cho [một bài đăng trên blog](https://minimaxir.com/2025/01/write-better-code/): liệu các LLM có thể viết mã tốt hơn nếu bạn liên tục yêu cầu chúng “viết mã tốt hơn” không? Đó là thời điểm trước khi các tác nhân lập trình (agentic coding) mạnh mẽ ra đời, nhưng Claude Sonnet 3.5 vẫn có khả năng cải thiện lặp đi lặp lại mã [Python](https://www.python.org/) thuật toán. Chỉ dẫn “tốt hơn” hóa ra lại không được xác định rõ ràng: Sonnet đã lạm dụng sự mơ hồ đó để thêm vào hàng tá tính năng vô dụng, nhưng mã nguồn thực sự đã chạy nhanh hơn. Ngay cả với sự trỗi dậy của các LLM tác nhân được [RLHF](https://en.wikipedia.org/wiki/Reinforcement_learning_from_human_feedback) chuyên biệt để giải quyết các bài toán lập trình dạng đạt/không đạt thông thường, việc tối ưu hóa nhìn chung vẫn không nằm trong bộ công cụ đó.

Ở cuối bài đăng đó, tôi đã đưa ra nhận định về một tương lai giả định nơi các LLM có thể viết mã Python siêu nhanh bằng cách viết mã [Rust](https://rust-lang.org/) và sử dụng [PyO3](https://github.com/pyo3/pyo3) để kết nối các ngôn ngữ, nhằm đạt được sự tiện dụng của Python với tốc độ của Rust. Một bản thảo trước đó của bài viết khẳng định rằng cùng chỉ dẫn “viết mã tốt hơn” đó có thể được áp dụng cho mã Rust cơ sở và cải thiện đáng kể tốc độ, sau đó lan truyền xuống mã Python: tuy nhiên, hồi đó tôi chưa biết đủ nhiều về Rust và việc đưa ra tuyên bố như vậy sẽ quá táo bạo mà không có bằng chứng.

Sau nhiều tháng thử nghiệm kể từ khi Opus 4.5 ra mắt giúp việc lập trình tác nhân trở nên khả thi hơn, tôi có thể tự tin xác nhận rằng các LLM tác nhân hiện đại thực sự có thể viết mã Rust nhanh hơn đáng kể so với các phương pháp tiên tiến nhất hiện nay nếu được cung cấp các rào chắn và ràng buộc phù hợp. Ngoài ra, vì các LLM đã có những cải tiến vượt bậc về lập trình trong mỗi lần phát hành mô hình tiên phong kể từ Opus 4.5, các tối ưu hóa đã trở nên tốt hơn nữa, tích lũy mang lại tốc độ nhanh hơn từ 2 đến 20 lần tùy thuộc vào lĩnh vực.

Quan trọng hơn, bài đăng này không phải là một bài viết mơ hồ và tôi sẽ bao gồm cả các câu lệnh (prompt) tôi đã sử dụng cùng kết quả kiểm chuẩn (benchmark). Bạn đã được cảnh báo trước rồi đấy.

### “Benchmaxxing” lặp đi lặp lại#

Ban đầu, việc làm cho phần mềm chạy nhanh hơn là một cách định lượng tốt để tôi kiểm tra và so sánh các mô hình tác nhân mới này. Tôi sử dụng Rust làm ngôn ngữ mục tiêu chủ yếu vì khả năng tích hợp với Python và tốc độ, nhưng ngôn ngữ Rust còn có những khía cạnh khác khiến nó đặc biệt hữu ích nếu tìm ra được cách triển khai nhanh, chẳng hạn như tính an toàn bộ nhớ và khả năng biên dịch sang [WebAssembly](https://webassembly.org/)/WASM để có thể chạy trên trình duyệt web mà không tốn nhiều công sức. Tuy nhiên, một ràng buộc quan trọng mà tôi sẽ tuân theo, dù về mặt kỹ thuật có thể không tạo ra mã nhanh nhất, là cấm sử dụng [unsafe code](https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html) bất cứ khi nào có thể.

Trường hợp thử nghiệm đầu tiên của tôi là triển khai lại các thuật toán học máy bằng Rust, điều này sẽ mang lại sự gia tăng năng suất đáng kể cho tôi với tư cách là một nhà khoa học dữ liệu nếu tôi có các công cụ nhanh hơn và có khả năng mở rộng. Vào thời điểm đó, thật ngạo mạn khi cho rằng tôi có thể đánh bại các thuật toán đã được kiểm chứng qua thực tế, vốn đã được lặp đi lặp lại trong hơn một thập kỷ và đã được viết bằng C, nên các lợi ích cấp thấp của Rust không quá rõ rệt. Thuật toán tôi muốn tối ưu hóa nhất là [UMAP](https://umap-learn.readthedocs.io/en/latest/), một thuật toán có giá trị cho việc [giảm chiều dữ liệu](https://en.wikipedia.org/wiki/Dimensionality_reduction) mà tôi đã sử dụng trong công việc của mình, nhưng nó mở rộng kém với dữ liệu lớn và rất chậm, trong khi các giải pháp thay thế như [cuML](https://github.com/NVIDIA/cuml) lại tốn thời gian thiết lập. Các crate Rust cho UMAP như [umap-rs](https://github.com/wilsonzlin/umap-rs) đã tồn tại và tôi có thể chỉ cần fork chúng rồi yêu cầu Claude Opus 4.5 thêm hỗ trợ Python/PyO3, nhưng như một thử nghiệm và trải nghiệm học tập, tôi muốn để tác nhân viết thuật toán từ đầu với các phụ thuộc Rust tối thiểu nhằm thực hiện tối ưu hóa ở cấp độ thấp nhất có thể.

Rust có một công cụ kiểm chuẩn toàn diện với crate [criterion](https://crates.io/crates/criterion) mà tất cả các tác nhân đều biết cách tận dụng. criterion sẽ chạy các bài kiểm chuẩn, theo dõi kết quả qua các lần lặp để xem hiệu suất được cải thiện hay suy giảm, và có thể tính toán xem sự thay đổi này có ý nghĩa thống kê hay chỉ là nhiễu.

![Typical criterion output, depicting a 3.5x speedup relative to the previous run of the benchmark.](https://minimaxir.com/2026/09/agentic-iteration/criterion.png)

Đầu tiên, trong câu lệnh ban đầu để tạo một crate Rust cho UMAP, tôi đã yêu cầu Opus 4.5 tạo các bài kiểm chuẩn với các kích thước dữ liệu đầu vào khác nhau vì các tối ưu hóa cho tập dữ liệu nhỏ có thể không hiệu quả với tập dữ liệu lớn và ngược lại.

```
Afterwards, create and run a benchmark suite which stores the results as a Markdown file. The benchmark suite MUST include inputs up to 100000x768 and be tested in both CPU and GPU modes.
```

Cách tiếp cận này đã tạo ra các bài kiểm chuẩn sử dụng criterion và tôi đã tự tay chạy lại bộ kiểm chuẩn sau khi yêu cầu các cải tiến tính năng hiệu suất như sử dụng [faer](https://crates.io/crates/faer) để tính toán đại số tuyến tính nhanh hơn và sử dụng [simsimd](https://crates.io/crates/simsimd) cho các [phép toán SIMD](https://en.wikipedia.org/wiki/Single_instruction,_multiple_data) nhanh hơn. Việc này nhanh chóng trở nên cồng kềnh vì tôi phải chạy lại thủ công từng bài kiểm chuẩn sau mỗi thay đổi để xác minh rằng không có sự suy giảm tốc độ nào.

Một lưu ý bên lề về phong cách đặt câu lệnh

Cách tôi đặt câu lệnh cho các LLM tác nhân khá bất thường: tôi thường cung cấp cho các tác nhân những câu lệnh rất dài được viết sẵn trong tài liệu Markdown, kết hợp với việc sử dụng CHỮ IN HOA và **in đậm** để nhấn mạnh. Điều này nhằm đảm bảo tôi nắm bắt được tất cả các sắc thái thông qua việc sử dụng [kỹ thuật đặt câu lệnh (prompt engineering)](https://en.wikipedia.org/wiki/Prompt_engineering), cùng với một vài thủ thuật khác như đã nêu chi tiết trong bài đăng này. Mặc dù một số người có thể cho rằng kỹ thuật đặt câu lệnh đã lỗi thời vì các mô hình mới nhất đã đủ thông minh để xử lý chính xác sự mơ hồ, tôi hoàn toàn không đồng ý vì các LLM cũng đã trở nên tốt hơn nhiều trong việc tuân theo các sắc thái đó.

![Running a prompt from a Markdown document (right) by tagging the file (left), using Zed Agent.](https://minimaxir.com/2026/09/agentic-iteration/zed_prompt.png)

Sau khi đủ tự tin rằng tác nhân sẽ không vô tình xóa sạch kho lưu trữ (rm -rf), tôi đã thử nghiệm để tác nhân hoạt động tự chủ, cho phép chúng lặp lại cho đến khi đạt được mức tăng tốc độ, hy vọng là vậy.

```
**YOU MUST KEEP ITERATING OPTIMIZATIONS AND SOLVING ISSUES UNTIL THE BENCHMARK RESULTS STOP IMPROVING AND THE CRATE IS AS FAST AS IT CAN BE**. You have permission to keep iterating until you run out of ideas.
```

Hóa ra “nhanh nhất có thể” lại quá mơ hồ và Opus 4.5 đã lười biếng nên nó chỉ tinh chỉnh một vài siêu tham số mà không thực sự tăng tốc độ bao nhiêu rồi kết thúc công việc. Điều tôi cần là một mục tiêu rõ ràng có thể đạt/không đạt, vì vậy tôi đã tinh chỉnh câu lệnh:

```
First, **without making any futher changes**, run the CPU Rust benchmarks to establish a True Performance Baseline.

Then, optimize the crate code to make it such that ALL CPU benchmarks run **atleast 1.2x faster** than the True Performance Baseline; ideally as fast as possible. NEVER hack the benchmarks to accomplish this runtime reduction, only iterate on the library code.

You may use ANY techniques to do so (e.g. import new crates) other than adding `unsafe` code. **REPEAT THIS PROCESS UNTIL BENCHMARK PERFORMANCE CONVERGES AND YOU ARE OUT OF OPTIMIZATION IDEAS.** You have permission to keep iterating. After each benchmark iteration, report the relative results to the True Performance Baseline to console.

Prioritize making quick/high-impact wins iteratively and making changes accordingly. Do not overthink the necessary changes.
```

Cách này hoạt động rất hiệu quả và tôi không chỉ đạt được tốc độ nhanh hơn 1,2 lần trên các bài kiểm chuẩn, mà tác nhân còn tiếp tục sau khi đạt được ràng buộc chỉ số và chỉ dừng lại nếu ràng buộc chỉ số đó không khả thi; trong trường hợp này, tác nhân đã đạt được mức tăng tốc từ 1,5 đến 2,0 lần. Các tối ưu hóa Rust cấp thấp tập trung vào một số kỹ thuật bao gồm nhưng không giới hạn ở: tận dụng các phép toán SIMD mạnh mẽ hơn, hợp nhất các hàm, mở vòng lặp (loop unrolling), tạo bộ nhớ đệm trung gian, sử dụng [Arc](https://doc.rust-lang.org/std/sync/struct.Arc.html) thay vì mượn (borrowing) bất cứ khi nào có thể, và tạo hồ sơ hiệu suất dựa trên dữ liệu đầu vào (ví dụ: nếu dữ liệu nhỏ, đừng sử dụng tính song song dữ liệu [rayon](https://github.com/rayon-rs/rayon) vì chi phí quản lý sẽ triệt tiêu các lợi ích đạt được).

Tôi chọn “nhanh hơn 1,2 lần” làm bài kiểm tra tính hợp lý: nếu mục tiêu quá cao, tác nhân có thể gian lận để đạt được nó thông qua việc viết lại mã đầy rủi ro hoặc dài dòng. Những thay đổi nhỏ hơn sẽ tốt hơn vì tác nhân có thể dễ dàng cô lập nguyên nhân gây ra sự tăng tốc/suy giảm, đó là lý do tại sao có ghi chú về việc lặp lại. Sau khi các LLM tiên phong mới như GPT-5.3 Codex và Opus 4.6 được phát hành, tôi đã lặp lại câu lệnh này mà không thay đổi cho mỗi LLM mới và mỗi mô hình đều có thể đạt được mức tăng tốc tích lũy từ 1,5 đến 2,0 lần so với lần trước đó. Đi đến tận cùng với GPT-6 Astra trong nhiều tháng, tốc độ nhanh hơn khoảng 7,5 đến 32 lần so với cơ sở triển khai ban đầu.

Cách tiếp cận này đang tối ưu hóa quá mức cho các bộ tiêu chuẩn (benchmarks) nhất định và do đó có thể được coi là [benchmaxxing](https://ctaio.dev/en/labs/benchmaxxing/): một thuật ngữ mang tính miệt thị dành cho các mô hình LLM tiên phong chỉ tập trung vào việc đạt điểm cao trên các bài kiểm tra mà lại kém hiệu quả khi áp dụng vào thực tế. Tuy nhiên, nếu các bộ tiêu chuẩn đủ đa dạng và thực sự đại diện cho các trường hợp sử dụng thực tế, thì đây không phải là vấn đề quá lớn. Đối với loại dự án này, có hai cách để giải quyết lo ngại về benchmaxxing: 1) để tác nhân (agent) thiết kế các tập dữ liệu đầu vào đa dạng/bất thường/đối nghịch thay vì các "đầu vào lên tới 100000x768" chung chung và 2) áp đặt cổng kiểm soát chất lượng (quality gate) lên đầu ra bằng cách so sánh nó với một bản triển khai đúng đã biết. Trong trường hợp các thuật toán học máy, luôn có sự đánh đổi giữa tốc độ và chất lượng, nhưng ở ví dụ này, việc làm cho mô hình chạy nhanh trước rồi mới sửa cho đúng lại dễ dàng đến bất ngờ. Đó không phải là cách làm kỹ thuật khoa học thông thường, nhưng một bản triển khai mới khó có thể sánh ngang với bản triển khai tốt đã biết trên nhiều tiêu chuẩn khác nhau trong một phép so sánh công bằng trừ khi nó thực sự chính xác.

![An agent-optimized gradient boosted decision tree implementation which beats xgboost significantly in speed, but also sometimes quality! (MSE: lower is better; other metrics, higher is better)](https://minimaxir.com/2026/09/agentic-iteration/gbdt.png)

May mắn thay, có một bản triển khai chuẩn của UMAP với gói Python [umap-learn](https://umap-learn.readthedocs.io/en/latest/) và các liên kết Python cho crate Rust đã được thêm vào một cách dễ dàng, vì vậy mục tiêu mới là các ràng buộc đồng thời: cải thiện chất lượng mã nguồn trong khi vẫn giới hạn mức độ giảm tốc độ.

```
Create a Python Jupyter Notebook comparing the performance of the Python bindings with `umap-learn`, including a check to confirm where the outputs and UMAP losses are as similar. Use diverse datasets with different matrix sizes than the benchmarks.

If the outputs are not sufficiently similar, investigate methods to fix it **without causing more than a 5% speed regression**.
```

Quả thực, bản triển khai Rust bằng tác nhân có chất lượng kém hơn, nhưng lời nhắc (prompt) tiếp theo đã thành công và tất cả các chỉ số chất lượng đều được cải thiện gần như tương đương với mức giảm tốc độ tối thiểu. Và crate mới này vẫn nhanh hơn từ 4 đến 15 lần so với umap-learn cùng các liên kết Python của nó, và nhanh hơn từ 2 đến 4 lần so với bản triển khai umap-rs bằng Rust tương đương.

![Results from the most up-to-date optimization pass for the Rust UMAP crate. In addition to faster speed, it matches or beats Python in most quality metrics.](https://minimaxir.com/2026/09/agentic-iteration/umap_final.png)

Sự hội tụ đạt được khi một lượt lặp của tác nhân chỉ mang lại mức tăng tốc độ nhỏ khoảng 3-5%, vốn có thể không có ý nghĩa thống kê trong khi tác nhân lại thêm vào một lượng mã nguồn lớn một cách không tương xứng; sự đánh đổi này là không đáng.

Tôi đã thử nghiệm các thuật toán học máy khác với cùng tiến trình nhắc: cây quyết định tăng cường độ dốc (GBDT), mạng perceptron đa lớp (MLP), mạng đồ thị, nhiều thuật toán điển hình từ [scikit-learn](https://scikit-learn.org/stable/)… và nó đều hoạt động trên tất cả. Tôi không muốn bị quá khớp (overfit) chỉ vào việc tối ưu hóa học máy mặc dù bản thân điều đó đã cực kỳ giá trị, vì vậy tôi đã áp dụng một quy trình tương tự trên các thư viện phần mềm hàng ngày để tối ưu hóa chúng: công cụ tạo mẫu (templating engines), phân tích cú pháp HTML và thậm chí cả máy chủ web… và nó lại hoạt động trên tất cả.

Những tối ưu hóa này không phải là một quá trình đơn giản và bạn không thể chỉ nhắc theo kiểu "cố lên, hãy tạo ra một bước đột phá" để có được mã nguồn tốt hơn vì sự mơ hồ của câu lệnh đó. Tôi không hài lòng với việc chỉ viết phần mềm nhanh nhất: tôi muốn phần mềm phải nhanh nhất có thể, chết tiệt thật. Vì vậy, giống như tác nhân của mình, tôi tiếp tục lặp lại và tìm ra nhiều thủ thuật hơn nữa để kỹ thuật nhắc (prompt engineer) các tác nhân tạo ra những bước đột phá thực sự.

### Nhắc theo ràng buộc thay vì kết quả#

Các dự án đang thực hiện

Tất cả các dự án được giới thiệu trong bài đăng blog này đều đang trong quá trình phát triển tích cực và kết quả có thể không phản ánh các bản phát hành cuối cùng… mặc dù tôi nghi ngờ rằng chúng sẽ còn tốt hơn nữa. 😇

Cần phải nhắc lại rằng các tác nhân có thể và sẽ gian lận nếu chúng có thể. Trong một ví dụ, tôi đã thử nghiệm quy trình lặp tác nhân trên [ballin](https://github.com/minimaxir/ballin)—mô phỏng vật lý bóng 2D của tôi trong terminal—để thay thế công cụ vật lý [rapier2d](https://github.com/dimforge/rapier) của nó vốn đang chạm ngưỡng hiệu suất. Opus 4.5 thực sự đã có thể tăng tốc từng bước vật lý… hơi quá mức cần thiết.

![The numbers indicate the number of balls in the simulation: initially the sim lags at 15k.](https://minimaxir.com/2026/09/agentic-iteration/ballin_speedup.png)

Trong headless_step, mức tăng tốc 34.500 lần và hiệu suất ổn định trên các số lượng bóng đều rất đáng ngờ: khi kiểm tra thủ công, hóa ra Claude đã đạt được tốc độ đó bằng cách vô hiệu hóa hoàn toàn công cụ vật lý. Điều này cũng công bằng, nhưng không lý tưởng; một lời nhắc tiếp theo đã khắc phục được vấn đề và mang lại hiệu suất tổng thể tốt hơn (với các bài kiểm tra hồi quy được thêm vào để đề phòng).

Đối với các thí nghiệm trên, tôi đã sử dụng một tệp AGENTS.md tùy chỉnh dành cho Rust; phiên bản mới nhất của nó [có sẵn tại đây](https://gist.github.com/minimaxir/86de3cc8f628079d8337e70924b3411d). Đáng ngạc nhiên là tôi không cần phải cập nhật các quy tắc cốt lõi kể từ các thí nghiệm tác nhân đầu tiên vào tháng Hai vì các LLM liên tục cải thiện khả năng lập trình và tôi chưa gặp phải vấn đề lớn nào cần phải bổ sung. Tuy nhiên, học hỏi từ các thí nghiệm tiêu chuẩn của mình, tôi đã thêm một phần nữa vào AGENTS.md với một số quy tắc để giảm thiểu các nguồn gian lận quan sát được:

```
## Benchmarking and Optimization

- **NEVER** run benchmarks in parallel, as the benchmarks will compete for resources and the results will be invalid
- **NEVER** game the benchmarks. Do not manipulate the benchmarks themselves to satisfy any required performance constraints
- **NEVER** run benchmarks with `target-cpu=native` or any other `RUSTFLAGS`
- Ensure benchmark tests are independent. If the tests are dependent due to a feature (e.g. caching), ensure the feature is disabled
- **ALWAYS** use `criterion` directly for running benchmarks if available
```

Hãy giải thích từng mục một:

_Bài gốc còn tiếp._ Xem tiếp tại: <https://minimaxir.com/2026/09/agentic-iteration>