سرعت استنتاج برای عوامل کدنویسی: TTFT در مقابل توان عملیاتی

سرعت در کدنویسی هوش مصنوعی به‌راحتی می‌تواند ساده‌سازی شود. تیم‌ها اغلب درباره یک مدل یا بک‌اند صحبت می‌کنند گویی که صرفاً سریع یا کند است، اما جریان‌های کاری واقعی کدنویسی سرعت را حداقل به دو سؤال مختلف تقسیم می‌کنند: چقدر سریع اولین توکن مفید می‌رسد و سیستم چقدر کار می‌تواند حفظ کند وقتی تولید آغاز شده است.

یک بنچمارک اخیر کلاین این تقسیم‌بندی را بسیار آشکار کرد. در یک وظیفه کوتاه به سبک حذف، یک تنظیمات مبتنی بر ابر برنده شد زیرا سریع‌تر شروع کرد. در یک آزمون استنتاج خام طولانی‌تر، یک تنظیمات محلی DGX Spark توان عملیاتی بسیار قوی‌تری نسبت به یک GPU مصرف‌کننده که همان مدل را با تخلیه حافظه سنگین اجرا می‌کرد، ارائه داد. برای تیم‌هایی که تصمیم می‌گیرند کجا عامل‌های کدنویسی را اجرا کنند، این تمایز بسیار مهم است.

مقایسه سریع: آنچه آزمون نشان داد

• یک تنظیمات مک مبتنی بر ابر وظیفه کوتاه “Thunderdome” را در 1.04 ثانیه برنده شد.
• همان بنچمارک DGX Spark را در 42.9 توکن در ثانیه در مسابقه استنتاج مستقیم اندازه‌گیری کرد.
• تنظیمات RTX 4090 با تخلیه سنگین RAM به 8.7 توکن در ثانیه رسید.
• زمان دیواری در مسابقه استنتاج مستقیم برای مک مبتنی بر ابر 5.11 ثانیه، برای DGX Spark برابر با 21.83 ثانیه، و برای ورک‌استیشن 4090 برابر با 93.89 ثانیه بود.

جزئیات سخت‌افزاری به توضیح این فاصله کمک می‌کند. NVIDIA’s نمای کلی سیستم DGX Spark طراحی حافظه یکپارچه 128 گیگابایتی آن را برجسته می‌کند، در حالی که ماشین 4090 در آزمون دارای 24 گیگابایت VRAM بود و مجبور بود بخش زیادی از یک مدل 120B را به RAM سیستم تخلیه کند. این کل شکل بار کاری را تغییر می‌دهد.

چرا TTFT مسابقه کوتاه را برنده شد

در یک وظیفه کوچک ترتیبی، زمان تا اولین توکن برنده را تعیین می‌کند. اولین سیستمی که درخواست را درک کند، یک فرمان معتبر تولید کند و آن را اجرا کند، یک شروع اولیه به دست می‌آورد که دیگران ممکن است هرگز نتوانند جبران کنند. این دقیقاً همان چیزی است که در آزمون کوتاه کلاین اتفاق افتاد.

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

چرا توان عملیاتی در جلسات واقعی کدنویسی اهمیت بیشتری دارد

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

با سرعت 42.9 توکن در ثانیه، نتیجه DGX Spark نشان می‌دهد که وقتی یک مدل بزرگ می‌تواند در حافظه سریع باقی بماند چه اتفاقی می‌افتد. در مقابل، نتیجه 4090 نشان می‌دهد که وقتی مدل برای VRAM محلی بیش از حد بزرگ است، انتقال داده چقدر هزینه‌بر می‌شود. همان خانواده مدل می‌تواند بسته به چیدمان حافظه، نه فقط برند یا قیمت خام GPU، کاملاً متفاوت به نظر برسد.

اگر با استک‌های محلی کار می‌کنید، مستندات Ollama یک مرجع خوب برای نحوه ارائه نقاط پایانی مدل محلی و مبتنی بر ابر به صورت سازگار توسط تیم‌ها است. درس مهم این نیست که کدام ابزار را انتخاب می‌کنید. بلکه این است که اندازه مدل، تناسب حافظه و توپولوژی شبکه تجربه کاربر را بسیار بیشتر از آنچه یک تیتر بنچمارک واحد نشان می‌دهد تغییر می‌دهد.

اندازه مدل اقتصاد را تغییر می‌دهد

مقایسه Cline بر روی یک مدل 120B متمرکز بود که سخت‌افزار مصرف‌کننده را به یک رژیم کاملاً متفاوت سوق می‌دهد. وقتی یک مدل از حافظه سریع خارج می‌شود، هزینه شما دیگر فقط توکن‌ها نیست. شما همچنین در تأخیر، صف‌بندی و صبر توسعه‌دهنده هزینه می‌پردازید.

به همین دلیل است که انتخاب بین محلی و ابر به ندرت یک انتخاب صرفاً ایدئولوژیک است. ابر می‌تواند در راحتی و راه‌اندازی سریع برنده شود. سیستم‌های محلی بزرگ می‌توانند در حریم خصوصی، هزینه حاشیه‌ای قابل پیش‌بینی و توان خروجی پایدار برنده شوند. سخت‌افزار مصرف‌کننده همچنان می‌تواند انتخاب درستی باشد، اما اغلب برای مدل‌های کوچکتری که به خوبی جا می‌شوند.

جایگاه ShareAI

ShareAI زمانی کمک می‌کند که بهترین پاسخ یک بک‌اند دائمی نباشد. با بیش از 150 مدل از طریق یک API, ، می‌توانید یک جریان کاری کدنویسی پایدار را حفظ کنید در حالی که مدل یا ارائه‌دهنده را بر اساس کار تغییر می‌دهید. این زمانی مفید است که یک کار TTFT پایین را ترجیح دهد و کار دیگر خروجی پایدار قوی‌تر یا قیمت‌گذاری متفاوت را ترجیح دهد.

می‌توانید از مستندات ShareAI و شروع سریع API برای ساده نگه داشتن این لایه مسیریابی استفاده کنید. به جای بازنویسی یکپارچه‌سازی خود هر بار که می‌خواهید ارائه‌دهندگان یا مدل‌ها را مقایسه کنید، می‌توانید عامل را به یک API هدایت کنید و تصمیمات هوشمندانه‌تری در مورد بک‌اند بگیرید.

چگونه استک مناسب را انتخاب کنیم

• زمانی که پاسخ اول بیشترین اهمیت را دارد و سرعت راه‌اندازی بیشتر از کنترل محلی اهمیت دارد، ابتدا ابر را انتخاب کنید.
• سخت‌افزار محلی با حافظه بالا را انتخاب کنید زمانی که به حریم خصوصی، هزینه قابل پیش‌بینی و توان عملیاتی پایدار قوی در مدل‌های بزرگ نیاز دارید.
• GPUهای مصرف‌کننده را با دقت انتخاب کنید و آن‌ها را با اندازه مدل‌هایی که به خوبی سازگار هستند، مطابقت دهید.
• یک لایه انتزاعی مانند ShareAI را انتخاب کنید زمانی که می‌خواهید ارائه‌دهندگان را بدون بازسازی جریان کاری خود مقایسه، مسیریابی و تغییر دهید.

مرحله بعد

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