مهندسی تأخیر استنتاج هوش مصنوعی: معیار، بودجه و بده‌بستان

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

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

معیارهای صنعتی اکنون مرحله‌های سرو مدل را جدا می‌کنند. MLCommons در معیارهای جدید LLM، TTFT و TPOT را برای سناریوی سرور به کار می‌برد و در توضیح MLPerf Inference v5 محدودیت‌های مخصوص benchmark در صدک ۹۹ تعیین می‌کند، نه یک میانگین کلی. قراردادهای معنایی GenAI در OpenTelemetry نیز معیار زمان تا نخستین توکن دارد. درس ماندگار روشن است: مرحله‌ها و مسیر کند را جدا بسنجید.

واژگان تأخیر را با تجربه کاربر هماهنگ کنید

حداقل این معیارها را instrument کنید:

مرز ساعت را دقیق مشخص کنید. TTFT اندازه‌گیری‌شده در سرور استنتاج با «نخستین نتیجه مفید» در مرورگر فرق دارد. بافر شبکه شاید توکن را دریافت کرده باشد، اما چیزی روی صفحه paint نشده باشد. ابزار شاید HTTP 200 برگرداند، ولی برنامه هنوز وضعیت واقعی کسب‌وکار را بررسی نکرده باشد.

Google Cloud در مستند فعلی معیارهای استنتاج، TPOT را زمان تولید پس از توکن اول تقسیم بر تعداد توکن‌های باقی‌مانده تعریف می‌کند. یک فرمول انتخاب کنید، حالت‌های لبه مانند خروجی تک‌توکن را بنویسید و همه‌جا همان را به کار ببرید.

یک درخواست را به trace مرحله‌ای بشکنید

در مرز کاربر یک شناسه trace بسازید و آن را از این مرحله‌ها عبور دهید:

1. رویداد مرورگر و paint بعدی.
2. شبکه و edge.
3. احراز هویت، مجوز، rate limit و سیاست.
4. بارگذاری گفت‌وگو و حافظه.
5. پرس‌وجوی بازیابی، rerank و دریافت سند.
6. مونتاژ زمینه، tokenization و اعتبارسنجی.
7. مسیریابی مدل و ارائه‌دهنده.
8. پذیرش در صف.
9. prefill.
10. decode و stream.
11. ابزار و retry.
12. اعتبارسنجی خروجی و کنترل ایمنی.
13. رندر رابط.
14. اجرای اثر و بررسی شرط نهایی.

پرامپت و پاسخ حساس را به هر span نچسبانید. شناسه پایدار، نسخه، تعداد توکن، وضعیت cache، مدل، مسیر، نام ابزار، کلاس نتیجه و زمان کافی است. نمونه‌گیری یا redaction محتوا باید سیاست دسترسی جدا داشته باشد.

عملیات موازی را درست نمایش دهید. اگر سه بازیابی هم‌زمان اجرا شوند، زمان آن‌ها به‌سادگی جمع نمی‌شود؛ مسیر بحرانی از کندترین شاخه ضروری و overhead هماهنگی می‌آید.

راهنمای مشاهده‌پذیری عامل ساخت trace گردش‌های چندمرحله‌ای را دقیق‌تر پوشش می‌دهد.

تفاوت prefill، decode، صف و ابزار را بشناسید

Prefill

مدل در prefill زمینه ورودی را پردازش و KV cache لازم برای تولید را می‌سازد. پرامپت بلند معمولاً کار و حافظه بیشتری می‌خواهد. سند بازیابی‌شده بزرگ یا کل تاریخچه می‌تواند TTFT را خراب کند، حتی اگر پاسخ نهایی کوتاه باشد.

Decode

مدل autoregressive خروجی را به‌صورت ترتیبی تولید می‌کند. سرعت decode، TPOT و زمان کل تولید را هدایت می‌کند. طول خروجی مهم است؛ نرخ سریع توکن هم اگر سامانه ۳۰۰۰ توکن غیرضروری بسازد، کار را کند نگه می‌دارد.

صف و batching

سرور درخواست‌ها را برای استفاده بهتر از شتاب‌دهنده batch می‌کند. batching بزرگ‌تر ممکن است throughput کل را بالا ببرد، اما انتظار هر درخواست یا tail latency در ورودی‌های با طول متفاوت را بدتر کند. throughput با responsiveness یکسان نیست.

زمان ابزار و گردش‌کار

در عامل، پایگاه، مرورگر، جست‌وجو، اجرای کد یا انتظار تأیید ممکن است از مدل طولانی‌تر باشد. هر وابستگی، retry و مرز انسانی را جدا بسنجید. کل trace را «تأخیر LLM» نام نگذارید.

SLO را بر اساس کار، ریسک و صدک تعریف کنید

TTFT خوب جهانی وجود ندارد. هدف را با نوع کار تنظیم کنید:

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

از p50 برای تجربه معمول و p90، p95 و p99 برای مسیر کند استفاده کنید. منطقه، دستگاه، شبکه، سازمان، مدل، طول ورودی و خروجی، وضعیت cache، concurrency، زبان، ابزار و کلاس درخواست را جدا کنید.

آستانه benchmark را مستقیماً SLO محصول نکنید. محدودیت MLPerf مقایسه سخت‌افزار را زیر workload مشخص ممکن می‌کند؛ کاربر، پرامپت، هدف کیفیت، مسیر ارائه‌دهنده و زنجیره کامل شما متفاوت‌اند.

هر SLO زمانی باید کف کیفیت و ایمنی داشته باشد. مسیریابی‌ای که p95 را بهتر می‌کند اما hallucination را بالا می‌برد regression است.

بودجه میلی‌ثانیه بسازید

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

اعداد توصیه جهانی نیستند؛ هدف، پاسخ‌گویی مالک است. اگر بازیابی ۱٫۴ ثانیه طول می‌کشد، افزایش سرعت مدل از ۴۰ به ۵۰ توکن بر ثانیه شاید تأثیر کمی بر زمان تا ارزش داشته باشد.

برای مسیر گرم و سرد، cache hit و miss، درخواست دارای ابزار و بدون ابزار و کار foreground و background بودجه جدا نگه دارید.

به ترتیبی بهینه کنید که کاربر حس می‌کند

۱. فوری واکنش نشان دهید

مرورگر باید پیش از پایان شبکه تغییر قابل مشاهده بدهد. راهنمای Core Web Vitals درباره Interaction to Next Paint توضیح می‌دهد تأخیر بازخورد چگونه رابط را بی‌پاسخ نشان می‌دهد. این تأخیر مدل نیست، اما کاربر کل محصول را تجربه می‌کند.

ارسال تکراری را ببندید، دامنه فعال را نشان دهید و امکان لغو یا انتقال امن به پس‌زمینه بدهید. spinner مبهم برای عامل بلندمدت کافی نیست؛ مرحله‌هایی مانند «در حال بررسی منابع» یا «منتظر تأیید» را نمایش دهید.

۲. کار غیرضروری را حذف کنید

بازیابی تکراری، بارگذاری چندباره سیاست، فراخوانی زائد مدل، تاریخچه بیش‌ازحد و خروجی طولانی‌تر از نیاز را حذف کنید. ارزان‌ترین میلی‌ثانیه مربوط به کاری است که نباید انجام شود.

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

۳. شاخه مستقل را موازی کنید

بازیابی و lookup مستقل را هم‌زمان اجرا کنید، به شرطی که واقعاً مستقل و داخل محدودیت منابع باشند. اثرهای جانبی دارای ترتیب یا رکورد مشترک را موازی نکنید.

deadline و cancellation داشته باشید. اگر منبع اختیاری از بودجه گذشت، شاید بتوان با نتیجه جزئی و برچسب روشن ادامه داد؛ غیبت منبع مرجع ضروری باید باعث خودداری یا ارجاع شود.

۴. بر اساس کار مسیریابی کنید

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

راهنمای مسیریابی مدل میان هزینه، تأخیر و کیفیت چارچوب تصمیم را ارائه می‌کند.

۵. prefix و نتیجه پایدار را با احتیاط cache کنید

کامپایل تغییرناپذیر سیاست، schema، embedding، نتیجه بازیابی با قاعده تازگی و prefix مشترک مجاز را cache کنید. کلید باید سازمان، مجوز، زبان، نسخه سیاست، مدل و نسخه داده را شامل شود. برای سرعت، نشت بین کاربر یا اختیار کهنه نسازید.

نرخ hit، زمان ذخیره‌شده، stale hit و تأخیر invalidation را بسنجید. نرخ hit بالا اگر سیاست قدیمی تحویل دهد موفقیت نیست.

۶. واحد معنادار stream کنید

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

اندازه chunk بر روانی اثر دارد. chunk بسیار کوچک overhead و jitter می‌سازد؛ بسیار بزرگ پیشرفت را دیر نشان می‌دهد. paint مرورگر و خوانایی را اندازه بگیرید، نه فقط event ارائه‌دهنده را.

لایه سرو را بدون پنهان‌کردن بده‌بستان بهینه کنید

Continuous batching و مدیریت KV cache

مقاله vLLM و PagedAttention اتلاف حافظه KV cache را هدف می‌گیرد و در workloadهای آزموده‌شده throughput بالاتر با سطح مشابه latency گزارش می‌کند. موتورهای جدید نیز continuous batching و scheduler برای پذیرش کار دارند.

اما برد throughput در یک benchmark تضمین کاهش p99 workload ترکیبی شما نیست. طول واقعی پرامپت، طول تولید، concurrency، معماری مدل و سخت‌افزار را آزمایش کنید.

Speculative decoding

Speculative sampling از مدل draft سریع برای پیشنهاد چند توکن استفاده می‌کند و مدل هدف آن‌ها را موازی بررسی می‌کند؛ در پیاده‌سازی درست توزیع هدف حفظ می‌شود. سود به هزینه draft و نرخ پذیرش وابسته است. تحلیل تأخیر ۲۰۲۶ گزارش می‌کند با افزایش بار و تغییر batch مؤثر، speedup ممکن است کم شود.

با نرخ ورود واقعی benchmark کنید. بهینه‌سازی برنده تک‌درخواست شاید در اشباع سرور بازنده باشد.

Quantization و مدل کوچک

دقت عددی کمتر می‌تواند حافظه را کاهش و سرعت را بالا ببرد، اما شاید دقت، قابلیت استفاده ابزار، کیفیت فارسی و calibration را عوض کند. خروجی را روی مجموعه ارزیابی با مرجع precision بالاتر مقایسه کنید، نه فقط tokens/s.

Prefix caching

استفاده دوباره از حالت prefill برای prefix مشترک، کار تکراری را کم می‌کند. کلید باید هر جزء تغییر‌دهنده معنا یا مجوز را دربرگیرد. cache مدیریت‌شده ارائه‌دهنده پیامد نگهداری و حاکمیت داده دارد؛ قواعد جاری را بررسی کنید.

Autoscaling و admission control

پیش از غالب‌شدن صف scale کنید، اما زمان بارگذاری و warm-up مدل را لحاظ کنید. ترافیک تعاملی فوری را از گزارش بلند پس‌زمینه جدا کنید. زیر overload صریح reject یا degrade کنید، نه اینکه کار را در صف بی‌نهایت بپذیرید.

تأخیر ابزار طراحی قابلیت اتکای جدا می‌خواهد

برای هر ابزار:

• deadline اتصال، پاسخ و کل تعریف کنید.
• cancellation را propagate کنید.
• خطا را retryable، غیرقابل retry یا commit نامعلوم طبقه‌بندی کنید.
• backoff نمایی با jitter و بودجه محدود retry داشته باشید.
• برای اثر جانبی idempotency key به کار ببرید.
• پیش از تکرار commit مبهم، وضعیت کسب‌وکار را بررسی کنید.
• برای وابستگی خراب circuit breaker بگذارید.
• در صورت امکان نتیجه جزئی، صف یا fallback انسانی ارائه دهید.
• ارائه‌دهنده و منطقه را بدون ثبت راز نگه دارید.

hedged request می‌تواند tail خواندن یکتا را با ارسال درخواست دوم پس از تأخیر کم کند، اما بار را بالا می‌برد و ممکن است congestion را بدتر کند. پرداخت یا پیام غیر idempotent را hedge نکنید.

راهنمای گردش‌کار پایدار عامل checkpoint و اثر دقیقاً یک‌بار در سطح کسب‌وکار را توضیح می‌دهد.

زیر بار واقعی تست کنید، نه لپ‌تاپ خلوت

توزیع workload را از تولید یا نمونه حریم‌خصوصی‌محور بسازید:

• پرامپت کوتاه، میانه و بلند.
• خروجی کوتاه و بلند.
• متن انگلیسی، فارسی و ترکیبی.
• cache hit و miss.
• مسیر بدون بازیابی، با بازیابی و چندابزاری.
• instance گرم و سرد.
• کاربر منطقه‌ای و شبکه ضعیف.
• burst، concurrency پایدار و job پس‌زمینه.
• throttling، timeout و شکست stream ارائه‌دهنده.

اگر ورود مستقل کاربر را مدل می‌کنید، load generator باز به کار ببرید؛ کلاینت بسته که تا پایان هر پاسخ صبر می‌کند ممکن است فروپاشی صف را پنهان کند، زیرا با کندشدن سرور ترافیک کمتری می‌فرستد.

برای هر سناریو histogram تأخیر، throughput، عمق صف، استفاده شتاب‌دهنده، حافظه، طول توکن، خطا، retry، cancellation، کیفیت و هزینه را ثبت کنید. هنگام مقایسه تنظیم سرو، کیفیت را ثابت نگه دارید.

شکل‌های رایج تأخیر را تشخیص دهید

• TTFT بالا، TPOT عادی: زمینه بلند، بازیابی کند، صف، شروع سرد یا prefill.
• TTFT عادی، TPOT بالا: bottleneck decode، سخت‌افزار محدود، خروجی بلند یا پذیرش ضعیف speculative.
• p50 خوب، p99 بد: contention، batch با طول ترکیبی، مسیر سرد، tail ابزار، عدم توازن منطقه یا طوفان retry.
• trace ارائه‌دهنده سریع، مرورگر کند: buffering، proxy، chunk بزرگ، کار main thread یا رندر.
• مدل سریع، گردش‌کار کند: ابزار ترتیبی، loop غیرضروری، انتظار تأیید یا نبود parallelism.
• بدترشدن latency با throughput: اشباع صف، فشار حافظه، admission ضعیف یا scheduler طرفدار throughput کل.
• cache hit بدون speedup: overhead lookup، سهم کم prefix قابل استفاده، bottleneck شبکه یا مرز اندازه‌گیری اشتباه.

پیش از بهینه‌سازی علت را پیدا کنید. decoder سریع‌تر، document store کند را درست نمی‌کند.

پرسش‌های رایج

آیا TTFT مهم‌ترین معیار تأخیر هوش مصنوعی است؟

برای تولید تعاملی مهم است، اما کافی نیست. TTFT پایین می‌تواند با توکن کند، توقف ابزار، رندر ضعیف یا اقدام تأییدنشده همراه باشد. معیار نزدیک به ارزش را انتخاب کنید: نخستین نتیجه مفید، زمان تا تصمیم یا اثر تأییدشده.

آیا streaming سامانه را سریع‌تر می‌کند؟

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

آیا باید p99 را بهینه کنیم؟

برای مسیر مهم تعاملی و تراکنشی بله، اما جمعیت پشت آن را بررسی کنید. چند صدک و چند segment گزارش کنید؛ یک tail شاید کلاس‌های متفاوتی را مخلوط کرده باشد که مسیر و SLO جدا می‌خواهند.

چه زمانی مدل کوچک‌تر انتخاب کنیم؟

وقتی ارزیابی کنترل‌شده نشان دهد همان آستانه کیفیت و ایمنی کار را با سود معنادار latency یا هزینه می‌گذراند. اندازه مدل به‌تنهایی سیاست routing نیست.

منابع و تاریخ بازبینی

این مقاله در ۸ مرداد ۱۴۰۵ (۳۰ ژوئیه ۲۰۲۶) با منابع زیر به‌طور اساسی بازبینی شد:

• MLCommons: معیارهای LLM در MLPerf Inference v5
• مستند MLPerf Inference
• قرارداد معنایی معیار GenAI در OpenTelemetry
• Google Cloud: معیار استنتاج AI/ML
• vLLM و PagedAttention
• شتاب تولید مدل با speculative sampling
• مدل تفسیری تأخیر speculative decoding
• web.dev: Interaction to Next Paint

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