هوش گیتهوش گیترسانه، شبکه و یادگیری AI
ورود
خانهشبکهمدل‌هایادگیریپروژه‌ها
Hooshgate Referenceراهنمای نصبمتن‌بازبازبینی: 2026-04-23

راهنمای self-host روی لینوکس

این guide برای تیمی است که واقعاً می‌خواهد روی Linux self-host کند: انتخاب بین vLLM، TGI، GGUF، container و incident path.

بهترین کاربرد

stack self-host، private infra، rollout مدل‌های باز و تیم‌هایی که production serving را روی Linux جلو می‌برند.

مسیر اجرا

Linux production-minded

ملاحظه مهم

self-host فقط نصب مدل نیست؛ queueing، logging، incident، security و upgrade path هم باید روشن باشند.

دسترسی سریع

پوشش صفحهمرورآموزشنصبران‌تایمعملیاتریسک‌هامقایسهارزیابیمنابع

لایسنس

Open deployment stack

پیچیدگی

مسیر واقعی infra و serving

تسک‌ها

چت و دستیار • کدنویسی • RAG و دانش سازمانی

مودالیته‌ها

متن و چت • چندوجهی • Embedding • صوت و گفتار

پوشش واقعی

این صفحه چه packهایی را واقعاً پوشش می‌دهد؟

مرور مدل

کامل

این صفحه باید اول به‌عنوان مرجع شناخت، fit و boundary تصمیم‌گیری قابل اتکا باشد.

آموزش عملی

کامل

سناریوی شروع و مسیر استفاده اولیه روی همین صفحه آمده است.

نصب و راه‌اندازی

کامل

این صفحه برای setup و onboarding عمیق طراحی شده است.

اکوسیستم vLLMText Generation Inference (TGI)

serving و runtime

کامل

runtime و serving path در این نوع صفحه بخش اصلی decision surface است.

اکوسیستم vLLMText Generation Inference (TGI)

پیاده‌سازی

از طریق guide مرتبط

integration اینجا فقط تا حد اشاره آمده و عمق بیشتر در guideهای مرتبط است.

اکوسیستم vLLMText Generation Inference (TGI)

سازگارسازی

تعریف نشده

fine-tuning در این نوع صفحه محور اصلی نیست.

استقرار

از طریق guide مرتبط

در این صفحه deployment فقط برای انتخاب direction آمده و جزئیات در guideهای مرتبط است.

اکوسیستم vLLMText Generation Inference (TGI)

مقایسه

خلاصه روی همین صفحه

مقایسه در این نوع صفحه برای ایجاد context آمده، نه به‌عنوان matrix کامل.

ارزیابی

خلاصه روی همین صفحه

در setup guide ارزیابی بیشتر در حد readiness check می‌آید.

منابع رسمی

کامل

منابع رسمی و مسیر مطالعه بیشتر باید روی هر صفحه کامل و شفاف باشد.

مرور مدل

این مدل چیست و کجا می‌درخشد؟

این guide generic deployment نیست؛ موضوع آن self-host واقعی روی Linux است.

در Hooshgate این page یکی از مهم‌ترین مسیرهای setup/deployment usable است.

اگر private infra و data boundary برای شما اولویت است، این guide معمولاً یکی از اولین pageهاست.

نقاط قوت

  • production-oriented
  • stack decision روشن
  • مناسب private infra

محدودیت‌ها

  • ops burden بالا
  • team without infra maturity را خسته می‌کند

تفاوت کلیدی

سه نکته‌ای که این خانواده را از گزینه‌های هم‌رده جدا می‌کند.

نکته 1

در برابر local guide روی rollout production تمرکز دارد.

نکته 2

در برابر cloud-managed platform autonomy بیشتری می‌دهد.

نکته 3

برای Hooshgate این guide یکی از core pages برای self-host path است.

برای چه مناسب است

  • stack self-host، private infra، rollout مدل‌های باز و تیم‌هایی که production serving را روی Linux جلو می‌برند.
  • private infra و data boundary مهم است.
  • team شما serving engineering دارد.

برای چه مناسب نیست

  • self-host فقط نصب مدل نیست؛ queueing، logging، incident، security و upgrade path هم باید روشن باشند.
  • pilot ساده و کم‌بار دارید.
  • managed cloud برایتان کافی است.

آموزش عملی

اولین مسیر عملی با راهنمای self-host روی لینوکس

انتخاب و نصب runtime مناسب برای self-host مدل‌های باز روی سرور Linux

مرحله 1

ابتدا use-case را به‌صورت محدود برای انتخاب و نصب runtime مناسب برای self-host مدل‌های باز روی سرور Linux تعریف کنید و success metric را قبل از اجرا بنویسید.

مرحله 2

روی راهنمای self-host روی لینوکس فقط با چند ورودی واقعی pilot بگیرید و خروجی را با schema، human review یا benchmark داخلی بسنجید.

مرحله 3

اگر pilot قابل‌دفاع بود، بعد سراغ integration، logging و rollout کنترل‌شده بروید نه rollout کامل از روز اول.

نمونه ورودی

یک issue واقعی، function signature یا diff target به همراه constraintهای repo

خروجی مورد انتظار

patch، پیشنهاد refactor یا پاسخ ساخت‌یافته برای review مهندسی

خطاهای رایج

اشتباه‌هایی که معمولاً باعث می‌شوند pilot یا implementation شکست بخورد.

نکته 1

pilot را با داده مصنوعی یا ورودی خیلی تمیز قضاوت نکنید.

نکته 2

بدون schema، quality gate و fallback، مسیر production خیلی زود ناپایدار می‌شود.

نکته 3

قبل از rollout، هزینه و latency را در mode واقعی deployment بسنجید.

راهنمای نصب

راه‌اندازی راهنمای self-host روی لینوکس

self-host عملیاتی

برای چه مناسب است

data residency، volume پایدار، customization یا economics قابل‌پیش‌بینی

کجا مناسب نیست

تیم بدون GPU ops یا workload نامعلوم

مسیر شروع

  • نسخه runtime یا API path را مشخص کنید و از همان ابتدا logging و owner را تعیین کنید.
  • وقتی baseline روشن شد، فقط همان flow را وارد stack اصلی یا CI/CD کنید.
  • gateway، observability و fallback را بیرون از runtime طراحی کنید.

نمونه دستور

docker run --gpus all vllm/vllm-openai:latest
docker run ghcr.io/huggingface/text-generation-inference:latest

trade-off

کنترل بیشترپیچیدگی و ownership بیشترنیاز به benchmark و capacity planning

پیش‌نیازها

  • Linux server
  • GPU/CPU capacity plan
  • container and observability basics

محیط‌ها

  • single-node Linux
  • containerized server
  • private network

نکته‌های مهم

  • runtime را براساس traffic و model class انتخاب کنید، نه براساس hype.
  • health check، log retention و rollback path را از همان روز اول بگذارید.

مرحله 1

نسخه runtime یا API path را مشخص کنید و از همان ابتدا logging و owner را تعیین کنید.

مرحله 2

اول با یک workload کوچک و repeatable health check بگیرید و بعد quality را روی داده واقعی بسنجید.

مرحله 3

وقتی baseline روشن شد، فقط همان flow را وارد stack اصلی یا CI/CD کنید.

فلو راه‌اندازی

یک نگاه سریع برای اینکه pilot را مرحله‌به‌مرحله جلو ببرید.

بلوک 1

نسخه runtime یا API path را مشخص کنید و از همان ابتدا logging و owner را تعیین کنید.

بلوک 2

اول با یک workload کوچک و repeatable health check بگیرید و بعد quality را روی داده واقعی بسنجید.

بلوک 3

وقتی baseline روشن شد، فقط همان flow را وارد stack اصلی یا CI/CD کنید.

نمونه دستورها

docker run --gpus all vllm/vllm-openai:latest
docker run ghcr.io/huggingface/text-generation-inference:latest
python -m llama_cpp.server --model model.gguf

serving و runtime

انتخاب runtime و serving path

اول use-case، latency target و boundary داده را روشن کنید؛ بعد runtime را انتخاب کنید.

self-host فقط وقتی ارزش دارد که benchmark، ops و ownership آن روشن باشد.

self-host

کجا مناسب است

  • data residency، workload پایدار، custom serving و optimization اقتصادی در scale
  • کنترل بیشتر
  • ops و ownership بیشتر

کجا مناسب نیست

  • تیم بدون GPU ops یا benchmark discipline

مسیر شروع

گام 1

نسخه runtime یا API path را مشخص کنید و از همان ابتدا logging و owner را تعیین کنید.

گام 2

وقتی baseline روشن شد، فقط همان flow را وارد stack اصلی یا CI/CD کنید.

گام 3

observability، auth و fallback را بیرون از runtime بسازید.

hardware / fit

  • CPU or GPU Linux server depending on chosen model

latency و cost

cost autonomy بیشتری می‌گیرید ولی burden ops و incident هم به تیم شما منتقل می‌شود.

عملیات production

چک‌لیست production

فازهای rollout

  • offline eval و success criteria
  • staging با tracing و feature flag
  • limited rollout و سپس rollout مرحله‌ای

امنیت و policy

  • artifact trust، network policy و access control را قبل از launch روشن کنید.
  • PII masking و audit trail را بیرون از مدل طراحی کنید.
  • بدون on-call ownership، self-host خیلی زود شکننده می‌شود.

observability و review

  • queue depth
  • p95 latency
  • task-level cost، latency و quality review را کنار هم مانیتور کنید.

maintenance و trade-off

  • model، prompt/template و routing policy را version کنید.
  • runtime migration path را قبل از scale بنویسید.
  • deployment stability

ریسک‌های رایج

چیزهایی که معمولاً pilot یا rollout را خراب می‌کنند

pitfallهای اصلی

این نکته‌ها معمولاً همان جاهایی هستند که تیم‌ها قبل از رسیدن به value عملی زمین می‌خورند.

نکته 1

pilot را با داده مصنوعی یا ورودی خیلی تمیز قضاوت نکنید.

نکته 2

بدون schema، quality gate و fallback، مسیر production خیلی زود ناپایدار می‌شود.

نکته 3

قبل از rollout، هزینه و latency را در mode واقعی deployment بسنجید.

نکته 4

self-host فقط نصب مدل نیست؛ queueing، logging، incident، security و upgrade path هم باید روشن باشند.

نکته 5

بدون on-call ownership، self-host خیلی زود شکننده می‌شود.

مقایسه

چه زمانی راهنمای self-host روی لینوکس را انتخاب کنیم؟

وقتی این مدل انتخاب خوبی است

  • private infra و data boundary مهم است.
  • team شما serving engineering دارد.

وقتی باید سراغ گزینه دیگر رفت

  • pilot ساده و کم‌بار دارید.
  • managed cloud برایتان کافی است.

نقشه تصمیم

اگر هنوز بین این خانواده و گزینه‌های رقیب مردد هستید، از این trade-off path شروع کنید.

بلوک 1

stack self-host، private infra، rollout مدل‌های باز و تیم‌هایی که production serving را روی Linux جلو می‌برند.

بلوک 2

Linux production-minded

بلوک 3

self-host فقط نصب مدل نیست؛ queueing، logging، incident، security و upgrade path هم باید روشن باشند.

راهنمای deployment برای محصول و سازمان

چه زمانی راهنمای self-host روی لینوکس بهتر است

برای self-host Linux دقیق‌تر است.

چه زمانی گزینه مقابل بهتر است

برای rollout اصولی در سطح broader، آن guide مکمل است.

اکوسیستم Amazon Bedrock

چه زمانی راهنمای self-host روی لینوکس بهتر است

برای autonomy و private infra بهتر است.

چه زمانی گزینه مقابل بهتر است

برای managed cloud ops، Bedrock ساده‌تر است.

اکوسیستم vLLM

چه زمانی راهنمای self-host روی لینوکس بهتر است

برای stack selection guide بهتر است.

چه زمانی گزینه مقابل بهتر است

برای خود runtime vLLM، آن page دقیق‌تر است.

ارزیابی

Checklist ارزیابی

مرحله 1

deployment stability

مرحله 2

ops burden

مرحله 3

latency

مرحله 4

security readiness

منابع رسمی

منابع رسمی و مسیر مطالعه بیشتر

vLLM docs

https://docs.vllm.ai/

TGI docs

https://huggingface.co/docs/text-generation-inference/en/index

llama.cpp

https://github.com/ggml-org/llama.cpp