اگر امروز برای اجرای مدل‌های هوش مصنوعی در مقیاس سازمانی هزینه می‌کنید، احتمالاً متوجه شده‌اید که کمبود GPU مشکل اصلی نیست، بلکه نبود دید عملیاتی (Operational Visibility) است. طبق تحلیل دقیقی که در ۱۹ اوت ۲۰۲۶ توسط dev.to منتشر شد، مدل‌های عملیاتی که برای اپلیکیشن‌های سازمانی سنتی استفاده می‌شدند، برای هوش مصنوعی در مقیاس بالا ناکافی هستند. مشکل بنیادین این است که اکنون در یک محیط واحد، استنتاج آنی (Real-time Inference)، پردازش‌های دسته‌ای (Batch Jobs) و عامل‌های هوش مصنوعی (AI Agents) با یکدیگر ترکیب شده‌اند و همگی برای دسترسی به شتاب‌دهنده‌های گران‌قیمت رقابت می‌کنند. اولین چالش زیرساختی معمولاً پس از موفقیت نسخه آزمایشی (PoC) ظاهر می‌شود؛ در حالی که یک اثبات مفهوم می‌تواند تخصیص دستی منابع، محاسبات گران‌قیمت و نظارت‌های نامنظم را تحمل کند، محیط عملیاتی (Production) چنین انعطاف‌پذیری ندارد. این دشواری در انتقال از محیط آزمایشی به عملیاتی اغلب با موانع سازمانی گره خورده است، همان‌طور که برخی تأییدات اداری می‌توانند به سد اصلی در مسیر تبدیل مدل‌ها به محصول تبدیل شوند.
وقتی سرویس‌های مشتری‌محور، کوپایلوت‌های داخلی، پردازش اسناد، حجم‌های کاری تحلیلی و عامل‌های هوش مصنوعی شروع به اشتراک‌گذاری زیرساخت می‌کنند، رهبران فناوری باید الزامات متضاد برای ظرفیت، تأخیر (Latency)، قابلیت اطمینان، امنیت و هزینه را مدیریت کنند. دیگر سؤال این نیست که آیا محیط دارای سرور، نمونه‌های ابری یا GPU کافی است یا خیر. سؤال این است که آیا زیرساخت می‌تواند به حجم کاری درست، در سطح عملکرد مناسب، با دید کافی برای درک هزینه‌ها و حاکمیت کافی برای کنترل نحوه عملیات اختصاص یابد؟
برنامه‌ریزی سنتی زیرساخت بر روابط پایدار میان تقاضا و مصرف منابع متکی بود. برای مثال، یک سیستم ERP ممکن است پیک‌های فصلی داشته باشد؛ یک پلتفرم تجارت الکترونیک در طول جشنواره‌ها به ظرفیت اضافی نیاز داشته باشد؛ یا یک پورتال مشتری ترافیک روزانه قابل پیش‌بینی داشته باشد. اما حجم‌های کاری هوش مصنوعی این الگو را می‌شکنند. یک محیط هوش مصنوعی سازمانی اکنون ممکن است شامل موارد زیر باشد:
- سرویس‌های استنتاج آنی (Real-time inference services)
- پردازش‌های استنتاج دسته‌ای (Batch inference jobs)
- آموزش مدل و تنظیم دقیق (Model training and fine-tuning) — شبیه وقتی که به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود
- حجم‌های کاری تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد
- تولید بردار معنایی (Embedding generation) — مثل کارت معرفی عددی برای هر واژه که همسایگی آن با کلمات دیگر را مشخص می‌کند
- جست‌وجوی برداری (Vector search)
- خط لوله‌های آماده‌سازی داده (Data preparation pipelines)
- عامل‌های هوش مصنوعی (AI agents) که چندین اپلیکیشن و API را فراخوانی می‌کنند
به نقل از گزارش dev.to، یک بانک ممکن است مدلی برای تشخیص کلاهبرداری آنی اجرا کند که در آن هر میلی‌ثانیه تأخیر اضافی بر یک فرآیند تجاری عملیاتی تأثیر می‌گذارد، در حالی که هم‌زمان یک شغل طبقه‌بندی اسناد را روی میلیون‌ها رکورد آرشیوی اجرا می‌کند که می‌تواند بدون هیچ تأثیر تجاری، به جای ساعت ۲ بعدازظهر در ساعت ۲ بامداد انجام شود. تخصیص هر دو حجم کاری بر اساس مفروضات یکسان سطح سرویس (SLAs)، باعث اتلاف شدید سرمایه می‌شود.
طبق این گزارش، برخورد با این موارد به عنوان یک دسته‌بندی واحد زیرساختی منجر به اتلاف گسترده می‌شود. رهبران زیرساخت اکنون باید حجم‌های کاری را بر اساس معیارهای خاصی طبقه‌بندی کنند و سپس سرویس ابری یا خانواده GPU را انتخاب نمایند. این معیارهای طبقه‌بندی عبارتند از:
- حیاتی بودن برای کسب‌وکار (Business criticality)
- تحمل تأخیر (Latency tolerance)
- الزامات در دسترس بودن (Availability requirements)
- شدت محاسبات (Compute intensity)
- وابستگی به شتاب‌دهنده (Accelerator dependency)
- حجم داده‌ها (Data volume)
- مدت زمان پردازش (Processing duration)
- رفتار هم‌زمانی و مقیاس‌پذیری (Concurrency and scaling behavior)
- الزامات امنیتی و رگولاتوری (Security and regulatory requirements)
شروع تصمیم‌گیری با انتخاب GPU مورد نظر، پیکربندی کوبرنتیز (Kubernetes) یا پلتفرم مدل، به‌جای تحلیل ویژگی‌های حجم کاری، توالی تصمیمات لازم را به‌طور اشتباه معکوس می‌کند.
چرخش به سمت ارکستراسیون ظرفیت
برنامه‌ریزی ظرفیت در گذشته می‌پرسید «سازمان انتظار دارد به چه مقدار زیرساخت نیاز داشته باشد؟»، اما ارکستراسیون هوش مصنوعی می‌پرسد «وقتی منابع محدود یا گران هستند، کدام حجم کاری باید ظرفیت را دریافت کند؟». این تمایز حیاتی است زیرا ظرفیت شتاب‌دهنده معادل محاسبات سنتی نیست. یک اپلیکیشن متکی به GPU ممکن است به خانواده‌های خاصی از شتاب‌دهنده‌ها، ویژگی‌های حافظه خاص، در دسترس بودن منطقه‌ای یا پنجره‌های تخصیص خاص نیاز داشته باشد.
از آنجایی که در دسترس نگه داشتن دائمی ظرفیت اغلب از نظر اقتصادی توجیه‌پذیر نیست، سازمان‌ها به سمت مدل ظرفیت ترکیبی حرکت می‌کنند. برخی حجم‌های کاری به منابع اختصاصی یا رزرو شده نیاز دارند. برخی دیگر می‌توانند از ظرفیت‌های Burst (انفجاری) استفاده کنند. پردازش‌های دسته‌ای ممکن است صف‌ها را تحمل کنند و حجم‌های کاری توسعه ممکن است Preemptible (قابل توقف) باشند. آزمایش‌های با اولویت پایین ممکن است به محدودیت‌های سخت‌گیرانه هزینه نیاز داشته باشند. گزارش مذکور یک مدل سه‌لایه را پیشنهاد می‌دهد:
- لایه ۱ (حیاتی برای کسب‌وکار): استنتاج‌های مشتری‌محور یا حساس به تراکنش با ظرفیت قابل پیش‌بینی، زیرساخت با تأخیر کم، افزونگی (Redundancy) قوی‌تر و اهداف سطح سرویس (SLO) سخت‌گیرانه.
- لایه ۲ (عملیاتی داخلی): کوپایلوت‌ها و اپلیکیشن‌های دانش داخلی که می‌توانند تأخیر متوسط یا صف‌های کوتاه را بدون تأثیر مادی بر عملیات تجاری بپذیرند.
- لایه ۳ (دسته‌ای/آزمایشی): کارهای آموزشی، اجراهای ارزیابی، پردازش‌های حجیم و استنتاج‌های غیرفوری که بر اساس در دسترس بودن منابع و هزینه زمان‌بندی می‌شوند.
مقیاس‌دهی خودکار (Autoscaling) نمی‌تواند این مشکل را حل کند. زمان‌های تخصیص (Provisioning)، کوتاهای ابری، در دسترس بودن شتاب‌دهنده‌ها، مقداردهی اولیه مدل (Model Initialization)، محلی بودن داده‌ها و الزامات تأخیر اپلیکیشن، اغلب مانع از آن می‌شوند که زیرساخت با سرعت کافی برای پاسخ به تقاضای آنی گسترش یابد. راهکار، ارکستراسیون آگاه از اولویت‌های تجاری است که بپرسد: «اگر این حجم کاری پنج دقیقه منتظر بماند چه اتفاقی می‌افتد؟ اگر پنج ساعت منتظر بماند چه می‌شود؟ هزینه نگهداری ظرفیت بیکار چقدر است؟ هزینه تجاری نبود ظرفیت کافی چیست؟ در زمان رقابت بر سر منابع، کدام حجم کاری باید اول ظرفیت خود را از دست بدهد؟»
این سؤالات به‌طور فزاینده‌ای به حوزه «سرویس‌های مدیریت زیرساخت» (Infrastructure Managed Services) تعلق دارند، زیرا عملیات اکنون به اولویت‌بندی مستمر حجم‌های کاری نیاز دارد، نه صرفاً به بهینه‌سازی دوره‌ای اندازه منابع (Right-sizing).
اتصال مشاهده‌پذیری به نتایج
پشته‌های مشاهده‌پذیری (Observability) استاندارد، بهره‌وری CPU، اتمام حافظه و نرخ خطاها را ردیابی می‌کنند. با این حال، هوش مصنوعی لایه‌های جدیدی بین زیرساخت و عملکرد تجاری ایجاد می‌کند. یک کاربر ممکن است پاسخ کندی را تجربه کند، حتی اگر سرور اپلیکیشن زیرین سالم به نظر برسد. این لگ (Lag) می‌تواند ناشی از چندین نقطه شکست خاص باشد:
- اشباع GPU یا تأخیر در بارگذاری مدل
- تراکم صف‌ها (Queue backlogs)
- تأخیر در بازیابی (Retrieval latency) یا عملکرد پایگاه‌داده برداری
- سرعت انتقال شبکه و سرعت تولید توکن (Token generation speed)
- وابستگی به APIهای مدل خارجی یا تأخیر در خط لوله داده‌ها
تله‌متری زیرساخت به‌تنهایی نمی‌تواند این مشکلات را توضیح دهد. برای حل این مسئله، گزارش پیشنهاد می‌کند از کنوانسیون‌های معنایی GenAI در OpenTelemetry استفاده شود. این روش یک راه استاندارد برای ثبت هویت مدل، تعداد توکن‌های ورودی و خروجی، فراخوانی ابزارها (Tool calls) و مدت زمان عملیات LLM در سراسر Traceها و Metricها فراهم می‌کند. بدون این دید لایه‌ای، یک تیم ممکن است ساعت‌ها وقت خود را صرف دیباگ کردن مدل کند، در حالی که مشکل واقعی سرویس بازیابی برداری است که پس از رشد قابل توجه ایندکس خود، دچار تأخیر بالا شده است. در واقع، بسیاری از این ناکارآمدی‌ها ریشه در زیرساخت‌های قدیمی دارند، چرا که معماری‌های سنتی می‌توانند عامل اصلی پیش‌بینی‌های نادرست و خطاهای عملیاتی هوش مصنوعی باشند.
رهبران زیرساخت باید انتظار داشته باشند که نظارت به این سؤال پاسخ دهد: «کدام حجم کاری AI، کدام منابع را، با چه هزینه‌ای و در حالی که چه سطحی از سرویس را ارائه می‌دهد، مصرف می‌کند؟». معیارهای عملیاتی کلیدی اکنون شامل موارد زیر است:
- بهره‌وری حافظه GPU و شتاب‌دهنده‌ها
- مدت زمان صف و توان عملیاتی استنتاج (Inference throughput)
- تأخیر پاسخ مدل و تأخیر بازیابی
- میزان مصرف توکن
- نرخ شکست و تلاش مجدد (Retry rates)
- هزینه زیرساخت در سطح هر حجم کاری
- بهره‌وری ظرفیت به تفکیک مدل یا اپلیکیشن
این امر مستلزم شکستن سیلوهای سازمانی است. اگر تیم پلتفرم فقط معیارهای زیرساخت را ببیند، تیم AI معیارهای مدل را ببیند، تیم داده عملکرد بازیابی را ببیند و FinOps هزینه را فقط در سطح حساب کاربری ببیند، هیچ‌کس تصویر کامل عملیاتی را نخواهد داشت. مدیریت زیرساخت AI نیازمند تله‌متری مشترک است، نه فقط داشبوردهای بیشتر.
اقتصاد جدید هوش مصنوعی (FinOps)
مدیریت هزینه ابری در حال تبدیل شدن به «اقتصاد توکن» است. بنیاد FinOps این موضوع را به عنوان دیسیپلین اندازه‌گیری و انتساب مصرف AI و اتصال آن به نتایج تجاری توصیف می‌کند که اقتصاد واحد (Unit Economics) سنتی را به هزینه متغیر محاسبات هوشمند گسترش می‌دهد. دانستن اینکه یک پلتفرم ماهانه ۱۸۰,۰۰۰ دلار هزینه دارد، یک واقعیت بودجه‌ای است، اما بهره‌وری را ثابت نمی‌کند.
رهبران فناوری اکنون باید هزینه هر نتیجه مفید را اندازه‌گیری کنند، مانند:
- هزینه به ازای هر استنتاج یا هر سند پردازش‌شده
- هزینه به ازای هر گردش‌کار AI یا هر کاربر فعال
- هزینه به ازای هر مدل یا هر تراکنش مشتری
- هزینه به ازای هر وظیفه موفق عامل (Agent task)
این نگاه، تصمیمات معماری را تغییر می‌دهد. فرض کنید دو مدل نتایج تجاری مشابهی تولید می‌کنند. اگر مدل A کمی دقیق‌تر باشد اما به ظرفیت شتاب‌دهنده به‌طور قابل توجهی بیشتری نیاز داشته باشد و هزینه هر تراکنش را نسبت به مدل B افزایش دهد، انتخاب دیگر صرفاً درباره عملکرد مدل نیست، بلکه یک تصمیم اقتصادی زیرساختی است. به همین ترتیب، کاهش زمان پاسخ از سه ثانیه به یک ثانیه ممکن است نیازمند در دسترس نگه داشتن ظرفیت بسیار بیشتری باشد. در حالی که این موضوع برای یک تصمیم کلاهبرداری مشتری‌محور توجیه‌پذیر است، برای یک ابزار خلاصه‌سازی داخلی ممکن است نباشد. هدف، کمترین هزینه زیرساختی است که همچنان نتیجه تجاری مورد نیاز حجم کاری را برآورده کند.
سازمان‌هایی که از سرویس‌های مدیریت زیرساخت استفاده می‌کنند، باید انتظار داشته باشند که مدیریت هزینه فراتر از بهینه‌سازی اندازه ابری (Right-sizing) به انتساب حجم کاری، بهره‌وری شتاب‌دهنده، استراتژی ظرفیت و اقتصاد واحد AI گسترش یابد.
حاکمیت و ریسک‌های مقیاس‌پذیری
تکه تکه شدن (Fragmentation) زمانی رخ می‌دهد که تیم‌های محصول به‌طور مستقل پایگاه‌داده‌های برداری، محیط‌های GPU یا گیت‌وی‌های مدل خود را تخصیص دهند. این امر باعث ایجاد هرج‌ومرج در کنترل‌های دسترسی، سیاست‌های چرخه عمر و مدل‌های هزینه می‌شود. گزارش مذکور نسبت به متمرکز کردن بیش از حد — جایی که هر آزمایش نیاز به تأیید کمیته پلتفرم داشته باشد — هشدار می‌دهد، زیرا این کار باعث ایجاد گلوگاه شده و تیم‌ها را تشویق می‌کند تا راه‌کارهای جایگزین غیررسمی ایجاد کنند.
در عوض، مدل توصیه‌شده، استانداردسازی «حفاظ‌ها» (Guardrails) است. یک تیم پلتفرم مرکزی، الگوهای تخصیص تأییدشده، کنترل‌های هویت، مشاهده‌پذیری، ردیابی هزینه، گیت‌وی‌های مدل و سیاست‌های امنیتی را فراهم می‌کند. سپس تیم‌های AI انتخاب‌های خاص هر حجم کاری را در داخل آن مرزها انجام می‌دهند. حاکمیت AI سازمانی باید به‌طور خاص به موارد زیر گسترش یابد:
- تخصیص زیرساخت و مدیریت هویت/دسترسی (IAM)
- الگوهای استقرار تأییدشده و دسترسی به نقاط انتهایی (Endpoints) مدل
- مرزهای شبکه، استانداردهای لاگ‌گیری و اقامت داده‌ها (Data residency)
- محدودیت‌های منطقه‌ای و مالکیت منابع
- انتساب هزینه و سیاست‌های انقضا/نگهداری محیط
پشته مدیریت زیرساخت AI
برای مقیاس‌پذیری ایمن، گزارش یک پشته مدیریتی ساختاریافته را پیشنهاد می‌کند: حجم کاری $ \rightarrow $ محاسبات $ \rightarrow $ داده $ \rightarrow $ مشاهده‌پذیری $ \rightarrow $ اقتصاد $ \rightarrow $ حاکمیت. هر لایه لایه بعدی را هدایت می‌کند. الزامات تجاری یک حجم کاری، انتخاب‌های محاسباتی را دیکته می‌کند که به نوبه خود بر عملکرد و هزینه تأثیر می‌گذارد. مشاهده‌پذیری نشان می‌دهد سیستم چگونه رفتار می‌کند، دید اقتصادی تعیین می‌کند که آیا معماری همچنان زیست‌پذیر است یا خیر، و حاکمیت تعیین می‌کند که آیا این الگو می‌تواند به‌طور ایمن مقیاس یابد.
رهبران زیرساخت باید چهار تغییر در مدل عملیاتی را پیش از گسترش حجم اجرا کنند:
۱. طبقه‌بندی حجم‌های کاری پیش از انتخاب زیرساخت: مستندسازی حیاتی بودن تجاری، تحمل تأخیر، وابستگی داده، الزامات محاسباتی، رفتار مقیاس‌پذیری، اهداف در دسترس بودن، محدودیت‌های امنیتی و مالکیت هزینه برای جلوگیری از پیش‌فرض‌های پرهزینه.
۲. ساخت قابلیت‌های پلتفرم مشترک: تبدیل الگوهای تکراری به سرویس‌های قابل استفاده مجدد برای تخصیص، مدیریت هویت، شبکه، دسترسی به مدل، لاگ‌گیری، مشاهده‌پذیری، انتساب هزینه، کنترل‌های امنیتی و اجرای سیاست‌ها.
۳. اتصال زودهنگام FinOps به مهندسی AI: اطمینان از وجود دید هزینه در طول توسعه تا تیم‌ها مصرف منابع و اقتصاد واحد مورد انتظار را پیش از مقیاس یافتن حجم‌های کاری ببینند.
۴. ایجاد مالکیت عملیاتی مشترک: ایجاد مسئولیت‌های شفاف در سراسر مهندسی پلتفرم، AI/ML، داده، امنیت، FinOps، مهندسی اپلیکیشن و مالکان کسب‌وکار.
آمادگی زیرساختی اکنون پیش‌نیاز آمادگی در هوش مصنوعی است. پیش از افزودن حجم‌های کاری عملیاتی جدید، رهبران باید هر مورد استفاده را در برابر مجموعه‌ای از سؤالات مشترک ارزیابی کنند:
- این مورد چقدر برای کسب‌وکار حیاتی است و چه نوع حجم کاری است؟
- کسب‌وکار واقعاً به چه میزان تأخیر نیاز دارد؟
- به کدام منابع محاسباتی و شتاب‌دهنده‌های تخصصی نیاز دارد؟
- به کدام سرویس‌های داده متکی است و تقاضا چگونه تغییر خواهد کرد؟
- چه هدف در دسترس بودنی توجیه‌پذیر است؟
- چه کسی مالک هزینه است و آیا می‌توان آن را به ازای هر نتیجه مفید اندازه‌گیری کرد؟
- چه تله‌متری در سراسر مسیر کامل درخواست وجود دارد؟
- کدام کنترل‌های امنیتی و حاکمیتی اعمال می‌شوند؟
سؤال دیگر این نیست که «آیا می‌توانیم این مدل را اجرا کنیم؟»، بلکه این است که «آیا می‌توانیم هزاران تراکنش از این دست را به‌طور قابل‌اعتماد، اقتصادی، امن و مکرر اجرا کنیم بدون اینکه نسل دیگری از پیچیدگی‌های زیرساختی ایجاد کنیم؟»
گام بعدی شما
- حجم‌های کاری فعلی خود را بر اساس سه لایه (حیاتی، عملیاتی، دسته‌ای) طبقه‌بندی کنید.
- معیارهای نظارتی خود را از CPU/RAM به «هزینه به ازای هر نتیجه مفید» و «تأخیر بازیابی» تغییر دهید.
- یک لایه حفاظ (Guardrail) مرکزی برای دسترسی به مدل‌ها و مدیریت هزینه‌ها ایجاد کنید تا از تکه‌تکه شدن زیرساخت جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو