پیوندهای مهم
داشبورد سلامت خدمات (در حال حاضر فقط برای مشتریان Enterprise API در دسترس است)
با پیش‌فرض‌های درست شروع کنید
وقتی داشبورد سلامت خدمات را باز می‌کنید، به‌طور پیش‌فرض روی این موارد تنظیم است:
همه پروژه‌ها
۳۰ روز گذشته
تفکیک‌پذیری ساعتی
این نما فقط برای جهت‌گیری مفید است. عیب‌یابی معنادار همیشه به فیلتر کردن نیاز دارد.
پیش از بررسی، فیلتر کنید
فیلتر کردن درست مهم‌ترین مرحله است. بیشتر برداشت‌های نادرست از ترکیب مدل‌ها، رده‌ها یا پروژه‌ها ناشی می‌شود.
فیلتر بر اساس مدل (یکی در هر بار)
همیشه روی یک مدل واحد فیلتر کنید.
چرا:
مشکلات مدل‌های کم‌ترافیک می‌تواند توسط ترافیک با حجم بالاتر پنهان شود
مدل‌های پرترافیک می‌توانند مشکلات محلی را سراسری جلوه دهند
مدل‌های مختلف اهداف عملکردی متفاوتی دارند
توجه: انتخاب چند مدل آن‌ها را تجمیع می‌کند—بین آن‌ها جابه‌جا نمی‌شود.
فیلتر براساس رده خدمات
اگر از بیش از یک رده استفاده می‌کنید (استاندارد، حالت سریع که پیش‌تر «پردازش اولویت‌دار» نام داشت، و رده مقیاس‌بندی)، همیشه نتایج را براساس رده‌ای که بررسی می‌کنید فیلتر کنید.
دلیل:
رده‌ها ویژگی‌های عملکردی متفاوتی دارند
حالت سریع و رده مقیاس‌بندی، توافق‌نامه سطح خدمات (SLA) مشخص دارند
ترکیب رده‌ها، عملکرد رده پولی را پنهان می‌کند
این موضوع به‌ویژه برای تحلیل تأخیر اهمیت دارد.
برای مدل‌های موجود، ترافیک حالت سریع همچنان با عنوان priority در داشبورد Usage نمایش داده می‌شود.
فیلتر بر اساس پروژه
به‌طور پیش‌فرض، سلامت خدمات همه پروژه‌ها را نشان می‌دهد.
برای عیب‌یابی، روی پروژه یا پروژه‌هایی که مشکل در آن‌ها مشاهده شده است فیلتر کنید.
چرا:
یک پروژه پرترافیک می‌تواند بر معیارها غالب شود.
پروژه‌های کوچک‌ترِ تحت تأثیر می‌توانند توسط ترافیک نامرتبط پنهان شوند.
فقط زمانی «همه پروژه‌ها» را انتخاب‌شده نگه دارید که باور دارید مشکل واقعاً در کل سازمان است.
عیب‌یابی خطاها
از نمای درخواست‌های HTTP استفاده کنید
برای بررسی خطاها:
بر اساس مدل و رده خدمات فیلتر کنید.
زبانه درخواست‌های HTTP را به‌جای زبانه زمان فعالیت باز کنید.
این نما کل درخواست‌ها و تعداد خطاها را بر اساس کد وضعیت HTTP نشان می‌دهد. برای شناسایی افزایش‌های ناگهانی یا تغییرات ریزدانه، تا تفکیک‌پذیری دقیقه‌ای بزرگ‌نمایی کنید.
نرخ خطا را تفسیر کنید، نه تعداد را
در هر سیستم تولیدی، وجود برخی خطاها مورد انتظار است. روی درصد خطا تمرکز کنید، نه مجموع خام.
هرچه حجم کل شما بزرگ‌تر باشد، حتی با نرخ خطای بسیار پایین، تعداد بالقوه خطاها بیشتر خواهد بود.
وقتی خطاها در سلامت خدمات دیده نمی‌شوند
اگر خطاهای سمت کلاینت را می‌بینید اما داده متناظری در سلامت خدمات وجود ندارد:
احتمالاً درخواست‌ها به OpenAI نرسیده‌اند.
مشکل معمولاً بالادستی است (مهلت زمانی، پراکسی‌ها، شبکه).
این موضوع در مهلت‌های زمانی تهاجمیِ سمت کلاینت رایج است.
عیب‌یابی تأخیر
تحلیل تأخیر برای رده‌های حالت سریع و رده مقیاس‌بندی که توافق‌نامه سطح خدمات (SLA) مشخص دارند، معنادارتر است. رده استاندارد ممکن است نوسان تأخیر بیشتری داشته باشد و تأخیر آن تضمین‌شده نیست.
معیارهای کلیدی
برای مشاهده هر معیار، روی زبانه مربوط کلیک کنید:
سرعت توکن: توکن‌های تولیدشده در هر ثانیه؛ مستقل از اندازه اعلان.
زمان درخواست: مدت کل درخواست؛ به‌شدت تحت تأثیر اندازه خروجی و استدلال است.
زمان تا اولین توکن (TTFT): زمان تا تولید اولین توکن؛ به‌شدت تحت تأثیر اندازه اعلان ورودیِ کش‌نشده و استدلال است.
همیشه صدک‌های P50 / P75 / P95 را بررسی کنید. میانگین‌ها می‌توانند اثر واقعی بر کاربران را پنهان کنند.
بررسی ارتباط تأخیر با مصرف توکن
وضعیت سلامت سرویس نشان می‌دهد رفتار سرویس چه زمانی تغییر کرده است. داده‌های مصرف به توضیح علت این تغییر کمک می‌کنند.
در داشبورد مصرف، مراحل زیر را انجام دهید تا مطمئن شوید داده‌هایی که بررسی می‌کنید با نمای شما در داشبورد سلامت سرویس مرتبط‌اند:
داده‌ها را بر اساس همان پروژه و مدل فیلتر کنید.
در صورت لزوم، داده‌ها را بر اساس رده خدمات گروه‌بندی کنید.
روی توکن‌های خروجی تمرکز کنید که بیشترین تأثیر را بر تأخیر دارند.
برای تحلیل عمیق‌تر، از داده‌های فعالیت خروجی بگیرید و تعداد توکن‌ها در هر درخواست را در طول زمان بررسی کنید.
اطلاعاتی که باید با پشتیبانی در میان بگذارید (در صورت نیاز)
اگر با پشتیبانی تماس می‌گیرید، این موارد را ارائه کنید:
شناسه سازمان‌های تحت تأثیر مشکل (مهم)
نقاط پایانی تحت تأثیر مشکل، مانند Chat Completions یا Responses (مهم)
مدل‌های تحت تأثیر مشکل (مهم)
اینکه مشکل در حالت سریع رخ می‌دهد یا در رده مقیاس‌بندی (مهم)
بازه‌های زمانی بروز تأخیر یا خطا، همراه با منطقه زمانی (مهم)
مقدار x-request-id یا X-Client-Request-Id مرتبط، در صورت دسترسی
زمان دقیق همراه با منطقه زمانی، یا دست‌کم تاریخ، برای درخواست‌هایی که ارائه می‌کنید
در صورت دسترسی، این موارد را نیز ارائه کنید:
شناسه پروژه مرتبط با درخواست‌ها
اینکه آیا درخواست‌های مشمول الزامات محل اقامت داده تحت تأثیر قرار گرفته‌اند و اگر چنین است، کدام درخواست‌ها
شرح روندهایی که مشاهده می‌کنید
بسته به نوع مشکل، این موارد را ارائه کنید:
خطاها: درصد تقریبی درخواست‌های ناموفق یا دارای خطا، کدهای پاسخ، پیام‌های خطا و مدت‌زمان لازم برای دریافت پاسخ خطا.
تأخیر: صدک‌های تحت تأثیر (P50 / P90 / P95 / P99)، میزان افزایش آن‌ها نسبت به مقدار مبنای مشتری، و نمونه‌هایی از درخواست‌های کند همراه با زمان دقیق ارسال و دریافت.
هر دو: تصاویر صفحه یا جدولی از داده‌های خطا یا تأخیر، به‌همراه توضیح اینکه چگونه تشخیص دادید نرخ خطا یا میزان تأخیر بیش از حد انتظار بوده است.
سناریوهای رایج عیب‌یابی
مهلت‌های زمانی رخ می‌دهند اما سلامت خدمات عادی به نظر می‌رسد
علت ممکن: مهلت زمانی درخواست‌ها پیش از رسیدن به OpenAI به پایان می‌رسد.
بررسی کنید:
تنظیمات مهلت زمانی کلاینت یا پراکسی
تغییرات شبکه محلی یا متعادل‌کننده بار
وجود خطاهای 499 در داشبورد سلامت خدمات (این‌ها ممکن است در سیستم‌های خودتان به‌صورت خطاهای 5xx ظاهر شوند).
تأخیر بدون استقرار جدید افزایش یافته است
علت ممکن: اندازه توکن خروجی یا استفاده از استدلال افزایش یافته و/یا ترافیک بین رده‌های خدمات جابه‌جا شده است.
بررسی کنید:
میانگین توکن‌های خروجی به ازای هر درخواست در داشبورد استفاده (نیازمند دانلود داده‌ها و تقسیم توکن‌های خروجی بر کل درخواست‌ها).
صدک‌های زمان درخواست و TTFT در داشبورد سلامت خدمات.
حالت سریع یا رده مقیاس‌بندی کند به نظر می‌رسد
علت احتمالی: معیارهای رده‌های مختلف با هم ترکیب شده‌اند؛ یعنی ترافیک رده استاندارد، عملکرد رده پولی را پنهان می‌کند.
بررسی کنید:
فیلترها فقط به یک رده و مدل محدود شده باشند.
سرعت تولید توکن را میان رده‌ها مقایسه کنید.
افزایش ناگهانی خطاهای 5XX
علت احتمالی: خرابی‌های گذرا که درصد کمی از ترافیک را تحت تأثیر قرار می‌دهند.
بررسی کنید:
درصد نرخ خطا
اینکه حجم ترافیک در همان زمان تغییر کرده است یا نه
مشکل فقط یک پروژه را تحت تأثیر قرار می‌دهد
علت احتمالی: پیکربندی یا الگوی استفاده مختص پروژه.
بررسی کنید:
فیلتر کردن در سطح پروژه
مقایسه با پروژه‌های تحت تأثیر قرار نگرفته
نکات نهایی
پیش از تفسیر معیارها، در موارد مرتبط بر اساس مدل، رده و پروژه فیلتر کنید.
برای تحلیل تأخیر، از صدک‌ها استفاده کنید، نه میانگین‌ها.
نرخ‌های خطای کوچک مورد انتظار هستند.
داده‌های مفقود معمولاً نشان‌دهنده مشکلات بالادستی است.
داده‌های استفاده می‌توانند توضیح دهند تأخیر چرا تغییر کرده است؛ سلامت خدمات نشان می‌دهد رفتار چه زمانی تغییر کرده است.