Kỹ thuật vận hành agent và bài toán chi phí token trong thực tế
Kỹ thuật vận hành agent và bài toán chi phí token trong thực tế
Nhiều đội ngũ kỹ thuật khi triển khai các agent lập trình thường bắt đầu bằng cách nhồi nhét quy chuẩn dự án vào các tệp tài liệu dạng AGENTS.md. Nhưng chỉ sau vài vòng lặp mã lệnh, agent bắt đầu quên quy tắc, gọi trực tiếp các module bên ngoài và làm hỏng kiến trúc sẵn có. Thay vì tiếp tục chỉnh sửa câu lệnh mô tả (prompt) một cách vô vọng, kỹ sư Geoffrey Huntley chọn cách thực tế hơn nhiều: dựng một pre-commit hook để quét thẳng phần git diff. Nếu agent dám bỏ qua thư viện chẩn đoán nội bộ để gọi bừa bãi vào hệ thống ngoài, hook sẽ từ chối commit ngay lập tức, rồi đẩy ngược chính thông báo lỗi đó vào ngữ cảnh để agent tự sửa.
Cách làm đó phản ánh một bước chuyển rõ rệt trong ngành: chúng ta đang chuyển từ giai đoạn trầm trồ trước khả năng tạo mã sang giai đoạn thiết lập kỷ luật và tối ưu chi phí vận hành cho các mô hình tự hành.
Đưa agent vào kỷ luật bằng công cụ xác định
Khi làm việc với các hệ thống tự động sinh mã, kỳ vọng mô hình luôn tuân thủ tài liệu chỉ dẫn là một sai lầm phổ biến. Bản chất xác suất khiến các mô hình ngôn ngữ lớn luôn có độ trôi nhất định sau nhiều bước xử lý. Nếu chỉ dựa vào câu chữ để khuyên răn mô hình, lập trình viên sẽ liên tục rơi vào bẫy gỡ lỗi thủ công.
Giải pháp ở đây là kết hợp giữa tính ngẫu nhiên của mô hình với tính tất định của các công cụ kiểm thử truyền thống. Việc chặn vi phạm ngay từ pre-commit hook, dịch lỗi thành phản hồi kỹ thuật rồi bắt mô hình thử lại đem lại độ tin cậy tuyệt đối cho luồng phát triển. Mô hình không cần phải “thông minh hơn”, nó chỉ cần được đặt trong một hành lang kỹ thuật có ranh giới rõ ràng.
Quy trình phát triển phần mềm đang dần bình thường hóa sự hiện diện của trí tuệ nhân tạo. Việc các nhà phát triển nhân Linux thảo luận kế hoạch loại bỏ thẻ “Assisted-By” bắt buộc đối với các đoạn mã có AI hỗ trợ là một tín hiệu điển hình. Khi công cụ đã đi sâu vào từng dòng lệnh hằng ngày, thứ được đem ra nghiệm thu cuối cùng vẫn là chất lượng của đoạn mã trên git diff và khả năng chạy ổn định của hệ thống, chứ không phải danh tính của thực thể đã gõ ra dòng lệnh đó.
Phối hợp nhiều mô hình và bài toán suy luận nội bộ
Trong các bài toán kỹ thuật phức tạp, thói quen giao toàn bộ công việc cho một mô hình duy nhất đang bộc lộ nhiều điểm nghẽn. Thay vào đó, việc phân tách quy trình để từng mô hình đảm nhiệm thế mạnh riêng mang lại hiệu quả rõ rệt hơn.
Simon Willison gần đây chia sẻ cách ông tối ưu hóa hiệu năng cho dự án web-edit: sử dụng GPT-6 Astra để phân tích và xuất báo cáo hiệu năng (profiling) trên nền Python 3.15, sau đó cấp toàn bộ dữ liệu này cho Claude Opus 5.5 để viết lại các đoạn mã nghẽn cổ chai. Việc kết hợp này giúp lập trình viên tận dụng năng lực phân tích dữ liệu thô của mô hình này để dẫn đường cho khả năng tái cấu trúc mã nguồn của mô hình khác, thay vì phụ thuộc hoàn toàn vào một bên cung cấp.
| Mô hình | Đặc điểm kiến trúc hoặc vận hành | Mục đích triển khai phù hợp |
|---|---|---|
| LFM2.5-24B-A2B | 24 tỷ tham số tổng, chỉ kích hoạt 2 tỷ tham số (2B active) | Chạy cục bộ trên CPU/GPU cá nhân, bảo mật dữ liệu, xử lý tác vụ nội bộ |
| Claude Opus 5.5 / GPT-6 Astra | Mô hình biên quy mô lớn trên đám mây | Tái cấu trúc mã nguồn phức tạp, phân tích hiệu năng hệ thống diện rộng |
| Gemini 4 Argon | Cân bằng giữa khả năng giải quyết vấn đề khó và chi phí vòng lặp | Chạy các chuỗi agentic harness dài, yêu cầu kiểm soát ngân sách token |
Tuy nhiên, việc gửi mọi yêu cầu lên đám mây tiềm ẩn rủi ro rò rỉ dữ liệu nhạy cảm và phát sinh chi phí khó lường. Hướng đi khả dĩ cho các tác vụ cần bảo mật là đưa mô hình về chạy trực tiếp trên thiết bị (on-device). Kiến trúc của LFM2.5-24B-A2B từ LiquidAI là một minh chứng đáng chú ý: dù sở hữu tổng quy mô 24 tỷ tham số, mô hình chỉ kích hoạt khoảng 2 tỷ tham số trong mỗi lượt suy luận.
Nhờ cơ chế kích hoạt thưa này, các agent suy luận có thể chạy nhanh trên phần cứng thông thường như CPU và GPU cá nhân mà không đòi hỏi dàn máy chủ đắt đỏ. Đối với các tác vụ nhạy cảm như kiểm tra mã nguồn nội bộ hoặc quản lý khóa bảo mật, việc xử lý cục bộ bằng mô hình nhỏ gọn giải quyết triệt để vấn đề rò rỉ dữ liệu mà các mô hình thương mại qua API vẫn đang khiến giới kỹ thuật e ngại.
Ảo giác giá rẻ và thước đo chi phí thật
Khi tính toán chi phí vận hành agent, số đông thường nhìn vào bảng giá tính trên mỗi triệu token vào/ra do nhà cung cấp công bố. Chẳng hạn, Gemini 4 Argon ra mắt với mức giá 2 USD cho mỗi triệu token đầu vào và 10 USD cho mỗi triệu token đầu ra - mức giá ngang ngửa GPT-6 Sol và chỉ bằng một phần nhỏ so với Claude Fable 5.1 hay GPT-6 Astra, trước khi tăng giá gấp đôi vào ngày 1 tháng 12.
Thế nhưng, đơn giá token rẻ chưa chắc đã giúp hệ thống tiết kiệm ngân sách. Trong một chuỗi thao tác tự hành (agentic harness), chỉ số quyết định tổng chi phí không phải là giá mỗi token đơn lẻ, mà là mô hình cần tiêu tốn bao nhiêu token để hoàn thành xong một mục tiêu. Một mô hình có đơn giá rẻ nhưng suy luận vòng vo, sinh mã lỗi rồi phải chạy lại nhiều lần sẽ đốt ngân sách nhanh hơn nhiều so với một mô hình đắt tiền nhưng xử lý dứt điểm ngay từ lần gọi đầu.
Báo cáo đo kiểm từ Artificial Analysis cho thấy Gemini 4 Argon tiêu tốn 2.407 USD để hoàn thành bộ điểm chuẩn, mức chi phí cạnh tranh sát sao với GLM-5.3 và rẻ hơn đáng kể so với nhiều dòng mô hình đầu bảng khác từ OpenAI hay Anthropic. Thước đo chi phí chạy trên toàn bộ tác vụ thực tế mới là con số các kỹ sư cần nhìn vào khi lập ngân sách hạ tầng.
Lối đi cho các đội ngũ kỹ thuật trong nước
Việc các phòng thí nghiệm lớn phải tìm mua lại dữ liệu từ những startup công nghệ đã đóng cửa cho thấy nguồn dữ liệu huấn luyện công khai chất lượng cao đang cạn dần. Càng về sau, sự chênh lệch về trí thông minh thuần túy giữa các mô hình biên sẽ dần thu hẹp. Lợi thế cạnh tranh thực sự của các nhóm kỹ sư nằm ở kiến trúc điều phối bên ngoài.
Đối với các kỹ sư và nhóm phát triển tại Việt Nam, đây là thời điểm nên rà soát lại cách tích hợp AI vào quy trình làm việc:
- Ngừng xem mô hình ngôn ngữ như một công cụ trò chuyện đơn lẻ; hãy coi nó như một tiến trình không đáng tin cậy cần được bao bọc bởi các bài kiểm thử tự động, linter và git hook nghiêm ngặt.
- Tách bạch rõ luồng công việc: tận dụng các mô hình nhỏ có cơ chế kích hoạt thưa chạy cục bộ để xử lý dữ liệu nhạy cảm, chỉ gọi đến các API đắt đỏ cho những tác vụ thực sự đòi hỏi khả năng lập luận sâu.
- Đo lường chi phí dựa trên tỷ lệ giải quyết thành công tác vụ (cost-per-task) thay vì nhìn vào đơn giá tính trên mỗi triệu token quảng cáo trên trang chủ dịch vụ.
Khi các rào cản hành chính như nhãn dán mã nguồn dần biến mất, sự am hiểu sâu sắc về kiến trúc hệ thống và khả năng kiểm soát chất lượng đầu ra chính là thước đo tay nghề thực chất của người làm kỹ thuật.