سیستم‌های هوش مصنوعی و ایجنت‌ها

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

مدل در برابر سیستم#

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

چرا محاسبات LLM با نرم‌افزار معمولی فرق دارد#

محاسبات ناهمگن و دو فاز متفاوت#

در یک سرور LLM، CPU و GPU کارهای متفاوتی دارند. CPU توکن‌سازی، اجرای kernelها، جابه‌جایی داده و فراخوانی ابزارها را انجام می‌دهد و GPU ضرب ماتریس را. حتی روی GPU هم دو فاز با رفتار کاملاً متفاوت داریم:

• prefill، یعنی پردازش کل پرامپت در یک گذر، محدود به محاسبه (compute-bound) است.
• decode، یعنی تولید توکن‌به‌توکن پاسخ، محدود به پهنای باند حافظه (memory-bound) است.

زمان اجرای هر درخواست به طول خروجی بستگی دارد و این طول از قبل معلوم نیست. همین زمان‌بندی را سخت می‌کند. جلسه‌های ۱۰ و ۱۱ این دو فاز را با عدد بررسی می‌کنند.

ناهمگنی به همین‌جا ختم نمی‌شود. در یک خوشه‌ی واقعی معمولاً چند نسل GPU کنار هم کار می‌کنند و گاهی شتاب‌دهنده‌های دیگر (xPU) هم هستند. هر استقرار ممکن است به یکی از سه سقف برسد: محاسبه، پهنای باند یا ظرفیت حافظه.

محاسبات غیرقطعی#

جمع اعشاری شرکت‌پذیر نیست. اگر ترتیب جمع عوض شود، نتیجه می‌تواند کمی فرق کند:

>>> (0.1 + 0.2) + 0.3
0.6000000000000001
>>> 0.1 + (0.2 + 0.3)
0.6

در یک GPU ترتیب جمع از سه جا عوض می‌شود:

• زمان‌بندی در زمان اجرا: زمان‌بندی warpها و blockها، ترتیب دسترسی به حافظه، streamهای ناهمگام و اندازه‌ی batch
• انتخاب‌های نرم‌افزاری: یک دستور FMA (ضرب و جمع با هم) یا دو دستور جدا، انتخاب خودکار kernel (autotuning) و رفتار با اعداد خیلی کوچک (subnormal)
• سخت‌افزار: هسته‌ی CUDA معمولی یا Tensor Core، و قالب عددی؛ مثلاً FP8 در Hopper در برابر کاشی‌های micro-scaling در Blackwell

یک تفاوت در رقم هفتم اعشار در یک ضرب ماتریس می‌تواند احتمال دو توکن را جابه‌جا کند و از آنجا کل ادامه‌ی پاسخ عوض شود؛ نوعی «اثر پروانه‌ای». پس حتی با temperature صفر هم خروجی کاملاً قطعی تضمین نمی‌شود.

دو خاصیت دیگر هم در اعداد اعشاری برقرار نیستند:

• توزیع‌پذیری: a * (b + c) لزوماً با a * b + a * c برابر نیست، هرچند در عمل کمتر به آن تکیه می‌شود.
• تعدی: از a == b و b == c نمی‌شود نتیجه گرفت a == c، وقتی تساوی با یک حد خطا سنجیده شود.

نکته‌ی مقابل هم مهم است: برای LLM محاسبه‌ی تقریبی قابل قبول است. هدف این نیست که هر بیت یکسان باشد؛ هدف این است که کیفیت پاسخ حفظ شود. همین اجازه می‌دهد از دقت‌های پایین‌تر و kernelهای سریع‌تر استفاده کنیم (جلسه‌ی ۱۱).

حافظه و ارتباط#

• وزن‌های مدل از چند گیگابایت تا چند ترابایت حجم دارند.
• KV cache، یعنی حالتی که مدل برای هر توکن قبلی نگه می‌دارد، برای هر توکن ده‌ها تا صدها کیلوبایت جا می‌گیرد.
• prefix cache همین KV را بین درخواست‌هایی که شروع یکسان دارند به اشتراک می‌گذارد.

در اغلب موارد گلوگاه خودِ محاسبه نیست، جابه‌جایی داده است. وقتی مدل روی چند GPU تقسیم شود، ارتباط بین GPUها هم به گلوگاه اضافه می‌شود:

مدل‌ها و بارهای کاری که مدام عوض می‌شوند#

معماری attention در چند سال از MHA به GQA، MLA، attention پراکنده (مثل NSA) و attention خطی رسیده است (جلسه‌ی ۱۰). بار کاری هم عوض شده است:

• چت چندنوبتی: تعاملی و حساس به تأخیر
• مدل‌های استدلالی با خروجی خیلی طولانی
• RAG: بازیابی سند پیش از جواب، با کانتکست طولانی
• ایجنت‌ها که به prefix caching، مسیریابی و توزیع بار نیاز دارند

نتیجه یک چرخه است: مدل‌ها برای سخت‌افزار تطبیق داده می‌شوند و سخت‌افزار برای مدل‌ها طراحی می‌شود.

قابلیت اطمینان و توان#

اگر نرخ خرابی سالانه‌ی هر GPU حدود ۹٪ باشد (میانگین زمان بین خرابی حدود ۵۰ هزار ساعت)، در خوشه‌ای با ۱۶ هزار GPU تقریباً هر سه ساعت یک GPU خراب می‌شود. توان هم مسئله است:

مصرف GPU هم ثابت نیست و با فاز کار بالا و پایین می‌رود. این نوسان در مقیاس یک دیتاسنتر باید مدیریت شود.

ایجنت چیست؟#

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

برنامه‌ریزی ─◄ عمل (فراخوانی ابزار) ─◄ مشاهده‌ی نتیجه ─◄ تطبیق ─◄ ... ─◄ تحویل

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

ایجنت، دستیار، ربات#

سه واژه که اغلب جای هم به کار می‌روند (طبقه‌بندی Google Cloud، از اسلایدهای اختیاری جلسه):

ایجنت مثل یک کامپیوتر جدید#

یک تشبیه مفید برای کل مجموعه:

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

چرا ایجنت یک مسئله‌ی سیستمی است#

سرویس‌دهی سنتی ساده است: درخواست، استنتاج، پاسخ. سرویس‌دهی ایجنت یک زنجیره است:

استنتاج ─◄ ابزار ─◄ بازیابی ─◄ استنتاج ─◄ ابزار ─◄ ... ─◄ پاسخ

مسیر بحرانی این زنجیره از GPU، CPU، دیسک، شبکه و سرویس‌های بیرونی می‌گذرد. شش چالشی که اسلاید برای این زنجیره نام می‌برد:

• وابستگی بین قدم‌ها
• تأخیر بسیار متغیر هر قدم
• مسدود شدن و انتظار برای ابزارها
• حالتی که سریع بزرگ می‌شود
• هم‌روندی و اجرای پیش‌دستانه
• خرابی در هر نقطه از مسیر

هر ویژگی ایجنت یک مسئله‌ی سیستمی تازه می‌سازد:

پشته‌ی سیستم ایجنتی#

کاربر و برنامه
هارنس ایجنت      → برنامه‌ریزی، کانتکست، حافظه، ابزار، زیرایجنت
مدل
سیستم سرویس‌دهی  → batching، زمان‌بندی، مسیریابی، کش
runtime و kernel  → CUDA، Triton، ارتباطات جمعی
سخت‌افزار         → GPU، CPU، حافظه، شبکه، دیسک
محیط بیرونی       → وب، فایل‌ها، APIها، انسان‌ها

بهترین بهینه‌سازی‌ها اغلب از طراحی هم‌زمان چند لایه می‌آیند، مثلاً هارنسی که می‌داند سرور چه چیزی را کش کرده است.

چه چیزی را بهینه کنیم؟#

برای ایجنت، throughput هدف اشتباهی است. معیارهایی مثل زمان رسیدن اولین توکن (TTFT)، زمان هر توکن خروجی (TPOT)، تأخیر ابزار و بهره‌وری GPU مفیدند اما کافی نیستند. هدف واقعی این است:

بیشینه کردن موفقیت کار، با قید تأخیر، هزینه، منابع، قابلیت اطمینان و امنیت.

معیارهای بهتر:

• نرخ موفقیت کار
• تأخیر سرتاسری (از درخواست تا نتیجه‌ی قابل استفاده)
• توکن به ازای هر کار
• دلار به ازای هر کار موفق
• انرژی به ازای هر کار موفق

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

مشاهده‌پذیری: بدون دیدن، بهینه‌سازی ممکن نیست#

ردِ اجرای یک ایجنت درختی تودرتو است:

نشست (session)
┘── نوبت کاربر (turn)
    ┘── قدم ایجنت (step)
        ┤── درخواست به مدل
        ┤── فراخوانی ابزار ─◄ نتیجه‌ی ابزار
        ┘── زیرایجنت ─◄ (همین ساختار، بازگشتی)

قبل از هر بهینه‌سازی باید بتوانید این درخت را ببینید: هر قدم چند توکن خورده، چقدر طول کشیده و کدام ابزار کند بوده است.

سطوح کدنویسی ایجنتی#

یک مقیاس ساده برای اینکه خودتان کجا هستید:

هدف جلسه‌های ۲ و ۳ این است که با اطمینان به سطح ۴ و ۵ برسید.

پرسش‌هایی که در طول این مجموعه جواب می‌دهیم#

1. چرا batching توان عملیاتی را بالا می‌برد ولی می‌تواند تأخیر ایجنت را بدتر کند؟
2. ایجنت کی باید از مدل بزرگ‌تر استفاده کند؟
3. KV cache و prefix cache کجا نگه داشته شوند؟
4. درخواست‌های یک ایجنت چطور زمان‌بندی شوند؟
5. آیا فراخوانی ابزار می‌تواند با استنتاج هم‌پوشانی داشته باشد؟
6. ایجنت کی باید زیرایجنت بسازد؟
7. بین GPUها و مدل‌های ناهمگن چطور مسیریابی کنیم؟
8. ایجنتی را که ۳۰ دقیقه کار کرده و خراب شده چطور بازیابی کنیم؟
9. چطور «دلار به ازای کار موفق» را بهینه کنیم و نه «توکن بر ثانیه» را؟

خارج از محدوده‌ی این مجموعه#

آموزش مدل (خط لوله‌ی داده، checkpoint، پیش‌آموزش، fine-tuning، post-training و rollout در RL)، مدیریت خوشه، طراحی معماری مدل، و از موضوع‌های استنتاج: ارتباطات، توان و انرژی، و طراحی سخت‌افزار جدید. تمرکز مجموعه روی استنتاج و ایجنت است؛ به گفته‌ی اسلاید، چون امروز استنتاج بیشترِ تقاضای محاسباتی را تشکیل می‌دهد.

پرسش‌هایی برای فکر کردن#

• آخرین باری که از یک ایجنت کدنویس استفاده کردید، به نظرتان چند فراخوانی مدل پشت یک درخواست شما بود؟ (جلسه‌ی بعد جواب را می‌بینید.)
• در تشبیه «ایجنت به‌عنوان کامپیوتر»، compaction کانتکست معادل کدام مفهوم سیستم‌عامل است؟

منابع#

• اسلاید جلسه: Course overview (1_intro.pdf)
• سایت درس CS2680
• Andrej Karpathy، Software is changing (again)، برای توصیف «فوق‌انسانی و ناتوان هم‌زمان»
• Meta، The Llama 3 Herd of Models، برای آمار خرابی در خوشه‌های بزرگ GPU