Một yêu cầu gửi tới Opus 5.5 có thể do Opus 4.8 xử lý không?

Có. Ghi chú ra mắt của Anthropic có một chú thích cuối trang nói rằng một số yêu cầu Opus 5.5 có thể được chuyển sang Opus 4.8 trong giai đoạn chuyển tiếp. Endpoint của model là alias, không phải đảm bảo về phiên bản.

Làm sao để biết model nào thực sự đã xử lý một yêu cầu?

Đọc trường model trong nội dung phản hồi của API. Ghi log trường này cho mọi lời gọi và tách mọi chỉ số chi phí theo model đã phân giải thay vì model đã yêu cầu.

Điều này có ảnh hưởng đến model của OpenAI không?

Có. Cùng cách vận hành alias và chuyển tiếp áp dụng cho nhiều nhà cung cấp, bao gồm đợt ra mắt GPT-6 Sol và Luna ngày 22 tháng 9 năm 2026. Hãy ghim model ID có ngày cho mọi thứ bạn lập ngân sách hoặc đánh giá.

Vì sao mức tiết kiệm chi phí mỗi tác vụ của tôi thấp hơn con số 40% được quảng cáo?

Nhiều khả năng là do trộn phiên bản. Con số rẻ hơn 40% là trung bình trên khối lượng công việc thông thường, vốn giả định số token giảm đi. Nếu các model rẻ hơn nhưng cũ hơn tạo ra câu trả lời dài hơn, mức tiết kiệm đã trộn sẽ thu hẹp lại.

Hạ cấp model âm thầm và mô hình chi phí

Cập nhật September 27, 2026 · đăng lần đầu September 27, 2026

Ngày 23 tháng 9 năm 2026, một thread trên r/GroundTruthAINews đã chỉ ra một chú thích cuối trang được giấu trong ghi chú ra mắt Opus 5.5 của Anthropic: một yêu cầu gửi tới Opus 5.5 có thể được xử lý bởi Opus 4.8. Anthropic và OpenAI đều công bố giảm giá trong cùng một buổi chiều. Cả hai hãng cùng bán một ý tưởng: giữ nguyên năng lực, chi tiêu ít hơn nhiều. Chú thích cuối trang mới là phần quan trọng với FinOps.

Thực tế đã xảy ra gì

Claude Opus 5.5 ra mắt với giá $4/$20 cho mỗi triệu token, thấp hơn Opus 5 khoảng 20%, và giá đọc cache giảm 60% xuống còn $0.20. Anthropic cho rằng số token ít hơn cho mỗi tác vụ cùng tốc độ đầu ra nhanh hơn 30% giúp các khối lượng công việc thông thường rẻ hơn khoảng 40%. Khoảng 90 phút sau, OpenAI ra mắt GPT-6 Sol với giá $2/$10 và Luna với giá $0.10/$0.50, cả hai đều bằng một nửa giá của GPT-5.6.

Mọi bài công bố ra mắt trong giai đoạn này đều có cùng một loại chú thích: endpoint bạn gọi là một alias, và alias này được cân bằng tải giữa nhiều phiên bản model trong một khoảng thời gian chuyển tiếp. Đây là cách vận hành năng lực thông thường. Nhưng nó cũng là một vấn đề đối với việc mô hình hóa chi phí.

Vì sao nó phá vỡ các con số

Chi phí mỗi tác vụ bị trôi. Dự báo của bạn giả định giá đầu ra của Opus 5.5. Nếu một phần lời gọi rơi vào 4.8, cả đơn giá lẫn số token đều thay đổi, theo hai hướng ngược nhau.
Eval đo một hỗn hợp. Một bộ eval chạy trong khoảng thời gian chuyển tiếp sẽ chấm điểm trên tổ hợp nhiều phiên bản. Điểm số đó không thể tái lập về sau.
Giảm giá bị ghi nhận sai. Nếu mức tiết kiệm 40% chỉ hiện ra là 15%, khoảng chênh lệch thường đến từ việc trộn phiên bản chứ không phải một tối ưu hóa bị hỏng.
Mốc độ trễ bị lỗi thời. 4.8 không nhanh bằng 5.5. Mọi p50 bạn đo được giữa giai đoạn chuyển tiếp đều không phải p50 ở trạng thái ổn định.

Cách phát hiện việc hoán đổi

Mọi nhà cung cấp lớn đều trả về model đã được phân giải trong nội dung phản hồi. Hãy ghi log lại. Một trường, bốn dòng code:

resolved = response.model  # e.g. "claude-opus-4-8-20260115"
assert resolved.startswith(EXPECTED_PREFIX) or resolved in ALLOWED_FALLBACKS

Sau đó, hãy tách mọi chỉ số chi phí theo model đã phân giải, không theo model bạn yêu cầu. Ngay khi một nhóm bắt đầu trôi, bạn đã có câu trả lời: alias đang trộn các phiên bản và chi phí mỗi tác vụ của bạn là trung bình có trọng số của hai sản phẩm khác nhau.

Hệ quả đối với ngân sách

Trong giai đoạn chuyển tiếp, hãy lập kế hoạch theo chi phí đã trộn, không theo con số quảng cáo. Nếu 20% lời gọi chuyển sang một model cũ hơn, đơn giá đầu vào thực tế của bạn không phải $4.00 cho mỗi triệu token mà là mức do tổ hợp đó tạo ra. Logic tương tự cũng áp dụng cho mức tiết kiệm được quảng cáo: con số rẻ hơn 40% là trung bình trên khối lượng công việc thông thường, vốn đã giả định số token giảm đi. Giả định này có thể không đúng nếu chính model rẻ hơn nhưng cũ hơn lại là model tạo ra các câu trả lời dài hơn.

Các quy tắc cần giữ

Không bao giờ mô hình hóa trên alias. Ghim một model ID có ngày cụ thể cho mọi thứ bạn lập ngân sách hoặc đánh giá.
Ghi log model đã phân giải cho mọi request. Đây là điều bắt buộc nếu bạn từng chạy lại một eval.
Thiết lập lại mốc cơ sở sau khi hết giai đoạn chuyển tiếp. Thông thường kéo dài vài tuần chứ không phải vài quý, nhưng hãy xác nhận lại.
Định giá giai đoạn chuyển tiếp như một hỗn hợp. Hỏi nhà cung cấp tỷ lệ phân bổ dự kiến, hoặc tự đo.

Kết luận

Một đợt giảm giá và một lần hạ cấp âm thầm có thể xảy ra trong cùng một buổi chiều. Giảm giá là tiêu đề; hạ cấp là chú thích cuối trang lặng lẽ làm mất hiệu lực dự báo của tháng trước. Hãy ghi log model đã phân giải, ghim các ID có ngày và định giá phần hỗn hợp.

Liên quan

Bạn muốn áp dụng điều này cho hệ thống của mình? Hãy mang theo hóa đơn nhà cung cấp, nhật ký gateway và các quy trình chính; chúng tôi sẽ xác định yếu tố chi phí và hướng tiết kiệm. Đặt lịch kiểm toán miễn phí →

Quay lại finopsllm.com