Đừng đếm token nữa, hãy đếm phần mềm thực sự được ship

Khi một lập trình viên giao việc cho AI agent, agent không chỉ trả lời một lần. Nó lập kế hoạch, sinh mã, chạy kiểm thử và lặp lại để sửa lỗi — khiến một tác vụ có thể dùng lượng token gấp 10 đến 50 lần so với một prompt chat thông thường. Càng hữu ích, agent càng gọi model nhiều hơn, và với mô hình tính phí theo token, chính những quy trình tạo giá trị cao nhất lại trở thành những quy trình đắt đỏ nhất.

Mô hình AI đang được sử dụng để hỗ trợ phát triển phần mềm

Áp lực chi phí đã hiện rõ

Con số biết nói đang xuất hiện ngày càng nhiều trong giới công nghệ:

• Uber được cho là đã tiêu hết toàn bộ ngân sách AI của năm 2026 chỉ trong vòng bốn tháng, sau khi mở rộng sử dụng Claude Code.
• GitHub Copilot chuyển từ gói giá cố định sang tính phí theo tín dụng (metered credits).
• Gartner dự báo đến năm 2028, chi phí token cho lập trình AI sẽ vượt mức lương trung bình của một lập trình viên.

Phản ứng tự nhiên của doanh nghiệp là hạn chế sử dụng — đặt hạn mức, giới hạn số ghế, thêm bước phê duyệt trước khi lập trình viên khởi chạy agent. Nhưng các giới hạn áp đặt đồng loạt có thể bóp nghẹt chính những quy trình đang tạo ra giá trị, và tệ hơn, chúng tối ưu sai chỉ số.

Chi phí mỗi token đo lường mức tiêu thụ, không đo lường kết quả.

Một phần chi tiêu phản ánh sự lãng phí — các lần thử lại, vòng lặp chạy mãi không dừng. Nhưng một phần khác chính là công việc thực sự tạo ra phần mềm. Một chiếc đồng hồ đo token không thể phân biệt hai loại này, và một hạn mức chi tiêu cũng vậy.

Đo phần mềm được ship, không đo token

Một thước đo tốt hơn là chi phí mỗi pull request được merge: tổng chi phí phát triển có AI chia cho số thay đổi đã qua review và được hợp nhất. Đi kèm với đó là theo dõi lượng việc làm lại và số lỗi, để những thay đổi "rẻ" không che giấu chất lượng thấp hơn.

Nếu chi phí này giảm trong khi mức sử dụng AI tăng mà chất lượng không bị ảnh hưởng, nghĩa là đội ngũ đang chuyển hóa mức tiêu thụ nhiều hơn thành phần mềm hữu ích. Câu hỏi không phải là họ dùng bao nhiêu token, mà là khoản đầu tư đó tạo ra bao nhiêu công việc hoàn chỉnh.

Để cải thiện phương trình này cần hai thay đổi: dành suy luận đắt tiền cho những tác vụ thực sự cần, và giảm chi phí cho công việc thường ngày.

Gắn mô hình với đúng tác vụ

Lập trình bằng agent không đòi hỏi mô hình mạnh nhất ở mọi bước. Hãy dùng mô hình tiên tiến (frontier) — hoặc một mô hình chủ lực chạy tại chỗ khi chính sách yêu cầu — cho việc lập kế hoạch khó và suy luận mới lạ. Còn những việc phù hợp như sinh mã, tạo kiểm thử, tái cấu trúc lặp đi lặp lại thì chuyển sang các mô hình mã nguồn mở do chính doanh nghiệp vận hành.

Một gateway có thể định tuyến yêu cầu theo độ phức tạp, độ nhạy cảm dữ liệu, chi phí và độ trễ. Cách này giữ suy luận cao cấp cho những thời điểm thực sự xứng đáng, thay vì áp mức giá cao cấp cho cả một quy trình. Hãy đo cái ngoại lệ, đừng đo toàn bộ khối lượng công việc.

Các mô hình mã nguồn mở ngày càng khiến sự phân chia này khả thi. Các bài benchmark kỹ thuật phần mềm cho thấy những mô hình mở hàng đầu có thể tiếp cận hiệu năng của mô hình tiên tiến ở một số tác vụ. Tuy nhiên, điều đó không đồng nghĩa với sự tương đương trên mọi kho mã hay quy trình. Doanh nghiệp cần đánh giá ứng viên trên chính mã nguồn, bộ kiểm thử và tiêu chí nghiệm thu của mình trước khi đưa vào công việc thực tế.

Thay đổi bài toán kinh tế của việc dùng lặp lại

Bước tiếp theo là xác định ai sở hữu năng lực tính toán. Với suy luận thuê ngoài, mỗi lần gọi đều cộng vào hóa đơn. Với năng lực sở hữu, phần lớn chi phí được cam kết trước, nên mỗi lần gọi thêm càng rẻ đi khi mức sử dụng tăng.

Nguyên lý rất đơn giản: tính phí theo token khiến dùng nhiều càng đắt, trong khi năng lực sở hữu càng được dùng nhiều càng hiệu quả. Dĩ nhiên, sở hữu không hề miễn phí — điện năng, vận hành, bảo trì và khấu hao đều phải tính đến. Con số quan trọng cuối cùng vẫn là chi phí toàn phần cho mỗi pull request được merge.

Năng lực sở hữu còn mang lại một giá trị không bao giờ xuất hiện trên hóa đơn: quyền kiểm soát mã nguồn nhạy cảm. Khi việc sinh mã và kiểm thử chạy tại chỗ, mã độc quyền vẫn nằm trong doanh nghiệp. Chỉ những prompt lập kế hoạch đã được phê duyệt và các ngoại lệ có kiểm soát mới được đưa ra model bên ngoài, thông qua gateway do tổ chức kiểm soát. Điều này mở đường cho những kho mã nhạy cảm mà trước đây bảo mật thường chặn việc áp dụng AI — cũng chính là nơi những lợi ích lớn nhất đang chờ đợi.

Kiểm chứng mô hình vận hành

Tại HPE, một nền tảng AI hybrid định tuyến khối lượng công việc thường ngày từ hơn 150 ứng dụng nội bộ sang các mô hình mã nguồn mở chạy tại chỗ, trong đó có HPE Private Cloud AI. Kết quả: chi phí token giảm 30-50%.

Đó chính là ý nghĩa của hybrid. Sở hữu năng lực suy luận không có nghĩa là từ bỏ các mô hình tiên tiến. Hãy chạy phần khối lượng lớn trên năng lực mình sở hữu và để gateway chuyển những việc khó nhất ra ngoài.

Dữ liệu cũng cho thấy chính mức sử dụng, chứ không phải số ghế được cấp phép, mới là yếu tố quyết định chi tiêu. Nhóm 5% người dùng hàng đầu tạo ra phần lớn mức tiêu thụ, và người dùng nhiều nhất tiêu tốn gấp khoảng 450 lần người dùng ít nhất trên cùng một giấy phép. Nếu nhóm người dùng mạnh mẽ này mở rộng từ thiểu số nhỏ lên một nửa lực lượng lao động, chi tiêu hàng tháng có thể tăng khoảng 4,4 lần dù số nhân sự không đổi. Tỷ lệ này sẽ khác nhau ở mỗi doanh nghiệp — và đó chính là lý do bạn cần đo lường.

Xây dựng để mở rộng, không phải để hạn chế

Sở hữu năng lực tính toán không phải lựa chọn cho tất cả mọi người. Mức sử dụng thấp hoặc khó dự đoán sẽ phù hợp với API hơn, không phải đổ vốn vào hạ tầng nhàn rỗi. Việc sở hữu chỉ có lợi khi nhu cầu ổn định đủ để giữ hạ tầng luôn bận rộn.

Hầu hết doanh nghiệp sẽ vận hành theo mô hình hybrid: API tiên tiến cho công việc đòi hỏi cao hoặc không liên tục, năng lực sở hữu cho khối lượng lặp lại đều đặn. Một gateway có kiểm soát sẽ quyết định dữ liệu nào được ra khỏi tổ chức, giúp bạn dùng được mô hình tiên tiến mà không đánh mất chủ quyền đối với mã nguồn.

Khi lập trình viên ngày càng dựa nhiều vào coding agent, mức sử dụng sẽ tiếp tục tăng. Lựa chọn thực sự là liệu sự tăng trưởng đó hiện ra như một hóa đơn chi phí biến đổi lớn hơn, hay như nhiều phần mềm hơn được ship trên năng lực bạn đang sở hữu. Các công ty dẫn đầu về phát triển phần mềm có AI sẽ không hạn chế việc áp dụng để kiểm soát chi phí — họ sẽ xây dựng một mô hình vận hành nơi việc dùng AI nhiều hơn cải thiện, thay vì làm suy yếu, bài toán kinh tế.

Với các doanh nghiệp Việt Nam đang bắt đầu triển khai AI vào quy trình phát triển phần mềm, bài học là hãy thiết lập chỉ số đo lường ngay từ đầu — cả chi phí trên mỗi lập trình viên lẫn chi phí trên mỗi pull request được merge — trước khi quyết định đầu tư hạ tầng hay mở rộng quy mô sử dụng.