استقرار محلی در برابر ابری؛ تحلیل هزینه‌های استنتاج مدل‌های زبانی

اگر امروز برای هر توکن تولیدشده توسط مدل‌های ابری هزینه می‌پردازید، باید بدانید که انتقال به زیرساخت شخصی می‌تواند صورت‌حساب‌های ماهانه شما را به صفر برساند. اما این جابه‌جایی، هزینهٔ مالی را به هزینهٔ عملیاتی تبدیل می‌کند. برای درک ابعاد این موضوع، باید به اعداد نگاه کرد؛ برای مثال، یک نمونه از مدل Llama 3.3 70B در حالت FP16 به تقریباً ۱۴۰ گیگابایت VRAM برای اجرا نیاز دارد. این حجم از حافظه، تیم‌ها را مجبور می‌کند تا بین ارکستراسیون سخت‌افزاری گران‌قیمت یا استفاده از پلتفرم‌های مدیریت‌شده یکی را انتخاب کنند. برای تخمین دقیق‌تر این نیازها، بررسی نحوه محاسبه حافظه VRAM برای مدل‌های محلی می‌تواند به شما در انتخاب سخت‌افزار بهینه کمک کند.

طبق راهنمای منتشرشده در ۵ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، عبور از سرویس‌های مدیریت‌شده، وابستگی به قیمت‌گذاری متغیر APIها را حذف کرده و حاکمیت داده‌ها را تقویت می‌کند. این تغییر رویکرد، شبیه به تبدیل یک خانهٔ اجاره‌ای به خانهٔ شخصی است؛ شما دیگر اجاره نمی‌دهی، اما حالا مسئولیت لوله‌کشی و سیم‌کشی ساختمان بر عهده شماست.

همان‌طور که در تحلیل قبلی ما درباره‌ی استفاده از Oxlo.ai برای ساخت دیباگرهای خوداصلاح‌گر با Qwen 3 اشاره کردیم، تمایل به میزبانی شخصی معمولاً از نیاز به کنترل کامل بر وزن‌های باز (Open Weights) — یعنی دسترسی به «دستور پخت» مدل به‌جای دریافت غذای آماده — نشأت می‌گیرد.

سخت‌افزار و انتخاب مدل

استقرار مدل‌های متراکم یا مدل‌های ترکیب خبره‌ها (Mixture of Experts) نیازمند برنامه‌ریزی دقیق توپولوژی است. برای یک نمونه از Llama 3.3 70B، به حداقل دو عدد GPU مدل NVIDIA A100 80GB یا سه عدد A100 40GB با استفاده از موازی‌سازی تنسور (Tensor Parallelism) نیاز است. برای مدل‌های عظیم‌تر مانند DeepSeek R1 671B MoE، تیم‌ها به خوشه‌های GPU چندگره‌ای (Multi-node) با اتصالات پهنای‌باند بسیار بالا مانند InfiniBand یا NVLink نیاز دارند.

بر اساس مستندات فنی، پیش از نصب درایورها، تیم‌ها باید نقشه‌برداری دقیقی از پهنای‌باند PCIe، توپولوژی NUMA و بک‌پلین شبکه انجام دهند. همچنین وزن‌های مدل باید روی حافظه‌های NVMe پرسرعت با دسترسی‌های محدود سیستم‌فایل (Filesystem Permissions) ذخیره شوند تا امنیت و سرعت بارگذاری تضمین شود.

گزینه‌های کلیدی برای محیط عملیاتی عبارت‌اند از:

• استدلال عمومی: Llama 3.3 70B، Qwen 3 32B و GLM 5
• کدنویسی و استدلال عمیق: DeepSeek R1 671B MoE، DeepSeek V4 Flash و Kimi K2.6
• بهینگی و کارایی: DeepSeek V3.2 و Minimax M2.5

پشتهٔ سرویس‌دهی

برای افزایش توان عملیاتی (Throughput)، ابزار vLLM به دلیل مکانیزم PagedAttention که اتلاف حافظه KV-cache را به حداقل می‌رساند، به استاندارد صنعت تبدیل شده است. این ابزار یک مسیر سازگار با OpenAI در قالب /v1/chat/completions فراهم می‌کند تا توسعه‌دهندگان بتوانند بدون بازنویسی کد کلاینت، بک‌اند خود را عوض کنند.

یک اجرای استاندارد Docker برای Llama 3.3 70B روی چهار GPU، از ایمیج vllm/vllm-openai:latest با پیکربندی --tensor-parallel-size 4 و --max-model-len 32768 استفاده می‌کند.

جایگزین‌هایی مثل TGI و TensorRT-LLM تأخیر (Latency) کمتری دارند اما نیازمند نسخه‌های بسیار دقیق (Version Pinning) و کامپایل سفارشی مدل هستند. این موضوع یک ریسک عملیاتی قابل توجه ایجاد می‌کند؛ به‌طوری که یک به‌روزرسانی ساده درایور CUDA در عصر جمعه می‌تواند به‌راحتی سازگاری سیستم را به‌هم زده و منجر به توقف کامل سرویس در سطح سازمان شود.

ارکستراسیون و مقیاس‌پذیری

پس از پایداری نسخه اولیه (Proof-of-Concept)، توصیه می‌شود از Kubernetes به همراه NVIDIA GPU Operator استفاده کنید. این روش اجازه می‌دهد بارهای کاری استنتاج (Inference) از کارهای آموزشی (Training) با استفاده از Node Selectors و محدودیت‌های منابع (Resource Limits) جدا شوند.

جزئیات استقرار شامل موارد زیر است:

• درخواست منابع: در یک مانیفست استاندارد، مقدار nvidia.com/gpu: 4 درخواست می‌شود.
• ذخیره‌سازی: برای اجرای چندین نسخه (Replica)، از PVC با قابلیت ReadWriteMany برای ذخیره وزن‌های مدل استفاده کنید.
• قالب‌بندی: برای مدیریت و استقرار سرور استنتاج از Helm استفاده کنید.

برای جلوگیری از حلقه‌های ری‌استارت (Restart Loops)، پروب‌های Liveness و Readiness باید بسیار سبک باشند. یک بررسی سلامت (Health Check) ناموفق در مدل ۷۰ میلیارد پارامتری می‌تواند منجر به چرخه ری‌استارتی شود که تا ۱۰ دقیقه طول می‌کشد و در دسترس بودن سیستم را به‌طور کامل نابود می‌کند.

مدیریت API

برای دسترسی به پادهای استنتاج، نیاز به یک درگاه API (API Gateway) مانند Envoy یا NGINX است. برای حفظ پایداری سیستم، تیم‌ها باید محدودیت نرخ (Rate Limiting) با الگوریتم Token Bucket، سقف اندازه درخواست‌ها (Request Size Caps) و چرخش کلیدهای API (API Key Rotation) را پیاده‌سازی کنند.

موازنه هزینه کل مالکیت (TCO)

اگرچه میزبانی شخصی هزینه‌های هر توکن را حذف می‌کند، اما هزینه کل مالکیت (TCO) اغلب گمراه‌کننده است. APIهای ابری زیرساخت را به یک هزینه متغیر تبدیل می‌کنند، در حالی که استقرار درون‌سازمانی، بار تأمین GPU و مدیریت پیچیده درایورها را به دوش تیم داخلی می‌اندازد.

سرویس‌دهی مدل تنها نیمی از مسیر است. تیم‌ها باید به‌طور مداوم پیاده‌سازی‌های خود را با فرمت‌های جدید safetensor، بهینه‌سازی‌های جدید مکانیزم توجه (Attention) و افزونه‌های طول کانتکست (Context-length Extensions) به‌روز کنند.

برای شرکت‌هایی که مدیریت سخت‌افزار تخصص اصلی آن‌ها نیست، پلتفرم‌های مدیریت‌شده‌ای مثل Oxlo.ai لایه زمان اجرا (Runtime) و پشته درایورها را در لایه‌های بالادستی مدیریت می‌کنند. Oxlo.ai بیش از ۴۵ مدل متن‌باز و اختصاصی را در هفت دسته مختلف، از بینایی ماشین و صوت گرفته تا مدل‌های Embedding پشتیبانی می‌کند. این قابلیت اجازه می‌دهد تیم‌ها درخواست‌های خود را از طریق کلاینت‌های استاندارد به https://api.oxlo.ai/v1 ارسال کنند، بدون اینکه درگیر مدیریت ترابایت‌ها وزن مدل یا پهنای‌باند PCIe شوند.

گام بعدی شما

• موجودی VRAM فعلی خود را با نیازهای خانواده Llama 3.3 یا DeepSeek تطبیق دهید تا امکان اجرای پایلوت محلی مشخص شود.
• در صورت محدودیت سخت‌افزاری، مدل‌های کوانتیده (Quantized) را برای کاهش مصرف حافظه بررسی کنید.
• ساختار vLLM را روی یک گره کوچک تست کنید تا سازگاری درایورهای CUDA را بسنجید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.