از زمان آغاز پاسخ تا سرعت تولید توکن؛ نقش حافظه، همزمانی و ارتباطات در کارایی واقعی استنتاج

یک سامانهٔ استنتاج ممکن است در هر ثانیه توکن بیشتری تولید کند، اما کاربر برای دریافت پاسخ از آن بیشتر منتظر بماند. حتی ممکن است سامانه‌ای زودتر نوشتن را آغاز کند و دیرتر پاسخ را تمام کند. این تفاوت‌ها تناقض نیستند؛ حاصل اندازه‌گیری چیزهای متفاوت با عنوان مشترک «سرعت» هستند.

در مقالهٔ پیشین، «INT8 یا FP8؟ پیش از انتخاب GPU، پشتیبانی واقعی را بررسی کنیم»، مسئله این بود که توان درج‌شده در مشخصات سخت‌افزار الزاماً در مسیر واقعی اجرای مدل قابل استفاده نیست. اینجا یک مرحله جلوتر می‌رویم: حتی اگر مدل از کرنل مناسب و شتاب سخت‌افزاری استفاده کند، هنوز نمی‌توان از روی توان محاسباتی کارت، زمان پاسخ سرویس را پیش‌بینی کرد.

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

وقتی می‌گوییم «سریع»، چه چیزی را اندازه می‌گیریم؟

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

معیارتعریف عملیاتیکاربرد
TTFT؛ زمان تا نخستین توکنفاصلهٔ ارسال درخواست تا دریافت نخستین توکن محتواییسنجش انتظار اولیه
TPOT؛ زمان به‌ازای توکن خروجیمیانگین زمان تولید توکن‌های پس از نخستین توکنسنجش آهنگ ادامهٔ پاسخ
ITL؛ فاصلهٔ بین توکن‌هافاصله‌های دریافت در طول جریان خروجی، با توجه به تعداد توکن هر بستهتشخیص مکث و نوسان
نرخ توکن هر کاربرتعداد توکن‌های پس از نخستین توکن، تقسیم بر مدت دریافت آن‌هاسنجش سرعت تولید برای یک درخواست
توان عملیاتی کل خروجیمجموع توکن‌های خروجی در بازهٔ اندازه‌گیری، تقسیم بر طول آن بازهسنجش ظرفیت کل سرویس
تأخیر انتهابه‌انتهافاصلهٔ ارسال درخواست تا دریافت آخرین توکنسنجش زمان تکمیل پاسخ

این تفکیک با معیارهای ابزارهای سنجش استنتاج سازگار است؛ بااین‌حال تعریف دقیق هر ابزار باید همراه نتیجه ثبت شود. برخی ابزارها فاصلهٔ بسته‌های پاسخ را اندازه می‌گیرند و هر بسته می‌تواند چند توکن داشته باشد. مستندات معیارهای GenAI-Perf

در این مقاله، اگر زمان ارسال درخواست را t0t_0، دریافت نخستین توکن را t1t_1، دریافت آخرین توکن را tNt_N و تعداد توکن‌های خروجی را N>1N>1 بگیریم:

TTFT=t1−t0TTFT=t_1-t_0
TPOT=tN−t1N−1TPOT=\frac{t_N-t_1}{N-1}
ruser=N−1tN−t1r_{\text{user}}=\frac{N-1}{t_N-t_1}

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

TTFT اندازه‌گیری‌شده در سمت کاربر نیز صرفاً زمان اجرای GPU نیست؛ صف، شبکه و پردازش درخواست را در بر می‌گیرد. در مدل‌های استدلالی، نخستین توکن استدلال هم ممکن است بسیار زودتر از نخستین بخش پاسخ نهایی برسد. AIPerf برای این تفاوت، معیار جداگانهٔ «زمان تا نخستین توکن خروجی غیر‌استدلالی» دارد. تعریف معیارها در AIPerf

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

شروع زودتر، پایان زودتر را تضمین نمی‌کند

دو پیکربندی فرضی را در نظر بگیریم:

پیکربندیTTFTTPOTنرخ تولید پس از نخستین توکنپایان پاسخ ۱۰۱ توکنیپایان پاسخ ۱۰۰۱ توکنی
الف۰٫۴ ثانیه۴۰ میلی‌ثانیه۲۵ توکن‌برثانیه۴٫۴ ثانیه۴۰٫۴ ثانیه
ب۱ ثانیه۲۰ میلی‌ثانیه۵۰ توکن‌برثانیه۳ ثانیه۲۱ ثانیه

اعداد جدول آموزشی‌اند و به سخت‌افزار مشخصی تعلق ندارند. فرض شده طول خروجی یکسان است و TPOTهای ذکرشده در هر دو طول برقرار می‌مانند. زمان پایان از رابطهٔ زیر محاسبه شده است:

Tresponse=TTFT+(N−1)×TPOTT_{\text{response}}=TTFT+(N-1)\times TPOT

پیکربندی الف زودتر آغاز می‌کند؛ پیکربندی ب پاسخ‌های بلند را زودتر تمام می‌کند. در این مثال، برای خروجی ۳۱ توکنی زمان پایان هر دو برابر است و پس از آن، ب جلو می‌افتد.

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

استنتاج، یک بار کاری یکنواخت نیست

در اجرای متداول یک مدل زبانی خودرگرسیو، prefill ورودی را پردازش و اطلاعات کلید و مقدار لایه‌های attention را در KV cache ذخیره می‌کند. خروجی این پردازش برای انتخاب نخستین توکن نیز استفاده می‌شود. سپس decode با استفاده از وضعیت قبلی، تولید را ادامه می‌دهد و KV cache را گسترش می‌دهد.

در prefill، تعداد زیادی توکن ورودی می‌توانند در محاسبات ماتریسی مشارکت کنند. در decode معمول، هر درخواست در هر گام یک توکن پیش می‌رود؛ بنابراین فرصت استفادهٔ همزمان از واحدهای محاسباتی متفاوت است. decode با batch کوچک می‌تواند به خواندن وزن‌ها و KV cache حساس باشد، در حالی که prefill بلند معمولاً فرصت بیشتری برای استفاده از توان محاسباتی فراهم می‌کند. این توصیف یک گرایش است؛ طول زمینه، ساختار مدل، batch و روش اجرا می‌توانند گلوگاه را تغییر دهند. تحلیل استنتاج ترنسفورمر در How To Scale Your Model

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

حافظه فقط محل جاگرفتن مدل نیست

در ارزیابی حافظه باید سه پرسش جدا مطرح شود: داده‌ها جا می‌شوند؟ با چه نرخی خوانده می‌شوند؟ رسیدن به دادهٔ مورد نیاز چقدر تأخیر دارد؟

ظرفیت بیشتر می‌تواند امکان نگهداری مدل، زمینهٔ بلندتر یا درخواست‌های فعال بیشتر را فراهم کند. اما این ظرفیت به‌تنهایی زمان خواندن وزن‌ها را کاهش نمی‌دهد. پهنای‌باند نیز نرخ انتقال را توصیف می‌کند و با تأخیر دسترسی یکسان نیست.

برای یک عملیات، یک تقریب اولیه چنین است:

Top≳max⁡(FP,DB)T_{\text{op}}\gtrsim \max\left( \frac{F}{P}, \frac{D}{B} \right)

در این رابطه، FF تعداد عملیات محاسباتی، PP نرخ محاسبه، DD حجم تبادل داده با سطح حافظهٔ مورد بررسی و BB پهنای‌باند همان سطح است. این تقریب فرض می‌کند محاسبه و انتقال امکان هم‌پوشانی دارند؛ سربار اجرا و کمبود موازی‌سازی می‌توانند زمان را بیشتر کنند. راهنمای رسمی NVIDIA دربارهٔ محدودیت محاسبه، حافظه و تأخیر

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

برای نمونه، فرض کنیم در یک گام decode لازم باشد دقیقاً ۷۰ گیگابایت داده از حافظه خوانده شود و پهنای‌باند مؤثر ۲ ترابایت‌برثانیه باشد. کف زمان همین خواندن، با واحدهای ده‌دهی، ۳۵ میلی‌ثانیه است:

70×1092×1012=0.035 s\frac{70\times10^9}{2\times10^{12}}=0.035\ \text{s}

این محاسبه پیش‌بینی سرعت یک مدل ۷۰ میلیاردپارامتری نیست؛ فرض مشخصی دربارهٔ حجم واقعی خواندن در هر گام دارد و attention، ارتباطات و سربارها را نیز جدا حساب نکرده است. فایدهٔ آن نشان‌دادن محدودیتی است که افزایش FLOPS به‌تنهایی برطرف نمی‌کند.

KV cache هم باید در بودجهٔ حافظه حضور داشته باشد. در attention متداولِ تمام‌زمینه، با افزایش طول توالی و درخواست‌های فعال، نیاز آن رشد می‌کند. کوانتیزه‌سازی یا انتقال cache به حافظهٔ میزبان می‌تواند مصرف حافظهٔ GPU را کاهش دهد، اما آثار عملکردی خودش را دارد؛ نوع attention و راهبرد cache نیز تعیین‌کننده‌اند. راهنمای راهبردهای KV cache در Transformers

جاگرفتن وزن‌ها، اثبات ظرفیت سرویس‌دهی نیست.

چرا افزایش ظرفیت کل می‌تواند سرعت هر کاربر را کاهش دهد؟

اجرای چند درخواست در یک batch می‌تواند استفاده از وزن‌ها و منابع محاسباتی را مؤثرتر کند. بااین‌حال، هدف سامانه ممکن است بیشینه‌کردن خروجی جمعی باشد، حتی اگر فاصلهٔ توکن‌های هر درخواست افزایش یابد.

برای روشن‌شدن تفاوت، یک بازهٔ پایدار و کاملاً فرضی را در نظر بگیریم که همهٔ درخواست‌های آن در حال decode هستند:

حالتدرخواست فعال در decodeنرخ هر درخواستنرخ کل خروجی
الف۲۰۸۰ توکن‌برثانیه۱٬۶۰۰ توکن‌برثانیه
ب۱۰۰۳۰ توکن‌برثانیه۳٬۰۰۰ توکن‌برثانیه

حالت ب تقریباً ۱٫۹ برابر توکن بیشتری تولید می‌کند، اما هر کاربر در حالت الف حدود ۲٫۷ برابر سریع‌تر خروجی می‌گیرد. این جدول رابطهٔ حسابی یک وضعیت فرضی را نشان می‌دهد؛ قانون تغییر سرعت با افزایش همزمانی نیست.

در سرویس واقعی، درخواست‌ها دائماً وارد و خارج می‌شوند و طول‌های متفاوت دارند. زمان‌بندی نیز مهم است. برای مثال، مستندات vLLM توضیح می‌دهد که chunked prefill ورودی‌های بلند را به بخش‌های کوچک‌تر تقسیم و با decode زمان‌بندی می‌کند. تغییر بودجهٔ توکن این زمان‌بندی می‌تواند موازنهٔ TTFT و فاصلهٔ توکن‌ها را تغییر دهد. مستندات بهینه‌سازی vLLM

پس دو بنچمارک با سخت‌افزار و مدل یکسان، اما سیاست زمان‌بندی متفاوت، ممکن است تجربهٔ کاربری متفاوتی بسازند.

LPX؛ تقسیم کار حتی داخل decode

NVIDIA در معماری معرفی‌شدهٔ Vera Rubin همراه با Groq 3 LPX، prefill و attention مرحلهٔ decode را به GPU و بخش‌های FFN/MoE در decode را به LPU می‌سپارد. بنابراین همهٔ decode به LPU منتقل نمی‌شود. داده‌های میانی میان دو بخش مبادله می‌شوند. شرح رسمی معماری NVIDIA

نمودار زیر بازترسیم مفهومی همین تقسیم کار است؛ عملیات فرعی مانند نرمال‌سازی، اتصالات باقیمانده و جزئیات توزیع تانسورها را نشان نمی‌دهد:

تقسیم کار GPU و LPU: اجرای prefill و attention روی GPU و واگذاری FFN یا خبرگان MoE به LPU در حلقهٔ تولید توکن

دریافت کد Mermaid نمودار

این تفکیک با جداکردن prefill و decode در دو گروه پردازنده یکسان نیست. پژوهش DistServe نمونه‌ای از تفکیک دو مرحله برای کنترل تداخل آن‌ها و بهینه‌سازی خدمت‌دهی تحت قید تأخیر است؛ نمونهٔ LPX تفکیک را به اجزای داخل decode نیز می‌برد. مقالهٔ اصلی DistServe

علت توجه به این نمونه، نام یک محصول نیست. مسئلهٔ معماری آن است که بخش‌های مختلف یک درخواست، نسبت یکسانی از ظرفیت حافظه، پهنای‌باند و توان محاسباتی نمی‌خواهند.

اعداد حافظه را در مقیاس درست بخوانیم

صفحهٔ رسمی LPX مشخصات زیر را اعلام می‌کند:

مشخصهٔ اعلام‌شدهمقیاس
۵۰۰ مگابایت SRAMهر LPU
۱۵۰ ترابایت‌برثانیه پهنای‌باند SRAMهر LPU
۲۵۶ تراشهٔ LPUیک رک LPX
۱۲۸ گیگابایت SRAM و ۱۲ ترابایت DDR5یک رک LPX
حدود ۴۰ پتابایت‌برثانیه پهنای‌باند SRAMتجمیعی در سطح رک
۶۴۰ ترابایت‌برثانیه پهنای‌باند scale-upدر سطح رک

منبع: صفحهٔ رسمی NVIDIA Groq 3 LPX

این‌ها مشخصات اعلامی سازنده‌اند. عدد تجمیعی SRAM یک رک را نمی‌توان مستقیماً با پهنای‌باند HBM یک GPU مقایسه کرد. همچنین ظرفیت DDR5، SRAM نیست و نرخ scale-up داخل رک، نرخ قابل استفادهٔ یک تبادل مشخص میان GPU و LPU را تعیین نمی‌کند.

از مجموع ۱۲۸ گیگابایت SRAM نیز نمی‌توان نتیجه گرفت که تمام وزن‌های یک مدل بسیار بزرگ همواره در SRAM جا می‌گیرند. محل داده، نحوهٔ توزیع و دفعات جابه‌جایی باید در تحلیل بمانند.

ارتباطات، هزینهٔ تقسیم کار را تعیین می‌کند

تقسیم یک عملیات میان دو شتاب‌دهنده زمانی سودمند است که صرفه‌جویی اجرا از هزینهٔ اضافهٔ انتقال و هماهنگی بیشتر باشد.

برای تقریب زمان یک تبادل می‌توان نوشت:

Ttransfer≈α+SBeffectiveT_{\text{transfer}}\approx \alpha+\frac{S}{B_{\text{effective}}}

در اینجا α\alpha تأخیر ثابت آغاز و تحویل، SS اندازهٔ پیام و BeffectiveB_{\text{effective}} پهنای‌باند مؤثر مسیر است. این مدل ساده، اثر ازدحام و تغییرات زمان اجرا را کامل پوشش نمی‌دهد، اما یک تمایز را روشن می‌کند: برای پیام کوچک، کاهش تأخیر ثابت ممکن است از افزایش پهنای‌باند مهم‌تر باشد.

مثلاً فرض کنیم در یک طراحی فرضی، تولید هر توکن به ۸۰ رفت‌وبرگشت وابسته نیاز داشته باشد و هزینهٔ ثابت مجموع هر رفت‌وبرگشت ۱۰ میکروثانیه باشد. سهم ثابت ارتباطات، پیش از حساب‌کردن حجم داده، ۰٫۸ میلی‌ثانیه می‌شود. اگر رفت‌وبرگشت ۵۰ میکروثانیه باشد، این سهم به ۴ میلی‌ثانیه می‌رسد.

این مثال مشخصات LPX نیست. نشان می‌دهد چرا حتی تبادل داده‌های کم‌حجم در یک حلقهٔ پرتکرار می‌تواند مهم باشد.

شرط سادهٔ سودمندی واگذاری یک بخش، در حالت بدون هم‌پوشانی، چنین است:

Told>Tnew+Ttransfer+TcoordinationT_{\text{old}}> T_{\text{new}}+ T_{\text{transfer}}+ T_{\text{coordination}}

در پیاده‌سازی واقعی باید سهمی از این هزینه‌ها را سنجید که پس از هم‌پوشانی همچنان در مسیر بحرانی باقی می‌ماند.

همین ملاحظه دربارهٔ افزودن GPU هم برقرار است. افزایش tensor parallelism می‌تواند حافظهٔ بیشتری آزاد کند، اما هماهنگی بیشتری می‌طلبد؛ مستندات vLLM نیز صریحاً به این سربار اشاره می‌کند. ملاحظات موازی‌سازی در vLLM

بنابراین «مدل روی چهار کارت اجرا می‌شود» به معنی «هر کاربر چهار برابر سریع‌تر پاسخ می‌گیرد» نیست.

ادعای سازنده را با چه حدودی بخوانیم؟

NVIDIA برای ترکیب Vera Rubin NVL72 و LPX، در نقطهٔ حدود ۴۰۰ توکن‌برثانیه برای هر کاربر، تا ۳۵ برابر توان عملیاتی بیشتر به‌ازای مگاوات نسبت به GB200 NVL72 اعلام می‌کند. این ادعای سازنده دربارهٔ پیکربندی و سناریوی معرفی‌شده است؛ به معنی ۳۵ برابر کاهش زمان پاسخ هر درخواست یا برتری همگانی LPX نیست. نمودار و توضیح NVIDIA

برای تبدیل چنین ادعایی به مبنای خرید باید مدل، دقت عددی، طول ورودی و خروجی، همزمانی، تعداد رک‌ها، مرز اندازه‌گیری توان و محدودیت تأخیر معلوم باشند. عدد «توکن به‌ازای مگاوات» نیز قیمت خرید، هزینهٔ شبکه، بهره‌برداری و استفادهٔ واقعی از ظرفیت را به‌تنهایی پوشش نمی‌دهد.

در منابع بررسی‌شده برای این مقاله، مبنای شرح LPX اسناد خود NVIDIA است. اعداد آن در اینجا نتیجهٔ بازتولید مستقل معرفی نمی‌شوند.

چه ظرفیتی واقعاً قابل فروش یا استفاده است؟

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

در تجربهٔ فشار بار روی ترگمان، شروع پاسخ در زمان خلوتی معمولاً کمتر از یک ثانیه طول می‌کشید؛ زیر بار، انتظار می‌توانست به آستانهٔ ۲۰ ثانیه برسد و درخواستِ بدون شروع پاسخ لغو می‌شد. سامانه در آن وضعیت حدود ۳۰۰ درخواست هم‌زمان داشت، اما همه به پاسخ موفق نمی‌رسیدند. این همان تفاوتی است که در محاسبهٔ ظرفیت قابل استفاده باید دیده شود: شمار درخواست‌های حاضر در سامانه، جای شمار پاسخ‌های تحویل‌شده در زمان قابل قبول را نمی‌گیرد.

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

برای یک سرویس مشخص می‌توان ابتدا چنین هدفی نوشت: «حداقل ۹۵ درصد درخواست‌ها، هم TTFT کمتر از دو ثانیه و هم TPOT کمتر از ۵۰ میلی‌ثانیه داشته باشند.» این اعداد فقط نمونه‌اند و باید از نیاز محصول استخراج شوند.

تأکید بر «هم» عمدی است. گزارش جداگانهٔ صدک ۹۵ هر معیار تضمین نمی‌کند که همان ۹۵ درصد درخواست‌ها هر دو شرط را برآورده کرده باشند.

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

آزمون پذیرش را از نیاز سرویس بنویسیم

پیش از مقایسهٔ کارت‌ها، مشخصات آزمون باید ثابت و قابل تکرار باشند:

بخش آزمونمواردی که باید ثبت شوند
مدل و کیفیتنسخهٔ وزن‌ها، tokenizer، کوانتیزه‌سازی و معیار پذیرش پاسخ
ورودی و خروجیتوزیع طول‌ها، زبان، زمینهٔ چندنوبتی و طول خروجی واقعی
بار ورودینرخ ورود، همزمانی، جهش ترافیک و مدت آزمون
موتور اجرانسخه‌ها، batch، موازی‌سازی، chunked prefill و تنظیم cache
قابلیت‌های شتاب‌دهیوضعیت prefix caching و speculative decoding
تأخیرتوزیع TTFT و TPOT، مکث‌های جریان و زمان پایان
ظرفیتنرخ خروجی کل، درخواست موفق، خطا، timeout و goodput
زیرساخت و هزینهتعداد کارت و سرور، توپولوژی، مصرف توان و هزینهٔ کل پیکربندی

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

برای محتوای فارسی، ورودی‌های واقعی فارسی باید در نمونه حضور داشته باشند. «توکن‌برثانیه» میان دو tokenizer الزاماً حجم یکسانی از متن را نمایندگی نمی‌کند؛ بنابراین مقایسهٔ مدل‌های متفاوت به سنجش کیفیت و زمان انجام کار مشترک هم نیاز دارد.

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

انتخاب GPU از تعریف پاسخ مطلوب آغاز می‌شود

برای خرید زیرساخت استنتاج، پرسش «کدام کارت سریع‌تر است؟» هنوز زودهنگام است. ابتدا باید معلوم شود پاسخ کوتاه است یا بلند، چند درخواست همزمان داریم، تأخیر قابل قبول چقدر است و کدام بخش اجرا زمان را مصرف می‌کند.

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

معیار خرید باید ظرفیت خدمت‌دهی با کیفیت و تأخیر مورد نیاز باشد. توان محاسباتی، حافظه و شبکه ابزار رسیدن به این هدف‌اند؛ رتبهٔ بالاتر در یکی از این ستون‌ها، به‌تنهایی رتبهٔ بالاتر در پاسخ‌گویی نمی‌سازد.