ลิงก์สำคัญ
แดชบอร์ดสถานะบริการ (ขณะนี้มีให้ใช้เฉพาะลูกค้า Enterprise API เท่านั้น)
เริ่มต้นด้วยค่าเริ่มต้นที่เหมาะสม
เมื่อคุณเปิดแดชบอร์ดสถานะบริการ ค่าเริ่มต้นคือ:
โปรเจ็กต์ทั้งหมด
30 วันที่ผ่านมา
ความละเอียดรายชั่วโมง
มุมมองนี้มีประโยชน์เพื่อการทำความเข้าใจเบื้องต้นเท่านั้น การแก้ไขปัญหาอย่างมีความหมายต้องใช้การกรองเสมอ
กรองก่อนตรวจสอบ
การกรองให้ถูกต้องคือขั้นตอนที่สำคัญที่สุด การตีความผิดส่วนใหญ่มาจากการปะปนโมเดล ประเภทของแพ็กเกจ หรือโปรเจ็กต์
กรองตามโมเดล (ครั้งละหนึ่งโมเดล)
กรองให้เหลือโมเดลเดียวเสมอ
เหตุผล:
ปัญหาในโมเดลที่มีทราฟฟิกต่ำอาจถูกซ่อนโดยทราฟฟิกปริมาณสูงกว่า
โมเดลที่มีปริมาณสูงอาจทำให้ปัญหาเฉพาะจุดดูเหมือนเป็นปัญหาทั่วทั้งระบบ
โมเดลต่างกันมีเป้าหมายด้านประสิทธิภาพต่างกัน
หมายเหตุ: การเลือกหลายโมเดลจะเป็นการรวมข้อมูล ไม่ใช่การสลับระหว่างโมเดลเหล่านั้น
กรองตามประเภทของแพ็กเกจ
หากคุณใช้มากกว่าหนึ่งประเภทของแพ็กเกจ (standard, priority, scale) ให้กรองไปยังประเภทที่คุณกำลังตรวจสอบเสมอ
เหตุผล:
ประเภทของแพ็กเกจมีลักษณะประสิทธิภาพต่างกัน
ประเภท priority และ scale มี SLA ที่กำหนดไว้
การปะปนประเภทของแพ็กเกจทำให้ประสิทธิภาพของระดับแบบชำระเงินไม่ชัดเจน
สิ่งนี้สำคัญเป็นพิเศษสำหรับการวิเคราะห์เวลาแฝง
กรองตามโปรเจ็กต์
ตามค่าเริ่มต้น สถานะบริการจะแสดงโปรเจ็กต์ทั้งหมด
สำหรับการแก้ไขปัญหา ให้กรองไปยังโปรเจ็กต์ที่พบปัญหา
เหตุผล:
โปรเจ็กต์เดียวที่มีปริมาณสูงอาจครอบงำเมตริกได้
โปรเจ็กต์ขนาดเล็กที่ได้รับผลกระทบอาจถูกทราฟฟิกที่ไม่เกี่ยวข้องบดบัง
เลือก “โปรเจ็กต์ทั้งหมด” ไว้เฉพาะเมื่อคุณเชื่อว่าปัญหานั้นเกิดทั่วทั้งองค์กรจริง ๆ
การแก้ไขปัญหาข้อผิดพลาด
ใช้มุมมองคำขอ HTTP
หากต้องการตรวจสอบข้อผิดพลาด:
กรองตามโมเดลและประเภทของแพ็กเกจ
เปิดแท็บ HTTP Requests แทนแท็บ Uptime
มุมมองนี้แสดงจำนวนคำขอทั้งหมดและจำนวนข้อผิดพลาดตามรหัสสถานะ HTTP ซูมไปที่ความละเอียดระดับนาทีเพื่อระบุการเพิ่มขึ้นอย่างฉับพลันหรือการเปลี่ยนแปลงแบบละเอียด
ตีความอัตราข้อผิดพลาด ไม่ใช่จำนวน
ข้อผิดพลาดบางส่วนเป็นสิ่งที่คาดได้ในระบบที่ใช้งานจริงทุกระบบ มุ่งเน้นที่ เปอร์เซ็นต์ ข้อผิดพลาด ไม่ใช่ยอดรวมดิบ
ยิ่งปริมาณรวมของคุณมาก จำนวนข้อผิดพลาดที่อาจเกิดขึ้นก็ยิ่งมาก แม้อัตราข้อผิดพลาดจะต่ำมากก็ตาม
เมื่อข้อผิดพลาดไม่ปรากฏในสถานะบริการ
หากคุณเห็นข้อผิดพลาดฝั่งไคลเอ็นต์แต่ไม่มีข้อมูลที่สอดคล้องกันในสถานะบริการ:
คำขอน่าจะไปไม่ถึง OpenAI
ปัญหามักอยู่ที่ต้นทาง (หมดเวลา พร็อกซี เครือข่าย)
สิ่งนี้พบได้บ่อยเมื่อไคลเอ็นต์ตั้งค่าการหมดเวลาเข้มงวดเกินไป
การแก้ไขปัญหาเวลาแฝง
การวิเคราะห์เวลาแฝงมีความหมายมากที่สุดในประเภทของแพ็กเกจ priority และ scale ซึ่งมี SLA ที่กำหนดไว้ ระดับมาตรฐานอาจมีความแปรผันของเวลาแฝงมากกว่า และไม่มีการรับประกันเวลาแฝง
เมตริกสำคัญ
หากต้องการดูแต่ละเมตริก ให้คลิกแท็บที่เกี่ยวข้อง:
ความเร็วของ Token: จำนวน Token ที่สร้างต่อวินาที ไม่ขึ้นกับขนาดคำสั่ง
Request Time: ระยะเวลารวมของคำขอ ได้รับผลกระทบอย่างมากจากขนาดเอาต์พุตและการให้เหตุผล
Time to First Token (TTFT): เวลาจนกว่า Token แรกจะถูกสร้าง ได้รับผลกระทบอย่างมากจากขนาดคำสั่งอินพุตที่ไม่ได้แคชและการให้เหตุผล
ตรวจสอบเปอร์เซ็นไทล์ P50 / P75 / P95 เสมอ ค่าเฉลี่ยอาจซ่อนผลกระทบต่อผู้ใช้จริงได้
6. การเชื่อมโยงเวลาแฝงกับการใช้ Token
สถานะบริการแสดงว่าพฤติกรรมเปลี่ยนไป เมื่อใด ข้อมูลการใช้งานช่วยอธิบายว่า เพราะเหตุใด
ในแดชบอร์ดการใช้งาน ให้ทำดังต่อไปนี้เพื่อให้แน่ใจว่าคุณกำลังดูข้อมูลที่เกี่ยวข้องกับมุมมองของคุณในแดชบอร์ดสถานะบริการ:
กรองเป็นโปรเจ็กต์และโมเดลเดียวกัน
จัดกลุ่มตามประเภทของแพ็กเกจ หากเกี่ยวข้อง
มุ่งเน้นที่ Token เอาต์พุต ซึ่งส่งผลต่อเวลาแฝงมากที่สุด
สำหรับการวิเคราะห์เชิงลึกยิ่งขึ้น ให้ส่งออก Activity Data และตรวจสอบ Token ต่อคำขอตามเวลา
7. สิ่งที่ควรแชร์กับฝ่ายสนับสนุน (หากจำเป็น)
หากคุณติดต่อฝ่ายสนับสนุน ให้ระบุ:
Org ID ที่ได้รับผลกระทบ (สำคัญ)
endpoint ที่ได้รับผลกระทบ เช่น Chat Completions หรือ Responses (สำคัญ)
โมเดลที่ได้รับผลกระทบ (สำคัญ)
เป็นระดับการรองรับการใช้งานหรือ Priority tier หรือไม่ (สำคัญ)
ช่วงเวลาพร้อมเขตเวลาสำหรับเวลาแฝงหรือข้อผิดพลาด (สำคัญ)
x-request-id หรือ X-Client-Request-Id ที่เกี่ยวข้อง หากมี
เวลาประทับพร้อมเขตเวลา หรืออย่างน้อยวันที่ สำหรับคำขอที่คุณให้มา
หากมี ให้ระบุเพิ่มเติม:
Project ID ที่เกี่ยวข้องกับคำขอ
คำขอเกี่ยวกับถิ่นที่อยู่ของข้อมูลได้รับผลกระทบหรือไม่ และรายการใดบ้าง
คำอธิบายแนวโน้มที่คุณเห็น
สำหรับประเภทของปัญหา ให้ระบุ:
ข้อผิดพลาด: เปอร์เซ็นต์โดยประมาณของคำขอที่ล้มเหลวหรือเกิดข้อผิดพลาด รหัสการตอบกลับ ข้อความข้อผิดพลาด และใช้เวลานานเท่าใดกว่าจะได้รับการตอบกลับข้อผิดพลาด
เวลาแฝง: เปอร์เซ็นไทล์ใดที่ได้รับผลกระทบ (P50 / P90 / P95 / P99) ค่าสูงเพียงใดเมื่อเทียบกับค่าพื้นฐานของลูกค้า และตัวอย่างคำขอที่ช้าพร้อมเวลาประทับขณะส่งและรับ
ทั้งสองอย่าง: ภาพหน้าจอหรือตารางข้อมูลข้อผิดพลาดหรือเวลาแฝง รวมถึงวิธีที่คุณใช้พิจารณาว่าอัตราข้อผิดพลาดหรือเวลาแฝงสูงกว่าที่คาดไว้
สถานการณ์การแก้ไขปัญหาที่พบบ่อย
เกิดการหมดเวลาแต่สถานะบริการดูปกติ
สาเหตุที่เป็นไปได้: คำขอหมดเวลาก่อนถึง OpenAI
ตรวจสอบ:
การตั้งค่าการหมดเวลาของไคลเอ็นต์หรือพร็อกซี
การเปลี่ยนแปลงของเครือข่ายภายในหรือโหลดบาลานเซอร์
การมีข้อผิดพลาด 499 ในแดชบอร์ดสถานะบริการ (สิ่งเหล่านี้อาจแสดงเป็นข้อผิดพลาด 5xx ในระบบของคุณเอง)
เวลาแฝงเพิ่มขึ้นโดยไม่มีการปรับใช้
สาเหตุที่เป็นไปได้: ขนาด Token เอาต์พุตหรือการใช้การให้เหตุผลเพิ่มขึ้น และ/หรือทราฟฟิกย้ายไประหว่างประเภทของแพ็กเกจ
ตรวจสอบ:
Token เอาต์พุตเฉลี่ยต่อคำขอในแดชบอร์ดการใช้งาน (ต้องดาวน์โหลดข้อมูลและนำ Token เอาต์พุตหารด้วยจำนวนคำขอทั้งหมด)
เปอร์เซ็นไทล์ของ Request Time และ TTFT ในแดชบอร์ดสถานะบริการ
Priority หรือระดับการรองรับการใช้งานดูเหมือนช้า
สาเหตุที่เป็นไปได้: เมตริกถูกปะปนกันระหว่างประเภทของแพ็กเกจ ทำให้ทราฟฟิกระดับมาตรฐานบดบังประสิทธิภาพของระดับแบบชำระเงิน
ตรวจสอบ:
ตัวกรองถูกจำกัดไว้ที่ประเภทของแพ็กเกจและโมเดลเดียว
การเปรียบเทียบความเร็วของ Token ระหว่างประเภทของแพ็กเกจ
ข้อผิดพลาด 5XX เพิ่มขึ้นอย่างฉับพลัน
สาเหตุที่เป็นไปได้: ความล้มเหลวชั่วคราวที่ส่งผลต่อทราฟฟิกในสัดส่วนเล็กน้อย
ตรวจสอบ:
เปอร์เซ็นต์อัตราข้อผิดพลาด
ปริมาณทราฟฟิกเปลี่ยนแปลงในเวลาเดียวกันหรือไม่
ปัญหาส่งผลต่อโปรเจ็กต์เดียวเท่านั้น
สาเหตุที่เป็นไปได้: การกำหนดค่าหรือรูปแบบการใช้งานเฉพาะโปรเจ็กต์
ตรวจสอบ:
การกรองระดับโปรเจ็กต์
การเปรียบเทียบกับโปรเจ็กต์ที่ไม่ได้รับผลกระทบ
ข้อสรุปสำคัญ
กรองตามโมเดล ประเภทของแพ็กเกจ และโปรเจ็กต์ที่เกี่ยวข้องก่อนตีความเมตริก
ใช้ เปอร์เซ็นไทล์ ไม่ใช่ค่าเฉลี่ย สำหรับการวิเคราะห์เวลาแฝง
คาดว่าจะมีอัตราข้อผิดพลาดเล็กน้อย
ข้อมูลที่หายไปมักบ่งชี้ถึงปัญหาต้นทาง
ข้อมูลการใช้งานช่วยอธิบายได้ว่าเวลาแฝงเปลี่ยนไป เพราะเหตุใด ส่วนสถานะบริการแสดงว่าเกิดการเปลี่ยนแปลง เมื่อใด