ลิงก์สำคัญ
*ขณะนี้แดชบอร์ด Service Health ใช้งานได้เฉพาะลูกค้า Enterprise API เท่านั้น
เริ่มต้นด้วยค่าตั้งต้นที่ถูกต้อง
เมื่อคุณเปิดแดชบอร์ด Service Health ระบบจะตั้งค่าเริ่มต้นเป็น:
ทุกโปรเจกต์
30 วันที่ผ่านมา
ความละเอียดรายชั่วโมง
มุมมองนี้มีประโยชน์สำหรับการดูภาพรวมเบื้องต้นเท่านั้น การแก้ไขปัญหาที่มีความหมายต้องอาศัยการกรองเสมอ
กรองก่อนตรวจสอบ
การกรองที่ถูกต้องเป็นขั้นตอนที่สำคัญที่สุด การตีความผิดส่วนใหญ่มาจากการปะปนกันของโมเดล tier หรือโปรเจกต์
กรองตามโมเดล (ครั้งละหนึ่งโมเดล)
ให้กรองเหลือเพียงโมเดลเดียวเสมอ
เหตุผล:
ปัญหาในโมเดลที่มีทราฟฟิกต่ำอาจถูกกลบด้วยทราฟฟิกที่มีปริมาณสูงกว่า
โมเดลที่มีทราฟฟิกสูงอาจทำให้ปัญหาเฉพาะจุดดูเหมือนเป็นปัญหาในวงกว้าง
โมเดลต่างกันมีเป้าหมายด้านประสิทธิภาพต่างกัน
หมายเหตุ: การเลือกหลายโมเดลจะเป็นการรวมข้อมูลเข้าด้วยกัน ไม่ได้สลับดูระหว่างโมเดล
กรองตาม Service Tier
หากคุณใช้มากกว่าหนึ่ง tier (standard, priority, scale) ให้กรองเฉพาะ tier ที่คุณกำลังตรวจสอบเสมอ
เหตุผล:
tier แต่ละแบบมีลักษณะประสิทธิภาพต่างกัน
tier แบบ priority และ scale มี SLA ที่กำหนดไว้
การปะปน tier จะทำให้ประสิทธิภาพของ tier แบบชำระเงินไม่ชัดเจน
เรื่องนี้สำคัญอย่างยิ่งสำหรับการวิเคราะห์ความหน่วง
กรองตามโปรเจกต์
โดยค่าเริ่มต้น Service Health จะแสดงทุกโปรเจกต์
สำหรับการแก้ไขปัญหา ให้กรองไปที่โปรเจกต์ที่พบปัญหา
เหตุผล:
โปรเจกต์เดียวที่มีทราฟฟิกสูงอาจครอบงำ metric ทั้งหมดได้
โปรเจกต์ขนาดเล็กที่ได้รับผลกระทบอาจถูกกลบด้วยทราฟฟิกที่ไม่เกี่ยวข้อง
ให้คงการเลือก “ทุกโปรเจกต์” ไว้เฉพาะเมื่อคุณเชื่อว่าปัญหาเกิดขึ้นกับทั้งองค์กรจริง ๆ
การแก้ไขปัญหาข้อผิดพลาด
ใช้มุมมอง HTTP Requests
เพื่อตรวจสอบข้อผิดพลาด:
กรองตามโมเดลและ tier
หากต้องการสลับจาก Uptime ไปเป็น HTTP Requests ให้คลิกแท็บ HTTP Requests
มุมมองนี้จะแสดงจำนวน request ทั้งหมดและจำนวนข้อผิดพลาดตามรหัสสถานะ HTTP ซูมไปที่ความละเอียดระดับนาทีเพื่อระบุการพุ่งสูงขึ้นหรือการเปลี่ยนแปลงแบบละเอียด
ตีความอัตราข้อผิดพลาด ไม่ใช่จำนวน
ข้อผิดพลาดบางอย่างเป็นสิ่งที่คาดว่าจะเกิดขึ้นได้ในระบบ production ให้โฟกัสที่เปอร์เซ็นต์ของข้อผิดพลาด ไม่ใช่ยอดรวมดิบ
ยิ่งปริมาณรวมของคุณมาก จำนวนข้อผิดพลาดที่เป็นไปได้ก็ยิ่งมากขึ้น แม้อัตราข้อผิดพลาดจะต่ำมากก็ตาม
เมื่อไม่พบข้อผิดพลาดใน Service Health
หากคุณเห็นข้อผิดพลาดฝั่งไคลเอนต์แต่ไม่พบข้อมูลที่สอดคล้องกันใน Service Health:
เป็นไปได้ว่า request ไปไม่ถึง OpenAI
ปัญหามักอยู่ที่ระบบ upstream (timeouts, proxies, networking)
เรื่องนี้พบได้บ่อยเมื่อมีการตั้ง client-side timeout ที่เข้มงวดเกินไป
การแก้ไขปัญหาความหน่วง
การวิเคราะห์ความหน่วงมีความหมายมากที่สุดบน tier priority และ scale ซึ่งมี SLA ที่กำหนดไว้ tier standard อาจแสดงความแปรปรวนของความหน่วงได้กว้างกว่า และไม่มีการรับประกันความหน่วง
Metric สำคัญ
หากต้องการดู metric แต่ละรายการ ให้คลิกแท็บที่เกี่ยวข้อง:
Token Velocity
จำนวน Token ที่สร้างต่อวินาที
ไม่ขึ้นกับขนาดของคำสั่ง
Request Time
ระยะเวลารวมของ request
ได้รับผลกระทบอย่างมากจากขนาดเอาต์พุตและการให้เหตุผล
Time to First Token (TTFT)
เวลาจนกระทั่งมีการสร้าง Token แรก
ได้รับผลกระทบอย่างมากจากขนาดคำสั่งอินพุตที่ไม่ได้แคชและการให้เหตุผล
ตรวจสอบค่าเปอร์เซ็นไทล์ P50 / P75 / P95 เสมอ ค่าเฉลี่ยอาจซ่อนผลกระทบที่เกิดกับผู้ใช้จริงได้
6. เชื่อมโยงความหน่วงกับการใช้ Token
Service Health แสดงให้เห็นว่าเกิดการเปลี่ยนแปลงพฤติกรรมเมื่อใด ข้อมูล Usage ช่วยอธิบายว่าเกิดขึ้นทำไม
ในแดชบอร์ด Usage ให้ทำดังต่อไปนี้เพื่อให้แน่ใจว่าคุณกำลังดูข้อมูลที่เกี่ยวข้องกับมุมมองของคุณในแดชบอร์ด Service Health:
กรองให้เป็นโปรเจกต์และโมเดลเดียวกัน
จัดกลุ่มตาม service tier หากใช้ได้
โฟกัสที่ output token ซึ่งส่งผลต่อความหน่วงมากที่สุด
สำหรับการวิเคราะห์ที่ลึกขึ้น ให้ส่งออก Activity Data และตรวจสอบจำนวน token ต่อ request ตามเวลา
7. สิ่งที่ควรแชร์กับฝ่ายสนับสนุน (หากจำเป็น)
หากคุณติดต่อฝ่ายสนับสนุน โปรดระบุ:
Org ID ที่ได้รับผลกระทบ (สิ่งนี้สำคัญ)
endpoint ที่ได้รับผลกระทบ (Chat Completions, Responses ฯลฯ) (สิ่งนี้สำคัญ)
โมเดลที่ได้รับผลกระทบ (สิ่งนี้สำคัญ)
เกิดขึ้นบน tier แบบ scale หรือ priority หรือไม่? (สิ่งนี้สำคัญ)
ช่วงเวลาพร้อม timezone สำหรับความหน่วงหรือข้อผิดพลาด (สิ่งนี้สำคัญ)
x-request-id หรือ X-Client-Request-Id ที่เกี่ยวข้อง (มักสำคัญ; ถ้าเป็นไปได้ให้รวมมาด้วย)
Timestamp พร้อม timezone (หรืออย่างน้อยวันที่) ของ request ที่ให้มา
ความหน่วง - หากแชร์ตัวอย่าง request ที่ช้า โปรดระบุว่าฝั่งคุณใช้เวลานานเท่าใด และถ้าเป็นไปได้ให้รวม timestamp ของเวลาที่ส่ง request และเวลาที่ได้รับกลับมาด้วย
ข้อผิดพลาด - โปรดแชร์เปอร์เซ็นต์โดยประมาณของ request ที่ล้มเหลว/เกิดข้อผิดพลาด รหัส response ข้อความข้อผิดพลาด และใช้เวลานานเท่าใดจึงได้รับ response ข้อผิดพลาด
Project id ที่เกี่ยวข้องกับ request
สิ่งนี้ส่งผลกระทบต่อ request ด้านถิ่นที่อยู่ของข้อมูลหรือไม่? ถ้าใช่ คือรายการใดบ้าง?
คำอธิบายแนวโน้มที่คุณพบ
ข้อผิดพลาด: % โดยประมาณของ request ที่ล้มเหลว/เกิดข้อผิดพลาด
ความหน่วง: เปอร์เซ็นไทล์ใดได้รับผลกระทบ (p50 / p90 / p95 / p99) และสูงกว่าค่าพื้นฐานของลูกค้ามากเพียงใด
ทั้งสองอย่าง: ภาพหน้าจอหรือตารางข้อมูลข้อผิดพลาดหรือความหน่วง (คุณพิจารณาได้อย่างไรว่าค่าอัตราข้อผิดพลาดหรือความหน่วงสูงกว่าที่คาดไว้?)
สถานการณ์การแก้ไขปัญหาที่พบบ่อย
เกิด Timeout แต่ Service Health ดูปกติ
สาเหตุที่เป็นไปได้: request หมดเวลาก่อนจะไปถึง OpenAI
ตรวจสอบ:
การตั้งค่า timeout ของไคลเอนต์หรือพร็อกซี
การเปลี่ยนแปลงของเครือข่ายภายในหรือ load balancer
การมีอยู่ของข้อผิดพลาด 499 ในแดชบอร์ด Service Health (สิ่งเหล่านี้อาจแสดงเป็นข้อผิดพลาด 5xx ในระบบของคุณเอง)
ความหน่วงเพิ่มขึ้นโดยไม่มีการ deploy
สาเหตุที่เป็นไปได้: ขนาด output token หรือการใช้การให้เหตุผลเพิ่มขึ้น และ\or ทราฟฟิกย้ายไปมาระหว่าง service tier
ตรวจสอบ:
จำนวน output token เฉลี่ยต่อ request ในแดชบอร์ด Usage (ต้องดาวน์โหลดข้อมูลและหารจำนวน output token ด้วยจำนวน request ทั้งหมด)
เปอร์เซ็นไทล์ Request Time และ TTFT ในแดชบอร์ด Service Health
Priority หรือ Scale Tier ดูช้า
สาเหตุที่เป็นไปได้: metric ถูกปะปนกันข้าม tier (หมายความว่าทราฟฟิก standard-tier กำลังกลบประสิทธิภาพของ tier แบบชำระเงิน)
ตรวจสอบ:
ตัวกรองถูกจำกัดไว้ที่ tier และโมเดลเดียว
การเปรียบเทียบ token velocity ระหว่าง tier
ข้อผิดพลาด 5XX พุ่งสูงขึ้น
สาเหตุที่เป็นไปได้: ความล้มเหลวชั่วคราวที่ส่งผลต่อทราฟฟิกเพียงส่วนน้อย
ตรวจสอบ:
เปอร์เซ็นต์อัตราข้อผิดพลาด
ปริมาณทราฟฟิกมีการเปลี่ยนแปลงในเวลาเดียวกันหรือไม่
ปัญหาส่งผลเฉพาะกับหนึ่งโปรเจกต์
สาเหตุที่เป็นไปได้: การกำหนดค่าหรือรูปแบบการใช้งานเฉพาะของโปรเจกต์
ตรวจสอบ:
การกรองระดับโปรเจกต์
การเปรียบเทียบกับโปรเจกต์ที่ไม่ได้รับผลกระทบ
ข้อสรุปสำคัญ
กรองตามโมเดล tier และโปรเจกต์ที่เกี่ยวข้อง ก่อนตีความ metric
ใช้เปอร์เซ็นไทล์ ไม่ใช่ค่าเฉลี่ย สำหรับการวิเคราะห์ความหน่วง
อัตราข้อผิดพลาดเล็กน้อยเป็นสิ่งที่คาดว่าจะเกิดขึ้นได้
ข้อมูลที่หายไปมักบ่งชี้ถึงปัญหา upstream
ข้อมูล Usage ช่วยอธิบายได้ว่าทำไม ความหน่วงจึงเปลี่ยนไป และ Service Health ช่วยแสดงว่าเกิดขึ้นเมื่อใด