از یک AI builder بخواهید یک فرآیند ورود کارکرد را راهاندازی کند — فرم، اعتبارسنجی، یک مسیر، یک بررسی پایگاه داده — و معمولاً بین ۳۵ تا ۹۰ ثانیه منتظر میمانید تا یک diff ظاهر شود. اگر این درخواست را سرتاسر بررسی کنید، خود مدل، یعنی بخشی که واقعاً توکن تولید میکند، فقط حدود ۳ تا ۴ ثانیه از این زمان را به خود اختصاص میدهد. رفتوبرگشت شبکه ۱ تا ۲ ثانیه دیگر اضافه میکند. بیش از ۳۰ ثانیه باقیمانده، همان بخشی که آن را «فکر کردن هوش مصنوعی» تجربه میکنید، تقریباً بهطور کامل چیز دیگری است: تیم ایجنت شما در حال خواندن فایلها، اجرای build و بررسی کار خودش پیش از نمایش نتیجه به شماست.
این نسبت تقریباً برای همه، در اولین باری که آن را اندازهگیریشده میبینند، شگفتآور است، حتی برای مهندسانی که کارشان ساخت همین چیزهاست. تصور رایج این است که یک مدل بزرگتر و کندتر باید گلوگاه باشد، پس راهحل یک build کند باید یک مدل سریعتر باشد. گاهی این درست است. اما در بیشتر مواقع اینطور نیست، و درک اینکه چرا اینطور است نحوه تفکر شما درباره اندازه پرامپت، اندازه پروژه و انتظارتان از زمانی که یک build احساس «گیر کردن» میدهد را تغییر میدهد.
چه چیزی واقعاً زمان را پر میکند
یک درخواست ساده «افزودن یک ویژگی» را به مراحل مختلف تقسیم کنید و بلافاصله یک الگو نمایان میشود: مدل زمان خود را در انفجارهای کوتاه و ارزان میگذراند — تصمیمگیری درباره قدم بعدی، نوشتن یک فراخوانی ابزار، خواندن یک نتیجه — در حالی که بخشهای پرهزینه و کند بین این انفجارها، روی دیسک و در یک شل رخ میدهند.
| مرحله | سهم معمول از کل زمان | چه اتفاقی میافتد |
|---|---|---|
| استنتاج مدل (تولید) | 5–10% | توکنهایی که تولید میشوند — برنامه، کد، آرگومانهای فراخوانی ابزار |
| خواندن فایلها / گردآوری context | 10–15% | دریافت فایلهای موجود، تاریخچه اجراهای قبلی، قراردادهای پروژه |
| اجرای ابزار (نوشتن، شل، نصب پکیجها) | 35–45% | تغییر واقعی فایلها، اجرای linter، نصب یک وابستگی |
| مرحله build / کامپایل | 15–25% | build فریمورک، بررسی نوع، bundling — این با اندازه پروژه مقیاسپذیر است، نه اندازه پرامپت |
| ایجنتهای اعتبارسنجی | 15–20% | یک بررسی دوم که مطمئن میشود diff دقیقاً همان کاری را انجام میدهد که خواسته شده، پیش از نمایش آن به شما |
| سربار شبکه / استریمینگ | 2–5% | رفتوبرگشتها بین مدل، sandbox و مرورگر شما |
دو نکته از این جدول بیرون میآید که وقتی کنار هم دیده شوند، بدیهی نیستند. اول، مرحله build با اندازه کل پروژه مقیاسپذیر است، نه اندازه پرامپت شما — یک تغییر یکخطی CSS در یک اپلیکیشن ۴۰۰ فایلی میتواند بیشتر از افزودن یک ویژگی پنجفایلی به یک پروژه تازه طول بکشد تا اعتبارسنجی شود، چون کامپایلر در هر دو حالت باید چیزهای بیشتری را بررسی کند. دوم، بزرگترین اهرم اصلاً مدل نیست. این است که چه مقدار لمس میشود.
چرا این توهم پایدار میماند
رابطهای استریمینگ تا حدی مقصرند، اما به شکلی مثبت. اولین توکن معمولاً در کمتر از یک ثانیه ظاهر میشود، پس رابط کاربری بلافاصله پاسخگو به نظر میرسد — میبینید که یک برنامه شکل میگیرد، یک جمله تایپ میشود، فراخوانیهای ابزار اسکرول میشوند. این تأخیر اولین توکن همان چیزی است که افراد در ذهن خود آن را «سرعت هوش مصنوعی» ثبت میکنند. چیزی که بهوضوح نمیبینند این است که وقتی مدل تصمیمگیری درباره کاری که باید انجام دهد را تمام میکند، کار را به یک pipeline build تحویل میدهد که دیگر ربطی به مدلسازی زبان ندارد. یک `docker build`، یک `npm install`، یک type-checker که در گراف importها حرکت میکند — هیچکدام از اینها سریعتر نمیشوند چون GPT-5 جایگزین GPT-4 شده، یا Sonnet جایگزین یک Sonnet قدیمیتر شده است. سریعتر میشوند چون کسی یک لایه وابستگی را cache کرده یا یک بررسی زائد را حذف کرده است.
من دیدهام سازندگانی که در میانه یک پروژه مدل را عوض میکنند به این امید که یک build «کند» را برطرف کنند، دو بار در همان هفته، پیش از آنکه متوجه شوند گلوگاه واقعی یک مرحله اعتبارسنجی بوده که در هر ذخیره یک بررسی نوع کامل را از نو اجرا میکرده، بهجای یک بررسی تدریجی. تعویض مدل هیچچیز را تغییر نداد، چون مدل هیچگاه بخش کند ماجرا نبود.
جایی که این واقعاً به شما آسیب میزند
پیامد عملی در چند مکان قابلپیشبینی خودش را نشان میدهد:
- پرامپتهای بزرگ و پراکنده بهشکلی نامتناسب کند به نظر میرسند — نه به این دلیل که مدل در تجزیه آنها مشکل دارد، بلکه چون یک درخواست که دوازده فایل را لمس میکند، دوازده خواندن فایل، دوازده نوشتن، و یک build که حالا باید همه آنها را با هم هماهنگ کند را فعال میکند.
- با رشد پروژهها، تکرار روی آنها کندتر میشود، حتی وقتی هر پرامپت بهتنهایی ساده باقی میماند، چون مراحل build و اعتبارسنجی با اندازه کل پروژه مقیاسپذیر هستند.
- «گیر کرده» بهندرت به معنای معطل ماندن مدل است. تقریباً همیشه یک مرحله build است که منتظر یک registry پکیج مانده، یا یک ایجنت اعتبارسنجی که یک بررسی را دوباره اجرا میکند که نیازی به اجرای دوباره نداشت.
- تقسیم یک درخواست بزرگ به چند درخواست کوچک اغلب در مجموع سریعتر تمام میشود، چون هر درخواست کوچکتر یک build محدودتر و یک مرحله اعتبارسنجی سبکتر را فعال میکند، حتی اگر حالا در انتظار مراحل بیشتری باشید.
یکی از سازندگان در Discord ما این را خوب بیان کرد: «من مدام یک مغز سریعتر میخواستم، در حالی که چیزی که نیاز داشتم یک diff کوچکتر بود.»
چه چیزی واقعاً زمان انتظار را کوتاه میکند
هیچیک از راهحلهای واقعی به یک مدل بزرگتر نیاز ندارند. buildهای تدریجی که فقط چیزی را که تغییر کرده دوباره کامپایل میکنند بهجای کل پروژه، سهم مرحله build را بهطور چشمگیری کاهش میدهند — این بزرگترین اهرم موجود است و اغلب ارزشش از همه بهینهسازیهای دیگر روی هم بیشتر است. cache کردن نصب وابستگیها بین اجراها بخشی از مرحله اجرای ابزار را حذف میکند که ربطی به پرامپت خاص شما ندارد. محدود کردن اعتبارسنجی به diff واقعی، بهجای بررسی دوباره کل کدبیس در هر بار، این مرحله را متناسب با آنچه تغییر کرده نگه میدارد، نه آنچه وجود دارد. و اجرای موازی فراخوانیهای ابزار مستقل — خواندن سه فایل نامرتبط بهطور همزمان بهجای پشتسرهم — ثانیههای واقعی را از مرحله ورودی/خروجی فایل میکاهد، بدون اینکه به مدل دست بزند.
هیچکدام از اینها جذاب نیستند. همچنین همین دلیلی است که دو سازنده میتوانند پرامپتهای تقریباً یکسانی را در همان روز در همان پلتفرم تایپ کنند و تجربهای کاملاً متفاوت از میزان «هوشمندی» یا «سرعت» آن داشته باشند، در حالی که تفاوت واقعی شکل پروژه است، نه کیفیت مدل. مدل هیچگاه واقعاً همان ساعتی نبود که به آن نگاه میکردید. فقط اینطور به نظر میرسید.
