Giảm giá GPT-5.6: hướng dẫn định tuyến tác nhân và FinOps

Tổng quan

Đợt giảm giá GPT-5.6 hạ giá API của Luna 80% và của Terra 20%, đồng thời bổ sung chế độ Fast có trả phí cho Sol. Với nhà sáng lập, lãnh đạo RevOps và các đội nền tảng hoặc đội phát triển tác nhân, điều này giúp giảm bớt chi phí tác nhân đang tăng mất kiểm soát, nhưng không tự động khắc phục tình trạng suy luận chậm và đắt đỏ. Hướng dẫn này cung cấp cho bạn một runbook định tuyến theo từng bậc mô hình và một kế hoạch ra quyết định dựa trên chi phí trên mỗi kết quả được chấp nhận.

Theo thông báo ngày 30/7/2026 của OpenAI, khoản tiết kiệm này đến từ những cải tiến trên các mô hình, hệ thống suy luận, phần mềm production và bộ khung chạy tác nhân (agent harness) của hãng. Chỉ Luna và Terra trở nên rẻ hơn. Sol Fast là lựa chọn riêng cho những đội sẵn sàng trả nhiều hơn để có độ trễ thấp hơn.

Bài toán vận hành đó rất quen thuộc với Vanaxity, tác nhân nội dung tự chủ của Van Data Team cho SEO, GEO và AEO. Vanaxity nghiên cứu, viết, minh họa, xuất bản và phân phối nội dung, trong khi các bước duyệt bảo vệ chất lượng. Xem cách Vanaxity biến pipeline dữ liệu, tác nhân AI, tự động hóa quy trình và báo cáo thành một hệ thống xuất bản.

Những điểm cốt lõi cần nắm vững

Bài toán kinh tế mới có lợi cho việc định tuyến có chọn lọc, chứ không phải mặc định giao mọi tác vụ cho mô hình rẻ nhất hay nhanh nhất.

• Chỉ GPT-5.6 Luna và Terra được giảm giá. Giá Sol tiêu chuẩn vẫn giữ nguyên.
• Sol Fast cho tốc độ xử lý nhanh hơn tới 2,5 lần với mức giá gấp 2 lần theo báo cáo.
• Luna phù hợp với khối lượng lớn công việc có phạm vi giới hạn, Terra phù hợp với suy luận tầm trung, còn Sol phù hợp với những bước khó nhất.
• Các đội nên đo chi phí trên mỗi kết quả được chấp nhận, tính trên cả các lần thử lại, công cụ, lượt đánh giá và lượt chuyển cấp.
• Mọi thay đổi định tuyến đều cần khả năng quan sát, kiểm thử hồi quy, quyền truy cập theo nguyên tắc đặc quyền tối thiểu và một lộ trình hoàn tác.

Đợt giảm giá GPT-5.6 đã thay đổi những gì

OpenAI giảm giá Luna và Terra, giữ nguyên Sol tiêu chuẩn và giới thiệu một tùy chọn tốc độ cao cấp chỉ dành cho Sol.

Mọi mức giá dưới đây tính bằng đô la Mỹ trên một triệu token. Bảng so sánh trước và sau tách riêng mức giá được báo cáo với các khuyến nghị định tuyến của Vanaxity.

Dữ kiện được báo cáo: Luna và Terra nay có giá thấp hơn. Điều đó không có nghĩa là Luna hay Terra đã nhanh hơn. Sol tiêu chuẩn giữ nguyên mức giá hiện có, còn Sol Fast mua độ trễ thấp hơn với giá cao hơn.

OpenAI nêu thẳng nguyên tắc vận hành này trong thông báo gốc của hãng:

"Sử dụng AI hiệu quả bắt đầu từ kết quả."

OpenAI cũng cho biết Sol đã tự chủ viết lại và tối ưu các kernel production, thiết kế các thí nghiệm suy luận và giám sát quá trình huấn luyện. Những cải tiến đó làm tăng mức sử dụng GPU và giúp mã production hiệu quả hơn. Phần hiệu quả phục vụ mô hình thu được từ đó đã bù cho đợt giảm giá Luna và Terra.

Phân tích của Vanaxity: Luna nay có thể làm lớp nền rộng hơn nhiều cho các khối lượng công việc chạy liên tục. Terra trở thành lộ trình chuyển cấp tiết kiệm hơn. Sol Fast nên chỉ là ngoại lệ cho những việc khó mà thời gian chờ có chi phí kinh doanh đo lường được.

Token rẻ hơn không bảo đảm kết quả rẻ hơn

Chỉ số tài chính hữu ích là tổng chi phí trên mỗi kết quả được chấp nhận, không phải giá của một lần gọi mô hình riêng lẻ.

Tác nhân tự chủ hiếm khi gửi một yêu cầu rồi dừng. Chúng lập kế hoạch, truy xuất ngữ cảnh, gọi công cụ, kiểm tra phản hồi, thử lại khi lỗi và chuyển cấp những trường hợp chưa chắc chắn. Một lần gọi rẻ có thể trở thành một quy trình tốn kém khi đầu ra yếu kích hoạt các vòng lặp lặp đi lặp lại hoặc khối lượng rà soát lớn của con người.

Hãy dùng công thức vận hành sau:

Chi phí trên mỗi kết quả được chấp nhận = tổng chi phí API mô hình qua mọi lần thử / số đầu ra vượt qua bước nghiệm thu

Định nghĩa "được chấp nhận" thay đổi theo từng quy trình:

• Với marketing, đó có thể là một trang chính xác, đã được duyệt, đã xuất bản, đã được lập chỉ mục và sẵn sàng cho tìm kiếm cũng như trích dẫn của AI.
• Với RevOps, đó có thể là một hồ sơ tài khoản đã được làm giàu dữ liệu, vượt qua kiểm tra schema, kiểm tra nguồn và quy tắc định tuyến.
• Với tác nhân phần mềm, đó có thể là một bản vá vượt qua kiểm thử, rà soát mã, kiểm tra bảo mật và chính sách của kho mã.
• Với tự động hóa bán hàng, đó có thể là một bản tóm tắt tài khoản được nghiên cứu chính xác và được người vận hành phê duyệt để sử dụng.

Hãy xét Maya, một trưởng nhóm RevOps giả định. Ban đầu, tác nhân làm giàu dữ liệu của cô gửi mọi bản ghi sang Sol vì đội ngũ coi trọng chất lượng. Thế nhưng phần lớn bản ghi chỉ cần trích xuất trường dữ liệu và chuẩn hóa schema.

Maya chuyển việc trích xuất có phạm vi giới hạn sang Luna, gửi các bản ghi mơ hồ sang Terra và dành Sol cho những xung đột có hệ quả lớn. Sau đó cô so sánh số bản ghi được chấp nhận, số lần thử lại, độ trễ và gánh nặng rà soát. Tuyến rẻ hơn chỉ được phát hành nếu toàn bộ quy trình được cải thiện.

Nguyên tắc tương tự áp dụng cho nội dung. So sánh Vanaxity với vận hành SEO thủ công nghĩa là xem xét mức độ bao phủ đã được duyệt, đã xuất bản và sẵn sàng cho câu trả lời, chứ không phải đếm xem một tác nhân tạo ra bao nhiêu bản nháp giá rẻ.

Định tuyến từng bước theo độ phức tạp, rủi ro và mức độ khẩn cấp

Chính sách định tuyến mô hình an toàn nhất là dùng bậc có chi phí thấp nhất mà vẫn vượt qua bước đánh giá của quy trình một cách ổn định.

Bảng quyết định sau là điểm khởi đầu do Vanaxity khuyến nghị. Đây không phải là hướng dẫn định tuyến do OpenAI quy định.

Chính sách này có thể nằm phía trên LangGraph, LangChain, CrewAI, cơ chế gọi hàm tích hợp sẵn (native function calling), các công cụ kết nối qua MCP hoặc mẫu Plan-and-Execute. Framework kiểm soát trạng thái và việc thực thi. Chính sách định tuyến quyết định mô hình nào xử lý từng bước.

Sự tách biệt đó rất quan trọng. Các đội cần có khả năng thay đổi một tuyến mà không phải viết lại toàn bộ tác nhân. Họ cũng nên so sánh chi phí, độ trễ, ngân sách token, khả năng quan sát và kết quả đánh giá trong cùng điều kiện quy trình.

Một tác nhân marketing có thể dùng Luna để phân loại ý định tìm kiếm và chuẩn hóa dữ liệu nguồn. Terra có thể tổng hợp các bằng chứng trái chiều hoặc điều chỉnh một bản brief cho nhiều kênh. Sol xử lý những vấn đề định vị khó, mâu thuẫn kỹ thuật hoặc lượt rà soát rủi ro cao cuối cùng.

Với công việc phần mềm, Luna có thể xử lý metadata của kho mã và các tác vụ bảo trì có phạm vi giới hạn. Terra có thể phân tích các phụ thuộc hoặc điều tra một quy trình đang lỗi. Sol xử lý việc gỡ lỗi khó và các quyết định kiến trúc. Sol Fast chỉ đáng thử khi thời gian phản hồi làm nghẽn người vận hành hoặc việc khôi phục production.

Hợp nhất FinOps, khả năng quan sát và quản trị thành một hệ thống

FinOps cho tác nhân AI chỉ hiệu quả khi ngân sách, dữ liệu đo lường từ xa (telemetry), đánh giá, chất lượng dữ liệu và quyền truy cập dùng chung một vòng kiểm soát.

Hãy bắt đầu bằng việc đặt ngân sách token cho toàn bộ quy trình. Tính cả chỉ dẫn hệ thống, ngữ cảnh truy xuất được, kết quả công cụ, các lần thử lại, lượt gọi bộ đánh giá và prompt chuyển cấp. Ngân sách ở cấp từng prompt sẽ bỏ sót chi phí phát sinh từ vòng lặp tác nhân bao quanh prompt đó.

Dùng các chế độ xử lý rẻ hơn khi độ trễ cho phép. Batch API giảm tới 50% cho đầu vào và đầu ra với công việc bất đồng bộ. Lượt đọc đầu vào từ bộ nhớ đệm có giá thấp hơn 90% so với mức giá đầu vào tiêu chuẩn, còn lượt ghi vào bộ nhớ đệm có giá bằng 1,25 lần mức giá không dùng bộ nhớ đệm.

Xử lý theo lô phù hợp với phân loại chạy nền, làm giàu nội dung, bộ đánh giá và báo cáo định kỳ. Lưu đệm prompt (prompt caching) phù hợp với chỉ dẫn ổn định, schema, chính sách và tài liệu tham chiếu lặp lại. Hãy xác nhận điều kiện áp dụng và điều khoản giá hiện hành trước khi giả định rằng các mức giảm giá riêng lẻ có thể cộng dồn.

Về khả năng quan sát, hãy ghi lại quy trình, mô hình được chọn, lý do định tuyến, phiên bản prompt, lượng token sử dụng, hành vi bộ nhớ đệm, lệnh gọi công cụ, số lần thử lại, độ trễ, kết quả đánh giá và kết quả nghiệm thu cuối cùng. Tổng hợp các trường đó vào một dashboard theo kết quả. Riêng hóa đơn của nhà cung cấp không thể cho thấy hành vi nào của tác nhân đã tạo ra khoản chi.

Đánh giá phải đi trước việc chuyển đổi vì lý do giá. Chạy tuyến được đề xuất trên một bộ tác vụ đại diện, gồm công việc bình thường, đầu vào mơ hồ, lỗi công cụ và các trường hợp nhạy cảm về an toàn. So sánh chất lượng, độ trễ, chi phí, tỷ lệ chuyển cấp và gánh nặng rà soát của con người với mốc cơ sở hiện tại.

Quản trị phải nằm trong cùng thiết kế đó. Cấp cho mỗi tác nhân quyền API, dữ liệu và công cụ hẹp nhất cần cho vai trò của nó. Tách thông tin xác thực theo môi trường, hạn chế các thao tác ghi và yêu cầu phê duyệt trước những thay đổi bên ngoài có hệ quả.

Đầu ra của tác nhân cũng phụ thuộc vào những gì mô hình đọc. Chất lượng, độ mới, nguồn gốc dữ liệu, quyền sở hữu và SLA của feed và chỉ mục là những phụ thuộc của production. Ngay cả một tuyến được thiết kế tinh vi cũng không cứu được dữ liệu sản phẩm lỗi thời, bản ghi CRM trùng lặp hay chỉ mục tìm kiếm có nguồn gốc không rõ ràng.

Tại Van Data Team, chúng tôi bắt đầu từ bước nghiệm thu, rồi đi ngược lại tới pipeline dữ liệu, cách định tuyến, cơ chế kiểm soát rà soát và dashboard. Bạn có thể xem quy trình tác nhân đó vận hành thực tế trước khi áp dụng cách làm này cho hệ thống của riêng bạn.

Danh sách kiểm tra định tuyến và kết quả

Một thay đổi định tuyến chỉ sẵn sàng cho production khi quy tắc nghiệm thu, ngân sách, bằng chứng, quyền truy cập và điều kiện hoàn tác của nó đều được nêu rõ.

Hãy dùng bảng quyết định ở trên cùng với danh sách kiểm tra triển khai sau:

Trước khi thay đổi tuyến

• [ ] Xác định kết quả kinh doanh được chấp nhận bằng các tiêu chí có thể kiểm thử.
• [ ] Ghi lại mốc cơ sở về chi phí mô hình, độ trễ, số lần thử lại, số lần chuyển cấp và gánh nặng rà soát.
• [ ] Đặt ngân sách token cho toàn bộ quy trình.
• [ ] Phân loại tác vụ theo độ phức tạp, mức độ bất định, mức độ khẩn cấp và chi phí khi xảy ra lỗi.
• [ ] Xác nhận độ mới, nguồn gốc, quyền sở hữu và kỳ vọng dịch vụ của dữ liệu nguồn.
• [ ] Chọn bậc thấp nhất hiện đang vượt qua bước đánh giá.

Trong quá trình kiểm chứng

• [ ] Xác định điều kiện nâng từ Luna lên Terra và từ Terra lên Sol.
• [ ] Xác định cách xử lý dự phòng khi gặp lỗi công cụ, đầu ra sai định dạng và hết thời gian chờ.
• [ ] Chỉ thử Sol Fast với những việc của Sol nhạy cảm về độ trễ.
• [ ] Ghi log việc chọn mô hình, lý do định tuyến, quyền truy cập công cụ và kết quả nghiệm thu cuối cùng.
• [ ] Áp dụng thông tin xác thực và quyền dùng công cụ theo nguyên tắc đặc quyền tối thiểu.
• [ ] Chạy kiểm thử hồi quy trên các tác vụ đại diện và tác vụ khó.

Trước khi phát hành lên production

• [ ] Tính tổng chi phí API chia cho số kết quả được chấp nhận.
• [ ] So sánh chi phí, độ trễ, chất lượng và gánh nặng rà soát với mốc cơ sở.
• [ ] Xác nhận dashboard quan sát có thể làm lộ ra lỗi ở cấp từng tuyến.
• [ ] Hoàn tác nếu muốn có khoản tiết kiệm thì phải chịu mức suy giảm về chất lượng hoặc quản trị không thể chấp nhận.

Các kiểu thất bại thường gặp gồm định tuyến mọi thứ sang Luna vì rẻ, hoặc định tuyến mọi thứ sang Sol vì cảm thấy an toàn hơn. Cả hai đều bỏ qua cấu trúc của tác vụ. Chuyển cấp không có bước kiểm soát cũng có thể biến một quy trình tiết kiệm thành một khối lượng công việc Sol ẩn.

Một sai lầm khác là bật Sol Fast ở mọi nơi. Suy luận nhanh hơn chỉ có giá trị khi việc chờ đợi ảnh hưởng đến kết quả được chấp nhận. Nghiên cứu chạy nền, làm giàu dữ liệu và đánh giá thường được lợi nhiều hơn từ xử lý qua Batch API.

Cuối cùng, đừng để thay đổi về giá khiến bạn bỏ qua quản trị. Một mô hình rẻ hơn vẫn cần quyền truy cập dữ liệu hẹp, giới hạn công cụ, bước đánh giá và khả năng khôi phục sau sự cố.

Bạn muốn áp dụng tài liệu này vào hệ thống của mình? Hãy yêu cầu một đợt kiểm tra quy trình miễn phí qua các gói giá và phương án triển khai của Vanaxity. Bạn sẽ nhận được bản đồ định tuyến, kế hoạch ngân sách token, bản rà soát khoảng trống dashboard, thiết kế đánh giá và quy trình rà soát rủi ro có phạm vi rõ ràng.

Câu hỏi thường gặp

Nguồn tham khảo