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

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

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

به‌روزرسانی: 12 days ago

پیوندهای مهم

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

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

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

  • ۳۰ روز گذشته

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

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

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

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

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

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

چرا:

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

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

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

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

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

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

چرا:

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

  • رده‌های اولویت و مقیاس‌بندی SLAهای تعریف‌شده دارند

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

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

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

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

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

چرا:

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

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

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

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

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

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

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

  2. زبانه درخواست‌های 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

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

بررسی کنید:

  • درصد نرخ خطا

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

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

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

بررسی کنید:

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

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

نکات نهایی

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

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

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

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

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

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