انتقال مدل‌های زبانی بزرگ (LLMs) از دفترچه‌های آزمایشی به برنامه‌های سازمانی در سطح تولید دیگر یک نگرانی تخصصی نیست، بلکه یک الزام عملیاتی استاندارد است. برای تیم‌هایی که به حاکمیت داده و استنتاج با تأخیر کم متعهد هستند، Ollama به عنوان یک راه‌حل برتر برای اجرای مدل‌های متن‌باز به صورت محلی ظهور کرده است. با این حال، اجرای صرف ollama serve روی یک نود واحد به ندرت برای محیط‌های با ترافیک بالا کافی است. این پست به بررسی الگوهای معماری مورد نیاز برای ارکستراسیون جریان‌های کاری چندمدلی و مقیاس‌دهی کارآمد APIهای Ollama می‌پردازد.
چالش استنتاج تک‌مدلی (Monolithic)
در استقرارهای اولیه، اغلب یک نمونه از Ollama تمام درخواست‌ها را مدیریت می‌کند. اگرچه این رویکرد برای آزمایش مؤثر است، اما باعث ایجاد گلوگاه می‌شود. حافظه GPU محدود است و پنجره‌های زمینه (Context Windows) برای مدل‌هایی مانند Llama 3 یا Mistral می‌توانند به سرعت VRAM را اشغال کنند. علاوه بر این، هدایت تمام ترافیک از طریق یک نقطه پایانی واحد، از مقیاس‌پذیری افقی جلوگیری می‌کند. برای دستیابی به قابلیت اطمینان در سطح سازمانی، باید موتور استنتاج را از منطق برنامه جدا کرده و لایه‌های ارکستراسیون را معرفی کنیم.
کانتینرسازی و مقیاس‌دهی با Docker
قوی‌ترین نقطه شروع برای محیط تولید، کانتینرسازی است. Docker به شما امکان می‌دهد محیط‌های تکرارپذیری را تعریف کنید که در آن‌ها زمان اجرای Ollama، کتابخانه‌های مدل و متغیرهای محیطی تحت کنترل نسخه قرار دارند. با استفاده از Docker Compose، تیم‌ها می‌توانند چندین کانتینر Ollama را راه‌اندازی کنند که هر کدام ممکن است برای اندازه‌های مدل مختلف یا محدودیت‌های سخت‌افزاری بهینه شده باشند.
در اینجا یک پیکربندی پایه Docker Compose آورده شده است که API Ollama را نمایان می‌کند و یک مدل سبک را برای وظایف مسیریابی از پیش بارگذاری می‌کند:
version: '3.8'
services:
ollama:
image: ollama/ollama
ports:
- "11434:11434"
volumes:
- ollama-data:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_KEEP_ALIVE=24h
volumes:
ollama-data:این پیکربندی تضمین می‌کند که مدل‌ها در طول راه‌اندازی مجدد پایدار باقی می‌مانند و سرویس روی تمام رابط‌های شبکه گوش می‌دهد، که به سایر میکروسرویس‌ها امکان اتصال امن در داخل شبکه داخلی شما را می‌دهد.
ارکستراسیون جریان‌های کاری چندمدلی
برنامه‌های سازمانی به ندرت به یک مدل واحد تکیه می‌کنند. یک جریان کاری معمولی ممکن است از یک مدل کوچک‌تر مانند Phi-3 برای طبقه‌بندی قصد کاربر، یک مدل متوسط‌تر مانند Mistral برای خلاصه‌سازی و یک مدل بزرگ‌تر مانند Llama 3-70B برای استدلال پیچیده استفاده کند. چارچوب‌های ارکستراسیون مانند LangChain یا LlamaIndex در اینجا ضروری هستند، اما باید به گونه‌ای پیکربندی شوند که تغییر مدل را به صورت یکپارچه مدیریت کنند.
به جای نام‌گذاری سخت‌افزاری مدل‌ها، سیستم‌های تولید باید یک استراتژی مسیریابی را پیاده‌سازی کنند. برای مثال، می‌توانید یک سرویس پراکسی ایجاد کنید که پیکربندی درخواست ورودی را بررسی کند. اگر پرسش کاربر حاوی کلمات کلیدی فنی باشد، مسیری درخواست را به یک مدل تخصصی در کد هدایت می‌کند. در غیر این صورت، آن را به یک مدل همه‌منظوره هدایت می‌کند. این استراتژی با اجتناب از محاسبات سنگین برای وظایف ساده، هزینه‌ها و تأخیر را بهینه می‌کند.
مقیاس‌دهی API و تعادل بار
با افزایش بار کاربر، یک نمونه واحد Ollama با مشکل مواجه خواهد شد. راه‌حل، مقیاس‌پذیری افقی پشت یک پراکسی معکوس مانند Nginx یا Traefik است. این امر به شما امکان می‌دهد درخواست‌های استنتاج ورودی را بین چندین نود Ollama توزیع کنید.
هنگام پیاده‌سازی تعادل بار، در نظر گرفتن وابستگی GPU حیاتی است. شما نمی‌توانید یک مدل بزرگ واحد را بین دو GPU جداگانه در نودهای مختلف تقسیم کنید؛ هر نود باید مدل کامل را بارگذاری کرده باشد. بنابراین، تعادل بار زمانی بهترین عملکرد را دارد که چندین نود یکسان با اجرای همان مدل را داشته باشید، یا زمانی که خانواده‌های مدل مختلف را به گروه‌های نود مختلف هدایت کنید.
نتیجه‌گیری
استقرار Ollama در محیط تولید نیازمند تغییر رویکرد از اجرای ساده به انضباط معماری است. با کانتینرسازی سرویس‌های خود، پیاده‌سازی استراتژی‌های مسیریابی چندمدلی و استفاده از پراکسی‌های معکوس برای تعادل بار، تیم‌های سازمانی می‌توانند از قدرت LLMهای محلی بهره ببرند بدون آنکه از عملکرد یا قابلیت اطمینادستی بکشند. با بالغ‌تر شدن اکوسیستم هوش مصنوعی محلی، این الگوها به استاندارد ساخت برنامه‌های هوش مصنوعی امن، مقیاس‌پذیر و مقرون‌به‌صرفه تبدیل خواهند شد.