راه‌اندازی مدل‌های زبانی روی سرورهای اختصاصی (Self-hosted) دغدغه‌ی مشترک بسیاری از تیم‌های مهندسی است. در دسترس نبودن کارتهای اعتباری بین‌المللی برای شارژ مداوم API سرویس‌های ابری و هزینه‌های بالای اشتراک ارزی، میزبانی داخلی مدل‌ها را به انتخابی منطقی و ضروری تبدیل کرده است. با این حال، انتخاب میان ابزارهایی مانند vLLM ،SGLang ،llama.cpp یا Ollama اغلب تیم‌ها را دچار سردرگمی می‌کند.
تهیه‌ی پردازنده‌های گرافیکی قدرتمند خارجی برای کاربران ایرانی با چالش‌های هزینه و دسترسی همراه است؛ بنابراین باید متناسب با دقیق‌ترین دارایی‌های موجود، از پردازنده‌های معمولی (CPU) گرفته تا سرورهای مجهز به کارتهای NVIDIA یا AMD، بیشترین بازدهی ممکن استخراج شود. اجرای مدلی که می‌تواند با دقت بالا روی CPU اجرا شود در یک فریم‌ورک نامناسب، منجر به اتلاف شدید منابع یا کُندی سرویس خواهد شد.
در این درس یاد می‌گیرید که چطور بر اساس سه متغیر کلیدی — نوع سخت‌افزار، مقیاس کاربران همزمان و نوع بار کاری (از چت معمولی تا سیستم‌های ایجنتی چندمرحله‌ای) — بهترین موتور استنتاج را برگزینید و پایپ‌لاین مهاجرت از محیط آزمایشگاهی و لپ‌تاپ تا محیط عملیاتی را به‌درستی معماری کنید.
انتخاب موتور استنتاج تابعی از سخت‌افزار، مقیاس و زیست‌بوم ابزارهاست، نه رتبه‌بندی لیدربوردها. در سال 2026 چهار موتور بر استنتاج خودمیزبان (Self-hosted) مسلط هستند: llama.cpp، Ollama، vLLM و SGLang؛ و TGI نیز در وضعیت نگهداری (Maintenance mode) عقب مانده است. llama.cpp سریع‌ترین گزینه روی CPU است؛ با گسترده‌ترین پشتیبانی از مدل‌ها و کنترل کامل روی کوانتیزه‌سازی (Quantization) و ریسه‌بندی (Threading). Ollama گزینهی نصب تک‌دستوری روی لپ‌تاپ توسعه است؛ حدود 15 تا 30 درصد کُندتر از llama.cpp (به دلیل لایههای Go، CGo و سریالسازی HTTP) و با افت 3 برابری نرخ پردازش (Throughput) زیر بار شبه‌پروداکشن. TGI در تاریخ 11 دسامبر 2025 وارد وضعیت نگهداری شد؛ از این پس فقط اصلاح باگ دریافت می‌کند، نرخ پردازش خام آن حدود 10 درصد از vLLM کمتر است، اما از قدیم بهترین رصدپذیری (Observability) و یکپارچگی را با زیست‌بوم Hugging Face داشته است. همین وضعیت نگهداری، آن را به انتخابی پرریسک برای بلندمدت تبدیل می‌کند؛ بنابراین برای پروژه‌های جدید، SGLang یا vLLM گزینه‌های پیش‌فرضِ امن‌تری هستند. vLLM انتخاب پیش‌فرض و همه‌منظوره برای محیط عملیاتی (پروداکشن) است؛ نسخه‌ی v0.15.1 (فوریه‌ی 2026) پشتیبانی از PyTorch 2.10، معماری RTX Blackwell SM120 و بهینه‌سازی H200 را اضافه کرده است. SGLang متخصص بارهای کاری ایجنتی چندنوبتی (Multi-turn) و پیشوندهای سنگین است؛ با بیش از 400,000 پردازندهی گرافیکی فعال در پروداکشن (xAI، LinkedIn، Cursor، Oracle، GCP، Azure و AWS). محدودیت‌های سخت‌افزاری: اولویت با CPU ← llama.cpp؛ سخت‌افزار AMD یا غیر NVIDIA ← موتور vLLM قویترین مسیر پشتیبانی‌شده است (چرا که TRT-LLM فقط به سخت‌افزار NVIDIA محدود است). الگوی پایپ‌لاین در سال 2026: توسعه = Ollama، استیجینگ = llama.cpp، پروداکشن = vLLM یا SGLang. این موتورها فرمت‌های وزنی متفاوتی می‌پذیرند؛ GGUF برای خانواده‌ی llama.cpp و safetensors هاگینگ‌فیس برای موتورهای GPU؛ بنابراین ممکن است بین مراحل به تبدیل فرمت نیاز داشته باشید.
اهداف یادگیری
- انتخاب موتور مناسب با توجه به سخت‌افزار (CPU / AMD / NVIDIA Hopper / Blackwell)، مقیاس (1 کاربر / 100 / 10,000) و نوع بار کاری (چت عمومی / ایجنت / زمینه‌ی طولانی).
- شناخت وضعیت نگهداری TGI در سال 2026 (از تاریخ 11 دسامبر 2025) و چرایی سوق دادن پروژه‌های جدید به سمت vLLM یا SGLang.
- توصیف پایپ‌لاین توسعه/استیجینگ/پروداکشن، همراه با محل قرارگیری تبدیل فرمت وزنی GGUF به safetensors میان مراحل.
- توضیح چرایی ارجاع «اولویت با CPU» به llama.cpp و اینکه چرا انتخاب «AMD» موتور TRT-LLM را حذف می‌کند.
صورت مسئله
تیم شما پروژه‌ی جدیدی بر پایه‌ی یک مدل زبانی خودمیزبان آغاز می‌کند. یک مهندس Ollama را پیشنهاد میدهد، دیگری vLLM را مطرح می‌کند و سومی می‌گوید: «مگر TGI بدون دردسر و آماده‌ی کار نیست؟» هر سه نفر برای سناریوهای متفاوتی درست می‌گویند، اما هیچ گزینه‌ای برای همه‌ی سناریوها مناسب نیست.
در سال 2026 درخت تصمیم‌گیری اهمیت ویژه‌ای دارد: اول سخت‌افزار، دوم مقیاس، سوم بار کاری. از طرفی یک رویداد خاص در اواخر سال 2025 — ورود TGI به وضعیت نگهداری در 11 دسامبر — گزینهی پیش‌فرض را برای پروژه‌های جدید تغییر داده است.
مبانی نظری
پنج موتور اصلی
| موتور | بهترین برای | توضیحات |
|---|---|---|
| llama.cpp | پردازندهی CPU / محاسبات لبه (Edge) / حداقل نیازمندی‌ها / بیشترین تنوع مدل | سریع‌ترین روی CPU، کنترل کامل |
| Ollama | لپ‌تاپ‌های توسعه، تک‌کاربر، نصب تک‌دستوری | 15 تا 30 درصد کُندتر از llama.cpp؛ افت 3 برابری نرخ پردازش در پروداکشن |
| TGI | زیست‌بوم HF، صنایع با رگولاتوری سخت‌گیرانه | ورود به وضعیت نگهداری در 11 دسامبر 2025 |
| vLLM | مصارف عمومی پروداکشن، بیش از 100 کاربر | گزینهی پیش‌فرض و فراگیر پروداکشن؛ نسخه‌ی v0.15.1 در فوریه‌ی 2026 |
| SGLang | سناریوهای ایجنتی چندنوبتی، بارهای متکی بر اشتراک پیشوند | بیش از 400,000 پردازندهی گرافیکی در پروداکشن |
تصمیم اول: سخت‌افزار
اولویت با CPU ← موتور llama.cpp. کار با Ollama هم ممکن است اما کُندتر اجرا می‌شود. هیچ موتور دیگری روی CPU توان رقابت با آن را ندارد.
پردازندهی گرافیکی AMD ← موتور vLLM بهترین مسیر پشتیبانی‌شده است (پشتیبانی از AMD ROCm). موتور SGLang هم کار می‌کند. اما TRT-LLM حذف می‌شود چون منحصراً به NVIDIA قفل شده است.
معماری NVIDIA Hopper (مدل‌های H100 / H200) ← انتخاب بین vLLM، SGLang یا TRT-LLM؛ هر سه در بالاترین سطح عمل می‌کنند.
معماری NVIDIA Blackwell (مدل‌های B200 / GB200) ← موتور TRT-LLM در نرخ پردازش پیشتاز است (فاز 17 · 07). موتورهای vLLM و SGLang با فاصله‌ی اندکی آن را تعقیب می‌کنند.
اپل سیلیکون (سری M) ← موتور llama.cpp (از طریق Metal). ابزار Ollama نیز لایه‌ای روی همین بستر است.
تصمیم دوم: مقیاس
1 کاربر / توسعه‌ی محلی ← موتور Ollama. یک دستور اجرا می‌کنید و خروجی نخستین توکن ظرف چند ثانیه تولید می‌شود.
10 تا 100 کاربر / تیم کوچک ← یک نمونه vLLM با تکGPU.
100 تا 10 هزار کاربر / پروداکشن ← پشته‌ی پروداکشن vLLM (فاز 17 · 18) یا SGLang.
بیش از 10 هزار کاربر / سازمان‌های بزرگ ← پشته‌ی پروداکشن vLLM + معماری تفکیک‌شده (Disaggregated؛ فاز 17 · 17) + کش LMCache (فاز 17 · 18).
تصمیم سوم: نوع بار کاری
چت عمومی / پرسش و پاسخ ← موتور vLLM به لطف سازگاری گسترده و پیش‌فرض بودن برنده است.
سناریوهای ایجنتی چندنوبتی (ابزارها، برنامه‌ریزی، حافظه) ← سازوکار RadixAttention در SGLang (فاز 17 · 06) بی‌رقیب است.
سیستم‌های RAG با استفادهی مجدد و سنگین از پیشوند ← موتور SGLang.
تولید کد ← موتور vLLM مناسب است؛ اما SGLang به دلیل عملکرد بهتر کش برتری اندکی دارد.
زمینه‌ی طولانی (بیش از 128K) ← موتور vLLM همراه با پیش‌پرکنی تکه‌ای (Chunked prefill)؛ یا SGLang همراه با حافظه‌ی KV چندسطحی (Tiered KV).
دام وضعیت نگهداری در TGI
موتور TGI متعلق به Hugging Face در 11 دسامبر 2025 وارد وضعیت نگهداری شد و از این پس فقط اصلاح باگ دریافت می‌کند. مزایای همیشگی آن: رصدپذیری عالی، عمیق‌ترین یکپارچگی با زیست‌بوم HF (شناسنامه‌های مدل، ابزارهای ایمنی)؛ هرچند از نظر نرخ پردازش خام اندکی عقب‌تر از vLLM بود.
برای پروژه‌های جدید در سال 2026: سراغ TGI نروید. سرویس‌های فعال مبتنی بر TGI می‌توانند فعلاً به کارشان ادامه دهند اما در نهایت باید مهاجرت کنند. موتورهای SGLang و vLLM پیش‌فرض‌های امن‌تری به شمار می‌روند.
الگوی پایپ‌لاین
توسعه (Ollama) ← استیجینگ (llama.cpp) ← پروداکشن (vLLM). این موتورها فرمت‌های وزنی متفاوتی دریافت می‌کنند: GGUF برای خانواده‌ی llama.cpp و HF safetensors برای موتورهای مبتنی بر GPU؛ بنابراین ممکن است بین این مراحل نیاز به تبدیل فرمت داشته باشید. مهندسان روی لپ‌تاپ به‌سرعت تغییرات را آزمایش می‌کنند، استیجینگ وضعیت کوانتیزه‌سازی پروداکشن را شبیه‌سازی می‌کند و پروداکشن بستر نهایی سرویس‌دهی است.
نکته‌ی مهم درباره‌ی Ollama
ابزار Ollama برای محیط توسعه عالی است، اما برای محیط عملیاتی اشتراکی مناسب نیست: سریالسازی HTTP در زبان Go سربار ایجاد می‌کند، مدیریت همروندی آن بسیار ساده‌تر از vLLM است و پشتیبانی آن از OpenTelemetry عقب‌تر از رقباست. از Ollama در نقطه‌ی قوتش استفاده کنید — یک کاربر، یک دستور — و برای بارهای کاری اشتراکی سراغ vLLM بروید.
تصمیم‌گیری مستقل میان خودمیزبانی و سرویس‌های ابری مدیریت‌شده
فاز 17 · 01 (سرویس‌های ابری بزرگ) و فاز 17 · 02 (پلتفرم‌های استنتاج) مسیرهای مدیریت‌شده را پوشش می‌دهند. در این درس فرض بر این است که از قبل تصمیم به خودمیزبانی گرفته‌اید. دلایل روی آوردن به خودمیزبانی: قوانین ماندگاری داده (Data residency)، مدل‌های سفارشیِ فاین‌تون‌شده، هزینه‌ی کل مالکیت (TCO) کمتر در مقیاس بالا و عدم ارائه‌ی مدل‌های تخصصی روی سرویس‌های ابری عمومی.
اعدادی که باید به خاطر بسپارید
- آغاز وضعیت نگهداری TGI: 11 دسامبر 2025.
- نسخه‌ی vLLM v0.15.1: فوریه‌ی 2026؛ پشتیبانی از PyTorch 2.10 و معماری Blackwell SM120.
- ردپای عملیاتی SGLang: بیش از 400,000 پردازندهی گرافیکی.
- اختلاف نرخ پردازش Ollama در مقایسه با llama.cpp: بین 15 تا 30 درصد کُندتر؛ و 3 برابر افت ظرفیت زیر بار پروداکشن.
استفاده از ابزارهای واقعی
اسکریپت code/main.py یک پیمایش‌گر درخت تصمیم است: بر اساس ورودی‌های سخت‌افزار، مقیاس و بار کاری، موتور مناسب را انتخاب می‌کند و دلیل آن را توضیح میدهد.
خروجی این درس
این درس سند outputs/skill-engine-picker.md را ایجاد می‌کند؛ سندی که با توجه به محدودیت‌های مشخص‌شده، موتور مناسب را برمی‌گزیند و برنامه‌ی مهاجرت را تدوین می‌کند.
تمرین‌ها
- اسکریپت
code/main.pyرا با مشخصات سخت‌افزار، مقیاس و بار کاری سیستم خود اجرا کنید. آیا نتیجه با حدس اولیه‌ی شما همخوانی دارد؟ - زیرساخت شما شامل 12 پردازندهی H100 و 8 پردازندهی AMD MI300X است. چه موتوری را انتخاب می‌کنید؟ چرا TRT-LLM از گزینه‌ها کنار می‌رود؟
- تیمی قصد دارد در سال 2026 همچنان از TGI استفاده کند چون «با آن راحت‌تر هستیم». استدلال‌های فنی خود را برای ضرورت مهاجرت بیان کنید.
- انتقال از Ollama در محیط توسعه به vLLM در پروداکشن: چه تغییراتی در کوانتیزه‌سازی، پیکربندی و رصدپذیری رخ میدهد؟
- محصولی مبتنی بر RAG دارید که صدک 99 (P99) طول پیشوند آن 8K توکن است و میان کاربران مختلف اشتراک بالایی دارد. موتور مناسب را برگزینید و پشته‌ی آن را با فازهای 17 · 11 و 17 · 18 هماهنگ کنید.
اصطلاحات کلیدی
| اصطلاح | اصطلاح رایج بازاری | معنای دقیق فنی |
|---|---|---|
| llama.cpp | «موتور مخصوص CPU» | بیشترین پشتیبانی از مدل‌ها، سریع‌ترین عملکرد روی CPU |
| Ollama | «موتور روی لپ‌تاپ» | نصب با یک دستور، نرخ پردازش در حد محیط توسعه |
| TGI | «موتور هاگینگ‌فیس» | در وضعیت نگهداری از دسامبر 2025 |
| vLLM | «موتور پیش‌فرض» | خط مبنای (Baseline) فراگیر برای پروداکشن در سال 2026 |
| SGLang | «موتور سیستم‌های ایجنتی» | بهینه‌سازی‌شده برای پیشوندهای سنگین به کمک RadixAttention |
| TRT-LLM | «موتور قفل‌شده به NVIDIA» | پیشتاز نرخ پردازش در معماری Blackwell، منحصراً روی تراشه‌های NVIDIA |
| GGUF | «فرمت مخصوص llama.cpp» | بسته‌بندی متغیرهای کوانتیزه‌سازی با روش K-quant |
| پشته‌ی پروداکشن (Production-stack) | «اجرای vLLM روی کوبرنتیز» | پیکربندی مرجع استقرار در فاز 17 · 18 |
| الگوی پایپ‌لاین (Pipeline pattern) | «چرخه‌ی توسعه، استیجینگ و پروداکشن» | زنجیره‌ی Ollama ← llama.cpp ← vLLM؛ فرمت وزن‌ها به تفکیک موتور تغییر می‌کند |
برای مطالعه‌ی بیشتر
- AI Made Tools — مقایسه‌ی vLLM ،Ollama ،llama.cpp و TGI در سال 2026
- Morph — مقایسه‌ی llama.cpp و Ollama در سال 2026
- n1n.ai — مقایسه‌ی جامع موتورهای استنتاج مدل‌های زبانی بزرگ
- PremAI — ده جایگزین برتر vLLM در سال 2026
- بیانیه‌ی وضعیت نگهداری TGI — در بخش یادداشت‌های انتشار.
- یادداشت‌های انتشار نسخه vLLM v0.15.1