خلاصه
- پاسخ‌های استریم‌شده نیاز به تجزیه‌ی مقاوم SSE دارند تا قطعات ناقص و داده‌های مصرف نهایی توکن را مدیریت کنند.
- شکست‌های حالت JSON معمولاً ناشی از تولید متن دنباله‌دار توسط مدل خارج از اسکیمای سخت‌گیرانه JSON است.
- پنجره زمینه ۱۰۰k بین متن ورودی و تکمیل مشترک است، بنابراین خروجی‌های طولانی فضای ورودی موجود را کاهش می‌دهند.
- برآورد هزینه باید تفاوت قیمت بالاتر توکن‌های خروجی نسبت به توکن‌های ورودی را در نظر بگیرد.
چرا پاسخ استریمینگ شما قفل می‌شود
پاسخ‌های استریم‌شده زمانی که کلاینت در خواندن قطعه نهایی رویداد سرور-ارسالی (SSE) حاوی داده‌های مصرف توکن شکست می‌خورد، گیر می‌کنند. API ما توکن‌ها را همان‌طور که تولید می‌شوند استریم می‌کند، اما اتصال پس از رسیدن آخرین قطعه کاملاً بسته می‌شود. اگر کد کلاینت شما زودتر قطع شود یا قطعه آخر را نادیده بگیرد، تعداد دقیق توکن‌های مورد نیاز برای تأیید صورتحساب را از دست می‌دهید.
هر قطعه را تا پایان جریان بخوانید. فرض نکنید که آخرین قطعه فقط حاوی آخرین توکن است. قطعه نهایی در جریان SSE ما شامل usage فیلد شامل مجموع توکن‌های ورودی و خروجی. اگر این داده‌ها را نادیده بگیرید، نمی‌توانید مصرف اعتبار پیش‌پرداخت خود را به دقت ردیابی کنید.
اشتباهات رایج
- نادیده گرفتن رویداد نهایی SSE.
- مقادیر Timeout برای تکمیل‌های طولانی خیلی کم تنظیم شده‌اند.
- پردازش ناقص JSON در حالت استریم.
همیشه جریان را تا انتها مصرف کنید تا سرور بداند که کلید دریافت پاسخ کامل را دریافت کرده است. این از نشت منابع در سمت ما جلوگیری کرده و تضمین می‌کند که داده‌های مورد نیاز برای لاگ‌های خود را دارید.
مدیریت خطاهای حالت JSON در تولید
خطاهای حالت JSON رخ می‌دهد زیرا مدل ممکن است متنی پس از آکولاد بسته تولید کند که قوانین سخت‌گیرانه تجزیه JSON را نقض می‌کند. وقتی Set response_format به {"type": "json_object", مدل تلاش می‌کند JSON معتدی خروجی دهد، اما اغلب پرکننده مکالمه‌ای مانند 'اینجا داده‌ها هستند:' را بعد از براکت بسته اضافه می‌کند. سپس پارسر شما به دلیل متن اضافی خراب می‌شود.
متن پس از آخرین آکولاد بسته معتبر را حذف کنید. به مدل اعتماد نکنید که دقیقاً در انتهای ساختار JSON متوقف شود. باید یک مرحله پس‌پردازش پیاده‌سازی کنید تا آخرین '}' یا ']' را پیدا کرده و همه چیز پس از آن را نادیده بگیرید. این هنگام تجزیه آرایه‌ها یا اشیای تو در تو حیاتی است.
بهترین شیوه‌ها
- از یک عبارت منظم (regex) برای استخراج آخرین بلوک JSON معتبر استفاده کنید.
- رشته استخراج شده را با یک تجزیه‌گر JSON اعتبارسنجی کنید.
- اگر خروجی آشفته است، با دمای پایین‌تر تلاش مجدد انجام دهید.
این رویکرد تضمین می‌کند که خط لوله تولید شما حتی زمانی که مدل تصمیم می‌گیرد پرحرف باشد، پایدار بماند. مدل‌های بدون سانسور محدودیت کمتری دارند، بنابراین ممکن است در قالب‌دهی خود 'خلاقانه‌تر' به نظر برسند.
درک محدودیت‌های پنجره متن
حد پنجره زمینه ۱۰۰,۰۰۰ توکن برای پرامپت و تکمیل ترکیبی است. این بدان معناست که اگر ورودی شما ۵۰,۰۰۰ توکن باشد، می‌توانید تا ۵۰,۰۰۰ توکن تولید کنید قبل از رسیدن به حد مجاز. حد مجاز فقط برای ورودی نیست؛ یک بودجه مشترک برای کل درخواست است.
فضای خروجی موجود خود را با تفریق تعداد توکن‌های ورودی از ۱۰۰,۰۰۰ محاسبه کنید. اگر یک سیستم‌پرامپت بزرگ یا تاریخچه طولانی پیام‌ها ارسال کنید، فضای خروجی موجود شما به همان اندازه کاهش می‌یابد. این موضوع برای برنامه‌هایی که تاریخچه مکالمات طولانی را حفظ می‌کنند، حیاتی است.
مثال محاسبه
- پنجره کلی: 100,000 توکن.
- توکن‌های ورودی: ۲۰,۰۰۰ توکن.
- حداکثر خروجی: 80,000 توکن.
اگر از این محدودیت تجاوز کنید، API خطا برمی‌گرداند. مصرف توکن خود را به دقت پایش کنید تا از قطع شدن غیرمنتظره پاسخ مدل جلوگیری کنید. مدل به صورت خودکار قطع نمی‌کند؛ بلکه اگر مجموع از پنجره تجاوز کند، صرفاً درخواست را رد می‌کند.
شمارش توکن و برآورد هزینه
برآورد هزینه باید تفاوت قیمت بین توکن‌های ورودی و خروجی را در نظر بگیرد. توکن‌های ورودی $0.15 به ازای هر 1M توکن و توکن‌های خروجی $0.50 به ازای هر 1M توکن هزینه دارند. توکن‌های خروجی به طور قابل توجهی گران‌تر هستند، بنابراین تولید پاسخ‌های طولانی هزینه‌های شما را سریع‌تر از ارسال پرامپت‌های طولانی افزایش می‌دهد.
هزینه‌های خود را با ضرب کردن تعداد توکن مورد انتظار در قیمت مربوطه تخمین بزنید. برای مثال، 10,000 توکن ورودی و 5,000 توکن خروجی هزینه خواهد داشت: (10,000/1,000,000 * $0.15) + (5,000/1,000,000 * $0.50). این برابر است با $0.0015 + $0.0025 = $0.004 برای هر درخواست.
جدول قیمت‌گذاری
| نوع توکن | قیمت به ازای ۱ میلیون توکن |
|---|---|
| ورودی | $0.15 |
| خروجی | $0.50 |
مصرف خود را از طریق قطعه نهایی SSE یا پاسخ API ردیابی کنید. این تضمین می‌کند که می‌توانید بودجه‌بندی دقیقی برای برنامه‌های با حجم بالا داشته باشید. اعتبار پیش‌پرداخت هرگز منقضی نمی‌شود، بنابراین می‌توانید هزینه‌های خود را در طول زمان بدون هزینه‌های ماهانه برنامه‌ریزی کنید.
محدودیت نرخ: توضیح ۳۰۰ RPM
محدودیت نرخ درخواست‌های شما را به ۳۰۰ درخواست در دقیقه به ازای هر کلید API محدود می‌کند. این محدودیت برای تمام درخواست‌ها، صرف‌نظر از اندازه payload یا تعداد توکن‌ها اعمال می‌شود. اگر از این حد تجاوز کنید، API خطای 429 را برمی‌گرداند. باید بازگشت نمایی (exponential backoff) را برای مدیریت این خطاها به صورت ایمن پیاده‌سازی کنید.
نرخ درخواست خود را پایش کنید و همزمانی را متناسب با آن تنظیم کنید. اگر از چندین رشته یا فرآیند استفاده می‌کنید، مطمئن شوید که کلید API یکسانی را به اشتراک می‌گذارند و در مجموع زیر محدودیت ۳۰۰ درخواست در دقیقه باقی می‌مانند. فراتر رفتن از این محدودیت منجر به خطاهای موقت تا زمان بازنشانی نرخ خواهد شد.
مدیریت خطاهای 429
- از بازگشت نمایی استفاده کنید.
- درخواست‌های ناموفق را برای تحلیل ثبت کنید.
- اگر محدودیت‌ها مکرر هستند، همزمانی را کاهش دهید.
API ما برای استفاده با حجم بالا طراحی شده است، اما محدودیت نرخ استفاده منصفانه را بین همه کلاینت‌ها تضمین می‌کند. اگر به محدودیت‌های بالاتری نیاز دارید، می‌توانید یک کلید API جدید تولید کنید، اما توجه داشته باشید که هر حساب کاربری محدود به یک کلید فعال در هر زمان است.
عیب‌یابی شکست‌های فراخوانی تابع
شکست‌های فراخوانی تابع زمانی رخ می‌دهد که تعریف ابزار مدل با طرح‌واره مورد انتظار مطابقت نداشته باشد یا مدل نتواند JSON معتبری برای استدلال‌های ابزار خروجی دهد. مطمئن شوید تعاریف ابزار شما دقیق هستند و تمام پارامترهای ضروری را شامل می‌شوند. طرح‌واره‌های مبهم منجر به فراخوانی‌های ابزار نامعتبر می‌شوند.
آرگومان‌های ابزار را قبل از اجرای تابع اعتبارسنجی کنید. مدل ممکن است آرگومان‌هایی تولید کند که فیلدهای ضروری را ندارند یا انواع نادرستی دارند. کد کلاینت شما باید این خطاها را با ارسال مجدد با پرامپت واضح‌تر یا تنظیم تعریف ابزار مدیریت کند.
مراحل اشکال‌زدایی
- نحوه تعریف ابزار را بررسی کنید.
- انواع و مقادیر آرگومان‌ها را اعتبارسنجی کنید.
- خروجی مدل را برای فیلدهای گمشده مرور کنید.
فراخوانی تابع یک ویژگی قدرتمند است، اما نیاز به طراحی دقیق طرح‌واره دارد. مدل‌های بدون سانسور ممکن است نسبت به تعاریف ابزار نسبت به همتایان فیلتر شده خود سازگاری کمتری داشته باشند، بنابراین اعتبارسنجی دقیق ضروری است.
چرا «بدون سانسور» کاملاً نامحدود نیست
برچسب «فیلتر نشده» به این معنی است که مدل به موضوعات بزرگسالان قانونی، داستانی یا بحث‌برانگیز پاسخ نمی‌دهد، اما همچنان یک محدودیت سخت برای محتوای جنسی شامل اطفال دارد. این تنها محدودیت سخت محتواست که همیشه اعمال می‌شود. درخواست‌های حاوی چنین محتوایی رد خواهند شد، حتی اگر بقیه پرامپت کاملاً معتبر باشد.
رد شدن‌های دیگر ممکن است همچنان به دلیل خطاهای فنی یا محدودیت‌های نرخ رخ دهد. مدل جادو نیست؛ همچنان ممکن است در تولید پاسخ شکست بخورد اگر ورودی خیلی پیچیده باشد یا پنجره زمینه تجاوز کند. درک کنید که 'uncensored' به سیاست محتوا اشاره دارد، نه قابلیت اطمینان فنی.
محدودیت‌های محتوا
- محتوای جنسی شامل اطفال.
- محتوای بزرگسالان قانونی مجاز است.
- خطاهای فنی همچنان می‌توانند منجر به رد شوند.
این تمایز برای برنامه‌هایی که نیاز به مدیریت طیف وسیعی از موضوعات دارند مهم است. دانستن محدودیت خاص به شما کمک می‌کند منطق فیلتر خود را به درستی طراحی کنید.
اشکال‌زدایی خطاهای ۴۰۰ و ۴۲۹
خطاهای 400 نشان‌دهنده مشکل در خود درخواست هستند، مانند JSON نامعتبر، فیلدهای ضروری گمشده، یا تجاوز از محدودیت ۸ مگابایتی بدنه درخواست. خطاهای 429 نشان می‌دهند که شما از محدودیت نرخ ۳۰۰ درخواست در دقیقه تجاوز کرده‌اید. تمایز قائل شدن بین این خطاها به شما کمک می‌کند تا مشکل صحیح را سریع‌تر رفع کنید.
برای خطاهای 400، پیکربندی درخواست و طرح داده را بررسی کنید. برای خطاهای 429، بازگشت به عقب (backoff) را پیاده‌سازی کنید و همزمانی را کاهش دهید. اگر خطای 400 با پیامی درباره اندازه بدنه درخواست دریافت کردید، اطمینان حاصل کنید که داده‌های زیادی را در یک درخواست ارسال نمی‌کنید. محدودیت 8 MB سخت‌گیرانه است.
کدهای خطا
| کد خطا | معنا |
|---|---|
| 400 | درخواست نامعتبر |
| 429 | محدودیت نرخ فراتر رفته است |
ثبت این خطاها با زمینه‌های آن‌ها (پیکربندی ورودی، زمان‌بندی) اشکال‌زدایی را بسیار آسان‌تر می‌کند. از این داده‌ها برای بهینه‌سازی ادغام خود و جلوگیری از شکست‌های مکرر استفاده کنید.
مراحل بعدی برای بهینه‌سازی Heretic LLM
بهینه‌سازی با پایش مصرف توکن و نرخ خطا آغاز می‌شود. از داده‌های توکن در قطعه نهایی SSE برای ردیابی مصرف واقعی خود استفاده کنید. این را با هزینه‌های تخمینی خود مقایسه کنید تا از دقت اطمینان حاصل کنید. استراتژی‌های همزمانی و محدودیت نرخ را بر اساس الگوهای مصرف مشاهده شده تنظیم کنید.
دمای پایین‌تری را برای خروجی JSON یا فراخوانی تابع سازگارتر در نظر بگیرید. اگر به پاسخ‌های خلاقانه‌تری نیاز دارید، دما را افزایش دهید اما برای خطاهای پارسینگ بیشتر آماده باشید. با پارامترهای مختلف آزمایش کنید تا تعادل مناسب برای مورد استفاده خود پیدا کنید.
نکات بهینه‌سازی
- مصرف توکن‌ها را به دقت پایش کنید.
- دما را برای ثبات در برابر خلاقیت تنظیم کنید.
- مدیریت خطای قوی را پیاده‌سازی کنید.
با آزمایش رایگان شروع کنید تا یکپارچه‌سازی خود را آزمایش کنید. این یک روش کم‌ریسک برای بررسی این است که آیا کد کلاینت شما استریمینگ، حالت JSON و محدودیت‌های نرخ را به درستی مدیریت می‌کند یا خیر، قبل از تعهد به اعتبار پیش‌پرداخت.
