۲۹۰ ثانیه؛ این زمانِ تکاندهندهای است که یک مدل ۱۲ میلیارد پارامتری روی سختافزارهای مصرفکننده صرف میکند تا فقط یک پرامپت سیستمی حجیم را بخواند. توسعهدهندهٔ Flash Onyx 2.1 فاش کرد که مجموعهای ۲۷ هزار توکنی از دستورات، مدل را تقریباً فلج کرده بود و آن را مجبور میکرد پیش از تولید حتی یک کلمه، دقایقی را صرف خواندن دستورات خودش کند.
این مشکل تأخیر، تلهای رایج در استقرار محلی مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — را آشکار میکند: هزینهٔ «نامرئی» ارزیابی پرامپت. طبق گزارش این توسعهدهنده، کاربران هنگام اجرای مدلها از طریق Ollama، معمولاً روی سرعت تولید توکن در ثانیه تمرکز میکنند، اما زمان عظیمی که مدل برای پردازش دستورات اولیه سیستمی نیاز دارد را نادیده میگیرند.
زمینه: شکاف عملکردی
این موضوع پس از گزارشهایی برملا شد که میگفت Onyx 2 «برای پاسخ دادن زمان زیادی میبرد». اگرچه پاسخها درست بودند، اما تأخیر بهقدری زیاد بود که کاربران تب مرورگر را میبستند و درخواست خود را فراموش میکردند.
بررسیهای اولیه روی بودجهٔ خروجی متمرکز بود. مقدار num_predict روی ۸۱۹۲ تنظیم شده بود. با سرعت تولید اندازهگیری شدهٔ ۹.۵ توکن در ثانیه، بدترین حالت برای یک پاسخ کامل، ۸۶۲ ثانیه — یعنی تقریباً چهارده و نیم دقیقه — بود. اما گلوگاه واقعی، تولید متن نبود، بلکه پیشپُرکردن (Prefill) بود.
تصور کنید یک سرآشپز حرفهای ۳۰ دقیقه وقت صرف خواندن دفترچه راهنمایی کند که به او میگوید «سریع و مستقیم باش»، و تازه بعد از آن دست به چاقو بزند. وضعیت Onyx 2 دقیقاً همین بود؛ مدل پیش از هر گفتگو، یک رمان را برای خودش میخواند و از میان پنجرهٔ زمینهٔ ۳۲ هزار توکنی، تنها ۵ هزار توکن را برای تعامل واقعی با کاربر باقی میگذاشت. این چالش با بحران مدیریت پنجرههای متنی در مدلهای زبانی همسو است که نشان میدهد ظرفیتهای اعلام شده همیشه با کیفیت خروجی واقعی مطابقت ندارند.
معمای «رشتهٔ خالی»
بحرانیترین شکست مدل، پدیدهٔ «رشتهٔ خالی» بود؛ یعنی مدل هیچ پاسخی برنمیگرداند. توسعهدهنده دریافت که مدل ۴۰۰ توکن را صرف زنجیره تفکر (Chain-of-Thought) — مثل وقتی شاگرد ریاضی پای تخته بلند بلند فکر میکند تا به جواب برسد — میکند، اما هیچ کاراکتری را در خروجی نمایش نمیدهد.
به دلیل اینکه Gemma 4 (پایهٔ مدل Onyx) از یک کانال تفکر مجزا استفاده میکند، مدل تمام بودجهٔ خروجی خود را صرف تأمل دربارهٔ شخصیت و لحن خود میکرد. در یک مورد خاص مربوط به افشای یک کلید امنیتی AWS که به شاخه main ارسال شده بود، مدل تمام بودجهٔ توکنی خود را صرف استدلال دربارهٔ پرسونای خود (سریع، مستقیم، بدون حاشیه، بدون استفاده از خط تیره یا em-dash) و اقدام اصلی (چرخاندن کلید) کرد.
در نهایت، مدل در حالی که هنوز در حال «فکر کردن» به این بود که چگونه مختصر باشد، به سقف توکنها رسید و خطای done_reason: length داد و یک رشتهٔ پاسخ خالی برگرداند. این اتفاق در حالی رخ داد که در یکی از خطوط پرامپت صراحتاً ذکر شده بود: «هرگز دربارهٔ لحن، طول یا انتخاب کلمات تأمل نکن». این محدودیتهای سختگیرانه در بودجه توکن، مشابه مشکلات فلجکننده در محیطهای محدود مانند Cloudflare OS است که در آن سقفهای توکنی مانع از عملکرد صحیح عاملهای AI میشوند.
جزئیات فنی: هزینهٔ استدلال
اندازهگیری مدل با فعال و غیرفعال کردن کانال تفکر، تفاوت فاحشی را در بهرهوری نشان داد:
- تفکر فعال: تولید ۴۰۰ توکن (محدود شده)، ۴۳ ثانیه زمان سپری شده، نتیجه: رشتهٔ خالی.
- تفکر غیرفعال: تولید ۲۰۵ توکن، ۲۴ ثانیه زمان سپری شده، نتیجه: پاسخ کامل و صحیح.
این موضوع ثابت کرد که استدلال یک پرچم (flag) در سطح درخواست است، نه یک تنظیم در Modelfile؛ یعنی کلاینت هزینهٔ استدلالی را میپرداخت که مدل در نهایت آن را در سطل زباله میانداخت.
فرآیند بهینهسازی
برای حل این مشکل، استراتژی سختگیرانهای برای فشردهسازی پرامپت اجرا شد. هدف حذف تکرارها بود؛ توسعهدهنده پذیرفت که یک قانون مشابه چهار بار در چهار بخش مختلف نوشته شده بود و بسیاری از جملات فقط برای «خوب به نظر رسیدن» بودند، نه تغییر رفتار مدل.
مثالی از فشردهسازی:
- قبل: «هرگز فرض نکن کسی میتواند به یک پرامپت برای تو پاسخ دهد. هر بار مسیر غیرتعاملی را انتخاب کن: از -y، --yes، --noconfirm، --no-pager استفاده کن و هر آرگومانی را از ابتدا ارائه بده، زیرا هر چیزی که منتظر ورودی بماند ممکن است تا زمان اتمام مهلت (timeout) متوقف شود. پیجرها، پرامپتهای تأیید، REPLها، ویرایشگرها، فلگهای -i و نبود یک آرگومان ضروری، همگی همان تله هستند.»
- بعد: «هرگز فرض نکن کسی میتواند به پرامپت پاسخ دهد. مسیر غیرتعاملی را بگیر: -y، --yes، --noconfirm، --no-pager، تمام آرگومانها از ابتدا. پیجرها، REPLها، ویرایشگرها، فلگهای -i و نبود آرگومان ضروری همگی تا زمان timeout متوقف میشوند.»
نتایج فوری و قابل اندازهگیری بود:
- طول پرامپت: از ۹۰۳ خط (۲۷ هزار توکن) به ۵۱۶ خط (۱۴ هزار توکن) کاهش یافت.
- زمان پیشپُرکردن: از ۲۹۰ ثانیه به ۱۵۲ ثانیه رسید.
- کیفیت پاسخ: ابتدا افت کرد، اما پس از بازتعریف مفهوم «ایجاز»، بهبود یافت.
پارادوکس ایجاز
کاهش کلمات همیشه به معنای عملکرد بهتر نبود. توسعهدهنده متوجه شد که دستور سادهٔ «مختصر باش» باعث میشود مدل سطحی شود.
به عنوان مثال، وقتی از مدل خواسته شد پیامی در Slack دربارهٔ تأخیر در استقرار (deploy) بنویسد، نسخه Onyx 2 یک بهروزرسانی انسانمحور ارائه داد. اما نسخه ۲.۱ پاسخ داد: «استقرار پنجشنبه به دوشنبه منتقل شد زیرا مهاجرت دیتابیس staging شکست خورد.» اگرچه این پاسخ از نظر فنی کوتاهتر بود، اما بیشتر شبیه به یک خط لاگ سیستمی بود تا پیامی برای یک انسان. شکست مشابهی در یک تست مذاکره رخ داد؛ جایی که مدل به جای بررسی هزینههای جایگزینی و پیشنهاد معامله، بلافاصله در برابر حداکثر درخواست کاربر تسلیم شد.
راه حل این بود که یک تغییر مفهومی در بخش ایجاز ایجاد شود: «فشردهسازی مربوط به کلمات است، نه محتوا. حذف یک گام، یک هشدار که پاسخ را تغییر میدهد، یک معاملهای که ارزش پیشنهاد دادن دارد، یا ادب و آدابی که یک پیام انسانی نیاز دارد، ایجاز نیست؛ بلکه ارائهٔ یک پاسخ بد است که اتفاقاً کوتاه است». این رویکرد به نوعی یادآور استراتژیهای حذف دادههای فکتمحور برای بهینهسازی مدلهای کوچکتر است، جایی که تعادل بین حجم دانش و کارایی مدل مورد بازنگری قرار میگیرد.
قدرت جایگاه (Position)
یکی از شگفتانگیزترین یافتهها، «سوگیری موقعیتی» در پرامپت بود. توسعهدهنده دو دور بازنویسی قوانین مذاکره را در حدود خط ۴۶۰ از ۵۱۶ انجام داد اما هیچ تأثیری نداشت؛ پاسخ در سه دور متوالی دقیقاً یکسان (byte-identical) باقی ماند.
اما به محض اینکه نسخه تکخطی همان قانون به انتهای پرامپت منتقل شد، رفتار مدل فوراً تغییر کرد و شروع به گنجاندن معاملههای مفقود کرد. این نشان میدهد در پرامپتهای سیستمی طولانی، دستورات پایانی وزن بسیار بیشتری نسبت به دستوراتی دارند که در میانه متن دفن شدهاند.
بنچمارکهای نهایی و اصلاحات
پس از چهار دور تنظیم، نسخه ۲.۱ در برابر هفت پرامپت تست شد. نتیجه نهایی: نسخه ۲.۱ در شش مورد برنده شد، در یک مورد تساوی کرد و در هیچ موردی نباخت. پاسخهای نهایی ۷۰٪ طول Onyx 2 بودند اما دقت بالاتری داشتند.
بهبودهای کلیدی در نسخه ۲.۱:
- فرمتبندی: به شدت به قانون «عدم استفاده از em-dash» پایبند بود، در حالی که Onyx 2 یک بار این قانون را شکست.
- منطق کدنویسی: اکنون تفاوت بین یک اسکریپت کامل و یک دستور تکخطی را میفهمد. پیش از این، درخواست «انتقال فایلهای ماه مارس» منجر به تولید یک اسکریپت bash با ۶۶۳ کاراکتر، شامل
set -euo pipefailو یک حلقه حفاظتی میشد. با افزودن جمله «اگر یک دستور کار را انجام میدهد، همان پاسخ است»، خروجی به ۲۰۲ کاراکتر کاهش یافت.
این نتایج بر اساس یک تست دود (smoke test) با مدل ۱۲ میلیارد پارامتری، با seed ثابت و نمرهدهی دستی بود؛ مدل ۳۱ میلیارد پارامتری تست نشد.
این آزمایش ثابت میکند مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن، مثل کسی که میداند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — فقط دربارهٔ کلمات نیست، بلکه دربارهٔ معماری فیزیکی پرامپت و مدیریت بودجهٔ استدلال مدل است. برای کسانی که مدلهای استدلالی را به صورت محلی از طریق ollama run Natuworkguy/flash-onyx-2.1:12b اجرا میکنند، درس روشن است: فیلدهای زمانبندی API خود را رصد کنید. مقدار prompt_eval_duration دقیقاً به شما میگوید که پرامپت سیستمی شما در زمان واقعی چقدر هزینهٔ تأخیر دارد.
گام بعدی شما
- اگر از مدلهای محلی استفاده میکنید، مقدار
prompt_eval_durationرا در خروجی API بررسی کنید تا بفهمید پرامپت سیستمی شما چقدر تأخیر ایجاد میکند. - دستورات حیاتی و تعیینکننده را به انتهای پرامپت سیستمی منتقل کنید تا اثرگذاری بیشتری داشته باشند.
- از تکرار قوانین در بخشهای مختلف پرامپت بپرهیزید و روی حذف کلمات تزئینی تمرکز کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو