ทุกการเรียกที่ผ่านการรับเข้าใช้สร้าง usage record ทันทีที่รับเข้า ก่อนมี provider I/O บันทึกนี้คือสิ่งที่ใช้คิดเงิน สิ่งที่ ขีดจำกัด นับ และสิ่งที่ใช้ตอบคำถามว่า “ทำไมจึงมีค่าใช้จ่ายนี้”
วิธีคิดค่าใช้จ่ายของการเรียก#
การคิดเงินเป็น reserve → settle → release ในหน่วย micro-USD จำนวนเต็ม (1 USD = 1,000,000 micro-USD):
- Reserve การรับเข้าใช้คำนวณค่าประมาณแบบเผื่อไว้ คือเพดานของ input รวมกับ requested output limit (1,024 tokens หากไม่ตั้ง
max_tokens) แล้วกันยอดจากกระเป๋าเงินของโปรเจกต์ ทุกการเรียกกันอย่างน้อยหนึ่ง micro-USD ดังนั้นแม้ราคาที่ปัดเป็นศูนย์ก็ต้องมีกระเป๋าเงินที่มีเงิน - Settle verified usage จากผู้ให้บริการแทนที่ค่าประมาณด้วยยอดจริง ผลิตภัณฑ์ที่คิดตาม token วัด input และ output token แยกกันตามอัตราต่อหนึ่งล้าน token ที่เผยแพร่ ส่วนผลิตภัณฑ์ต่อคำขอคิดราคาคงที่
- Release ยอดที่กันไว้เกินกว่าค่าใช้จ่ายจริงจะคืนไปยัง available balance ของกระเป๋าเงิน
คุณถูกคิดเงินจากการใช้งานจริง ไม่ใช่ค่าประมาณ reservation มีไว้หยุดการเรียกที่ไม่มีทางจ่ายไหว ไม่ได้มีไว้ตั้งราคา
เมื่อผลลัพธ์ไม่แน่ชัด#
การเรียกที่ล้มเหลวไม่ได้ฟรีโดยอัตโนมัติ และระบบจะไม่ retry โดยคิดเงินคุณ:
- Definite failure — pre-dispatch error ที่ทราบ หรือ provider 4xx ที่ชัดเจน จะปล่อย reservation คืนทั้งหมด ยอดคิดเงินเป็นศูนย์
- Uncertain outcome — timeout, การตอบกลับไม่สมบูรณ์หรือ 5xx, stream ที่จบโดยไม่มี usage จะคง reservation ไว้เป็น Reconciling ไม่มี automatic paid retry
การเรียกที่ไม่แน่ชัดเข้าสู่ reconciliation queue ที่ platform administrator ดูแล มนุษย์ตรวจหลักฐาน upstream บันทึกเหตุผล แล้วคิดยอดที่ยืนยันได้ (ไม่เกินยอดที่กันไว้) หรือปล่อยคืน reservation ที่ถูกทิ้งไว้ห้านาทีจะมีสิทธิ์ให้ตรวจสอบ การเรียกที่เสร็จแล้วจะ settle หรือ reconcile ซ้ำไม่ได้ มุมมอง usage แสดงรายการเหล่านี้เป็น held จนกว่าจะเสร็จ ยอดยังไม่ถูกใช้และยังใช้ไม่ได้
รหัส invocation#
ทุกการตอบกลับที่รับเข้าใช้แล้วมี X-AIGrid-Invocation ซึ่งกำหนดก่อนเรียกผู้ให้บริการ รหัสนี้คือ id ของ usage record และ streamed error frame จะส่งรหัสนี้ซ้ำ ดังนั้นคำตอบที่ล้มเหลว ถูกตัด หรือขาดตอนยังให้จุดติดตามแก่คุณ
เก็บรหัสนี้ไว้ คำตอบที่ล้มเหลวไม่ได้แปลว่าไม่ได้คิดเงิน หาก client ตัดการเชื่อมต่อระหว่าง stream server จะระบายข้อมูลจากผู้ให้บริการต่อและ settle ค่าใช้จ่าย เมื่อมีคำถามเรื่องยอด invocation id คือสิ่งแรกที่ใช้ค้นหาและสิ่งแรกที่ฝ่ายช่วยเหลือจะถาม
อ่านข้อมูลการใช้งาน#
/api/v2/tenants/{tenantID}/usage/api/v2/tenants/{tenantID}/consumption/{callID}/api/v2/tenants/{tenantID}/projects/{projectID}/budget| มุมมอง | สิ่งที่แสดง |
|---|---|
| Usage list | หนึ่งแถวต่อการเรียก: เวลา, โปรเจกต์, ผู้ใช้หรือ key prefix, product, modality, มี stream หรือไม่, status, tokens, latency และ micro-USD ที่กันไว้/คิดเงิน |
| Request detail | หนึ่งการเรียก: reservedMicro, chargedMicro, releasedMicro, เป็น held หรือ settled, ผลลัพธ์จากผู้ให้บริการ, คำอธิบายที่ปลอดภัย และ audit event ของ invocation |
| Project budget | fundedMicro, chargedMicro, reservedMicro, availableMicro — สิ่งที่กระเป๋าเงินมี ค้างอยู่ และยังใช้ได้ |
การเรียกที่ยังรอ reservation แสดง hold ไม่ใช่ค่าใช้จ่ายที่ยังไม่เกิดขึ้น
ใครดูอะไรได้#
| มุมมอง | ผู้ที่ดูได้ |
|---|---|
| Organization usage | organization Owner · Administrator |
| การเรียกของตนเอง | สมาชิกทุกคน |
| Request detail | ผู้เรียก หรือ Owner/Administrator — บุคคลอื่นได้รับ 404 |
มุมมองระดับองค์กรเป็นการกำกับดูแล ไม่ใช่สิทธิ์ใช้จ่าย การอ่านทุกแถวไม่ได้ให้สิทธิ์เรียกใช้หรือเติมเงิน
ขั้นตอนถัดไป#
- Caps and spend controls — จำกัดค่าใช้จ่ายก่อนเกิดขึ้น
- ข้อผิดพลาด — ทุกรหัสที่ผู้เรียกอาจเห็น และสิ่งที่แก้ได้