‏زیرساخت ذخیره‌سازی ابری آماده‌ی AI اجنتیک نیست

جنسن هوانگ، مدیرعامل انویدیا، اعلام کرده که وارد عصر «کارخانه‌های AI» شدیم؛ جایی که خروجی اصلی اقتصاد دیجیتال دیگه نرم‌افزار نیست، بلکه «هوش» هست. اما در حالی که همه چشم‌ها به کلاسترهای GPU و مدل‌های تریلیون‌پارامتری دوخته شده، یه بحران بزرگ و خاموش داره در لایه‌های پایین‌تر استک — یعنی ذخیره‌سازی ابری AWS، Azure و Google Cloud — شکل می‌گیره.

اینفرنس مثل OLTP++ رفتار می‌کنه. دو دهه گذشته، سیستم‌های داده رو برای رفتار انسانی تنظیم کردیم؛ انسان‌هایی که کلیک می‌کنن، منتظر می‌مونن، می‌خونن و ۳۰ ثانیه بعد دوباره کلیک می‌کنن. ولی یه AI agent که داره یه حلقه ReAct (Reasoning and Acting) اجرا می‌کنه، در چند میلی‌ثانیه یه کوئری می‌زنه، نتیجه رو می‌خونه، متوجه می‌شه اطلاعات بیشتری لازم داره و سه کوئری موازی دیگه می‌فرسته. حالا این رو ضربدر هزاران agent همزمان روی فلیت EC2 بکن. نتیجه؟ اسپایک‌های غول‌پیکر I/O که هیچ سیستم فعلی برای اون طراحی نشده.

گلوگاه RAG در لایه ذخیره‌سازیه، نه در مدل. وقتی یه اپلیکیشن RAG (Retrieval-Augmented Generation) از محیط Jupyter به پروداکشن AWS می‌ره، تیم‌های مهندسی با یه واقعیت تلخ روبه‌رو می‌شن: bottleneck نه Python هست نه LLM — بلکه نحوه ذخیره، دسترسی و جابه‌جایی داده در لایه زیرین ذخیره‌سازیه. جستجوی برداری با الگوریتم‌هایی مثل HNSW یا IVFFlat همراه با فیلتر metadata رابطه‌ای، عملیات‌های پیچیده و memory-intensive ایجاد می‌کنه که برای اجرای درست نیاز به زیر یه میلی‌ثانیه read روی hot vector داره.

اتکا به read replica در AWS RDS یه استراتژی نیست؛ آخرین چاره‌ست. اگه لایه storage رو آدرس ندی، scale کردن دیتابیس فقط گلوگاه رو جابه‌جا می‌کنه، حل نمی‌کنه.

EBS واقعیت‌هایی داره که نمی‌شه نادیده گرفت. EBS یه ابزار قوی‌ه، ولی با burst bucket و سقف IOPS و throughput کار می‌کنه. وقتی یه موج ناگهانی از ترافیک inference به لایه داده برخورد کنه، این credit‌ها در عرض چند دقیقه تموم می‌شن. بعد از اون، latency از ۱ میلی‌ثانیه به ۵۰ میلی‌ثانیه می‌پره، thread‌های سرور تموم می‌شن و کل استک قفل می‌کنه. صرفاً اضافه کردن IOPS هم راه‌حل نیست؛ یه جایی به سقف فیزیکی هر instance می‌رسی.

راه‌حل: جدا کردن لایه ذخیره‌سازی از محدودیت‌های native ابر. رویکرد پیشنهادی، استفاده از یه software-defined storage abstraction روی زیرساخت AWS هست که اپلیکیشن رو از محدودیت‌های native EBS آزاد می‌کنه. این کار در برابر کمبود ظرفیت EC2، اسپایک قیمت IOPS و قفل شدن به یه نوع instance خاص محافظت می‌کنه.

تنها KPI مهم: tail latency زیر بار مختلط. میانگین latency یه دروغ راحته. کاربران و AI agent‌ها outlier‌ها رو حس می‌کنن. اگه ۱٪ از کوئری‌هات ۳ ثانیه طول بکشه، کل زنجیره استدلال یه agent می‌تونه بلاک بشه. p99 و p999 رو باید به‌عنوان hard release blocker در نظر بگیری و حتماً زیر شرایط واقعی و پر استرس بسنجی، نه روی یه سیستم idle.

نکات کلیدی:

• AI agent‌ها برخلاف انسان‌ها، در میلی‌ثانیه‌ها صدها کوئری موازی می‌زنن و زیرساخت‌های فعلی ابر برای این حجم طراحی نشدن
• گلوگاه اصلی در اپلیکیشن‌های RAG، لایه ذخیره‌سازی و دسترسی به داده‌ست، نه مدل یا زبان برنامه‌نویسی
• EBS در AWS سقف‌های IOPS و burst bucket داره که زیر بار inference می‌تونه باعث افت شدید عملکرد بشه
• اضافه کردن read replica بدون آدرس دادن به لایه storage فقط گلوگاه رو جابه‌جا می‌کنه
• software-defined storage abstraction می‌تونه اپلیکیشن رو از محدودیت‌های native ابر آزاد کنه
• به‌جای میانگین latency، باید p99 و p999 رو زیر بار مختلط و واقعی اندازه بگیری