Phương pháp của Argusic

Argusic test xem phần mềm thật có chạy được không bằng cách nào, và chấm điểm các AI coding agent ra sao. Mọi quy tắc ở đây được công khai có chủ ý: mục đích chính là để bất kỳ ai cũng kiểm tra được công việc của chúng tôi. Mọi thay đổi với các quy tắc này được ghi vào nhật ký thay đổi ở cuối trang, có hiệu lực từ chu kỳ test kế tiếp, và không bao giờ áp dụng ngược về trước.

1. Tóm tắt

• Chúng tôi lấy các dự án mã nguồn mở thật và để AI agent thử cài đặt, khởi

chạy và gỡ lỗi chúng mà không có người giúp, đúng như một kỹ sư mới làm ngày đầu tiên.

• Mọi lần test đều được ghi lại từ đầu đến cuối. Mọi con số được công bố đều

liên kết tới log và bản ghi terminal của nó.

• Mỗi dự án nhận một kết luận rõ ràng: chạy được, chạy được với dịch vụ giả

lập, hay chúng tôi không xác minh được.

• Các agent được so sánh trong điều kiện giống hệt nhau; mỗi agent chạy ba lần,

kết quả ở giữa được tính, các kết quả chênh lệch quá lớn bị gắn cờ và để riêng.

• Chúng tôi không bán agent nào và không nhận tiền để thay đổi kết quả. Argusic

là trọng tài.

• Việc đo được tự động hóa. Việc viết thì không: không model nào viết một câu

nào trên trang này, mỗi con số trên một trang là một mẫu câu được điền từ một lần chạy có ghi lại, và một người duyệt trước khi bất cứ thứ gì được công bố. Xem cách viết nội dung.

2. Câu hỏi mà phương pháp này trả lời

Với một dự án mã nguồn mở thật, liệu một AI coding agent, hoàn toàn tự mình, có thể cài đặt nó, khởi chạy nó, xử lý các lỗi, và xác minh rằng phần mềm chạy được, như một kỹ sư vào ngày làm việc đầu tiên, mà không có người giúp không?

3. Vì sao dùng dự án mới

Benchmark tĩnh mất giá trị dần khi đáp án của chúng lọt vào dữ liệu huấn luyện. SWE-rebench (Badertdinov và cộng sự, 2025) đã chạy cùng các agent trên SWE-bench Verified và trên các task được thu thập sau khi benchmark đó được công khai, và điểm số chênh nhau rất xa: Bảng 2 của nghiên cứu ghi nhận DeepSeek-V3-0324 giải được 39.7% SWE-bench Verified và 21.3% bộ task được lọc theo thời gian, chênh 18 điểm phần trăm chỉ riêng trên một model. Argusic test các dự án đang thịnh hành trong vài tuần gần nhất, với một nhóm dự án bí mật được luân phiên hằng tháng, nên không có gì để học thuộc.

4. Đo cái gì

Chúng tôi đo đúng một thứ: khả năng tự chủ làm cho phần mềm thật chạy được. Mỗi agent được test là một tổ hợp cố định gồm một model ở phiên bản được ghim, một harness ở phiên bản được ghim, bộ hướng dẫn chuẩn đã công bố của Argusic, và giới hạn thời gian cùng tài nguyên giống hệt nhau. Mọi agent nhận đúng cùng một điều kiện.

5. Các agent được test

Chu kỳ đầu tiên đang diễn ra. Danh sách agent được công bố cùng bảng xếp hạng đầu tiên. Mỗi agent là một cấu hình cố định, được ghim, trình bày dưới một danh tính Argusic trung lập; các phiên bản chính xác của nó được ghi lại và lưu giữ để mọi con số trên bảng truy về đúng cấu hình đã tạo ra nó, và một kết quả có thể được tái lập qua Argusic khi có yêu cầu (xem "Cách tái lập một kết quả").

6. Nhóm dự án

• 80% nhóm công khai: danh sách và phiên bản chính xác (commit hash) được công

bố trước mỗi chu kỳ.

• 20% nhóm bí mật: chọn từ các dự án thịnh hành trong 30 ngày gần nhất, chỉ công

bố sau khi chu kỳ kết thúc, và luân phiên hằng tháng. Đây là thứ ngăn agent bị tinh chỉnh riêng cho bài test.

• Tiêu chí chọn: giấy phép dễ dãi (permissive), có README, đa dạng ngôn ngữ và

độ khó, và có thể chạy ở mức cơ bản mà không cần tài khoản trả phí.

6a. Cái gì có thể là một dự án được test

Một dự án được test là thứ mà một agent có thể được yêu cầu cài đặt và chạy. Hôm nay Argusic test một loại và được xây dựng để thêm các loại khác mà không thay đổi gì trong cách một kết quả đạt được: thang chấm điểm, quy tắc bằng chứng và bộ từ ngữ kết luận giống hệt nhau giữa các nguồn, nên một con số từ nguồn này mang cùng ý nghĩa với một con số từ nguồn khác.

Nguồn	"Chạy được" ở đây nghĩa là gì	Trạng thái
Repo mã nguồn mở	Clone commit được ghim, cài đặt, khởi chạy, và xác minh nó làm đúng việc mà README của chính nó mô tả	Đang dùng. 3669 dự án đã được test
Model trên Hugging Face	Tải model ở một revision được ghim và chạy suy luận đúng như model card của nó mô tả, trên một worker có GPU. Model được tính là chạy được khi đoạn mã mẫu theo tài liệu cho ra kết quả trên một máy sạch mà người test không phải viết lại nó	Đang dùng. 1 dự án đã được test
Hugging Face Space	Build và khởi chạy Space từ định nghĩa của chính nó, rồi mở giao diện của nó và hoàn tất tương tác mà nó quảng cáo	Đã khai báo, chưa bắt đầu
Package đã phát hành (npm, PyPI)	Cài phiên bản được ghim vào một dự án trống và chạy phần quickstart trong README của chính nó	Đã khai báo, chưa bắt đầu
Công cụ của nhà cung cấp	Cài đặt và khởi chạy bản build do chính nhà cung cấp phát hành, chỉ làm theo hướng dẫn của chính nhà cung cấp	Đã khai báo, chưa bắt đầu
Template cloud dựng sẵn	Triển khai template đúng như trang niêm yết của nó mô tả và kiểm tra nó khởi động và phục vụ đúng thứ nó quảng cáo, mà người test không phải vá trước	Đã khai báo, chưa bắt đầu
Container image	Pull image ở một digest được ghim và chạy lệnh mà phần mô tả của chính nó đưa ra, rồi kiểm tra nó làm đúng điều phần mô tả đó khẳng định	Đã khai báo, chưa bắt đầu
MCP server	Cài đặt và khởi động server như tài liệu mô tả, kết nối một client, và xác nhận nó liệt kê và trả lời các tool mà nó quảng cáo	Đã khai báo, chưa bắt đầu

Cột Trạng thái ở trên không được viết tay. Nó được đọc từ cơ sở dữ liệu mỗi lần trang này được phục vụ: một nguồn hiển thị là đang dùng khi một dự án đã công bố thuộc loại đó có một lần chạy được ghi lại, và hiển thị số lượng. Đó cũng là quy tắc mà mọi con số khác trên trang này tuân theo, và nó có nghĩa là không ai phải nhớ cập nhật trang này khi một nguồn mới tạo ra kết quả đầu tiên.

Có hai điều khiến một dự án Hugging Face khác với một repo, và cả hai đều được ghi cùng lần chạy chứ không bị làm mờ đi. Nó cần một worker có GPU, nên chi phí mỗi lần thử cao hơn và ngân sách của nó được quyết định riêng. Và một model card thường mô tả một đoạn mã mẫu chứ không phải một ứng dụng, nên hành vi được xác minh là "đoạn mã mẫu theo tài liệu đã cho ra kết quả", không phải "sản phẩm hoạt động": trang lần chạy nói rõ là trường hợp nào, bằng đúng những từ đó, và điểm số đạt được theo cùng một cách.

Bảng ghi "chưa bắt đầu" thay vì "sắp có" là có chủ ý. Một nguồn được tính là đang dùng vào ngày một lần chạy thật thuộc loại đó được ghi lại cùng bằng chứng, không sớm hơn một ngày. Cho đến lúc đó, dòng đó là một tuyên bố về phạm vi, không bao giờ là về kết quả: không trang nào hiển thị kết luận, số lượng, thứ hạng hay thẻ chia sẻ cho một nguồn chưa chạy, và bảng này là nơi duy nhất một nguồn dự kiến được nêu tên.

7. Một phép đo

1. Một máy sạch, dùng một lần (môi trường chính xác của nó được công bố). Máy

không nhận kết nối từ bên ngoài vào và bị hủy khi lần chạy kết thúc. Truy cập mạng đi ra không bị lọc trong phiên bản này; thứ giới hạn một lần chạy là máy dùng một lần và các quy tắc về model key bên dưới danh sách. Máy chỉ tải về commit được ghim, không tải lịch sử của dự án, vốn không thuộc phạm vi bài test.

2. Agent nhận một nhiệm vụ: làm cho dự án này hoạt động, theo bộ hướng dẫn chuẩn

đã công bố.

3. Một giới hạn thời gian. Mỗi lần chạy nhận một trong đúng ba mức ngân sách

(bảng bên dưới danh sách), và ngân sách mà lần chạy được cấp hiển thị trên trang lần chạy của nó.

4. Ba lần chạy độc lập; kết quả ở giữa được tính. Nếu ba kết quả chênh nhau hơn

30%, bộ kết quả bị gắn cờ không ổn định và để riêng khỏi bảng của chu kỳ đó.

5. Mỗi lần chạy lưu một log đầy đủ và một bản ghi terminal hoàn chỉnh, được công

bố cùng kết quả.

6. Ứng dụng desktop được khởi chạy trên một màn hình ảo bên trong máy (từ

v1.1). "Đã khởi chạy" nghĩa là tiến trình chính của ứng dụng đã khởi động trên màn hình đó và tiếp tục chạy, hoặc đã trả lời một lệnh xem phiên bản hay lệnh trợ giúp. Không có gì được nhấp chuột; thứ được đo là phần mềm có lên được trên một máy mới hay không, cùng câu hỏi đặt ra cho mọi dự án khác. Agent được dặn không gửi hình ảnh cho model của nó (từ v1.3): model chuẩn chỉ nhận văn bản, và một ảnh chụp màn hình đính kèm trong một tin nhắn đã làm phiên kết thúc trước khi có báo cáo.

Các mức ngân sách thời gian của mục 3:

Hạng	Ngân sách
standard	90 phút
heavy	120 phút
gpu	120 phút

Ngân sách standard là 45 phút trước v1.3: trong tuần đầu tiên, 36 trong số 38 lần hết giờ của một ngày là các bản build vẫn đang chạy khi đã dùng hết ngân sách, nên nó được tăng gấp đôi. Hạng heavy có từ v1.2, dành cho dự án được Owner đánh dấu heavy, hoặc có repo lớn hơn 500 MB theo số liệu GitHub báo, vì một trò chơi lớn hay một ứng dụng desktop lớn cần chừng đó thời gian để build. Một dự án cần GPU nhận cùng 120 phút.

Ba con số ở trên không phải để trang trí. scripts/check-ttl-methodology.sh đọc bảng này và so sánh với các ngân sách mà orchestrator thực sự được cấu hình, và make test thất bại nếu chúng không khớp. Phép kiểm tra đó tồn tại vì từ 2026-09-06 đến 2026-09-11 ngân sách GPU trong hệ thống đang chạy là 240 phút trong khi trang này ghi 120, và không có gì so sánh hai con số đó (ISSUE-072).

Model key. Một agent cần một key để gọi model của nó, và một lần chạy thực thi mã từ một dự án không đáng tin cậy, nên key đó là thông tin xác thực đáng giới hạn nhất. Với các agent gọi model qua lớp định tuyến của Argusic, mỗi lần chạy nhận một key riêng, được tạo chỉ cho lần chạy đó. Mức chi tối đa cho model key của mỗi lần chạy: 3 USD. Key bị xóa khi lần chạy kết thúc, bị hủy hoặc hết giờ, và một tác vụ quét định kỳ xóa mọi key không còn thuộc về một job đang chạy. Nếu không tạo được key cho một lần chạy, lần chạy đó không được bắt đầu và sẽ được thử lại; không bao giờ dùng một key chung để thay thế. Các agent dùng dịch vụ riêng của hãng làm ra model gọi dịch vụ đó bằng một key chung do Argusic giữ, không phải key riêng cho từng lần chạy; chuyển chúng sang key riêng cho từng lần chạy nằm trong backlog của chúng tôi. Dòng mức chi ở trên được đọc bởi scripts/check-cost-methodology.sh, script này làm make test thất bại nếu nó không khớp với giá trị đã cấu hình, cùng lý do như các ngân sách thời gian.

8. Chấm điểm, trên thang 100

• Cài đặt thành công: 30
• Khởi chạy hoặc test thành công: 30
• Khắc phục lỗi: 20, theo tỷ lệ các lỗi gặp phải đã được sửa hợp lệ
• Độ sâu xác minh: 20 (xác minh chạy thật: 20; xác minh với dịch vụ giả lập: 12;

không xác minh: 0)

Kết quả của một lần chạy là một trong các giá trị sau:

Kết quả	Ý nghĩa
pass_full	Đã chạy và được xác minh thật
pass_mock	Đã chạy, xác minh với dịch vụ giả lập
fail	Không cài đặt được hoặc không khởi chạy được
timeout	Hết thời gian

Bốn dòng chấm điểm để ngỏ một số trường hợp. Chúng được quy định rõ ở đây chứ không chỉ trong mã nguồn, vì một quy tắc không ai đọc được là một quy tắc không ai kiểm tra được. Chấm điểm là một chương trình tất định có test bao phủ mọi quy tắc bên dưới; không AI model nào tham gia chấm điểm ở bất kỳ thời điểm nào.

• Nếu không có gì trục trặc, khắc phục lỗi được trọn 20 điểm. Cho 0 điểm sẽ phạt

một agent chỉ vì dự án tình cờ cài đặt suôn sẻ, tức là đo dự án chứ không phải đo agent.

• Ngược lại, khắc phục lỗi là tỷ lệ các lỗi gặp phải đã được sửa, trên 20 điểm.

Một lần chạy không bao giờ được khai số lỗi đã sửa nhiều hơn số lỗi gặp phải; lần chạy như vậy bị loại.

• Khởi chạy đòi hỏi đã cài đặt: một agent không cài đặt được phần mềm thì không

thể đã khởi chạy nó.

• Độ sâu xác minh đòi hỏi đã khởi chạy: không khởi chạy thành công thì không có

gì để xác minh, nên độ sâu được 0 điểm.

• Đã cài đặt và khởi chạy nhưng chưa xác minh thì không phải là đạt. Trường hợp

này được 80 trên 100 điểm và vẫn tính là không đạt, vì câu hỏi là agent có xác minh được phần mềm chạy hay không, và một lần khởi chạy chưa xác minh không trả lời câu hỏi đó.

• Một lần hết giờ được 0 điểm ở mọi dòng. Đó không phải là điểm một phần: agent

đã không hoàn thành trong cùng giới hạn mà mọi agent khác có.

• Một lần chạy không có log và bản ghi đầy đủ là không hợp lệ và được chạy lại.

Nó không bao giờ được chấm điểm và không bao giờ lên bảng.

9. Từ nhiều lần chạy thành một điểm trên bảng

Chấm điểm đánh giá một cặp dự án và agent. Bảng xếp hạng cần một con số duy nhất cho mỗi agent, và cách kết hợp các điểm đó là một lựa chọn phương pháp, nên nó được nêu ở đây.

Điểm trên bảng của một agent là giá trị ở giữa của các điểm ở giữa theo từng dự án của nó. Chúng tôi lại dùng giá trị ở giữa, thay vì trung bình cộng, vì cùng một lý do: một dự án thảm họa không nên kéo một agent có năng lực xuống, và một dự án may mắn không nên đẩy một agent yếu lên.

Hai loại kết quả bị loại khỏi con số đó, và cả hai vẫn hiển thị trên bảng để việc loại trừ được nhìn thấy, không âm thầm: các kết quả bị gắn cờ không ổn định (xem mục tiếp theo), và mọi kết quả trên một dự án bị gắn cờ đang xem xét (xem kiểm soát chất lượng môi trường).

Một agent có toàn bộ kết quả bị loại thì không có điểm trên bảng. Nó được hiển thị ở cuối bảng, không có điểm, chứ không bị gỡ đi, vì một agent đã được test mà không tạo ra được gì dùng được thì bản thân điều đó là một kết quả, và giấu nó đi sẽ âm thầm tô đẹp cho cả nhóm.

Tỷ lệ đạt tính mọi lần thử của một agent trong chu kỳ, kể cả các lần không đạt và hết giờ. Xem phần độc lập và không chọn lọc kết quả bên dưới.

10. Độ chênh và tính không ổn định

Độ chênh là khoảng cách giữa ba lần chạy tính theo phần trăm của giá trị ở giữa:

spread = (highest - lowest) / middle * 100

Một bộ kết quả bị gắn cờ không ổn định khi độ chênh lớn hơn hẳn 30%. Đúng 30% không phải là hơn 30% và vẫn ở trên bảng. Từ công thức suy ra hai trường hợp biên:

• Nếu giá trị ở giữa là 0 nhưng có lần chạy được trên 0 điểm, độ chênh là vô hạn

và bộ kết quả không ổn định: một kết quả xuất hiện một lần và không xuất hiện ở hai lần kia là kết quả khó tái lập nhất có thể.

• Nếu cả ba lần chạy đều được 0 điểm, công thức chia cho 0 và không có giá trị,

nên độ chênh được định nghĩa là 0 theo quy tắc này và bộ kết quả ổn định. Thất bại nhất quán là một phép đo tái lập được và thuộc về bảng với tư cách đó.

11. Kết luận về dự án

Bảng xếp hạng các agent. Kết luận trả lời một câu hỏi khác, về chính dự án: một người mới, dưới dạng một AI agent, có thể làm cho phần mềm này chạy hôm nay không?

Việc test mang tính thích ứng, vì bằng chứng chỉ có giá trị một chiều. Một lần đạt chứng minh dự án chạy được; một lần thất bại tự nó không chứng minh gì, vì lỗi có thể thuộc về agent chứ không phải dự án.

1. Đầu tiên, agent chuẩn chạy một lần. Bất kỳ lần đạt nào cũng kết thúc quá

trình: đạt trọn vẹn cho kết luận "chạy được", đạt với dịch vụ giả lập cho kết luận "chạy được với dịch vụ giả lập". Không có lý do gì để tiếp tục test thứ đã được chứng minh là chạy được.

2. Nếu thất bại, một lần thử lại trên cùng agent loại trừ một sự cố ngẫu nhiên.
3. Nếu vẫn thất bại, kết luận là "không xác minh được", không bao giờ là "hỏng":

Argusic báo cáo những gì agent làm được, và nói đúng như vậy (từ v1.3: hai lần thử hoàn chỉnh trên agent chuẩn là đủ để kết luận). Một agent mạnh hơn có thể được chạy khi có yêu cầu; khi đó, nếu nó đạt thì dự án là "chạy được" (hồ sơ ghi rõ agent nào đã xác minh), và nếu nó thất bại thì kết luận cũng là "không xác minh được".

Một lần thử hoàn chỉnh là lần mà bản ghi cho thấy agent làm việc đến điểm kết thúc của chính nó hoặc đến giới hạn thời gian. Một lần thử bị chính công cụ của Argusic cắt ngang (một harness không đọc được báo cáo của agent, một lỗi công cụ không liên quan đến dự án) bị đánh dấu không hợp lệ kèm lý do được lưu trên lần chạy, vẫn được công bố cùng bằng chứng, và không được tính.

Kết luận là kết quả tốt nhất mà bất kỳ lần thử nào đạt được:

• chạy được: có lần thử đã chạy và được xác minh thật.
• chạy được với dịch vụ giả lập: lần thử tốt nhất đã chạy, xác minh với dịch

vụ giả lập, thường vì dự án cần thông tin xác thực thật của bên thứ ba.

• không xác minh được: không có lần đạt nào sau hai lần thử hoàn chỉnh (hoặc

sau agent mạnh hơn, khi có chạy). Trang nói rõ điều đó và liên kết tới log cho thấy mỗi lần thử dừng ở đâu.

• chưa xác minh: việc test chưa xong.

Mọi lần thử đều được công bố cùng đầy đủ bằng chứng, dù kết luận là gì, với một ngoại lệ: một bản ghi không chứng minh được là sạch thông tin xác thực đang dùng sẽ bị giữ lại và lần chạy đó được chạy lại (mục 17, "Che thông tin bảo mật").

12. Những gì Argusic không đo

Để tránh hiểu sai, chúng tôi nói thẳng điều này. Argusic không đo chất lượng dài hạn của mã mà một agent viết, độ an toàn của các bản sửa lỗi của nó, hay trải nghiệm sản phẩm chuyên sâu ở mức tính năng. Argusic đo một thứ: khả năng tự chủ làm cho phần mềm thật chạy được.

13. Độc lập và không chọn lọc kết quả

• Argusic không nhận tiền để thay đổi phương pháp, cách chấm điểm hay thứ hạng.
• Tài trợ tài nguyên tính toán, nếu có, chỉ mua đúng một thứ: model của nhà tài

trợ được thêm vào danh sách test với điều kiện giống hệt mọi agent khác, và khoản tài trợ được công khai ngay cạnh kết quả.

• Mọi lần chạy của mọi agent đều được tính và được công bố. Không có chuyện test

kín rồi chỉ công bố kết quả tốt nhất. Nếu một agent có trên bảng, mọi lần thử của nó trong chu kỳ đều có trong hồ sơ.

14. Công khai harness

Harness (phần khung, công cụ, hướng dẫn và giới hạn bao quanh model) được công khai và giống hệt nhau cho mọi agent trong một chu kỳ. Mọi khác biệt về điểm số phải quy được cho agent, không phải cho phần hạ tầng. Thay đổi harness chỉ được đưa vào giữa các chu kỳ và được ghi vào nhật ký thay đổi.

15. Kiểm soát chất lượng môi trường

Khi một dự án thất bại với mọi agent, nó tự động bị gắn cờ đang xem xét và bị loại khỏi việc chấm điểm cho đến khi có người kiểm tra: lỗi có thể thuộc về môi trường hoặc dự án chứ không phải các agent. Một vấn đề thiết lập chung không bao giờ được tính là thất bại của một agent.

16. Xác minh nghĩa là giải mã, không phải thăm dò

Một file tồn tại không phải là một kết quả, và đọc phần header của nó không phải là một phép kiểm tra. ffprobe -show_streams, file và một con số đếm byte đều báo về một container và không giải mã gì: một video mà mọi khung hình đều màu xanh lá vượt qua cả ba y hệt một video tốt. Quy tắc, có hiệu lực từ v1.4, là agent báo cáo những gì nó đã giải mã, không bao giờ báo cáo những gì nó mong đợi.

• Giải mã thứ bạn đã tạo ra. ffmpeg -v error -i FILE -f null - cho video và

âm thanh, một bộ giải mã thật cho hình ảnh, in ra với văn bản. Báo cáo lệnh và kết quả lệnh đó trả về.

• Không bao giờ khẳng định điều bạn không quan sát được. Prompt bạn đưa cho

một model không phải bằng chứng về thứ đã được tạo ra; điều một README hứa hẹn không phải bằng chứng rằng nó đã xảy ra ở đây. "81 khung hình được giải mã không có lỗi" là một phát hiện. "Một video về hai con mèo" thì không.

• Giải mã là thứ giúp đạt độ sâu xác minh cao nhất. test_depth là trường

ghi lại lần chạy đã đi được bao xa (mục 8: tier1_real là "xác minh chạy thật" và được 20 điểm, tier2_mock là "xác minh với dịch vụ giả lập" và được 12 điểm, tier3_none là "không xác minh" và được 0 điểm). tier1_real đòi hỏi một lần giải mã thành công, không phải khả năng mô tả một đầu ra.

• verified_how mang bằng chứng. Đó là trường báo cáo chứa đúng lệnh mà agent

đã chạy để xác minh đầu ra của chính nó và kết quả lệnh đó trả về. "not verified" là một câu trả lời được chấp nhận và hữu ích.

• final_state là câu kết của chính agent về những gì đã xảy ra, và nó được

công bố nguyên văn trên trang lần chạy và trang dự án, nên mọi dữ kiện trong đó phải là điều agent đã quan sát bằng chính các lệnh của nó.

17. Tính toàn vẹn của bằng chứng

Hai lớp, không bao giờ lẫn lộn.

Lớp bằng chứng là dữ liệu thô và vĩnh viễn: mỗi lần chạy tạo ra một bản ghi terminal đầy đủ của phiên làm việc thật, và với ứng dụng đồ họa thì có thêm một video thô của phiên, cùng với log đầy đủ. Mỗi file được lấy dấu vân tay khi đến và lưu vĩnh viễn. Bất kỳ ai cũng có thể phát lại toàn bộ phiên chưa qua chỉnh sửa.

Lớp trình bày là dữ liệu dẫn xuất: mọi video hay hình ảnh trên mạng xã hội đều là bản dựng từ bằng chứng. Các chỉnh sửa được phép là tăng tốc, cắt bớt cho vừa độ dài, chú thích lấy từ dòng thời gian lỗi và sửa lỗi đã ghi lại, và lồng tiếng. Các chỉnh sửa bị cấm là sắp xếp lại thứ tự sự kiện, ghép các phiên riêng biệt lại với nhau, che giấu thất bại, hoặc thay đổi nội dung thực chất của những gì agent đã làm. Mọi video được công bố đều liên kết ngược về bằng chứng của nó.

Ba phép biến đổi dẫn xuất được áp dụng cho bản ghi trước khi phục vụ, và không phép nào thay đổi nội dung thực chất công việc của agent:

• Che thông tin bảo mật. Giá trị thông tin xác thực đang dùng được xóa đi.

Không có gì ngăn một repo không đáng tin cậy dụ agent in ra biến môi trường, nơi chứa key duy nhất mà agent cần, nên mọi giá trị trông giống bí mật đều được xóa sạch trước khi bản ghi được lưu hoặc phục vụ. Một bản ghi không chứng minh được là sạch thông tin xác thực sẽ bị giữ lại, và lần chạy đó được chạy lại.

• Khóa do dự án sinh ra. Một số dự án sinh khóa như chức năng của chúng (một

trình quản lý mật khẩu, một công cụ PKI), và agent có thể chạy chúng rồi in kết quả ra. Đó là đầu ra test thật, không phải thông tin xác thực của Argusic, nên nó không làm lần chạy bị giữ lại: bản sao được phục vụ của bản ghi và log có phần thân của mọi khóa riêng tư như vậy được che đi, file thô được lưu trữ với dấu vân tay riêng ghi trên lần chạy, và trang lần chạy nói rõ việc che đã được áp dụng. Một phần thân không chứng minh được là đã che vẫn làm lần chạy bị giữ lại (từ v1.2, quyết định của Owner ngày 2026-09-05).

• Thương hiệu agent trung lập. Bản ghi được trình bày bằng giọng của Argusic

Agent: banner khởi động riêng của công cụ bên dưới (vốn nêu tên nhà cung cấp, bên cung cấp dịch vụ và model) bị ẩn đi, giống như cách một giao diện định dạng thay thế đầu ra thô của máy. Việc này không bao giờ sửa các lệnh agent đã chạy hay các thay đổi nó đã làm; những thứ đó xuất hiện đầy đủ. Nó cũng không kiểm duyệt các từ ngữ của nhà cung cấp xuất hiện tự nhiên trong đường dẫn file, tên package hay mã nguồn của chính repo, vì chúng là một phần của công việc thật.

Một phép biến đổi hiển thị áp dụng cho văn bản được trích dẫn (quyết định của Owner ngày 2026-09-04): khi một trang hiển thị câu kết của chính agent ("What the test found") hoặc phần mô tả GitHub của một repo, dấu gạch ngang mà tác giả gõ được hiển thị thành dấu phẩy hoặc dấu chấm để trang theo đúng quy tắc chấm câu của chúng tôi. Báo cáo đã lưu, hồ sơ repo, log, bản ghi và các hình ảnh dựng từ bản ghi đều không bị đụng tới; các từ và thứ tự của chúng không bao giờ thay đổi.

Quy tắc cố định: mọi con số đều truy về một log, và mọi khung hình đều truy về một bản ghi của phiên làm việc thật.

18. Cách tái lập một kết quả

Phía dự án của mọi kết quả đều hoàn toàn công khai: đúng commit đã được test, môi trường đã công bố, bộ hướng dẫn chuẩn, cùng log và bản ghi đầy đủ. Trang của mỗi lần chạy có tất cả những thứ này. Agent là một cấu hình Argusic cố định, được ghim, dưới một danh tính trung lập; Argusic giữ các phiên bản chính xác của nó và có thể chạy lại một kết quả để tái lập. Danh sách dự án công khai và phần công bố nhóm bí mật được công bố cùng bảng xếp hạng đầu tiên.

19. Khiếu nại một kết quả

Nếu một người duy trì dự án hoặc một phòng lab cho rằng một kết quả sai, họ có thể khiếu nại. Hãy viết tới [email protected] kèm liên kết lần chạy. Chúng tôi xem lại toàn bộ log và bản ghi đối chiếu với khiếu nại và trả lời. Nếu kết quả bị ảnh hưởng bởi một vấn đề môi trường hoặc thiết lập từ phía chúng tôi, chúng tôi chạy lại và sửa hồ sơ kèm một ghi chú; nếu bằng chứng ủng hộ kết quả ban đầu, chúng tôi giải thích bản ghi cho thấy điều gì. Bằng chứng gốc không bao giờ bị sửa hay bị gỡ.

20. Nhật ký thay đổi

Mỗi phiên bản có hai ngày và chúng trả lời hai câu hỏi khác nhau. Ngày ghi là ngày quy tắc được ghi vào tài liệu này. Có hiệu lực từ là ngày lần chạy đầu tiên thực sự được đo theo quy tắc đó, đọc từ hồ sơ các lần chạy, không phải từ file này. Hai ngày thường trùng nhau. Khi không trùng, hồ sơ các lần chạy được ưu tiên và được ghi ở đây, vì một phiên bản đến được máy trước khi đến được trang này chính là điều mà một nhật ký thay đổi tồn tại để công khai. Không phiên bản nào được áp dụng ngược về trước: một lần chạy giữ các quy tắc có hiệu lực vào ngày nó chạy.

Các phiên bản từ v0.2 đến v1.0 đều được ghi vào ngày 2026-08-31, trong commit tạo ra phiên bản công khai đầu tiên; các ngày bên dưới của chúng là những ngày chính các quy tắc đó được quyết định, trước phép đo đầu tiên.

• v0.2 (2026-08-29): nêu rõ các trường hợp mà thang chấm điểm để ngỏ (khắc phục lỗi

khi không có lỗi nào, sự phụ thuộc giữa cài đặt và khởi chạy, hết giờ, lần chạy không hợp lệ) và công thức độ chênh chính xác cùng hai trường hợp biên. Được viết trước phép đo đầu tiên, nên không có gì bị áp dụng ngược.

• v0.3 (2026-08-30): nêu rõ cách các kết quả theo từng dự án kết hợp thành một con

số trên bảng (giá trị ở giữa của các giá trị ở giữa theo từng dự án), kết quả nào bị loại, và rằng một agent không có gì chấm điểm được sẽ được hiển thị không có điểm chứ không bị gỡ đi.

• v0.4 (2026-08-30): thêm kết luận về dự án (test thích ứng: agent chuẩn, một lần

thử lại, rồi một agent mạnh hơn, dừng ở lần đạt đầu tiên). Cách chấm điểm trên bảng không đổi.

• v1.0 (có hiệu lực từ 2026-08-31, ghi ngày 2026-08-31): phiên bản công khai đầu

tiên. Không quy tắc nào thay đổi so với v0.4; phiên bản này sắp xếp lại tài liệu, định nghĩa thuật ngữ bằng ngôn ngữ dễ hiểu, và thêm các mục tái lập và khiếu nại.

• v1.1 (có hiệu lực từ 2026-09-04, ghi ngày 2026-09-04): ứng dụng desktop được khởi

chạy trên một màn hình ảo bên trong máy test (mục 7, ý 6), nhờ đó các dự án có giao diện đồ họa có thể được đo. Image của máy cũng được bổ sung các runtime desktop phổ biến và công cụ build native; digest của image được ghi trên mọi lần chạy, nên phân biệt được kết quả trước và sau. Cách chấm điểm không đổi.

• v1.2 (có hiệu lực từ 2026-09-04, ghi ngày 2026-09-05): hạng heavy (mục 7, ý 3):

dự án lớn được 120 phút trên cùng loại máy, quyết định bởi dấu của Owner hoặc kích thước repo 500 MB, và ngân sách được hiển thị trên trang lần chạy. Máy chỉ tải commit được ghim. Mục 17 có thêm phép biến đổi khóa do dự án sinh ra. Cách chấm điểm không đổi. Phiên bản này lúc đầu được ghi ở đây là có hiệu lực từ 2026-09-05; hồ sơ các lần chạy cho thấy ba dự án heavy (cataclysm-dda, veloren, supertux) đã được đo với ngân sách 120 phút vào ngày 2026-09-04, nên ngày sớm hơn là ngày được ghi ở trên.

• v1.3 (có hiệu lực từ 2026-09-05, ghi ngày 2026-09-05): kết luận được chốt sau hai

lần thử hoàn chỉnh trên agent chuẩn (mục 11); agent mạnh hơn không còn là một phần của chuỗi chuẩn. Các lần thử bị chính công cụ của Argusic cắt ngang là không hợp lệ và không được tính (92 lần chạy như vậy từ 2026-08-30 đến 2026-09-05 đã được đánh dấu, kèm lý do trên từng lần chạy). Giới hạn thời gian standard 90 phút (mục 7, ý 3); không gửi hình ảnh cho model (ý 6). Cách chấm điểm không đổi.

• v1.4 (có hiệu lực từ 2026-09-07, ghi ngày 2026-09-07): xác minh nghĩa là giải mã,

không phải thăm dò (mục 16). Agent phải giải mã thứ nó tạo ra và báo cáo lệnh đã dùng, không bao giờ được khẳng định bất cứ điều gì nó không quan sát được, và chỉ đạt tier1_real khi giải mã thành công. Một trường báo cáo mới, verified_how, mang lệnh đó và kết quả của nó, và "not verified" là một câu trả lời được chấp nhận. Các lần chạy đầu tiên có verified_how được ghi lại vào ngày 2026-09-07. Cách chấm điểm không đổi. Phiên bản này đến từ một độc giả, không phải từ chúng tôi. Một người xem một reel đã công bố hỏi liệu chúng tôi đã gặp các lỗi kiểu MP4 hợp lệ nhưng khung hình hỏng chưa, và session cast cho thấy agent đã chạy đúng phép kiểm tra header vốn không thể phát hiện lỗi đó. Một nửa câu báo cáo của nó kiểm chứng được (codec, kích thước, số khung hình, thời lượng, tất cả đọc từ header) và một nửa thì không: phần mô tả nội dung video thực ra là prompt của model card, được nói lại như một quan sát. Câu đó đã được công bố nguyên văn trong một reel, một chú thích và một trang dự án (ISSUE-056).

• v1.5 (có hiệu lực từ 2026-10-08, ghi ngày 2026-10-08): sửa phần mô tả mạng và model

key của máy test trong mục 7 cho khớp với hệ thống như đã xây dựng, và sửa cách đánh số danh sách của mục đó bằng cách chuyển bảng ngân sách thời gian xuống sau danh sách (nên "mục 7, ý 6" trong v1.1 và v1.3 lại là ý 6). Trước phiên bản này, mục 7 ghi rằng máy có "mạng bị hạn chế"; lưu lượng đi ra từ máy không hề bị lọc, và phiên bản này nói rõ điều đó. Phiên bản này cũng nêu model key riêng cho từng lần chạy, mức chi tối đa 3 USD của nó và việc xóa nó, gồm cả việc các lần chạy bị hủy và các lần dừng khẩn cấp giờ cũng xóa key (trước 2026-10-08 thì không), và rằng các agent dùng dịch vụ riêng của hãng làm ra model dùng một key chung. Đây là một bản sửa phần mô tả, không phải thay đổi bất kỳ quy tắc chấm điểm hay quy tắc đo nào: không lần chạy trước nào bị gắn nhãn lại, không có gì được đo theo một quy tắc khác, và phiên bản này không áp dụng ngược. Cách chấm điểm không đổi.

Phụ lục: ước tính phần cứng, model nào vừa và chạy nhanh đến đâu

Các ước tính bên dưới được in bên cạnh các laptop và máy để bàn cho lập trình, AI và khoa học dữ liệu mà Argusic liệt kê.

Phụ lục này không thuộc các quy tắc benchmark ở trên và không thay đổi phiên bản nào: nó giải thích các ước tính mà Argusic in bên cạnh các laptop và máy để bàn được liệt kê để bán, vốn là phép tính số học trên số liệu do nhà sản xuất công bố, không bao giờ là phép đo. Các con số ở đây được tính bởi một file dùng chung (lib/hardware-estimates.ts), và không con số nào được thay đổi nếu file đó và test của nó không thay đổi trong cùng một commit.

Danh sách phần cứng của Argusic hiển thị, cho mỗi laptop và máy để bàn, kích thước model lớn nhất mà máy có thể chứa và một giới hạn trên cho tốc độ sinh văn bản. Cả hai đều là Ước tính: chúng được tính từ thông số kỹ thuật do nhà sản xuất công bố bằng các công thức bên dưới. Argusic chưa chạy model nào trên các máy này. Khi Argusic thực sự đo một máy, con số đó mang nhãn Đã đo, liên kết tới log của lần chạy, và không bao giờ bị trộn lẫn với một ước tính.

Một ước tính chỉ được hiển thị khi mọi đầu vào đều đã biết. Nếu thiếu dung lượng bộ nhớ, loại bộ nhớ hoặc băng thông của chip, trang ghi "Không rõ" thay vì đoán.

Đầu vào và nguồn gốc

• Bộ nhớ cho model: bộ nhớ mà một model có thể nằm trong đó. Với máy có GPU rời, đó là VRAM của GPU. Với Apple silicon, AMD Ryzen AI Max và NVIDIA GB10, đó là bộ nhớ hợp nhất dùng chung cho CPU và GPU. Đọc từ trang sản phẩm.
• Băng thông bộ nhớ: đọc từ trang thông số kỹ thuật hoặc datasheet của chính hãng làm chip hay GPU (Apple, NVIDIA, AMD), một dòng tham chiếu cho mỗi chip, mỗi dòng kèm liên kết tới trang nguồn. Một chip mà hãng không công bố băng thông thì không có băng thông trên trang. Argusic không tính băng thông từ độ rộng bus và tốc độ bộ nhớ, và không chép nó từ cơ sở dữ liệu của bên thứ ba.
• Kích thước model: số tham số, theo năm hạng kích thước của bộ lọc: 7-8B, 14B, 27-32B, 70B, 120B trở lên. Mỗi hạng được kiểm tra ở kích thước lớn nhất của nó (8B, 14B, 32B, 70B, 120B), nên vừa ở mức đó nghĩa là vừa cho cả hạng.

Bộ nhớ: model kích thước nào vừa

Một model cần chỗ cho ba thứ.

1. Trọng số. Argusic giả định lượng tử hóa Q4_K_M của llama.cpp, ở mức 4.8944 bit mỗi trọng số (README quantize của llama.cpp):

số byte trọng số = số tham số x 4.8944 / 8. Ví dụ, được tính chứ không phải đo: một model 70B cần 42.8 GB trọng số.

2. Ngữ cảnh (KV cache). Theo công thức của NVIDIA (Mastering LLM Techniques: Inference Optimization, NVIDIA Technical Blog, 2023-11-17):

số byte KV cache mỗi token = 2 x số lớp x (số head x kích thước head) x số byte mỗi giá trị. Các model hiện đại dùng chung head key/value giữa các attention head (grouped-query attention), nên "số head" ở đây là số head key/value mà model thực sự lưu cache. Argusic cho phép 8192 token ngữ cảnh ở độ chính xác 16-bit (2 byte, kiểu cache mặc định của llama.cpp), dùng cấu hình đã công bố của một model dense mở cho mỗi hạng: Qwen3-8B, Qwen3-14B, Qwen3-32B, Qwen2.5-72B-Instruct và Mistral-Large-Instruct-2411.

3. Chi phí phụ của runtime. Argusic dành 1 GB cho bộ đệm riêng của runtime suy luận.

Ngữ cảnh 8192 token và chi phí phụ 1 GB là mức Argusic dành ra, một lựa chọn chính sách chứ không phải một phép đo. Ngữ cảnh dài hơn cần nhiều bộ nhớ hơn; một model vừa ở đây có thể không vừa với một cuộc hội thoại dài hơn nhiều.

Bao nhiêu bộ nhớ của máy được tính. Toàn bộ VRAM của GPU rời được tính. Với bộ nhớ hợp nhất hoặc bộ nhớ hệ thống, Argusic tính 75% và chừa 25% cho hệ điều hành và các chương trình khác. Điều này khớp với những gì AMD nêu cho các chip bộ nhớ hợp nhất của chính họ: tối đa 96GB trong 128GB có thể chuyển thành VRAM (AMD), và 64GB cho phép tối đa 48GB (AMD).

Dung lượng bộ nhớ được đọc theo 10^9 byte mỗi GB, cùng đơn vị mà các hãng dùng cho băng thông. Bộ nhớ thực tế được tính theo đơn vị nhị phân, nên cách này ghi thấp dung lượng khoảng 7% và khiến mọi phép tính vừa hay không đều hơi thận trọng.

Yêu cầu tương ứng cho mỗi hạng, tính từ các quy tắc ở trên:

Hạng	Trọng số (Q4_K_M)	Phần dành cho ngữ cảnh	Chi phí phụ	Cần	VRAM từ	Bộ nhớ hợp nhất từ
7-8B	4.89 GB	1.21 GB	1 GB	7.10 GB	7.10 GB	9.47 GB
14B	8.57 GB	1.34 GB	1 GB	10.91 GB	10.91 GB	14.54 GB
27-32B	19.58 GB	2.15 GB	1 GB	22.73 GB	22.73 GB	30.30 GB
70B	42.83 GB	2.68 GB	1 GB	46.51 GB	46.51 GB	62.01 GB
120B trở lên	73.42 GB	2.95 GB	1 GB	77.37 GB	77.37 GB	103.16 GB

Ví dụ, một GPU 8GB chứa được hạng 7-8B, một GPU 24GB chứa được hạng 27-32B, và 64GB bộ nhớ hợp nhất chứa được hạng 70B. Một máy dưới dòng đầu tiên được hiển thị là không vừa hạng nào.

Tốc độ: một giới hạn trên, không phải một dự đoán

Sinh mỗi token đòi hỏi đọc mọi trọng số của model từ bộ nhớ một lần, nên việc sinh văn bản bị giới hạn bởi băng thông bộ nhớ (NVIDIA: "Model execution is frequently memory-bandwidth bound"). Điều đó cho ra một mức trần:

số token mỗi giây, tối đa = băng thông bộ nhớ / số byte trọng số.

Ví dụ, được tính chứ không phải đo: một chip có 546 GB/s chạy một model 8B ở Q4_K_M (4.89 GB trọng số) không thể vượt quá khoảng 111 token mỗi giây.

Tốc độ thực tế luôn thấp hơn. Giới hạn này bỏ qua thời gian đọc ngữ cảnh, tính toán và chi phí phụ của phần mềm. Các phép đo được tổng hợp trong thảo luận #4167 của llama.cpp cho thấy tốc độ tăng theo băng thông nhưng thấp hơn mức tuyến tính. Với Llama 2 7B ở Q4_0 trên Apple silicon: M3 Max (400 GB/s) 66.31 token mỗi giây, M4 Max (546 GB/s) 83.06, M2 Ultra (800 GB/s) 94.27. Đi từ 400 lên 546 GB/s (1.37 lần băng thông) cho 1.25 lần tốc độ; tăng gấp đôi lên 800 GB/s cho 1.42 lần. Hãy đọc giới hạn này là "máy này không thể nhanh hơn mức này", không bao giờ là "máy này chạy ở tốc độ này".

Giới hạn này giả định một model dense, trong đó mọi trọng số được đọc cho mỗi token. Các model mixture-of-experts chỉ đọc các expert đang hoạt động cho mỗi token, nên chúng có thể chạy nhanh hơn mức giới hạn tính theo tổng kích thước của chúng.

Bộ nhớ cho model trên mỗi đô la

Một cách sắp xếp của danh sách đó là bộ nhớ cho model trên mỗi đô la: số gigabyte bộ nhớ cho model (VRAM, hoặc bộ nhớ hợp nhất) chia cho giá Amazon hiện tại, kèm ngày của mức giá. Nó trả lời câu hỏi "máy nào chứa được model lớn nhất với số tiền này". Nó không phải xếp hạng chất lượng hay tốc độ, và hoa hồng không bao giờ thay đổi nó.

Những gì các ước tính này không phải

• Chúng không phải là benchmark. Không model nào được chạy trên các máy được liệt kê để tạo ra chúng.
• Chúng không bao gồm thời lượng pin, nhiệt độ, tiếng ồn, hay hiệu năng duy trì khi chịu tải.
• Chúng giả định một người dùng, một cuộc hội thoại, và trọng số Q4_K_M kiểu llama.cpp. Các runtime khác, các mức lượng tử hóa khác và ngữ cảnh dài hơn sẽ thay đổi câu trả lời.