گزارش فنی: کمبود توکن باعث حذف پاسخ نهایی در مدل‌های استدلالی شد

تصور کنید برای یک مسئله پیچیده هزینه پرداخت کرده‌اید، اما مدل در نهایت هیچ پاسخی نمی‌دهد؛ فقط در سکوت فکر کرده و بودجه شما را تمام کرده است. اگر از مدل‌های استدلالی (Reasoning Model) — مدل‌هایی که قبل از جواب یک قدم درنگ می‌کنند و فکر می‌کنند، شبیه شطرنج‌بازی که چند حرکت جلوتر را می‌بیند — استفاده می‌کنید، باید بدانید که پاسخ‌های خالی همیشه به معنای خرابی سرور نیستند.

بر اساس گزارش یک توسعه‌دهنده در ۳۰ جولای ۲۰۲۶، یک خط لوله تولیدی که از مدل deepseek-v4 استفاده می‌کرد، با بحرانی عجیب روبرو شد: مدل پاسخ‌های کاملاً خالی برمی‌گرداند. سامانه این اتفاق را به عنوان خطای انتقال (Transport Error) ثبت می‌کرد و احتمال قطع شدن استریم یا محدودیت نرخ درخواست (Rate-limiting) را می‌داد، اما بررسی لاگ‌های شبکه در تمام طول فرآیند هیچ مشکلی را نشان نمی‌داد.

همان‌طور که در تحلیل‌های پیشین ما درباره قابلیت‌های استدلالی مدل‌های زبانی اشاره کردیم، این مدل‌ها برخلاف مدل‌های چت معمولی، ابتدا یک زنجیره تفکر (Chain-of-Thought) — شبیه وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — اجرا می‌کنند و سپس پاسخ نهایی را می‌نویسند.

تعقیب لایه‌ی اشتباه

توسعه‌دهنده در ابتدا تصور می‌کرد مشکل از لایه خروجی است و استریم پاسخ قطع شده است. طبق مستندات فنی منتشر شده، چون خطا به لایه خروجی اشاره می‌کرد، او چندین مرحله ابزارگذاری (Instrumentation) را روی مسیر استریم انجام داد تا نقطه شکست را پیدا کند. این بررسی‌ها شامل موارد زیر بود:

• بررسی اینکه آیا اتصال Server-Sent Events (SSE) در میانه‌ی پاسخ قطع می‌شود یا خیر.
• بررسی اینکه آیا ارائه‌دهنده در حال اعمال محدودیت نرخ (Rate-limiting) است و سوکت را به صورت بی‌صدا می‌بندد.
• تحلیل فرآیند بازسازی داده‌ها (Deserialization) برای یافتن بایت‌های گم‌شده یا بلعیده شده.

با این حال، لاگ‌ها نشان می‌دادند که یک رفت‌وبرگشت کامل (Round-trip) بدون هیچ‌گونه Time-out رخ داده است. درخواست‌ها ارسال شده و پاسخ‌ها با موفقیت بازگشته بودند. لایه HTTP هیچ تکه (Chunk) معیوبی را نشان نمی‌داد، اما در نوبت پاسخ دستیار (Assistant turn)، فیلد محتوا (Content) دقیقاً صفر توکن بود.

این حالت شکست، مختص به مدل‌های استدلالی است که متفاوت از LLMهای چت استاندارد عمل می‌کنند. این مدل‌ها پیش از نوشتن خروجی نهایی که برای کاربر قابل مشاهده است، یک توالی داخلی از زنجیره تفکر را اجرا می‌کنند. این نوع شکست‌های نامحسوس یادآور الگوهای شکست خاموشی است که در آن‌ها عامل‌های هوش مصنوعی بدون اعلام خطا، خروجی‌های گمراه‌کننده یا ناقص تولید می‌کنند. در این مورد خاص، تمام تفکرات داخلی مدل در فیلد reasoning_content قرار داشت، در حالی که فیلد content نهایی کاملاً خالی مانده بود.

به نقل از یک گزارش فنی در سایت dev.to، علت ریشه‌ای این اتفاق، بودجه توکنی بود که نسبت به پیچیدگی تسک بسیار پایین بود. مدل تمام توکن‌های موجود را صرف فرآیند فکر کردن داخلی خود کرد و در نهایت بودجه‌ای برای نوشتن پاسخ واقعی باقی ننماند. این وضعیت یک اثر انگشت فنی (API Fingerprint) خاص ایجاد کرد: ترکیب دلیل پایان finish_reason: "length" همراه با یک فیلد reasoning_content پر شده، اما یک فیلد content خالی.

راهکار فنی

برای حل این مشکل، توسعه‌دهنده دو تغییر اصلی را اعمال کرد که در کامیت 193aba6 در فایل‌های packages/llm-client/src/index.ts و produce.ts مستند شده است:

• گسترش بودجه: افزایش پارامتر maxTokens برای پوشش هم‌زمان زنجیره استدلال و خروجی نهایی. مدل‌های استدلالی توکن‌ها را متفاوت از مدل‌های استاندارد می‌سوزانند؛ بودجه‌ای که برای یک مدل غیر‌استدلالی کار می‌کند، ممکن است توسط زنجیره تفکر کاملاً بلعیده شود پیش از آنکه حتی یک توکن خروجی نوشته شود.
• به‌روزرسانی تشخیص: اضافه کردن یک پرچم (Flag) به نام reasoningOnly به نوع ChatResult که به صورت reasoningOnly: !content.trim() && hasReasoning تعریف شده است. این تغییر تضمین می‌کند که وقتی این پرچم فعال است، سیستم به جای یک خطای شبکه عمومی، پیام «بودجه توکن توسط استدلال مصرف شد — هیچ خروجی تولید نشد» را نمایش دهد.

این تغییر، منطق جایگزینی خودکار (Fallback) را به کلی تغییر داد. در گذشته، سیستم با دریافت محتوای خالی، بلافاصله مدل را با خانواده‌ای دیگر جایگزین می‌کرد. اما اکنون، سیستم یک توالی «دو برابر کردن بودجه و تلاش مجدد» را فعال می‌کند. دلیل این است که اگر reasoningOnly درست باشد، تعویض مدل کمکی نمی‌کند؛ زیرا اگر بودجه همچنان کم باشد، توسعه‌دهنده با هر خانواده مدل دیگری هم به همین دیوار برخورد خواهد کرد. این چالش در مدیریت منابع، مشابه مشکلاتی است که مدل‌های محلی در سناریوهای سخت مهندسی با آن‌ها مواجه شده و نرخ موفقیت آن‌ها در فراخوانی ابزارها به شدت افت می‌کند.

محدودیت‌ها و ملاحظات

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

• End-pointهای مدیریت‌شده: اگر درخواست از طریق یک پروکسی ارسال شود که پارامترهای بودجه را در دسترس قرار نمی‌دهد، امکان پیکربندی بودجه وجود ندارد.
• لایه‌های انتزاعی: لایه‌های ارکستراسیونی که پارامترهای بودجه را می‌پوشانند (Abstract)، مانع از اعمال اصلاح مستقیم می‌شوند.

در این موارد، تشخیص reasoningOnly همچنان برای دسته‌بندی خطاها مفید است، حتی اگر بودجه قابل تغییر نباشد.

این تجربه یک مسئله گسترده‌تر در ارکستراسیون هوش مصنوعی را برجسته می‌کند: پیام‌های خطای دقیق از نظر فنی (مانند «مدل محتوای خالی برگرداند»)، می‌توانند از نظر کاربردی بی‌فایده باشند چون انگشت اتهام را به سمت لایه‌ی اشتباهی از استک می‌گیرند. این موضوع شباهت زیادی به مشکلات ناشی از ورودی‌های داده خام دارد که هزینه‌های نامرئی ایجاد کرده و منجر به شکست عامل‌های هوش مصنوعی می‌شوند. لحظه‌ای که دلیل پایان خام (finish_reason) و هر دو فیلد محتوا در کنار هم مشاهده شدند، علت مشکل بدیهی شد.

این موضوع برای توسعه‌دهندگان به معنای تغییر در نحوه مانیتورینگ عامل‌های استدلالی است. دیگر نمی‌توانید فرض کنید پاسخ خالی به معنای Time-out سوکت است؛ بلکه باید نسبت توکن‌های استدلال به توکن‌های خروجی را بررسی کنید تا بفهمید آیا مدل شما صرفاً «خودش را در فکر غرق کرده و در بن‌بست گیر افتاده است» یا خیر.

توسعه‌دهندگان باید اکنون Wrapperهای مدیریت خطای خود را بازبینی کنند تا بین شکست‌های لایه انتقال و رویدادهای اتمام توکن در گردش‌کارهای استدلال-محور تفکیک قائل شوند.

گام بعدی شما

• بررسی مجدد Wrapperهای مدیریت خطای خود برای تفکیک خطاهای لایه انتقال از خطاهای اتمام توکن.
• افزایش حاشیه خطای maxTokens در تسک‌هایی که نیاز به استدلال عمیق دارند.
• مانیتور کردن فیلد reasoning_content در مدل‌های استدلالی برای تحلیل نرخ مصرف توکن قبل از خروجی.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.