The AI Unit-Economics Ledger — Playbook điều hành miễn phí

Playbook điều hành miễn phí.

AI của anh/chị đã rẻ hơn. Rẻ hơn rất nhiều. Vậy mà hóa đơn không hề giảm. Đó không phải lỗi tính tiền, và cũng không phải bài toán chi phí — đó là bài toán dự báo, và nó tệ hơn. Bài toán chi phí thì lập được ngân sách; anh/chị có thể quyết định chi nhiều hơn. Bài toán dự báo thì không, vì không có con số nào để đưa vào ngân sách. Giá các mô hình frontier thực sự đã giảm khoảng 80% so với mức gốc tháng 3/2023 — BenchLM Token Price Index, chỉ số phụ frontier, dữ liệu từ BenchLM.ai — vậy mà Gartner vẫn dự báo chi phí suy luận trên mỗi quy trình agent sẽ tăng hơn năm lần đến hết năm 2028 — cơ chế mà hãng này gọi tên vào tháng 8/2026 là Inference Paradox (nghịch lý suy luận): kinh tế đơn vị tốt hơn lại trợ giá cho các quy trình phức tạp hơn, nên tổng chi phí vẫn tăng dù từng đơn vị rẻ đi. Lý do hai con số tách rời nhau nằm ở kiến trúc chứ không phải ở thương mại. Giá mỗi token mô tả một đầu vào; ngân hàng mua đầu ra — một lần đối soát hoàn tất, một hồ sơ được giải quyết, một tài liệu được kiểm tra, một ngoại lệ được xử lý xong — và agent tạo ra những đầu ra đó bằng cách lập kế hoạch, gọi công cụ, tự kiểm tra công việc của mình và thử lại, đọc lại toàn bộ những gì đã làm ở mỗi vòng của vòng lặp đó. The AI Unit-Economics Ledger đặt bốn dòng chi phí một ngân hàng phải dự báo lên cùng một trang, sắp theo thời điểm ngân hàng phát hiện ra chúng — phê duyệt, tích hợp, vận hành thực tế, kiểm toán — mỗi dòng kèm nội dung của nó, lý do nó bị đánh giá thấp, và một chủ thể chịu trách nhiệm. Một quy tắc từ chối duy nhất giữ tất cả lại với nhau: không phê duyệt bất cứ thứ gì chỉ dự báo mỗi dòng thứ nhất. Đây là cách phân rã do tác giả đề xuất, không phải một chuẩn mực đã được phê chuẩn.

Trong playbook có gì

• Đặt lại vấn đề — trợ lý một lượt so với agent có dùng công cụ, đối chiếu theo năm hàng quyết định một dự báo: khối lượng xử lý mỗi yêu cầu của người dùng (một lần gọi mô hình · so với nhiều lần — lập kế hoạch, công cụ, thử lại, tự kiểm tra) · yếu tố chi phối chi phí (token đầu ra, những gì nó viết · so với token đầu vào, ngữ cảnh nó đọc lại ở mỗi lượt) · cách chi phí tăng theo quy mô (gần như tuyến tính theo mức sử dụng · so với siêu tuyến tính theo độ phức tạp của tác vụ) · khả năng dự báo (đơn giá nhân sản lượng · so với một phân phối, chênh tới ba mươi lần trên cùng một tác vụ) · và nơi phương án kinh doanh nhìn vào (chính xác ở cột thứ nhất, gần như không bao giờ ở cột thứ hai). Hệ quả đã được đo, nêu kèm phạm vi của nó: khối lượng công việc dạng agent tiêu thụ nhiều token hơn khoảng một nghìn lần so với một tác vụ chat lập trình hoặc suy luận lập trình, với đầu vào chứ không phải đầu ra chi phối chi phí — Bai và cộng sự, arXiv:2604.22750, đo trên tám mô hình frontier với một bộ benchmark kỹ thuật phần mềm. Agent đắt không phải vì những gì nó viết; nó đắt vì những gì nó cứ phải đọc đi đọc lại · cùng với lý do điều này ẩn kín đến vậy: hai trong bốn dòng hoàn toàn không tăng theo số người dùng. Truy xuất tăng theo quy mô và tần suất thay đổi của kho dữ liệu; điều phối tăng theo độ phức tạp của tác vụ. Vì thế cả hai đều vô hình trong đúng phép tính mà một phương án tính theo đầu người dùng được dựng lên, nên ngân hàng không chi vượt — ngân hàng dự báo sai, và phát hiện ra qua hóa đơn
• Sổ cái — đủ bốn dòng, với nội dung của từng dòng, vì sao nó bị đánh giá thấp, cửa kiểm soát nơi ngân hàng phát hiện ra nó, và chủ thể chịu trách nhiệm. Bốn, không phải sáu, vì một giám đốc tài chính có thể nắm bốn dòng trong đầu, còn một biểu mẫu không ai điền thì không phải là một biện pháp kiểm soát. L1 · Suy luận (lần gọi mô hình: token đầu vào, đầu ra, đầu vào được cache, token suy luận nếu được tính phí riêng, giá niêm yết so với giá cam kết so với giá đàm phán — dòng duy nhất mà hầu hết phương án có và là dòng có đơn giá giảm sâu nhất, chính vì thế nó tô đẹp cho dự báo; phát hiện ở khâu phê duyệt, chủ thể là nền tảng và kiến trúc) · L2 · Truy xuất và ngữ cảnh (embedding và embedding lại khi có thay đổi, lưu trữ và truy vấn vector, re-ranking, ngữ cảnh gửi lại ở mỗi lần gọi — nó tăng theo quy mô và tần suất thay đổi của kho dữ liệu, không theo số người dùng, nên không xuất hiện ở đâu trong một phương án tính theo đầu người dùng; phát hiện ở khâu tích hợp, chủ thể là dữ liệu và tri thức) · L3 · Điều phối (hệ số nhân: các bước lập kế hoạch, lần gọi công cụ, lần thử lại, tự kiểm tra, chuyển giao giữa nhiều agent — nơi tính phi tuyến thực sự nằm và là dòng ít được mô hình hóa nhất trong sổ cái; phát hiện khi vận hành thực tế, nơi tệ nhất có thể để phát hiện ra nó, chủ thể là kỹ thuật) · L4 · Vận hành, bảo đảm và rà soát (Vận hành: giám sát, truy vết, theo dõi trôi lệch · Bảo đảm: các mô hình chấm điểm cùng bộ kiểm thử hồi quy và red-team chạy lại ở mỗi lần phát hành · Rà soát: xử lý ngoại lệ, chuyển cấp, tranh chấp, khiếu nại — cả ba thường bị coi là chi phí xây dựng trong khi cả ba đều lặp lại, bảo đảm theo mỗi lần phát hành và rà soát theo mỗi ngoại lệ; phát hiện ở khâu kiểm toán, chủ thể là vận hành và rủi ro) · cùng với lý do Rà soát được gọi tên có chủ ý, và là nhánh hay bị xóa nhất: rà soát là nơi khoản tiết kiệm nhân sự mà một phương án kinh doanh đã hứa hoặc trụ lại, hoặc lặng lẽ biến mất, và một dòng gọi là "vận hành và bảo đảm" đọc lên như hạ tầng rồi bị giao cho bộ phận kỹ thuật, trong khi một dòng gọi là "vận hành, bảo đảm và rà soát" thì không thể bị giao như vậy · và nơi gánh nặng tuân thủ rơi vào: Luật Trí tuệ nhân tạo 134/2025/QH15 của Việt Nam — thông qua ngày 10/12/2025, có hiệu lực từ 01/3/2026 — đặt ra các nghĩa vụ về minh bạch và về phát hiện, khắc phục sự cố, và, với các hệ thống được phân loại rủi ro cao, các nghĩa vụ về giám sát của con người và can thiệp của con người. Điều 35(1)(a) cho thời gian chuyển tiếp mười tám tháng, đến 01/9/2027, chỉ dành cho các hệ thống AI đã vận hành trước ngày 01/3/2026 trong lĩnh vực tài chính, y tế và giáo dục — một triển khai mới không được thừa hưởng điều đó, và thứ mà thời gian chuyển tiếp lùi lại là nghĩa vụ tuân thủ đối với các hệ thống đã đang chạy, chứ không phải chi phí xây dựng năng lực. Nghĩa vụ đánh giá tác động mà ngân hàng thực sự phải gánh thuộc về chế độ bảo vệ dữ liệu cá nhân, không phải Luật AI: Điều 21(1) PDPL yêu cầu lập hồ sơ đánh giá tác động xử lý dữ liệu cá nhân trong vòng sáu mươi ngày kể từ khi bắt đầu xử lý, không kèm điều kiện, và cập nhật mỗi sáu tháng khi có thay đổi. Tất cả những nghĩa vụ này là chi phí vận hành lặp lại chứ không phải một dự án tuân thủ làm một lần, và giám sát của con người vừa là nghĩa vụ pháp lý vừa chính là nhánh Rà soát. Bên cạnh đó, các quy định xuyên biên giới của PDPL 91/2025/QH15 là yếu tố mạnh nhất chúng tôi xác định được làm tăng chi phí kiến trúc triển khai — chúng có thể buộc một phương án triển khai đắt hơn API công cộng, tức là một chi phí kiến trúc thuộc L1 và L2, và cách đọc về chi phí đó là đánh giá của playbook này chứ không phải một phát hiện có nguồn
• Độ biến động, và mẫu số còn thiếu — hệ số nhân chưa phải phát hiện tệ nhất. Trong cùng nghiên cứu đo lường đó, các nhà nghiên cứu chạy đúng một tác vụ nhiều lần, không phải các biến thể của nó, và lượng token tiêu thụ chênh nhau tới ba mươi lần: cùng một lần đối soát, chạy vào thứ Ba rồi chạy lại vào thứ Năm, có thể chênh nhau ba mươi lần, và không có gì trong nhật ký thay đổi giải thích được vì sao. Nên hóa đơn cho một đầu việc là một phân phối chứ không phải một con số · và lối tắt hiển nhiên cũng đã bị chặn, bởi cùng nhóm nghiên cứu đã kiểm tra xem các mô hình frontier có dự đoán được lượng token chính chúng sẽ dùng hay không, và tương quan ở mức yếu đến trung bình — tối đa 0,39 — với các mô hình có xu hướng hệ thống là đánh giá thấp chi phí thực của chúng. Bản thân mô hình cũng không biết nó sắp tiêu bao nhiêu, và đó là lý do đàm phán được đơn giá tốt hơn không giải quyết được vấn đề: đơn giá chưa bao giờ là vấn đề, sự sụp giảm của đơn giá đã xảy ra rồi, và điều ngân hàng hiện chưa làm được là dự đoán khối lượng · cùng với việc chuẩn FinOps định nghĩa gì và không định nghĩa gì. FinOps Open Cost and Usage Specification — FOCUS — chuẩn hóa lược đồ tập dữ liệu về hóa đơn và mức sử dụng giữa các nhà cung cấp AI, cloud, SaaS và trung tâm dữ liệu. Nó định nghĩa các cột dữ liệu, không định nghĩa chỉ số hiệu quả hoạt động: mức tiêu thụ AI đi qua các trường chung về khối lượng tiêu thụ và đơn vị tiêu thụ, nên một token, một request và một seat đều trở thành các dòng chi phí so sánh được, bất kể ai xuất hóa đơn. Điều nó không định nghĩa là chi phí mỗi tác vụ hoàn thành, và nó cũng chưa bao giờ tuyên bố như vậy — phân tích chi phí đơn vị được xác định rõ là việc của người thực hành, dựng trên nền dữ liệu đã chuẩn hóa, và một issue còn mở trên chính kho mã của đặc tả ghi nhận rằng người thực hành vẫn thiếu ví dụ cụ thể về cách ánh xạ lượng token tiêu thụ vào các cột đó: một khoảng trống được ghi nhận ngay trong chuẩn, chứ không phải sự thiếu vắng bằng chứng. FOCUS giúp tử số so sánh được; mẫu số là của anh/chị, và đó chính là toàn bộ lý do cần có một sổ cái
• Câu hỏi về nhân sự — hồ sơ công khai ủng hộ điều gì, và không ủng hộ điều gì. Những trường hợp được dẫn rộng rãi về việc thay thế hàng trăm nhân viên dịch vụ đều bắt nguồn từ thông báo của chính các công ty triển khai và từ nhà cung cấp công nghệ của họ, được trình bày như dự phóng hướng tới tương lai chứ không phải kết quả đã kiểm toán. Ở những nơi các dự phóng đó về sau được xem xét lại, phần điều chỉnh đều đi xuống, và không trường hợp nào được nêu lại như một mức giảm đã kiểm toán trong cơ sở chi phí của một quy trình chịu quản lý. Hồ sơ công khai không ủng hộ nhận định về một mức giảm ròng bền vững trong cơ sở chi phí của một quy trình ngân hàng chịu quản lý nhờ thay thế nhân sự. Cơ chế giải thích vì sao, và nó hữu ích hơn bất kỳ trường hợp đơn lẻ nào: tự động hóa luồng đơn giản để lại phần cặn khó — tranh chấp, ngoại lệ, khiếu nại — và phần việc đó cần những người đắt hơn so với khâu sàng lọc sơ cấp đã bị thay thế. Chi phí không biến mất; nó chuyển sang dòng thứ tư, nơi không ai dự báo · không có con số và không có công ty nào được nêu tên ở đây, một cách có chủ ý, bởi các con số đang lưu hành là dự phóng của chính bên công bố, và một dự phóng không phải là một phép đo
• Kiểm tra dự báo — sáu câu hỏi, một buổi chiều, một phương án kinh doanh đã được phê duyệt, mỗi câu kèm hình dung về một câu trả lời không đạt, nên kết quả không phải một con số mà là danh sách những dòng chi phí mà tổ chức của anh/chị hiện chưa nhìn thấy. L1 nằm ở đâu, và đó là giá niêm yết, giá cam kết hay giá đàm phán (không đạt: nó có ở đó — câu này luôn đạt, và đó chính là vấn đề) · L2 có được dự báo theo mức tăng và tần suất thay đổi của kho dữ liệu thay vì theo mức tăng người dùng hay không (không đạt: một con số theo đầu người dùng hoặc theo seat, bởi phương án chưa từng mô hình hóa kho dữ liệu) · hệ số nhân L3 là bao nhiêu, số lần gọi mô hình trên mỗi yêu cầu của người dùng, đã đo thực tế (không đạt: không ai đưa ra được, nên phương án không có mẫu số) · L4 tốn bao nhiêu mỗi lần phát hành và mỗi ngoại lệ, với ba nhánh được tách riêng (không đạt: bảo đảm bị hạch toán như một hạng mục xây dựng, và Rà soát hoàn toàn vắng mặt) · độ biến động là bao nhiêu, chứ không phải giá trị trung bình (không đạt: một ước tính điểm duy nhất cho khối lượng công việc có mức chênh ba mươi lần đã được ghi nhận) · và ai là người chịu trách nhiệm đứng tên cho dự báo của từng dòng (không đạt: "Khối Công nghệ" — một chức năng không phải là một con người) · rồi đến quy tắc từ chối dành cho hội đồng đầu tư: khi chỉ dòng thứ nhất được dự báo, người lãnh đạo nên trả phương án về, không phải vì hóa đơn quá lớn mà vì đó hoàn toàn không phải một dự báo — đó là một ước tính khoác áo dự báo

Năm trang · miễn phí khi đăng nhập thành viên · PDF.

Hai giới hạn trung thực được nêu cả trong bản tải về lẫn ở đây, bởi chúng xác định phạm vi mà sổ cái có thể tuyên bố. Khi nào khung tư duy này không đứng vững: một ngân hàng có năng lực kỹ thuật thực sự trưởng thành — phân tầng suy luận chặt chẽ, kiến trúc agent tận dụng cache — có thể khiến đà giảm giá đơn vị vượt nhanh hơn sự phình to của điều phối. Các biện pháp kiểm soát là có thật: prompt caching có bằng chứng đo lường trong tài liệu nghiên cứu (arXiv:2601.06007), và model routing là chính biện pháp Gartner khuyến nghị, nên routing là một biện pháp kiểm soát chứ không phải một lời bác bỏ. Vì vậy ràng buộc quyết định có thể là nhân tài, không phải giá — rất ít ngân hàng thương mại truyền thống đang vận hành các kiến trúc đó trong môi trường thực tế hiện nay, và đó là lập luận mạnh nhất ủng hộ sổ cái chứ không phải chống lại nó, bởi một ngân hàng chưa thể tối ưu bằng kỹ thuật thì tối thiểu phải đo được mức phơi nhiễm. Và về phạm vi: những phép đo mạnh nhất hiện có — hệ số nhân một nghìn lần, việc tập trung vào khâu rà soát, độ biến động ba mươi lần — được thực hiện trên tác vụ lập trình dạng agent. Cơ chế thì khái quát được; còn độ lớn cụ thể không nên được mặc định là chuyển nguyên vẹn sang một hồ sơ tín dụng hay một lần đối soát.

Những gì cố ý không có trong playbook này. Không có con số ngân sách công nghệ của ngân hàng nào. Không có đơn giá vector database hay observability. Không có hướng dẫn hạch toán kế toán. Không có ngưỡng giao dịch theo thông tư ngân hàng. Không nêu tên ngân hàng nào. Mỗi mục đều được nghiên cứu của tuần này đưa ra, mỗi mục đều được đối chiếu với một nguồn sơ cấp, và mỗi mục đều bị loại vì nguồn không đỡ nổi nhận định đó. Một con số không mang theo được điều kiện của nó thì không xuất hiện.

Xem: youtu.be/lkfZWBZcUxI — Video 17: Why cheaper AI cost more, 8 phút 0 giây.

Muốn nhận bản hằng tuần? Đăng ký The AI Architect Letter · Đọc bản phân tích đầy đủ · Đọc các bài phân tích mới nhất.