هوش مصنوعی لوکال چیست؟ راهنمای مرجع Local AI، انواع مدل‌ها، بنچمارک و انتخاب سخت‌افزار در ۲۰۲۶

تا چند سال قبل «هوش مصنوعی» برای اکثر کاربران مترادف با یک وب‌سایت یا API بود: سؤال را می‌فرستادید، پاسخ از دیتاسنتر شرکت دیگری برمی‌گشت. رشد مدل‌های open-weight، ابزارهایی مثل Ollama، llama.cpp و LM Studio و بهترشدن کوانتایز، این معادله را عوض کرد. حالا اجرای یک مدل توانمند روی لپ‌تاپ، ورک‌استیشن، سرور خصوصی یا زیرساخت داخلی شرکت دیگر پروژه‌ای آزمایشگاهی نیست.

اما «لوکال بودن» به‌خودی‌خود مساوی بهتر بودن نیست. مدلی که روی لپ‌تاپ شما اجرا می‌شود اگر کند، ضعیف یا بد تنظیم شده باشد، از یک API ابری متوسط هم تجربه بدتری می‌دهد. برعکس، یک مدل درست انتخاب‌شده که با RAG، ابزارهای سازمانی و سیاست‌های امنیتی مناسب ترکیب شود، برای پشتیبانی، جست‌وجوی اسناد، تحلیل داخلی، اتوماسیون و دستیارهای اختصاصی می‌تواند بسیار ارزشمند باشد.

هوش مصنوعی لوکال دقیقاً چه چیزی را «لوکال» می‌کند؟

Local AI یک محصول مشخص نیست؛ یک مدل استقرار است. ممکن است فقط مدل زبانی روی سرور شما باشد، یا کل زنجیره شامل embedding، پایگاه برداری، OCR، Speech-to-Text، Text-to-Speech و حتی ابزارهای Agent داخل شبکه اجرا شوند.

چرا Local AI مهم شده است؟

سه اتفاق هم‌زمان Local AI را جدی کرد: مدل‌های کوچک‌تر بسیار قوی‌تر شدند، فرمت‌های کوانتایز اجرای مدل را روی حافظه کمتر ممکن کردند و ابزارهای استقرار به‌قدری ساده شدند که برای بالا آوردن یک API محلی دیگر لازم نیست یک تیم پژوهش یادگیری ماشین داشته باشید.

• حریم خصوصی و مالکیت داده: متن قرارداد، اطلاعات مشتری، اسناد داخلی یا مکالمات می‌توانند داخل محیط کنترل‌شده بمانند.
• تاخیر شبکه کمتر: برای درخواست‌های کوتاه، حذف رفت‌وبرگشت اینترنت می‌تواند تجربه سریع‌تری ایجاد کند؛ البته سرعت خود مدل همچنان تعیین‌کننده است.
• هزینه ثابت‌تر: در حجم استفاده بالا، خرید یا اجاره سخت‌افزار ممکن است از پرداخت دائمی به‌ازای توکن اقتصادی‌تر شود.
• کنترل نسخه: می‌توانید دقیقاً یک نسخه مدل، پرامپت، پارامترها و داده را ثابت نگه دارید.
• سفارشی‌سازی: RAG، LoRA، fine-tuning، ابزارها و سیاست‌های پاسخ‌گویی تحت کنترل خودتان هستند.
• تاب‌آوری: سرویس داخلی شما به قطع API خارجی، محدودیت منطقه‌ای یا تغییر ناگهانی قیمت وابستگی کمتری دارد.

انواع هوش مصنوعی لوکال؛ فقط LLM نیست

۱) مدل‌های زبانی لوکال (Local LLM)

رایج‌ترین دسته همین است: مدل‌هایی برای چت، خلاصه‌سازی، تولید متن، ترجمه، تحلیل و کدنویسی. خانواده‌هایی مثل Qwen، Gemma، Mistral و gpt-oss در نسخه‌های مختلف می‌توانند روی سخت‌افزار شخصی یا سرور اجرا شوند.

۲) مدل‌های Reasoning

این مدل‌ها برای مسائل چندمرحله‌ای، ریاضی، کدنویسی و تصمیم‌گیری پیچیده‌تر، توکن بیشتری صرف استدلال می‌کنند. مزیتشان کیفیت بالاتر در بعضی وظایف و عیبشان زمان پاسخ و مصرف توکن بیشتر است. اگر چت‌بات شما فقط درباره ساعات کاری و موجودی محصول جواب می‌دهد، مدل reasoning سنگین احتمالاً اتلاف منابع است.

۳) مدل‌های چندوجهی (Vision-Language)

مدل‌هایی مثل Gemma 4، Qwen3.5 و Mistral Small 4 می‌توانند علاوه بر متن، تصویر را هم دریافت کنند. برای خواندن اسکرین‌شات، سند تصویری، نمودار، فرم یا عکس محصول کاربردی‌اند.

۴) Embedding و Reranker

برای RAG، فقط مدل چت مهم نیست. یک embedding خوب متن را به بردار تبدیل می‌کند و reranker نتیجه‌های بازیابی را دوباره مرتب می‌کند. در سامانه‌های سازمانی، کیفیت retrieval اغلب بیشتر از بزرگ‌تر کردن LLM روی دقت جواب اثر دارد.

۵) صوت و گفتار

Speech-to-Text مثل خانواده Whisper و TTSهای لوکال می‌توانند زنجیره تماس صوتی یا دستیار بدون وابستگی مستقیم به API ابری بسازند.

۶) تصویر و ویدئو

مدل‌های diffusion و نسل‌های جدید تولید تصویر نیز قابل اجرای لوکال‌اند، اما نیاز سخت‌افزاری و الگوی بنچمارک آن‌ها با LLM فرق دارد. در این مقاله تمرکز اصلی روی مدل‌های زبانی و مدل‌های مولد قابل استفاده در دستیارهای کسب‌وکار است.

پشته Local AI از چه اجزایی ساخته می‌شود؟

وقتی درباره «نصب یک مدل روی سرور» حرف می‌زنیم، فقط یک فایل وزن نداریم. یک سامانه لوکال حرفه‌ای معمولاً از چند لایه تشکیل می‌شود: مدل، runtime، API، retrieval، ذخیره‌سازی، ابزار، کنترل دسترسی، مانیتورینگ و رابط کاربر. اگر یکی از این لایه‌ها درست طراحی نشود، بزرگ‌ترکردن مدل مشکل را حل نمی‌کند.

این تفکیک برای هزینه و امنیت هم حیاتی است. ممکن است مدل شما روی یک GPU داخلی اجرا شود اما vector database یا لاگ‌ها روی سرویس دیگری باشند. بنابراین عبارت «همه‌چیز لوکال است» باید درباره کل زنجیره بررسی شود، نه فقط مدل.

Dense در برابر MoE؛ عدد پارامتر را چطور بخوانیم؟

در مدل Dense تقریباً همه پارامترهای شبکه در هر توکن درگیر محاسبه‌اند. در معماری Mixture of Experts یا MoE وزن‌های کل بسیار بیشترند، اما برای هر توکن فقط تعدادی expert فعال می‌شوند. همین موضوع مدل‌هایی مثل Qwen3.5-35B-A3B، Gemma 4 26B A4B و gpt-oss-20b را جذاب می‌کند: ظرفیت کل بالا می‌رود، در حالی که هزینه محاسبه هر توکن به اندازه مدل Dense هم‌حجم نیست.

Context Window یعنی چه و چرا عدد بزرگ همیشه بهتر نیست؟

Context Window مقدار متنی است که مدل در یک درخواست می‌تواند در دسترس داشته باشد. در نسل‌های جدید اعداد 128K، 256K و حتی بیش از آن رایج شده‌اند. Qwen3.5-35B-A3B به‌طور native از 262,144 توکن پشتیبانی می‌کند و طبق مدل‌کارت تا حدود یک میلیون توکن قابل گسترش است؛ Gemma 4 نیز تا 256K را هدف گرفته است. اما در عمل، context بزرگ سه هزینه دارد: حافظه KV cache، زمان prefill و احتمال افت تمرکز روی بخش‌های مرتبط.

برای RAG معمولاً بهتر است retrieval دقیق، chunking خوب و reranking داشته باشید تا اینکه بی‌دلیل صدها هزار توکن را داخل prompt بریزید. «مدل می‌تواند 256K ببیند» با «باید 256K به آن بدهیم» یک چیز نیست.

Open Source، Open Weight و Local؛ سه اصطلاح متفاوت

یکی از خطاهای رایج این است که هر مدلی که روی سیستم شخصی اجرا می‌شود «اوپن‌سورس» نامیده شود. Local یعنی محل اجرا. Open-weight یعنی وزن‌های مدل قابل دریافت‌اند. Open source در معنای سخت‌گیرانه‌تر، درباره بازبودن کد، وزن‌ها، فرایند و مجوز صحبت می‌کند. بنابراین ممکن است مدلی open-weight و قابل اجرای لوکال باشد، اما همه اجزای فرایند آموزش آن باز نباشد.

برای پروژه تجاری، مجوز مدل را جداگانه بررسی کنید. Apache 2.0 در مدل‌هایی مثل Qwen3.5، Mistral Small 4 و gpt-oss آزادی تجاری بالایی می‌دهد، اما همه خانواده‌ها دقیقاً همین مجوز را ندارند.

ابزارهای اجرای Local AI: Ollama، llama.cpp، LM Studio و vLLM

انتخاب runtime به‌اندازه انتخاب مدل مهم است. یک مدل یکسان با runtime، تعداد thread، offload و context متفاوت می‌تواند سرعت و مصرف حافظه کاملاً متفاوتی داشته باشد.

کوانتایز چیست و چرا قلب Local AI است؟

مدل‌ها معمولاً با دقت‌هایی مثل BF16 یا FP16 آموزش یا منتشر می‌شوند. نگهداری هر پارامتر در 16 بیت برای مدل‌های بزرگ حافظه زیادی می‌خواهد. Quantization دقت وزن‌ها را کاهش می‌دهد؛ مثلاً به 8 یا حدود 4 بیت. نتیجه این است که فایل کوچک‌تر می‌شود، RAM/VRAM کمتری لازم دارد و در بسیاری از سخت‌افزارها inference سریع‌تر می‌شود.

مستندات رسمی llama.cpp توضیح می‌دهد که کوانتایز با کاهش precision اندازه مدل را کم می‌کند و می‌تواند inference را سریع‌تر کند، هرچند مقداری افت کیفیت ممکن است رخ دهد. در اکوسیستم GGUF، فرمت‌هایی مثل Q4_K_M، Q5_K_M و Q8_0 رایج‌اند.

RAM و VRAM چطور تخمین زده می‌شوند؟

یک تخمین ساده برای وزن‌ها این است: تعداد پارامتر × تعداد بیت ÷ 8. مثلاً وزن‌های خام یک مدل 8B در 4 بیت حدود 4GB هستند. اما این فقط وزن خام است؛ runtime، metadata، buffers، KV cache، context و parallelism هم حافظه می‌خواهند. بنابراین فایل 4GB به معنی اجرای مطمئن در 4GB RAM نیست.

این اعداد تخمینی‌اند و برای برنامه‌ریزی اولیه‌اند، نه تضمین. معماری مدل، نوع quant، context و runtime می‌توانند مصرف واقعی را تغییر دهند. در مدل‌های MoE، تعداد پارامترهای فعال در محاسبه کم می‌شود اما معمولاً وزن‌های کل مدل همچنان باید در حافظه قابل دسترس باشند.

کانتکست هم ارزان نیست. مستندات Ollama صریحاً می‌گوید context بزرگ‌تر حافظه بیشتری مصرف می‌کند و برای workloadهایی مثل agent و coding context بالا می‌تواند لازم باشد. بنابراین مدل 8B با context بسیار بزرگ ممکن است حافظه بیشتری از چیزی که فقط از اندازه فایل حدس می‌زنید بخواهد.

مدل‌های مهم Local AI در ۲۰۲۶؛ چه گزینه‌هایی واقعاً ارزش بررسی دارند؟

بازار مدل‌های قابل‌اجرا روی زیرساخت شخصی با سرعت زیادی تغییر می‌کند. بنابراین این مقاله به‌جای اعلام یک «بهترین مدل جهان»، چند خانواده مهم را بر اساس معماری، اندازه، modality، context، کیفیت ارزیابی و واقع‌بینی سخت‌افزاری بررسی می‌کند. نسخه مدل همیشه مهم است؛ مثلاً Qwen3 با Qwen3.5 و Gemma 3 با Gemma 4 از نظر معماری و benchmark یکسان نیستند.

رده سخت‌افزار بالا برای برنامه‌ریزی اولیه است، نه تضمین. quantization، backend، context، concurrency و نوع حافظه نتیجه را تغییر می‌دهند.

Qwen3.5-35B-A3B؛ چرا برای Local AI مهم است؟

Qwen3.5-35B-A3B یک مدل MoE چندوجهی با 35 میلیارد پارامتر کل و حدود 3 میلیارد پارامتر فعال است. مدل‌کارت رسمی Qwen پشتیبانی 201 زبان و گویش، context بومی 262,144 توکن و امکان گسترش تا 1,010,000 توکن را ذکر می‌کند. از نظر معماری نیز از ترکیب Gated Delta Networks، attention و MoE استفاده می‌کند؛ یعنی هدف آن فقط افزایش اندازه نیست، بلکه افزایش throughput و کارایی inference است.

برای پروژه فارسی، ارزش Qwen3.5 فقط در «توانایی نوشتن فارسی» نیست. benchmarkهای چندزبانه رسمی مثل MMMLU، MMLU-ProX، INCLUDE و WMT24++ نشان می‌دهند تیم Qwen ارزیابی multilingual را جدی گرفته است. با این حال هنوز لازم است تست بومی فارسی داشته باشید؛ چون میانگین 29 یا 55 زبان لزوماً رفتار مدل روی محاوره ایرانی، تاریخ شمسی، نام برند و داده فروش شما را نشان نمی‌دهد.

Gemma 4؛ از Edge تا Workstation

Gemma 4 خانواده متنوع‌تری برای انتخاب سخت‌افزار ارائه می‌کند: E2B، E4B، 12B، 26B A4B و 31B. نسخه 26B A4B یک MoE با 25.2B پارامتر کل و 3.8B فعال است؛ درحالی‌که 12B و 31B Dense هستند. Google در مدل‌کارت رسمی context تا 256K و پشتیبانی بیش از 140 زبان را ذکر می‌کند. این خانواده به‌خصوص زمانی جذاب است که علاوه بر متن، ورودی تصویر و در بعضی اندازه‌ها صوت هم برای شما مهم باشد.

مزیت دیگر Gemma 4 این است که Google benchmarkهای اندازه‌های مختلف را در یک جدول و با روش یکدست‌تر منتشر کرده است؛ بنابراین مقایسه 12B با 26B A4B یا 31B درون همین خانواده معتبرتر از کنار هم گذاشتن عددهای پراکنده چند شرکت است.

gpt-oss-20b؛ Local Reasoning با حافظه مصرفی قابل‌دسترس‌تر

OpenAI در gpt-oss دو مدل 20b و 120b را با مجوز Apache 2.0 منتشر کرده است. gpt-oss-20b حدود 21B پارامتر کل و 3.6B فعال دارد و context آن 128K است. OpenAI صراحتاً می‌گوید نسخه 20b می‌تواند با حدود 16GB حافظه اجرا شود و برای on-device، local inference و iteration سریع طراحی شده است. این مدل text-only است و داده pretraining آن عمدتاً انگلیسی گزارش شده؛ پس برای فارسی باید benchmark اختصاصی داشته باشید.

ویژگی مهم gpt-oss امکان تنظیم reasoning effort در سه سطح low، medium و high است. این موضوع هنگام benchmark بسیار مهم است: اگر عدد reasoning=high را با مدل دیگری در حالت non-thinking مقایسه کنید، نتیجه از نظر latency و تعداد token عادلانه نیست. «کیفیت بالاتر» بدون ثبت هزینه زمانی و محاسباتی، نصف اطلاعات است.

Mistral Small 4؛ Local به معنای Self-host، نه لزوماً لپ‌تاپ

Mistral Small 4 نمونه خوبی برای یک سوءبرداشت رایج است. این مدل open و self-hostable است، اما با 119B پارامتر کل و 6B پارامتر فعال، مدل رومیزی معمولی نیست. Mistral حداقل زیرساخت را چند GPU دیتاسنتری H100/H200 یا یک B200 ذکر می‌کند. در نتیجه وقتی می‌گوییم «مدل لوکال»، باید بین on-device local و enterprise self-hosted فرق بگذاریم.

Small 4، reasoning، multimodal، instruct و agentic coding را در یک مدل یکپارچه می‌کند و context آن 256K است. برای سازمانی که کنترل کامل مدل و داده می‌خواهد اما زیرساخت چندGPU دارد، این کلاس مدل قابل بررسی است؛ برای یک سرور 32GB انتخاب منطقی نیست.

بنچمارک Local AI را چگونه بخوانیم؟ کیفیت مدل با سرعت اجرا یکی نیست

عبارت «بنچمارک هوش مصنوعی» دو معنی متفاوت دارد. معنی اول، ارزیابی توانایی مدل روی مجموعه‌سؤال‌هایی مثل MMLU-Pro، GPQA، AIME، LiveCodeBench و SWE-bench است. معنی دوم، ارزیابی کارایی inference روی سخت‌افزار مشخص است: TTFT، prompt processing، generation speed، RAM/VRAM و throughput. یک مقاله دقیق باید این دو را جدا نگه دارد.

بنچمارک رسمی Qwen3.5-35B-A3B

در مدل‌کارت رسمی Qwen3.5، مدل 35B-A3B در همان جدول با مدل‌های دیگر Qwen و چند مدل مرجع ارزیابی شده است. اعداد زیر برای شناخت سطح توانایی این نسخه مفیدند:

منبع: مدل‌کارت رسمی Qwen3.5-35B-A3B. CodeForces در همان مدل‌کارت روی query set خود Qwen گزارش شده و باید با همین قید خوانده شود.

بنچمارک داخل خانواده Gemma 4؛ مقایسه‌ای تمیزتر بین اندازه‌ها

از نظر روش‌شناسی، این جدول ارزش زیادی دارد چون چند اندازه از یک خانواده توسط یک سازنده و در یک مدل‌کارت مقایسه شده‌اند. بنابراین برای فهم trade-off اندازه/کیفیت مناسب‌تر است.

نکته جالب این جدول این است که MoE 26B A4B در بسیاری از benchmarkها به 31B Dense نزدیک می‌شود، در حالی که فقط حدود 3.8B پارامتر در هر توکن فعال است. اما باز هم این موضوع به معنای نیاز حافظه یک مدل 4B نیست.

بنچمارک رسمی gpt-oss؛ reasoning level را حتماً کنار عدد بنویسید

مدل‌کارت OpenAI برای gpt-oss نتیجه‌ها را در سه reasoning level منتشر می‌کند. در حالت high، gpt-oss-20b روی AIME 2025 بدون ابزار 91.7، GPQA Diamond بدون ابزار 71.5، MMLU برابر 85.3 و SWE-bench Verified برابر 60.7 گزارش شده است. نسخه 120b در همان حالت به‌ترتیب AIME 2025 برابر 92.5، GPQA برابر 80.1، MMLU برابر 90.0 و SWE-bench Verified برابر 62.4 دارد.

چرا یک عدد بالاتر ممکن است برای شما مدل بهتری نسازد؟

فرض کنید مدل A روی GPQA پنج امتیاز از مدل B بهتر است، اما روی سرور شما TTFT آن 4 ثانیه و سرعت تولید 9 توکن بر ثانیه است؛ مدل B در 700 میلی‌ثانیه شروع می‌کند و 35 توکن بر ثانیه می‌دهد. برای دستیار فروش آنلاین، مدل B ممکن است تجربه کاربری بسیار بهتری بسازد. برعکس برای تحلیل سند غیرهم‌زمان، کیفیت می‌تواند مهم‌تر از latency باشد.

بنابراین مدل را روی یک محور رتبه‌بندی نکنید. حداقل پنج محور را کنار هم ببینید: دقت، سرعت، حافظه، پایداری در context بلند و کیفیت روی زبان/دامنه خودتان.

بنچمارک واقعی Local AI روی سخت‌افزار؛ چه چیزهایی را اندازه بگیریم؟

برای استقرار واقعی، benchmark آکادمیک فقط نصف ماجراست. نیمه دوم این است که همان فایل مدل و همان quant روی سخت‌افزار مقصد چگونه رفتار می‌کند. بهتر است هر تست را با نسخه runtime، backend، quant، context و تعداد request هم‌زمان ثبت کنید تا قابل تکرار باشد.

نمونه تست با llama-bench

llama.cpp ابزار llama-bench را برای مقایسه prompt processing و generation در اختیار می‌گذارد. یک تست ساده می‌تواند ورودی 512 توکن و تولید 128 توکن را چند بار تکرار کند. برای مقایسه معتبر، warmup و تنظیمات یکسان داشته باشید.

./llama-bench \
  -m ./model.Q4_K_M.gguf \
  -p 512 \
  -n 128 \
  -ngl 99 \
  -r 5

عدد حاصل را همراه مدل دقیق، hash یا نسخه فایل، quant، GPU/CPU، backend، context و runtime commit ذخیره کنید. نوشتن «مدل X روی RTX سریع بود» قابل بازتولید نیست.

نمونه محاسبه tokens/s در Ollama

Ollama در پاسخ API مدت‌ها و تعداد token را برمی‌گرداند. سرعت generation را می‌توان از eval_count و eval_duration محاسبه کرد:

tokens_per_second = eval_count / eval_duration * 1e9

برای workload واقعی، همین محاسبه را در چند prompt کوتاه، متوسط و بلند اجرا کنید. سپس median و P95 را جداگانه گزارش کنید. همچنین context را در تست ثابت نگه دارید؛ چون افزایش context می‌تواند حافظه و زمان prefill را به‌طور محسوس بالا ببرد.

Apple Silicon؛ unified memory چه تغییری در Local AI ایجاد می‌کند؟

روی Macهای Apple Silicon، CPU و GPU از Unified Memory استفاده می‌کنند. این مدل حافظه باعث می‌شود بخشی از محدودیت کلاسیک «VRAM جدا از RAM» از بین برود و دستگاه‌های 32GB، 64GB یا بیشتر بتوانند مدل‌های نسبتاً بزرگ را بدون کپی‌های متعدد حافظه اجرا کنند. Ollama در ۲۰۲۶ موتور MLX را برای Apple Silicon گسترش داده و بهبود TTFT، سرعت generation و مصرف حافظه را گزارش کرده است.

با این حال unified memory معجزه نیست. اگر مدل 24GB وزن دارد و context بزرگ و چند session هم‌زمان دارید، یک دستگاه 24GB عملاً حاشیه امن کافی ندارد. همیشه برای سیستم‌عامل، runtime، KV cache و اپلیکیشن‌ها headroom بگذارید.

بهترین مدل لوکال برای فارسی؛ چطور واقعاً انتخاب کنیم؟

پرسش «بهترین مدل برای فارسی چیست؟» بدون تعریف task پاسخ دقیقی ندارد. مدل مناسب یک FAQ فروشگاهی با مدل مناسب تحلیل قرارداد، کدنویسی یا تولید مقاله یکسان نیست. علاوه بر این، کیفیت فارسی فقط grammar نیست؛ مدل باید واژگان محاوره‌ای، اعداد فارسی و انگلیسی، نیم‌فاصله، تاریخ شمسی، نام برند، کلمات فینگلیش و context فرهنگی را درست بفهمد.

Qwen3.5 در مدل‌کارت رسمی پوشش 201 زبان و گویش را اعلام می‌کند و benchmarkهای multilingual گسترده دارد، بنابراین برای پروژه فارسی نقطه شروع جدی است. Gemma 4 بیش از 140 زبان را پوشش می‌دهد و برای multimodal گزینه مهمی است. gpt-oss روی STEM، coding و general knowledge بسیار قوی است، اما OpenAI داده pretraining را عمدتاً انگلیسی توصیف می‌کند؛ بنابراین نمی‌توان فقط از عدد MMLU نتیجه گرفت که برای پشتیبانی فارسی بهترین گزینه است.

یک Persian Eval کوچک اما حرفه‌ای بسازید

برای هر پروژه، 100 تا 300 نمونه واقعی جمع کنید و آن‌ها را در چند گروه جدا قرار دهید. این مجموعه داده لازم نیست عمومی باشد؛ مهم این است که workload واقعی شما را نمایندگی کند:

• فهم محاوره: «این سفارشم چرا هنوز نرسیده؟»، غلط املایی، نیم‌فاصله و فینگلیش.
• اطلاعات دقیق: قیمت، موجودی، تاریخ، شماره سفارش و شرط‌های چندبخشی.
• RAG: پاسخ فقط بر اساس سند و توانایی گفتن «در منبع نیست».
• ساختار: JSON معتبر، tool calling، schema و خروجی قابل‌پردازش.
• لحن: کوتاه، محترمانه، بدون ترجمه‌زدگی و بدون اصطلاحات نامأنوس.
• ایمنی: عدم افشای داده کاربر دیگر و مقاومت در برابر prompt injection داخل سند.

دو یا سه مدل را با prompt یکسان و دمای ثابت به‌صورت blind ارزیابی کنید. اگر ممکن است، امتیاز انسانی را با معیارهای خودکار مثل exact match برای اعداد، JSON validity و groundedness ترکیب کنید. این eval داخلی از هر leaderboard عمومی برای تصمیم production ارزشمندتر است.

Local AI + RAG؛ ترکیبی که برای سازمان‌ها مهم‌تر از «مدل بزرگ‌تر» است

مدل لوکال دانش داخلی شرکت شما را خودکار نمی‌داند. برای وصل‌کردن اسناد، قیمت‌ها، قراردادها، دیتابیس و FAQ به مدل، معمولاً از RAG یا Retrieval-Augmented Generation استفاده می‌شود. RAG قبل از پاسخ، قطعات مرتبط را از منبع شما بازیابی می‌کند و همراه سؤال به مدل می‌دهد.

برای درک معماری مدل‌های زبانی، مقاله مدل‌های زبانی بزرگ چطور کار می‌کنند؟ پایه خوبی است. اگر پروژه شما قرار است ابزار اجرا کند و فقط جواب متنی ندهد، راهنمای AI Agent و مقاله MCP چیست؟ را هم ببینید.

در معماری Local RAG می‌توانید همه اجزا را خصوصی نگه دارید: parser، embedding، vector database، reranker و LLM. اما کیفیت نهایی به chunking، metadata، retrieval و سیاست پاسخ وابسته است. یک LLM 30B با retrieval ضعیف می‌تواند از یک مدل 8B با RAG تمیز بدتر باشد.

سه معماری واقعی برای پیاده‌سازی Local AI

معماری ۱: دستیار شخصی روی لپ‌تاپ

ساده‌ترین حالت، یک runtime مثل Ollama یا LM Studio، یک مدل 4B تا 12B quantized و رابط چت محلی است. این معماری برای خلاصه‌سازی فایل، پرسش از متن، کدنویسی سبک و آزمایش prompt مناسب است. مزیتش سادگی و حریم خصوصی بالاست؛ محدودیتش قدرت سخت‌افزار و نبود سرویس چندکاربره است.

معماری ۲: API داخلی روی یک سرور

در شرکت کوچک یا متوسط، مدل روی یک سرور GPU یا Apple Silicon/CPU قدرتمند اجرا می‌شود و اپلیکیشن‌ها از طریق API خصوصی به آن وصل می‌شوند. در این حالت باید reverse proxy، TLS، authentication، rate limit، queue و metrics داشته باشید. پورت خام runtime را مستقیم روی اینترنت باز نکنید.

معماری ۳: Local RAG/Agent سازمانی

در معماری پیشرفته، LLM فقط یک جزء است. ingestion اسناد، embedding، vector database، reranker، policy engine، tool gateway، audit log و human-in-the-loop اضافه می‌شوند. اگر ایجنت به CRM، دیتابیس یا عملیات مالی دسترسی دارد، کنترل دسترسی باید در سطح ابزار اجرا شود؛ صرفاً نوشتن «این کار را نکن» در system prompt امنیت محسوب نمی‌شود.

برای درک بهتر اتصال مدل به ابزارها، مقاله MCP چیست؟ و برای معماری agent مقاله ایجنت هوش مصنوعی چیست؟ در فیلتوری مکمل این راهنما هستند.

هوش مصنوعی لوکال یا ابری؟ مقایسه واقعی

برای خیلی از تیم‌ها جواب «یکی از این دو» نیست؛ Hybrid است. درخواست‌های حساس و پرتکرار روی مدل لوکال می‌مانند، کارهای پیچیده یا کم‌تکرار به مدل ابری قوی‌تر می‌روند. Router می‌تواند بر اساس نوع سؤال، سطح محرمانگی یا latency تصمیم بگیرد.

امنیت Local AI؛ مزیت ذاتی یا مسئولیت اضافه؟

لوکال بودن سطح کنترل را بالا می‌برد، ولی مسئولیت را هم به خودتان منتقل می‌کند. اگر API مدل بدون احراز هویت روی اینترنت باز باشد، یا فایل‌های RAG بدون کنترل دسترسی در یک vector database مشترک قرار گیرند، «لوکال» بودن به‌تنهایی امنیت ایجاد نمی‌کند.

• API مدل را مستقیم روی اینترنت expose نکنید؛ reverse proxy، TLS و authentication داشته باشید.
• برای RAG مجوز دسترسی سند را قبل از retrieval اعمال کنید.
• پرامپت و خروجی را با داده حساس لاگ نکنید مگر سیاست نگهداری مشخص باشد.
• Prompt injection از داخل سند را جدی بگیرید؛ سند منبع دستور سیستمی نیست.
• مدل و runtime را pin کنید و به‌روزرسانی را مثل هر dependency production مدیریت کنید.
• برای Agent، ابزارها را با حداقل دسترسی و allowlist ارائه دهید.

هزینه Local AI را چطور حساب کنیم؟

مقایسه فقط بر اساس قیمت GPU اشتباه است. هزینه واقعی شامل سخت‌افزار یا اجاره سرور، برق، نگهداری، مانیتورینگ، زمان مهندسی، storage مدل‌ها، redundancy و ظرفیت peak است. در طرف مقابل، سرویس ابری هزینه توکن، نرخ درخواست، ابزار و گاهی retrieval را دارد.

برای تصمیم اقتصادی، هزینه ماهانه را بر تعداد «وظیفه موفق» تقسیم کنید، نه صرفاً توکن. اگر مدل لوکال ارزان است ولی 20 درصد پاسخ‌ها نیاز به اصلاح انسانی دارند، صرفه اقتصادی ظاهری از بین می‌رود.

چطور مدل لوکال مناسب را انتخاب کنیم؟

1. وظیفه را تعریف کنید: چت، کد، RAG، vision، استخراج، tool calling یا reasoning؟
2. محدودیت سخت‌افزار را مشخص کنید: RAM/VRAM و تعداد کاربر هم‌زمان.
3. مدل‌های هم‌رده را انتخاب کنید: مثلاً سه مدل در بازه 8B تا 14B، نه 4B در برابر 70B.
4. یک quant مشترک بگیرید: مثلاً Q4_K_M برای مقایسه اولیه.
5. تست واقعی فارسی بسازید: حداقل 50 نمونه از workload خودتان.
6. کیفیت و latency را هم‌زمان بسنجید: مدل کندِ کمی بهتر شاید برای چت مناسب نباشد.
7. هزینه عملیاتی را اضافه کنید: مانیتورینگ، failover، نگهداری و به‌روزرسانی.
8. اول pilot، بعد scale: قبل از خرید سخت‌افزار بزرگ، بار واقعی را اندازه بگیرید.

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

جدول زیر نسخه خرید نیست؛ یک نقطه شروع برای shortlist است. قبل از نهایی‌کردن، فایل quant واقعی، context هدف و workload خودتان را تست کنید.

۱۰ اشتباه رایج در راه‌اندازی هوش مصنوعی لوکال

1. انتخاب مدل فقط بر اساس تعداد پارامتر.
2. نادیده‌گرفتن context و KV cache در محاسبه حافظه.
3. استفاده از benchmark سازنده به‌عنوان تضمین کیفیت فارسی.
4. اجرای مدل reasoning برای هر سؤال ساده.
5. باز کردن پورت Ollama/llama-server مستقیم روی اینترنت.
6. ذخیره همه اسناد RAG بدون ACL و تفکیک کاربر.
7. افزایش context به حداکثر فقط چون مدل پشتیبانی می‌کند.
8. مقایسه مدل‌ها با quant و runtime متفاوت.
9. اندازه‌گیری tokens/s و فراموش‌کردن TTFT و end-to-end latency.
10. خرید GPU قبل از pilot و ثبت telemetry واقعی.

Local AI برای SEO، GEO و AEO چه کاربردی دارد؟

Local AI فقط ابزار چت نیست. می‌تواند برای دسته‌بندی هزاران URL، استخراج entity، ساخت خلاصه کنترل‌شده، تحلیل query و لاگ جست‌وجو، پیشنهاد internal link، بررسی schema، تولید draft و ساخت موتور پاسخ داخلی استفاده شود. مزیت مهم این است که style guide، محتوای منتشرنشده یا داده Search Console/exportهای داخلی می‌توانند داخل زیرساخت کنترل‌شده باقی بمانند.

اما اجرای لوکال کیفیت یا رتبه را تضمین نمی‌کند. برای انتشار نهایی باید منبع، fact-check، تجربه انسانی، intent و ساختار محتوا حفظ شوند. اگر هدف شما دیده‌شدن در موتورهای مولد است، مقاله GEO چیست؟ و مقاله آیا GEO جای SEO را می‌گیرد؟ مکمل این بحث‌اند.

مزیت مهم Local AI برای تیم محتوا این است که می‌توانید pipeline را روی اسناد و style guide خود اجرا کنید، بدون اینکه هر فایل داخلی را به API عمومی ارسال کنید. مزیت دوم، reproducibility است: نسخه مدل، prompt و داده قابل pin شدن‌اند و خروجی‌ها قابل audit می‌شوند.

آینده Local AI در ۲۰۲۶ و بعد از آن: Intelligence per Watt مهم‌تر می‌شود

روند بازار روشن است: مدل‌های کوچک‌تر و MoE در حال گرفتن توانایی‌هایی هستند که قبلاً به مدل‌های بسیار بزرگ نیاز داشت. quantization از Q4های عمومی به فرمت‌های model-optimized پیش می‌رود، context طولانی‌تر می‌شود و runtimeها بهره‌وری بیشتری از GPU و unified memory می‌گیرند. Ollama در ۲۰۲۶ به‌طور مشخص روی MLX برای Apple Silicon، GGUF/llama.cpp و فرمت‌های 4-bit جدید سرمایه‌گذاری کرده است.

معیار مهم آینده فقط «چند امتیاز benchmark» نیست؛ intelligence per watt، latency، هزینه هر task موفق و امکان اجرای agent طولانی‌مدت روی سخت‌افزار شخصی اهمیت بیشتری پیدا می‌کند. این همان نقطه‌ای است که Local AI از یک سرگرمی فنی به زیرساخت محصول تبدیل می‌شود.

اما آینده احتمالاً «همه‌چیز لوکال» نیست. معماری‌های hybrid رشد می‌کنند: مدل کوچک و سریع نزدیک کاربر، مدل تخصصی داخل سازمان، و مدل ابری قوی برای موارد خاص. هنر مهندسی در سال‌های بعد بیشتر از انتخاب یک مدل، در routing، retrieval، ابزار، ارزیابی و کنترل خواهد بود.

پرسش‌های متداول درباره هوش مصنوعی لوکال

جمع‌بندی: Local AI یک مدل نیست؛ یک تصمیم معماری است

اگر بخواهیم تمام مقاله را در یک جمله خلاصه کنیم: هوش مصنوعی لوکال یعنی آوردن توان پردازش مدل به نزدیک داده و زیر کنترل خودتان. ارزش آن نه از «آفلاین بودن» به‌تنهایی، بلکه از ترکیب درست مدل، runtime، quantization، RAG، امنیت، سخت‌افزار و ارزیابی حاصل می‌شود.

برای پروژه کوچک، یک مدل 4B تا 8B جدید و خوب می‌تواند کاملاً کافی باشد. برای RAG سازمانی، 12B تا کلاس 20–30B همراه retrieval دقیق اغلب نقطه تعادل جذابی است. برای reasoning و agentic workload، gpt-oss-20b، Qwen3.5 یا مدل‌های هم‌رده ارزش تست دارند؛ و برای multimodal، Gemma 4 انتخاب مهمی است. هیچ‌کدام بدون benchmark واقعی روی داده و سخت‌افزار شما جواب نهایی نیستند.

منابع اصلی و روش بازبینی داده‌ها

مشخصات و benchmarkهای این مقاله در ۱۷ سپتامبر ۲۰۲۶ بازبینی شده‌اند. برای جلوگیری از مقایسه گمراه‌کننده، اعداد هر خانواده با نام منبع و شرایط گزارش شده‌اند و از ساختن «رتبه نهایی» از benchmarkهایی با پروتکل متفاوت خودداری شده است.

1. Qwen3.5-35B-A3B — مدل‌کارت رسمی، معماری، context، زبان‌ها و benchmarkها
2. Google Gemma 4 Model Card — معماری E2B/E4B/12B/26B A4B/31B و benchmark رسمی
3. OpenAI — معرفی gpt-oss، پارامتر فعال، context و نیاز حافظه
4. OpenAI gpt-oss Model Card — روش ارزیابی و نتایج رسمی
5. Mistral Small 4 — معماری، context، reasoning effort و سخت‌افزار self-host
6. llama.cpp Quantization — تعریف quantization و فرمت‌های GGUF
7. llama-bench — ابزار benchmark inference
8. Ollama + MLX on Apple Silicon — تغییرات performance سال ۲۰۲۶
9. Ollama 0.30 + GGUF/llama.cpp — GPU و Vulkan performance
10. راهنمای RAG در فیلتوری — معماری retrieval برای پروژه‌های خصوصی
11. مدل‌های زبانی بزرگ چطور کار می‌کنند؟ — فیلتوری