اگر اپلیکیشن شما در محیط تولید (Production) گاهی بدون دلیل کرش میکند و گاهی بهدرستی پاسخ میدهد، احتمالاً قربانی یک باگ شبکهای در استریمهای هوش مصنوعی شدهاید. این مشکل هیچ ارتباطی به کیفیت خروجی مدل ندارد، بلکه ریشه در نحوهٔ جابهجایی دادهها در لایههای شبکه دارد. در واقع، تجزیهٔ سادهلوحانه (Naive Parsing) در مرزهای تکههای داده (Chunk Boundaries) اغلب شکست میخورد، اما خطا از سمت خروجی مدل نیست، بلکه مربوط به انتقال شبکه است.
طبق یک راهنمای فنی که در ۱۴ اوت ۲۰۲۶ در dev.to منتشر شد، پاسخهای استریمشده از مدلها تا زمانی که کلاینت نقطهٔ پایان را تعیین نکند، یک «بستهٔ داده» (Payload) کامل محسوب نمیشوند. در واقع، بسیاری از توسعهدهندگان به اشتباه تصور میکنند هر تکه (Chunk) از دادهای که میرسد، یک شیء JSON معتبر است.
ماهیت باگ
بیشتر APIهای مدلها، پاسخها را به صورت استریم ارسال میکنند. کلاینت بایتها را در قالب تکههای مجزا میبیند، اما این مرزهای تکهها هیچ تضمینی دربارهٔ کامل بودن اشیاء JSON نمیدهند. یک تکه ممکن است دقیقاً در وسط نام یک کلید قطع شود، یا یک تکهٔ جدید با کامایی شروع شود که از شیء قبلی باقی مانده است.
تصور کنید یک آرایه JSON در قطعات مختلف میرسد. پاسخی که باید به صورت [{"role":"assistant","content":"ok","status":"ready"},...] باشد، ممکن است به شکل تکههای ناقصی مثل [{"role":"assistant","content":"ok","st برسد. اگر برنامهنویس روی هر تکه دستور json.loads را اجرا کند، پارسر با دیدن این قطعات ناقص کرش میکند. این یک باگ خطرناک است چون موفقیت یا شکست عملیات کاملاً به زمانبندی شبکه بستگی دارد، نه منطق کد. شما نمیتوانید این مشکل را با کوچکتر کردن خروجی مدل حل کنید؛ تنها راه حل، جداسازی لایهٔ انتقال از لایهٔ اعتبارسنجی است. این چالش با مشکلاتی مشابه در مدیریت استریمها همسو است، مانند آنچه در بهروزرسانی stream_struct برای تفکیک عدم آمادگی داده از مقادیر null بررسی شد.
برای اثبات این موضوع، نویسنده از MonkeyCode برای میزبانی یک فیکسچر (Fixture) استفاده کرد تا یک محیط انتقال نامنظم و واقعگرایانه را شبیهسازی کند. این کار وابستگیهای شبکهٔ محلی را حذف کرده و به توسعهدهنده اجازه میدهد همان شرایط تقسیمبندی دادهها را دوباره بازسازی کند. این سیستم از دو ماژول اصلی تشکیل شده است:
مکانیزم شکست
- chunk_server.py: سروری که پاسخها را با فرمت
Transfer-Encoding: chunkedارسال میکند. این سرور خودِ مدل زبانی را شبیهسازی نمیکند، بلکه لایه انتقال را مدل میکند. این سرور عمداً مرزهای منطقی JSON را نادیده میگیرد و دادهها را در اندازههای تصادفی بین ۷ تا ۹۷ بایت و با وقفههای متغیر ۰.۰۱ ثانیهای ارسال میکند. برای ایجاد یک خروجی JSON واقعگرایانه، از مجموعهای از ردیفهای شاملrole،contentوstatusاستفاده میکند. - validate_stream.py: اعتبارسنجی که دو روش تجزیه را مقایسه میکند. مسیر «ساده» (Naive) سعی میکند دادهها را در لحظه تجزیه کند و اغلب اگر یک تکه تصادفی دقیقاً روی یک شیء کامل تمام شود، گزارش «تجزیهٔ زودهنگام غیرمنتظره» میدهد، یا به دلیل اینکه تنها پس از آخرین بایت یک سند معتبر مییابد، گزارش «شکست تا زمان تکمیل» میدهد.
راهکار بافرینگ (Buffering)
- تجزیهٔ بافری: در این روش، تمام تکهها در یک بافر واحد جمعآوری میشوند. سیستم منتظر میماند تا تکهٔ پایانی (
0\r\n\r\n) برسد و سپس تنها یک بار عملیات اعتبارسنجی را روی کل داده انجام میدهد. - منطق اعتبارسنجی: پس از تکمیل استریم، پارسر ابتدا اطمینان حاصل میکند که ریشهٔ داده یک آرایه است. سپس بررسی میکند که هر آیتم شامل زیرمجموعهای از فیلدهای ضروری یعنی
role،contentوstatusباشد و بهطور خاص چک میکند که مقدارstatusرویreadyتنظیم شده باشد. برای تضمین سختگیرانهتر این ساختارها، برخی پلتفرمها مانند SpaceAI360 از ترکیب Zod و لایههای پاکسازی برای حذف توقفهای API استفاده میکنند.
این رویکرد با جدا کردن بایتهای انتقال از رکوردهای معنایی، اثر زمانبندی شبکه را خنثی میکند. این روش تضمین میکند که زمانبندی بدِ شبکه نتواند نتیجهٔ اعتبارسنجی را تغییر دهد و از پردازش اشیاء ناقص به عنوان اشیاء کامل جلوگیری میکند. البته باید توجه داشت که این روش مشکلاتی مثل تغییر در طرح داده (Schema Drift)، تزریق پرامپت (Prompt Injection) یا بازگرداندن شکل اشتباه شیء توسط مدل را حل نمیکند.
محدودیتها و تستها
یک ماتریس تست نشان میدهد که در حالی که پارسر سادهلوحانه غیرقطعی (Nondeterministic) است، پارسر بافری همیشه کل آرایه را بهطور پایدار اعتبارسنجی میکند. با این حال، این روش هزینههای خاص خود را دارد:
- حافظه: بافر کردن کل استریم حافظه بیشتری میگیرد. برای پاسخهای استثنائاً حجیم، راهنما پیشنهاد میکند به سراغ پارسرهای افزایشی (Incremental) مانند ijson یا json-stream بروید.
- تایماوت: همچنان باید یک زمانبندی (Timeout) اعمال شود. انتظار برای تکهٔ پایانی نباید نامحدود باشد.
- دادههای SSE: مرزهای تصادفی تکهها در خطوط دادهٔ رویدادهای ارسالی سرور (SSE) نیز ظاهر میشوند. همان قاعده حاکم است: ابتدا رویداد را جمعآوری کنید و سپس فیلد داده را تجزیه کنید. در محیطهای وب، بهینهسازی این جریانها میتواند با استفاده از مرزهای Suspense در Next.js برای کاهش تأخیر استنتاج تکمیل شود.
این تغییر معماری، فرض قدیمی مبنی بر اینکه APIهای استریمشده توالیای از اشیاء معتبر هستند را تغییر میدهد و استریم را به عنوان یک «رویداد انتقال واحد» میبیند. اگر از کلاینتهای سطح بالا با متد داخلی .json() استفاده میکنید، احتمالاً کلاینت این بافرینگ را برای شما انجام میدهد. به همین ترتیب، اگر حجم دادهها به قدری کوچک است که در یک بدنهٔ پاسخ جا شوند، یک دستور سادهٔ read() کافی است.
توسعهدهندگان اکنون باید این فیکسچر را روی کلاینتهای HTTP واقعی خود اجرا کنند. هر نقطهٔ انتهایی (Endpoint) مبتنی بر مدل باید پیش از انتشار، یک تست یکپارچهٔ اعتبارسنج بافری را پاس کند تا از کرشهای متناوب در محیط تولید جلوگیری شود.
گام بعدی شما
- تمام نقاط انتهایی (Endpoints) مدلهای خود را با یک تست یکپارچهٔ اعتبارسنج بافری بررسی کنید.
- اگر از پاسخهای حجیم استفاده میکنید، کتابخانه ijson را جایگزین
json.loadsکنید. - در پیادهسازی SSE، مطمئن شوید که ابتدا خط کامل رویداد را دریافت و سپس تجزیه میکنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو