OpenAI
این صفحه به‌صورت ماشینی ترجمه شده است. مقاله اصلی انگلیسی را مشاهده کنید.

عیب‌یابی خطاها و تأخیر API

این مقاله توضیح می‌دهد چگونه از داشبوردهای سلامت سرویس و مصرف برای عیب‌یابی خطاهای رایج و مشکلات تأخیر هنگام استفاده از OpenAI API استفاده کنید.

به‌روزرسانی: 20 hours ago

پیوندهای مهم

با پیش‌فرض‌های درست شروع کنید

وقتی داشبورد سلامت خدمات را باز می‌کنید، به‌طور پیش‌فرض روی این موارد تنظیم است:

  • همه پروژه‌ها

  • ۳۰ روز گذشته

  • تفکیک‌پذیری ساعتی

این نما فقط برای جهت‌گیری مفید است. عیب‌یابی معنادار همیشه به فیلتر کردن نیاز دارد.

پیش از بررسی، فیلتر کنید

فیلتر کردن درست مهم‌ترین مرحله است. بیشتر برداشت‌های نادرست از ترکیب مدل‌ها، رده‌ها یا پروژه‌ها ناشی می‌شود.

فیلتر بر اساس مدل (یکی در هر بار)

همیشه روی یک مدل واحد فیلتر کنید.

چرا:

  • مشکلات مدل‌های کم‌ترافیک می‌تواند توسط ترافیک با حجم بالاتر پنهان شود

  • مدل‌های پرترافیک می‌توانند مشکلات محلی را سراسری جلوه دهند

  • مدل‌های مختلف اهداف عملکردی متفاوتی دارند

توجه: انتخاب چند مدل آن‌ها را تجمیع می‌کند—بین آن‌ها جابه‌جا نمی‌شود.

فیلتر براساس رده خدمات

اگر از بیش از یک رده استفاده می‌کنید (استاندارد، حالت سریع که پیش‌تر «پردازش اولویت‌دار» نام داشت، و رده مقیاس‌بندی)، همیشه نتایج را براساس رده‌ای که بررسی می‌کنید فیلتر کنید.

دلیل:

  • رده‌ها ویژگی‌های عملکردی متفاوتی دارند

  • حالت سریع و رده مقیاس‌بندی، توافق‌نامه سطح خدمات (SLA) مشخص دارند

  • ترکیب رده‌ها، عملکرد رده پولی را پنهان می‌کند

این موضوع به‌ویژه برای تحلیل تأخیر اهمیت دارد.

برای مدل‌های موجود، ترافیک حالت سریع همچنان با عنوان priority در داشبورد Usage نمایش داده می‌شود.

فیلتر بر اساس پروژه

به‌طور پیش‌فرض، سلامت خدمات همه پروژه‌ها را نشان می‌دهد.

برای عیب‌یابی، روی پروژه یا پروژه‌هایی که مشکل در آن‌ها مشاهده شده است فیلتر کنید.

چرا:

  • یک پروژه پرترافیک می‌تواند بر معیارها غالب شود.

  • پروژه‌های کوچک‌ترِ تحت تأثیر می‌توانند توسط ترافیک نامرتبط پنهان شوند.

فقط زمانی «همه پروژه‌ها» را انتخاب‌شده نگه دارید که باور دارید مشکل واقعاً در کل سازمان است.

عیب‌یابی خطاها

از نمای درخواست‌های HTTP استفاده کنید

برای بررسی خطاها:

  1. بر اساس مدل و رده خدمات فیلتر کنید.

  2. زبانه درخواست‌های HTTP را به‌جای زبانه زمان فعالیت باز کنید.

این نما کل درخواست‌ها و تعداد خطاها را بر اساس کد وضعیت HTTP نشان می‌دهد. برای شناسایی افزایش‌های ناگهانی یا تغییرات ریزدانه، تا تفکیک‌پذیری دقیقه‌ای بزرگ‌نمایی کنید.

نرخ خطا را تفسیر کنید، نه تعداد را

در هر سیستم تولیدی، وجود برخی خطاها مورد انتظار است. روی درصد خطا تمرکز کنید، نه مجموع خام.

هرچه حجم کل شما بزرگ‌تر باشد، حتی با نرخ خطای بسیار پایین، تعداد بالقوه خطاها بیشتر خواهد بود.

وقتی خطاها در سلامت خدمات دیده نمی‌شوند

اگر خطاهای سمت کلاینت را می‌بینید اما داده متناظری در سلامت خدمات وجود ندارد:

  • احتمالاً درخواست‌ها به OpenAI نرسیده‌اند.

  • مشکل معمولاً بالادستی است (مهلت زمانی، پراکسی‌ها، شبکه).

این موضوع در مهلت‌های زمانی تهاجمیِ سمت کلاینت رایج است.

عیب‌یابی تأخیر

تحلیل تأخیر برای رده‌های حالت سریع و رده مقیاس‌بندی که توافق‌نامه سطح خدمات (SLA) مشخص دارند، معنادارتر است. رده استاندارد ممکن است نوسان تأخیر بیشتری داشته باشد و تأخیر آن تضمین‌شده نیست.

معیارهای کلیدی

برای مشاهده هر معیار، روی زبانه مربوط کلیک کنید:

  • سرعت توکن: توکن‌های تولیدشده در هر ثانیه؛ مستقل از اندازه اعلان.

  • زمان درخواست: مدت کل درخواست؛ به‌شدت تحت تأثیر اندازه خروجی و استدلال است.

  • زمان تا اولین توکن (TTFT): زمان تا تولید اولین توکن؛ به‌شدت تحت تأثیر اندازه اعلان ورودیِ کش‌نشده و استدلال است.

همیشه صدک‌های P50 / P75 / P95 را بررسی کنید. میانگین‌ها می‌توانند اثر واقعی بر کاربران را پنهان کنند.

۶. مرتبط کردن تأخیر با استفاده از توکن

سلامت خدمات نشان می‌دهد رفتار چه زمانی تغییر کرده است. داده‌های استفاده کمک می‌کند توضیح دهید چرا.

در داشبورد استفاده، برای اطمینان از اینکه داده‌های مرتبط با نمای خود در داشبورد سلامت خدمات را می‌بینید، این کارها را انجام دهید:

  • به همان پروژه و مدل فیلتر کنید.

  • در صورت کاربرد، بر اساس رده خدمات گروه‌بندی کنید.

  • روی توکن‌های خروجی تمرکز کنید که بیشترین تأثیر را بر تأخیر دارند.

برای تحلیل عمیق‌تر، داده‌های فعالیت را صادر کنید و توکن‌ها به ازای هر درخواست را در طول زمان بررسی کنید.

۷. چه اطلاعاتی را با پشتیبانی در میان بگذارید (در صورت نیاز)

اگر با پشتیبانی تماس می‌گیرید، این موارد را ارائه دهید:

  • شناسه‌های سازمانی (Org ID) تحت‌تأثیر (مهم)

  • نقاط پایانی تحت‌تأثیر، مانند Chat Completions یا Responses (مهم)

  • مدل‌های تحت‌تأثیر (مهم)

  • اینکه مشکل مربوط به حالت سریع است یا رده مقیاس‌بندی (مهم)

  • بازه‌های زمانی تأخیر یا خطاها، همراه با منطقه زمانی (مهم)

  • x-request-id یا X-Client-Request-Id مرتبط، در صورت وجود

  • مُهر زمانی همراه با منطقه زمانی یا دست‌کم تاریخ درخواست‌هایی که ارائه می‌کنید

در صورت امکان، این موارد را نیز ارائه دهید:

  • شناسه پروژه مرتبط با درخواست‌ها

  • اینکه درخواست‌های محل اقامت داده تحت‌تأثیر قرار گرفته‌اند یا نه، و کدام درخواست‌ها

  • شرح روندهایی که مشاهده می‌کنید

براساس نوع مشکل، این موارد را ارائه دهید:

  • خطاها: درصد تقریبی درخواست‌های ناموفق یا خطادار، کدهای پاسخ، پیام‌های خطا و مدت‌زمانی که دریافت پاسخ خطا طول کشیده است.

  • تأخیر: صدک‌های تحت‌تأثیر (P50 / P90 / P95 / P99)، میزان افزایش آن‌ها نسبت به خط مبنای مشتری و نمونه‌هایی از درخواست‌های کند همراه با مُهر زمانی ارسال و دریافت.

  • هر دو: اسکرین‌شات یا جدولی از داده‌های خطا یا تأخیر، به‌همراه توضیح نحوه تشخیص اینکه نرخ خطا یا تأخیر بیشتر از حد انتظار بوده است.

سناریوهای رایج عیب‌یابی

مهلت‌های زمانی رخ می‌دهند اما سلامت خدمات عادی به نظر می‌رسد

علت ممکن: مهلت زمانی درخواست‌ها پیش از رسیدن به OpenAI به پایان می‌رسد.

بررسی کنید:

  • تنظیمات مهلت زمانی کلاینت یا پراکسی

  • تغییرات شبکه محلی یا متعادل‌کننده بار

  • وجود خطاهای 499 در داشبورد سلامت خدمات (این‌ها ممکن است در سیستم‌های خودتان به‌صورت خطاهای 5xx ظاهر شوند).

تأخیر بدون استقرار جدید افزایش یافته است

علت ممکن: اندازه توکن خروجی یا استفاده از استدلال افزایش یافته و/یا ترافیک بین رده‌های خدمات جابه‌جا شده است.

بررسی کنید:

  • میانگین توکن‌های خروجی به ازای هر درخواست در داشبورد استفاده (نیازمند دانلود داده‌ها و تقسیم توکن‌های خروجی بر کل درخواست‌ها).

  • صدک‌های زمان درخواست و TTFT در داشبورد سلامت خدمات.

حالت سریع یا رده مقیاس‌بندی کند به نظر می‌رسد

علت احتمالی: معیارهای رده‌های مختلف با هم ترکیب شده‌اند؛ یعنی ترافیک رده استاندارد، عملکرد رده پولی را پنهان می‌کند.

بررسی کنید:

  • فیلترها فقط به یک رده و مدل محدود شده باشند.

  • سرعت تولید توکن را میان رده‌ها مقایسه کنید.

افزایش ناگهانی خطاهای 5XX

علت احتمالی: خرابی‌های گذرا که درصد کمی از ترافیک را تحت تأثیر قرار می‌دهند.

بررسی کنید:

  • درصد نرخ خطا

  • اینکه حجم ترافیک در همان زمان تغییر کرده است یا نه

مشکل فقط یک پروژه را تحت تأثیر قرار می‌دهد

علت احتمالی: پیکربندی یا الگوی استفاده مختص پروژه.

بررسی کنید:

  • فیلتر کردن در سطح پروژه

  • مقایسه با پروژه‌های تحت تأثیر قرار نگرفته

نکات نهایی

  • پیش از تفسیر معیارها، در موارد مرتبط بر اساس مدل، رده و پروژه فیلتر کنید.

  • برای تحلیل تأخیر، از صدک‌ها استفاده کنید، نه میانگین‌ها.

  • نرخ‌های خطای کوچک مورد انتظار هستند.

  • داده‌های مفقود معمولاً نشان‌دهنده مشکلات بالادستی است.

  • داده‌های استفاده می‌توانند توضیح دهند تأخیر چرا تغییر کرده است؛ سلامت خدمات نشان می‌دهد رفتار چه زمانی تغییر کرده است.

آیا این مقاله مفید بود؟