Chi phí API phát triển game bằng AI

Ước tính cả quy trình, không chỉ prompt ban đầu

Một phiên phát triển game có thể liên tục đọc mã nguồn, đề xuất chỉnh sửa, diễn giải lỗi engine, kiểm tra ảnh chụp và thử lại công việc thất bại. Brief ban đầu chỉ là một đầu vào. Bắt đầu lập ngân sách bằng một cột mốc nhỏ đã chấp nhận, chẳng hạn một vòng hoàn chỉnh và khởi động lại, thay vì giả định một yêu cầu sẽ tạo ra sản phẩm bàn giao.

Liệt kê các giai đoạn bạn dự kiến phải trả tiền: triển khai, gỡ lỗi, tài nguyên, bản địa hóa và rà soát. Đánh dấu giai đoạn nào chạy cục bộ và giai đoạn nào gọi dịch vụ tính phí. Dùng thử nghiệm thí điểm để biết mức sử dụng tích lũy ở đâu trước khi phê duyệt ngân sách lớn; ước tính phải mô tả giả định thay vì giống một hóa đơn đã đo.

Giữ sổ cái riêng cho các tài nguyên riêng

Dùng các danh mục riêng cho lần gọi mô hình văn bản, tạo hình ảnh, dịch vụ âm thanh, công việc engine cục bộ và can thiệp của con người. Biên dịch cục bộ không tự nhiên tiêu thụ token mô hình, trong khi gửi log của nó cho agent có thể tạo một yêu cầu khác. Một trợ lý có thể điều phối mọi hoạt động này mà không khiến đơn vị thanh toán của chúng giống nhau.

Tách hoạt động thuê bao khỏi mức sử dụng API. Nếu phân bổ một phần thuê bao cho dự án để lập ngân sách nội bộ, hãy gắn nhãn đó là quy tắc phân bổ, không phải phí mỗi yêu cầu được quan sát. Tương tự, đừng tính chi phí API của một nhiệm vụ phát triển là chi phí phát sinh cho mọi người chơi tương lai của game ngoại tuyến.

Ghi bản ghi yêu cầu trước khi tổng hợp

Gán mã định danh lần chạy và giai đoạn cho từng thao tác. Giữ các mã định danh yêu cầu của nhà cung cấp khi có, danh tính mô hình thực tế, kết quả, mức sử dụng và tham chiếu tới bằng chứng thanh toán. Làm sạch thông tin xác thực trước khi xuất log. Bản ghi minh họa bên dưới cố ý để các giá trị chưa quan sát là null.

Đừng suy ra yêu cầu thành công từ tệp cục bộ đã chấp nhận hoặc suy ra phí bằng không từ timeout. Một phần mức sử dụng có thể đến sau khi client mất kết nối. Đối soát bản ghi của nhà cung cấp trước khi chốt tổng và giữ các mục chưa khớp hiển thị. Nhờ vậy các thử nghiệm lặp lại có thể so sánh mà không biến khoảng trống telemetry thành khoản tiết kiệm hiển nhiên.

{
  "run_id": "game-pilot",
  "stage": "controller-repair",
  "provider_request_id": null,
  "model_id": null,
  "outcome": "not_started",
  "usage": null,
  "billed_amount": null,
  "currency": null,
  "billing_evidence": null,
  "accepted_artifact_hash": null
}

Áp dụng hợp đồng giá thực tế của nhà cung cấp

Dùng nhà cung cấp và tầng dịch vụ đã xử lý yêu cầu, cùng biểu giá áp dụng cho bản ghi thanh toán đó. Giá chính thức của OpenAI mô tả các danh mục token và công cụ; giá APIsRouter là một nguồn thương mại riêng. Không được âm thầm thay thế nguồn này cho nguồn kia.

Với ước tính, nhân từng danh mục tính phí với mức áp dụng rồi cộng các khoản riêng của dịch vụ. Kiểm tra cách nhà cung cấp báo cáo input được lưu trong cache, output và mức sử dụng công cụ để không đếm hai lần. Làm rõ tiền tệ và giả định chuyển đổi. Ưu tiên khoản phí đã quyết toán của nhà cung cấp khi đối soát chi tiêu thực tế và giữ ước tính riêng để giải thích chênh lệch.

Đặt điều kiện dừng quanh vòng lặp sửa lỗi

Đặt trần ngân sách và một điểm kiểm tra sau mỗi cột mốc được chấp nhận. Giới hạn thử lại tự động và quyết định triệu chứng nào kích hoạt chẩn đoán của con người, chẳng hạn các lần sửa lặp lại nhưng không thay đổi reproduction. Kiểm soát chi tiêu của nhà cung cấp và giới hạn nhiệm vụ agent bảo vệ những ranh giới khác nhau; dùng cả hai khi có và xác minh hành vi của từng cái.

Giảm ngữ cảnh không cần thiết bằng cách gửi cảnh liên quan, tệp đã đổi và lỗi có ý nghĩa đầu tiên. Giữ đủ trạng thái để không lặp lại cách tiếp cận thất bại. Đừng xóa bằng chứng quan trọng chỉ để rút ngắn đầu vào: một yêu cầu rẻ hơn nhưng tạo thêm lần sửa mù có thể làm tăng chi phí của kết quả đã chấp nhận.

So sánh mô hình trên cùng đường chấp nhận

Giữ brief, đường cơ sở dự án, đích và tiêu chí chấp nhận không đổi. Ghi lại lần thử thất bại và hỗ trợ của con người cho từng mô hình. So sánh tổng chi tiêu đã đối soát và hành vi đã chấp nhận, không chỉ giá token hay chất lượng biểu kiến của phản hồi đầu tiên.

Chỉ phân công các loại nhiệm vụ khác nhau sau khi thí điểm cho thấy chúng đạt tiêu chuẩn cần thiết. Xử lý chuỗi đơn giản, chẩn đoán gameplay khó và rà soát hình ảnh có thể có nhu cầu khác nhau. Mô hình mạnh hơn có thể giảm số vòng lặp, nhưng đó vẫn là giả thuyết cho đến khi bản ghi cùng nhiệm vụ ủng hộ. Tránh danh sách mô hình khuyến nghị cuốn chiếu trở nên lỗi thời hoặc hàm ý khả dụng chưa được xác minh.

Tách sản xuất game khỏi kinh tế runtime

Game ngoại tuyến đã xuất có thể dùng logic xác định thông thường sau khi phát triển. Nếu thêm hội thoại do mô hình tạo trực tiếp hoặc tính năng runtime khác, hãy tạo ngân sách riêng bao quát hành vi người chơi, lỗi dịch vụ, kiểm soát lạm dụng và vận hành liên tục. Giữ bí mật sau ranh giới dịch vụ phù hợp thay vì nhúng khóa nhà cung cấp vào client game.

Đừng ước tính ngân sách runtime bằng cách nhân token phát triển với doanh số. Đo mẫu yêu cầu thực tế của tính năng trong thử nghiệm được ủy quyền và rà soát yêu cầu nền tảng áp dụng. Tài nguyên hình ảnh tạo một lần trong sản xuất và hình ảnh tạo cho người chơi khi runtime cũng thuộc các mô hình chi phí khác nhau.

Bằng chứng và ca Astra

Danh tính mô hình của nguyên mẫu game vẫn chưa được xác minh cho đến khi gắn bằng chứng Astra rõ ràng. Xác nhận nhà cung cấp thực tế, chế độ truy cập và danh tính mô hình trước khi áp dụng bất kỳ mức giá nào cho ca đó. Dùng bản ghi thanh toán của nhà cung cấp thay vì suy ra phí từ mô hình được nêu trong brief phát triển.

Trang này không có ngân sách game được đo. Sổ cái và các bước lập ngân sách là phương pháp để thu được ngân sách đó. Báo cáo cuối hữu ích sẽ nêu cột mốc đã chấp nhận, danh tính artifact, chi tiêu API thực tế, phí tài nguyên riêng, công việc con người và các mục thanh toán chưa giải quyết để người đọc đánh giá khoản chi đã đạt gì.

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