تا اینجا تقریباً تمام مثال‌های ما یک فرض مشترک داشتند:
یعنی مدل هوش مصنوعی روی سرور شرکت دیگری اجرا می‌شود و ما از طریق API با آن ارتباط داریم.
این روش ساده، قدرتمند و برای بسیاری از پروژه‌ها کاملاً منطقی است.
اما تنها گزینه نیست.
می‌توان مدل را مستقیماً روی:
- Laptop
- Desktop
- Workstation
- Private Server
- On-premise Infrastructure
اجرا کرد.
به این رویکرد معمولاً Local AI یا Local LLM گفته می‌شود.
Local AI چیست؟
Local AI یعنی مدل هوش مصنوعی روی زیرساختی اجرا شود که تحت کنترل خودمان است.
مثلاً:
در این معماری برای هر Request الزاماً نیازی نیست اطلاعات به یک Cloud Provider ارسال شوند.
مدل می‌تواند روی همان سیستم کاربر اجرا شود.
یا روی یک Server داخل شبکه شرکت:
تفاوت Local AI و Cloud AI
در Cloud:
در Local:
تفاوت فقط محل اجرای مدل نیست.
این تصمیم روی موارد زیادی اثر می‌گذارد:
- Privacy
- Cost
- Latency
- Performance
- Maintenance
- Security
- Scalability
- Model Choice
- Infrastructure
چرا اصلاً Local AI؟
دلایل مختلفی وجود دارد.
یکی از مهم‌ترین آن‌ها Privacy است.
فرض کنید اطلاعات شما شامل:
- Source Code
- Internal Documents
- Customer Data
- Contracts
- Medical Records
- Financial Data
باشد.
ممکن است سازمان نخواهد این داده‌ها از شبکه خودش خارج شوند.
در این حالت Local AI می‌تواند جذاب باشد.
Privacy در Local AI
معماری Cloud:
معماری Local:
در حالت دوم می‌توان داده را داخل همان محیط نگه داشت.
البته Local بودن به صورت جادویی Security ایجاد نمی‌کند.
اگر Server شما:
- بد پیکربندی شده
- بدون Authentication
- بدون Encryption
- متصل به شبکه ناامن
باشد، Local AI فقط یک مشکل امنیتی محلی بسیار پیشرفته ساخته است.
آیا Local AI کاملاً Offline است؟
می‌تواند باشد.
مثلاً:
- Laptop
- +
- Downloaded Model
- +
- Local Runtime
در این حالت بعد از دانلود Model ممکن است Inference بدون Internet انجام شود.
این موضوع برای محیط‌هایی مثل:
- Secure Networks
- Remote Locations
- Offline Applications
- Industrial Systems
مهم است.
Inference چیست؟
وقتی از مدل برای تولید پاسخ استفاده می‌کنیم، این مرحله Inference نام دارد.
مثلاً:
این با Training متفاوت است.
Training یعنی وزن‌های مدل را آموزش دهیم یا تغییر دهیم.
Inference یعنی مدل از قبل آموزش‌دیده را اجرا کنیم.
بیشتر پروژه‌های Local AI در ابتدا فقط نیاز به Inference دارند.
اجرای مدل Local چه شکلی است؟
مثلاً Application می‌تواند به یک Server محلی متصل شود:
این Server می‌تواند API محلی ارائه دهد:
POST /chat
از دید Application تفاوت زیادی با Cloud API وجود ندارد.
مثلاً:
response = client.chat(
model="local-model",
messages=messages
)
فقط مدل روی Hardware خودمان اجرا می‌شود.
ابزارهای اجرای Local LLM
چند نوع ابزار رایج برای اجرای مدل‌های Local وجود دارند.
برای مثال:
- Ollama
- llama.cpp
- LM Studio
- vLLM
- Transformers
هرکدام کاربرد متفاوتی دارند.
بعضی برای Desktop ساده‌تر هستند.
بعضی برای Server و Throughput بالا مناسب‌ترند.
بعضی کنترل بسیار بیشتری روی Runtime ارائه می‌کنند.
Ollama
Ollama یکی از روش‌های ساده برای اجرای مدل‌های Local است.
معمولاً می‌توان مدلی را اجرا کرد و یک API محلی داشت.
ساختار کلی:
این مدل برای Prototype و Development بسیار ساده‌تر از ساخت Runtime از صفر است.
llama.cpp
llama.cpp یکی از پروژه‌های مهم برای اجرای مدل‌های زبانی روی Hardware معمولی است.
هدف اصلی آن اجرای Efficient مدل‌ها روی:
- CPU
- GPU
- Apple Silicon
- Various Hardware
است.
یکی از دلایل محبوبیت این نوع Runtimeها پشتیبانی از مدل‌های Quantized است.
بعداً به Quantization می‌رسیم.
Local Model Server
در Production ممکن است بخواهیم Model را روی Server اختصاصی اجرا کنیم.
معماری:
در این حالت چند Application می‌توانند از یک Model Server استفاده کنند.
GPU چه نقشی دارد؟
مدل‌های زبانی محاسبات زیادی انجام می‌دهند.
GPU برای انجام Parallel Computation بسیار مناسب است.
در نتیجه اجرای مدل روی GPU معمولاً بسیار سریع‌تر از CPU است.
معماری:
اما GPU فقط یک مشخصه مهم ندارد.
یکی از مهم‌ترین محدودیت‌ها:
VRAM
است.
VRAM چیست؟
VRAM حافظه‌ای است که GPU برای نگهداری داده‌های موردنیاز پردازش استفاده می‌کند.
برای LLMها معمولاً باید بخش زیادی از:
- Model Weights
- KV Cache
- Intermediate Data
در حافظه GPU قرار گیرد.
اگر Model بزرگ‌تر از VRAM باشد، ممکن است:
- بخشی روی RAM قرار گیرد
- بخشی روی GPU قرار گیرد
- یا اصلاً اجرا نشود
بسته به Runtime.
اندازه Model یعنی چه؟
احتمالاً نام‌هایی شبیه این دیده‌اید:
- 3B
- 7B
- 8B
- 14B
- 32B
- 70B
حرف B یعنی Billion Parameters.
مثلاً:
- 7B
- ≈
- 7 billion parameters
به طور کلی Model بزرگ‌تر:
- حافظه بیشتر
- Compute بیشتر
- Latency بیشتر
نیاز دارد.
البته بزرگ‌تر بودن همیشه به معنی مناسب‌تر بودن نیست.
چرا Model Size مهم است؟
فرض کنید یک Model با 70 میلیارد Parameter داریم.
اگر هر Parameter چند Byte حافظه مصرف کند، حجم Model بسیار بزرگ می‌شود.
در مقابل Model کوچک‌تر ممکن است روی Laptop اجرا شود.
بنابراین انتخاب Model باید براساس:
- Task
- Hardware
- Latency
- Quality
- Cost
انجام شود.
نه صرفاً:
بزرگ‌ترین Model موجود
چون Benchmark داشتن Model عظیم روی سیستمی که هر Token را با سرعت حرکت قاره‌ها تولید می‌کند، افتخار معماری محسوب نمی‌شود.
Quantization چیست؟
یکی از تکنیک‌های مهم Local AI Quantization است.
ایده اصلی این است که وزن‌های Model را با Precision پایین‌تری ذخیره کنیم.
مثلاً:
در نتیجه Model حافظه کمتری مصرف می‌کند.
مثال ساده Quantization
فرض کنیم Model در Precision اصلی:
14 GB
حافظه نیاز دارد.
نسخه Quantized ممکن است مثلاً:
8 GB
یا کمتر مصرف کند.
عدد دقیق بسته به Model و Quantization Format متفاوت است.
هدف اصلی:
Memory Usage ↓
است.
هزینه Quantization چیست؟
کاهش Precision رایگان نیست.
ممکن است:
- Quality کمی کاهش پیدا کند
- Accuracy بعضی Taskها افت کند
- Behavior تغییر کند
اما در بسیاری از کاربردها کاهش کیفیت نسبت به کاهش Hardware Requirement قابل قبول است.
به همین دلیل Quantization یکی از کلیدی‌ترین فناوری‌های Local LLM است.
CPU یا GPU؟
آیا بدون GPU می‌توان Local LLM اجرا کرد؟
بله.
بعضی Modelها روی CPU نیز اجرا می‌شوند.
اما معمولاً:
است.
GPU:
ولی هزینه Hardware بالاتری دارد.
RAM چه نقشی دارد؟
اگر Model یا بخشی از آن روی CPU اجرا شود، RAM مهم می‌شود.
همچنین Runtime ممکن است بخشی از داده را در RAM نگه دارد.
برای اجرای Local Model باید این سه مورد را جدا بررسی کنیم:
- Disk
- RAM
- VRAM
Disk برای ذخیره Model.
RAM برای Runtime و CPU Memory.
VRAM برای GPU.
Apple Silicon
سیستم‌های جدید Apple معماری Unified Memory دارند.
یعنی CPU و GPU می‌توانند به Memory مشترک دسترسی داشته باشند.
این موضوع باعث شده بعضی Macها برای اجرای Local LLMهای متوسط گزینه جذابی باشند.
ولی باز هم:
- Memory Capacity
- Model Size
- Quantization
- Context Length
تعیین‌کننده هستند.
Context Window چه تأثیری دارد؟
فقط Model Weight حافظه مصرف نمی‌کند.
وقتی Context بزرگ‌تر می‌شود، Memory Usage نیز افزایش پیدا می‌کند.
مثلاً:
4K Context
معمولاً سبک‌تر از:
64K Context
است.
بنابراین این تصور که:
- Model روی GPU جا شد
- پس همه چیز تمام است
دقیق نیست.
Context، Batch Size و Concurrent Users نیز مهم‌اند.
KV Cache چیست؟
هنگام Generation، مدل بخشی از محاسبات Tokenهای قبلی را نگه می‌دارد.
این داده معمولاً در چیزی به نام:
KV Cache
ذخیره می‌شود.
Context بزرگ‌تر:
KV Cache بزرگ‌تر
ایجاد می‌کند.
و در نتیجه Memory بیشتری مصرف می‌شود.
سرعت Local Model را چگونه اندازه بگیریم؟
یکی از Metricهای رایج:
Tokens per Second
یا:
tokens/s
است.
مثلاً:
- 5 tokens/s
- 20 tokens/s
- 80 tokens/s
هرچه بیشتر باشد، Generation سریع‌تر است.
اما سرعت تنها Metric مهم نیست.
Time To First Token
Metric مهم دیگر:
TTFT
یا:
Time To First Token
است.
یعنی از لحظه ارسال Request تا زمانی که اولین Token دریافت می‌شود.
برای Chatbot این Metric بسیار مهم است.
User معمولاً منتظر اولین نشانه حیات از سیستم است.
Local AI و Latency
Local AI می‌تواند مزیت Latency داشته باشد چون Request به Cloud نمی‌رود.
معماری:
اما اگر Hardware ضعیف باشد، Local Model ممکن است بسیار کندتر از Cloud باشد.
پس:
- Local
- ≠
- Automatically Faster
Cloud AI چگونه کار می‌کند؟
در Cloud Provider معمولاً زیرساخت قدرتمندی دارد.
مثلاً:
- High-end GPUs
- Model Serving
- Load Balancing
- Batching
- Caching
- Distributed Infrastructure
شما فقط API را می‌بینید.
این سادگی ارزش زیادی دارد.
مزایای Cloud AI
Cloud معمولاً مزایایی مثل این دارد:
- No GPU Management
- Fast Setup
- Scalability
- Powerful Models
- Managed Infrastructure
- Easy Updates
می‌توانید در چند دقیقه Application بسازید.
در Local، آن چند دقیقه گاهی تبدیل به یک عصر کامل با Driver و Memory Error می‌شود. فناوری باید سرگرمی داشته باشد.
معایب Cloud AI
در مقابل:
- Data leaves your infrastructure
- Recurring API Cost
- Internet dependency
- Provider dependency
- Rate limits
- Less infrastructure control
وجود دارد.
مزایای Local AI
Local AI مزایای مهمی دارد:
- Data Control
- Offline Usage
- No Per-token API Fee
- Model Customization
- Infrastructure Control
- Predictable Environment
برای بعضی سازمان‌ها Privacy مهم‌ترین دلیل است.
معایب Local AI
اما هزینه‌ها و پیچیدگی‌های خودش را دارد:
- GPU Cost
- Power Consumption
- Maintenance
- Updates
- Model Serving
- Monitoring
- Scaling
- Security
- Cooling
- Infrastructure
یعنی API Bill حذف می‌شود، اما قبض برق و مسئولیت DevOps با لبخند وارد می‌شوند.
مقایسه هزینه Cloud و Local
تصمیم هزینه ساده نیست.
Cloud معمولاً چیزی شبیه:
Cost
=
Requests
×
Tokens
×
Provider Price
دارد.
Local:
Cost
=
Hardware
+
Electricity
+
Maintenance
+
Engineering
+
Infrastructure
در Usage کم، Cloud معمولاً بسیار منطقی است.
در Usage زیاد و پایدار، Local ممکن است از نظر اقتصادی جذاب‌تر شود.
مثال ساده
فرض کنید یک تیم کوچک روزانه چند صد Request دارد.
خرید GPU قدرتمند فقط برای این Usage احتمالاً منطقی نیست.
Cloud:
Low Initial Cost
دارد.
اما اگر یک شرکت میلیون‌ها Request داخلی داشته باشد:
Recurring API Cost
ممکن است بسیار بزرگ شود.
آن زمان Local یا Hybrid ارزش بررسی دارد.
Local AI برای Privacy
یکی از مهم‌ترین Use Caseها:
- Enterprise Knowledge
- Legal Documents
- Source Code
- Healthcare
- Finance
- Government
است.
سیستم می‌تواند کاملاً داخل Private Network اجرا شود.
مثلاً:
در این حالت کل RAG Pipeline می‌تواند Local باشد.
Local RAG
قبلاً RAG را این‌طور داشتیم:
نسخه Local می‌تواند باشد:
یعنی هیچ بخش اصلی Pipeline الزاماً نیاز به Cloud ندارد.
Architecture کاملاً Local
مثلاً:
این معماری برای بعضی سیستم‌های Enterprise جذاب است.
Vector Database هم می‌تواند Local باشد
مثلاً:
PostgreSQL + pgvector
روی همان Infrastructure اجرا شود.
در این حالت:
- Documents
- Embeddings
- Model
- Logs
همگی تحت کنترل سازمان هستند.
Function Calling با Local Model
Local بودن مانع Tool Calling نمی‌شود.
اگر Model از Structured Tool Selection خوب پشتیبانی کند، معماری همان است:
بنابراین Agent نیز می‌تواند Local باشد.
Local AI Agent
مثلاً:
برای محیط‌هایی که Data Isolation اهمیت زیادی دارد، این معماری ارزشمند است.
Training Local با Running Local فرق دارد
یکی از اشتباه‌های رایج این است که:
Running Local Model
را با:
Training Local Model
یکسان بدانیم.
Inference یک Model Quantized ممکن است روی سیستم شخصی ممکن باشد.
اما Training یک Model بزرگ ممکن است به Hardware بسیار بیشتری نیاز داشته باشد.
Fine-tuning Local
Fine-tuning سبک‌تر از Training از صفر است، ولی همچنان می‌تواند Hardware زیادی بخواهد.
تکنیک‌هایی مثل:
- LoRA
- QLoRA
برای کاهش Resource موردنیاز Fine-tuning استفاده می‌شوند.
اما برای بسیاری از پروژه‌ها قبل از Fine-tuning باید بررسی کنیم آیا:
- Prompt
- RAG
- Tools
مسئله را حل می‌کنند یا نه.
انتخاب Model برای Local AI
به جای انتخاب براساس شهرت Model، باید آن را روی Task واقعی تست کنیم.
معیارها:
- Quality
- Model Size
- Memory Usage
- Tokens/sec
- Context Length
- Language Support
- Tool Calling
- License
برای سایت یا Application فارسی، کیفیت فارسی نیز باید جدا Evaluate شود.
License مهم است
همه Modelهای قابل دانلود شرایط استفاده یکسان ندارند.
قبل از استفاده Commercial باید License بررسی شود.
مواردی مثل:
- Commercial Use
- Redistribution
- Fine-tuning
- Hosting
- Derivative Models
ممکن است محدودیت داشته باشند.
دانلود شدن Model به معنی «هر کاری خواستم می‌کنم» نیست. قانون همچنان آن موجود سمج قدیمی است.
Benchmark عمومی کافی نیست
ممکن است Model در Benchmark عالی باشد.
اما در Task شما ضعیف باشد.
مثلاً پروژه شما:
Persian Support Chat
است.
Benchmark انگلیسی Coding به تنهایی اطلاعات زیادی به شما نمی‌دهد.
باید Evaluation Dataset داخلی بسازید.
Benchmark محلی
مثلاً 100 سؤال واقعی:
- Question
- Expected Answer
- Expected Source
بعد Modelهای مختلف را Compare کنید.
Metricها:
- Accuracy
- Faithfulness
- Latency
- Tokens/sec
- Memory
Local AI در Development
یکی از کاربردهای خوب Local AI توسعه نرم‌افزار است.
مثلاً:
- Code Assistant
- Commit Summary
- Documentation
- Local Search
- Test Generation
بدون ارسال Source Code به Cloud.
برای تیم‌هایی که Source Code حساس دارند، این مزیت مهم است.
Offline Coding Assistant
معماری:
می‌تواند بدون Internet کار کند.
البته کیفیت Model و Hardware همچنان تعیین‌کننده است.
Local AI برای Documents
مثلاً:
- Markdown
- Internal Wiki
- Source Code
را Index کنیم.
سپس:
Local RAG
روی آن‌ها اجرا کنیم.
این یکی از عملی‌ترین Use Caseهای Local AI است.
آیا Local Model اطلاعات جدید دارد؟
Model Local همان دانش Training خودش را دارد.
اگر اطلاعات جدید لازم است:
- RAG
- API
- Tools
همچنان لازم هستند.
Local بودن مشکل Freshness را حل نمی‌کند.
مدل روی Laptop شما هم نمی‌تواند آینده را از فن GPU استنتاج کند.
Updating Local Models
در Cloud Provider مدل را Update می‌کند.
در Local شما باید:
- Download New Model
- Test
- Benchmark
- Deploy
- Rollback
را مدیریت کنید.
این Control مزیت است.
اما مسئولیت هم هست.
Versioning
بهتر است Model Version مشخص باشد:
- model-v1
- model-v2
و در Log ثبت شود.
اگر کیفیت بعد از Upgrade افت کرد، باید بتوانیم Version قبلی را Deploy کنیم.
Monitoring Local AI
Local بودن به معنی عدم نیاز به Monitoring نیست.
باید موارد زیر را ببینیم:
- GPU Utilization
- VRAM Usage
- RAM
- Latency
- Tokens/sec
- Queue Length
- Errors
- Temperature
- Cost
بله، Temperature واقعاً می‌تواند Production Metric باشد. ماشین‌ها بالاخره راه خودشان را برای درخواست مرخصی پیدا کرده‌اند.
Concurrent Users
یک Laptop ممکن است برای یک User عالی باشد.
اما برای:
100 simultaneous users
داستان متفاوت است.
Inference Server باید:
- Batching
- Queueing
- Concurrency
- Memory
را مدیریت کند.
Scaling Local AI
Scaling ممکن است شامل:
- More GPUs
- More Servers
- Load Balancing
- Model Replicas
باشد.
معماری:
حالا Local AI کم‌کم شبیه Cloud کوچک شخصی شما می‌شود.
بشر همیشه در نهایت Cloud خودش را از نو می‌سازد.
Hybrid AI چیست؟
لازم نیست بین Local و Cloud یکی را مطلق انتخاب کنیم.
می‌توان Hybrid Architecture داشت.
مثلاً:
یا:
Example Hybrid Routing
Request
↓
Router
↓
┌───────────────────┐
│ │
Local Model Cloud Model
│ │
Private / Cheap Complex
│ │
└─────────┬─────────┘
↓
Response
این معماری می‌تواند Privacy و Quality را ترکیب کند.
Local-first Architecture
می‌توان ابتدا Local Model را امتحان کرد.
اگر Confidence یا Quality کافی نبود:
البته تصمیم Fallback باید با Policyهای Privacy هماهنگ باشد.
نباید اطلاعات حساس را بعد از Failure ناگهان به Cloud ارسال کنیم.
Data Classification
در Hybrid System بهتر است Data Classification داشته باشیم.
مثلاً:
- Public
- Internal
- Confidential
- Restricted
و Policy مشخص کند:
- Public → Cloud allowed
- Internal → Cloud maybe
- Confidential → Local only
- Restricted → Local isolated
این تصمیم باید Backend enforce کند.
Cost Control در Local AI
هرچند Per-token Fee نداریم، Cost همچنان وجود دارد.
مثلاً:
- Electricity
- Hardware Depreciation
- GPU Idle Time
- Maintenance
بنابراین باید:
- GPU Utilization
- Requests
- Cost per Task
را اندازه بگیریم.
GPU Idle Cost
فرض کنید GPU گران‌قیمت 90٪ زمان Idle باشد.
در این حالت شاید Cloud اقتصادی‌تر باشد.
Local زمانی جذاب‌تر می‌شود که Hardware واقعاً استفاده شود.
Cloud vs Local
یک مقایسه ساده:
| ویژگی | Local AI | Cloud AI |
|---|---|---|
| Privacy | کنترل بیشتر | وابسته به Provider |
| Setup | سخت‌تر | ساده‌تر |
| هزینه اولیه | بالاتر | پایین‌تر |
| هزینه مصرف | بدون Fee مستقیم Token | Pay per Usage |
| Scalability | نیازمند Infrastructure | معمولاً ساده‌تر |
| Offline | ممکن | معمولاً نه |
| Model Control | زیاد | محدودتر |
| Maintenance | با شما | با Provider |
| مدل‌های بسیار قدرتمند | محدود به Hardware | معمولاً در دسترس |
| Latency شبکه | کم | وابسته به Internet |
| Hardware Management | لازم | لازم نیست |
چه زمانی Local AI انتخاب خوبی است؟
Local معمولاً زمانی جذاب است که:
- Privacy اهمیت زیادی دارد
- Internet محدود است
- Offline نیاز داریم
- Data نباید خارج شود
- Usage بالا و پایدار است
- Model خاصی می‌خواهیم
- Infrastructure Control مهم است
چه زمانی Cloud منطقی‌تر است؟
Cloud معمولاً زمانی مناسب‌تر است که:
- سریع می‌خواهیم MVP بسازیم
- Usage پایین یا متغیر است
- مدل‌های بسیار قوی لازم داریم
- GPU نمی‌خواهیم مدیریت کنیم
- Scaling مهم است
- تیم Infrastructure کوچک است
چه زمانی Hybrid انتخاب خوبی است؟
Hybrid وقتی جذاب است که نیازها ترکیبی باشند.
مثلاً:
- Internal Documents → Local
- General Reasoning → Cloud
یا:
- Cheap Classification → Local
- Complex Analysis → Cloud
امنیت Local AI
حتی اگر Model Local باشد، همچنان باید:
- Authentication
- Authorization
- Encryption
- Network Security
- Logging
- Secrets Management
داشته باشیم.
همچنین Model Server نباید بدون Authentication در شبکه باز باشد.
Model Files هم Supply Chain هستند
Modelی که دانلود می‌کنیم نیز یک Dependency است.
باید به مواردی مثل:
- Source
- Integrity
- License
- Version
- Runtime Security
توجه کنیم.
همان‌طور که Package ناشناس را روی Production نصب نمی‌کنیم، Model ناشناس هم باید با احتیاط بررسی شود.
Local AI و Production
برای Production معماری می‌تواند چیزی شبیه این باشد:
در کنار آن:
- Monitoring
- Logging
- Model Versioning
- Health Checks
- Fallback
- Queue
وجود دارد.
Health Check
Inference Server باید Health Endpoint داشته باشد.
مثلاً:
GET /health
و بررسی کند:
- Model loaded?
- GPU available?
- Memory healthy?
اگر Server سالم نبود، Load Balancer نباید Request برای آن بفرستد.
Warm-up
Model Loading ممکن است زمان‌بر باشد.
در بعضی سیستم‌ها هنگام Startup Model را Load می‌کنیم:
تا اولین User مجبور نباشد هزینه Startup را تحمل کند.
Queue در Local Inference
اگر GPU ظرفیت محدودی دارد، بهتر است Requestها Queue شوند.
به جای اینکه همه Requestها همزمان Memory را مصرف کنند و GPU در اعتراض خاموش شود.
Local AI روی سیستم شخصی
برای استفاده شخصی ساده‌ترین معماری:
است.
برای کارهای روزانه مثل:
- Summarization
- Writing
- Coding
- Local Documents
- Brainstorming
می‌تواند مناسب باشد.
یک MVP ساده
برای شروع لازم نیست Infrastructure پیچیده بسازیم.
می‌توانیم:
- Local Runtime
- +
- Small Quantized Model
- +
- Simple API
داشته باشیم.
سپس اندازه‌گیری کنیم:
- Quality
- Latency
- Memory
بعد تصمیم بگیریم آیا Model بزرگ‌تر لازم است.
مسیر منطقی انتخاب Model
یک Strategy خوب:
Small Model
↓
Test
↓
Enough Quality?
├── Yes → Keep
└── No → Larger Model
نه:
با اینکه مسیر دوم ظاهراً بین توسعه‌دهندگان محبوبیت تاریخی دارد.
Benchmark Hardware
قبل از خرید Hardware بهتر است Model موردنظر را روی Hardware مشابه Benchmark کنیم.
معیارها:
- VRAM
- Tokens/sec
- TTFT
- Power
- Concurrent Users
- Context Size
فقط نام GPU کافی نیست.
آیا Local AI آینده همه پروژه‌هاست؟
احتمالاً نه به شکل مطلق.
Cloud مزایای جدی دارد.
Local هم مزایای جدی دارد.
احتمالاً بسیاری از معماری‌ها Hybrid خواهند بود.
مثلاً:
- On-device Models
- +
- Private Server Models
- +
- Cloud Models
هر Task به مناسب‌ترین Model Route می‌شود.
مهم‌ترین تصمیم
مسئله واقعی این نیست:
Local بهتر است یا Cloud؟
بلکه:
برای این Task، با این Data، این Budget، این Latency و این Risk کدام معماری مناسب‌تر است؟
مثلاً برای:
Prototype کوچک
Cloud ممکن است بهترین انتخاب باشد.
برای:
Internal Enterprise Knowledge
Local ممکن است ارزش بیشتری داشته باشد.
یک Decision Tree ساده
اگر Data بسیار حساس است:
Local را بررسی کن.
اگر سریع MVP می‌خواهی:
Cloud را بررسی کن.
اگر Usage زیاد و ثابت است:
Local Cost را محاسبه کن.
اگر بهترین Model ممکن لازم است:
Cloud احتمالاً ساده‌تر است.
اگر هر دو نوع نیاز را داری:
Hybrid.
جمع‌بندی
Local AI یعنی اجرای Modelهای هوش مصنوعی روی Hardware یا Infrastructure خودمان.
معماری ساده:
این روش می‌تواند مزایایی مثل:
- Privacy
- Offline Usage
- Control
- No Per-token Fee
- Customization
داشته باشد.
اما در مقابل باید مسئولیت:
- Hardware
- GPU
- VRAM
- Scaling
- Monitoring
- Maintenance
- Security
را نیز بپذیریم.
برای اجرای Local Model باید مفاهیمی مثل:
- Model Size
- Quantization
- VRAM
- RAM
- Context Window
- Tokens/sec
- Inference
را بشناسیم.
Cloud معمولاً ساده‌تر و Scale کردن آن راحت‌تر است.
Local کنترل و Privacy بیشتری می‌دهد.
و برای بسیاری از پروژه‌ها، معماری Hybrid ممکن است منطقی‌ترین انتخاب باشد.
در نهایت انتخاب بین Local و Cloud نباید براساس هیجان تکنولوژی باشد.
باید براساس:
- Data
- Cost
- Privacy
- Performance
- Scale
- Team
- Infrastructure
انجام شود.
گاهی بهترین معماری یک Cloud API است.
گاهی یک Model Quantized روی یک Server داخلی.
و گاهی ترکیبی از هر دو.
مهندسی خوب معمولاً همان لحظه‌ای شروع می‌شود که از پرسیدن «کدام تکنولوژی جذاب‌تر است؟» دست می‌کشیم و می‌پرسیم «کدام گزینه واقعاً مسئله ما را حل می‌کند؟»