DeepSeek V4.1 Flash tốn ít chi phí hơn GPT-6 Astra: Vì sao tìm đúng nguyên nhân chưa có nghĩa là sửa xong lỗi?

Từ hai lỗi thật của pytest, phân biệt khả năng tìm nguyên nhân, chọn phạm vi sửa và hoàn tất bản vá.

Ảnh bìa tạo bằng gpt-image-2; đây là minh họa, không phải ảnh chụp sản phẩm hay bằng chứng thử nghiệm.

Một mô hình giải thích đúng nguyên nhân lỗi chưa chắc đã tạo ra bản vá có thể chấp nhận. Khoảng cách này rất quan trọng khi so sánh DeepSeek V4.1 Flash với GPT-6 Astra: giá thấp có giá trị lớn nếu phần việc còn lại cho lập trình viên cũng giảm, chứ không chỉ khi câu trả lời trông thuyết phục.

Trong báo cáo DeepSWE của Fireworks ngày 14/9/2026, Flash đạt 74,34% pass@1, còn Astra đạt 74,12%. Chi phí mô hình trung bình cho mỗi tác vụ lần lượt là 0,430 USD và 6,524 USD. Flash dùng mức max, Astra dùng xhigh. Đây là chênh lệch chi phí khoảng 15 lần trong điều kiện của báo cáo.

Kết quả ấy khiến Flash trở thành ứng viên đáng thử cho công việc phần mềm. Để hiểu ứng viên đó cần đáp ứng những gì, nên tách “sửa được lỗi” thành các năng lực cụ thể.

1. Tìm đúng nguyên nhân: thông báo lỗi không phải toàn bộ vấn đề

Issue #14635 của pytest mô tả một tình huống khó chịu: một tệp kiểm thử được thu thập bình thường khi chạy riêng, nhưng việc thêm các đường dẫn khác phía trước lại khiến tham số fixture không được giải quyết đúng.

Fixture là cơ chế cung cấp dữ liệu hoặc thiết lập cần thiết cho bài kiểm thử. Nhìn vào thông báo, rất dễ nghi ngờ tên tham số. Tuy nhiên, nguyên nhân nằm ở quan hệ giữa các đối tượng trong quá trình thu thập thư mục.

Khi thư mục cha được thu thập lại, các nút thư mục con mới xuất hiện. Thông tin fixture đã có vẫn gắn với nút cũ. Hai nút có thể biểu diễn cùng một đường dẫn nhưng không phải cùng một đối tượng. Vì vậy, việc tra cứu phụ thuộc vào lịch sử thu thập, dù đường dẫn trên ổ đĩa không đổi.

Năng lực có ích ở đây là lần theo quan hệ trạng thái, không dừng ở câu chữ của lỗi. Nếu một mô hình chỉ đề xuất đổi tên hoặc thêm tham số để làm thông báo biến mất, nó có thể đang sửa sai tầng của vấn đề.

2. Chọn phạm vi sửa: không xóa luôn hành vi hợp lệ

Sau khi hiểu nguyên nhân, vẫn còn một quyết định khó: sửa rộng đến đâu?

Cấm toàn bộ việc thu thập trùng lặp có vẻ là một lối tắt. Nhưng pytest có hành vi hợp lệ với các đối số tệp lặp lại và tùy chọn “--keep-duplicates”. Một thay đổi quá rộng có thể làm mất chức năng đó.

PR #14645 tái sử dụng các nút con Directory phù hợp đã có cho cùng đường dẫn, đồng thời giữ cách xử lý Module và File. Bản vá không coi mọi dạng trùng lặp là lỗi.

“Hồi quy” ở đây là một hành vi trước đó hoạt động nhưng bị hỏng sau thay đổi. Đây là lý do một bài kiểm thử mới chuyển sang màu xanh chưa đủ để chấp nhận bản vá.

3. Hoàn tất thay đổi: một điểm gọi đúng chưa đại diện cho tất cả

Issue #14912 cho thấy rủi ro ngược lại: sửa quá hẹp. Một số đối tượng cảnh báo được tạo ra rồi dùng lại trong thời gian dài. Khi cấu hình biến cảnh báo thành lỗi, cùng một đối tượng có thể được ném lại và giữ traceback từ lần trước.

Trong lần tái hiện cục bộ, traceback đầu có 3 frame, lần tiếp theo có 6 frame. Traceback là chuỗi vị trí thực thi liên quan đến ngoại lệ; số frame tăng ở đây phản ánh trạng thái cũ bị mang theo, không phải chỉ một thông báo dài hơn.

Tạo đối tượng mới tại vị trí của ví dụ tối thiểu có thể làm ví dụ ấy chạy đúng. Nhưng những nơi liên quan vẫn tái sử dụng đối tượng cũ thì sao?

PR #14931 đổi các khai báo cảnh báo thuộc phạm vi sửa sang factory UnformattedWarning và cập nhật nhiều điểm sử dụng tương ứng. Nội dung thông báo, loại cảnh báo, stacklevel và tên công khai vẫn cần giữ tương thích. Đây không phải bằng chứng rằng mọi cảnh báo trong toàn bộ dự án đều đã được thay đổi.

Hình 1: Sơ đồ yêu cầu rút ra từ các issue và bản sửa upstream; không phải ảnh chụp một lần chạy mô hình.

Hai ví dụ bổ sung cho nhau. Vấn đề thư mục cần tránh sửa lan sang hành vi hợp lệ. Vấn đề cảnh báo cần tránh bỏ sót các điểm gọi thuộc cùng nguyên nhân. Mô hình có giá trị khi đưa ra phạm vi vừa đủ và thực hiện nhất quán phạm vi đó.

Kết quả cục bộ chứng minh điều gì?

Các bản gốc và bản sửa tham chiếu được kiểm tra trên Windows với Python 3.12.14. Bản gốc cũng được chạy cùng bài hồi quy mới để xác nhận bài đó thật sự phát hiện lỗi.

Hình 2: Tổng hợp log cục bộ đã lưu. Các bài bỏ qua không được tính là đạt; phạm vi chạy không phải toàn bộ pytest.

Flash và Astra không tạo ra hai bản vá trong kiểm chứng này. Kết quả xác nhận lỗi và cách sửa upstream, đồng thời làm rõ chuẩn đánh giá; nó không chứng minh mô hình nào sửa tốt hơn. Các issue đã công khai cũng có thể xuất hiện trong dữ liệu huấn luyện, nên không phù hợp để làm cơ sở duy nhất xếp hạng năng lực.

Đọc điểm benchmark theo đúng loại công việc

DeepSWE cung cấp bằng chứng rằng Flash có thể cạnh tranh trong một tập tác vụ phần mềm cụ thể. Pass@1 phản ánh kết quả của một lần thử theo cách đánh giá đó; một lần thử có thể gồm nhiều lần gọi mô hình và công cụ.

Khoảng cách 0,22 điểm phần trăm không đủ để tuyên bố Flash dẫn đầu ổn định. Báo cáo nêu biến động giữa các lần chạy là 1,4–3,2 điểm. Cách diễn đạt hợp lý là kết quả gần nhau trong phép đo này, không phải hai mô hình tương đương trong mọi tình huống.

Ở HLE, Flash đạt 34,52% và Astra đạt 50,40%; ở Terminal-Bench 2.1, hai con số là 86,5% và 87,5%. Năng lực không thay đổi theo một trục duy nhất. Một kết quả sửa mã không tự trả lời cho các bài suy luận học thuật khó hoặc công việc thiết kế chưa có tiêu chí rõ ràng.

Giá trị phải gắn với phần việc đã hoàn tất

Khi đánh giá trên kho mã của mình, nên giữ cùng điểm xuất phát và cùng điều kiện chấp nhận. Sau đó ghi nhận bản vá đầu tiên đạt đến đâu, cần thêm phản hồi gì, và phần nào do người trực tiếp sửa.

Không nên cộng kết quả “người đã sửa xong” vào số lần mô hình tự hoàn thành. Tương tự, các lần thử thất bại vẫn tiêu tốn tiền và thời gian. Bỏ chúng khỏi bảng so sánh sẽ khiến giá trị thực bị thổi phồng.

Chi phí API cũng cần đúng kênh sử dụng. Với Crazyrouter, hãy đối chiếu giá mô hình và các hạng mục tính phí, tách đầu vào thường, đầu vào cache và đầu ra. Chi phí trung bình của Fireworks không phải báo giá mặc định cho kênh khác.

Lợi thế của Flash đáng quan tâm vì nó mở ra khả năng có được công việc đạt chuẩn với chi phí thấp hơn. Nhưng phần “đạt chuẩn” phải được chứng minh bằng sản phẩm thực tế: tìm đúng nguyên nhân, giữ hành vi cần giữ, và hoàn tất các thay đổi liên quan. Khi ba điều đó được đáp ứng, chênh lệch giá mới trở thành giá trị kỹ thuật thay vì chỉ là một con số hấp dẫn.

Nguồn: Fireworks; pytest #14635/PR #14645, #14912/PR #14931. Commit gốc tương ứng: eb79044cea1c2c7b6e58ebcce17c55da871fef6c và f5240bef4d8b31232d570fb80ea4f7c50b087d1b. Metadata phiên bản build bị thiếu trong gói nguồn được bổ sung giống nhau ở hai môi trường. Ngày đối chiếu:13/10/2026.