رفع «جهنم وابستگیات» در توسعهٔ عامل‌های هوش مصنوعی با داکر کامپوز

تصور کنید ساعت‌ها زمان صرف تنظیم دستی محیط‌های توسعه می‌کنید و در نهایت با یک خطای کوچک در درایور کارت گرافیک، تمام زحمات شما به باد می‌رود. امروز تمام این فرسایش را می‌توان با یک دستور ساده یعنی docker compose up --build جایگزین کرد. با تغییر رویکرد از نصب‌های محلی به یک وضعیت بومی کانتینری (Container-native)، مهندسان وابستگی‌های شکننده‌ای را که معمولاً باعث شکست عامل‌های (Agents) هوش مصنوعی هنگام انتقال بین ماشین‌های مختلف می‌شوند، حذف می‌کنند. تنها راه تضمین هوش بازتولیدپذیر در تیم‌های مختلف، برخورد با استک (Stack) هوش مصنوعی به‌عنوان مجموعه‌ای از سرویس‌های تکلیفی (Declarative) است.

توسعهٔ محلی هوش مصنوعی همواره با «جهنم وابستگیات» دست‌وپنجه نرم می‌کند؛ جایی که یک مدل ۴۰ گیگابایتی روی یک سیستم اجرا می‌شود اما روی سیستمی دیگر به‌دلیل ناسازگاری درایورهای CUDA کرش می‌کند. وعده‌ی ساخت عامل‌های پیچیده اغلب توسط همین محیط‌های شکننده تخریب می‌شود. تصور کنید یک عدم تطابق جزئی در نسخه کتابخانه دیتابیس برداری، به‌طور خاموش حافظه بلندمدت یک عامل را فاسد کند. یا محیط اجرای عامل — که به یک محیط پایتون خاص وابسته است — در لحظه ادغام یک ابزار جدید، از کار بیفتد. این شکنندگی زیرساختی، مهندسی هوش را به نبردی علیه محیط‌های اجرایی تبدیل می‌کند و ساعت‌های بی‌شماری را به‌جای طراحی منطق، صرف رفع خطا و بازسازی محیط می‌کند. برای عبور از این چالش‌ها، بسیاری از سازمان‌ها در حال گذار از مدل‌های ساده به جریان‌های کاری عامل‌محور در پشته‌های فناوری سازمانی هستند تا پایداری عملیاتی را تضمین کنند.

برای حل این مشکل، طرح پیشنهادی از داکر کامپوز (Docker Compose) استفاده می‌کند تا استک هوش مصنوعی را نه به‌عنوان مجموعه‌ای از نرم‌افزارهای نصب‌شده، بلکه به‌عنوان مجموعه‌ای ایزوله، قابل حمل و تکلیفی از سرویس‌ها تعریف کند. این رویکرد, یک استک پیچیده چندسرویسه را به یک فایل YAML ساده و خوانا تبدیل می‌کند که به‌عنوان «تنها منبع حقیقت» پروژه عمل می‌کند. در این حالت، به‌جای تکیه بر مستندات قدیمی درباره «نصب Redis 7.2.1 با فلگ‌های خاص»، تیم‌ها از یک مشخصات اجرایی (Executable Specification) استفاده می‌کنند.

بر اساس بررسی‌های فنی، این معماری از چهار سرویس اصلی تشکیل شده است که در فایل docker-compose.yml تعریف شده‌اند. با اجرای دستور docker compose up --build توسعه‌دهندگان یک خط لوله کامل را با اجزای مشخص زیر فعال می‌کنند:

• محیط اجرای مدل (Ollama): به‌عنوان «مغز» عمل می‌کند. این سرویس از تصویر ollama/ollama:latest روی پورت ۱۱۴۳۴ استفاده کرده و برای حفظ وزن‌های مدل بین بازراه‌اندازی‌ها، از یک Volume نام‌گذاری شده به نام ollama_data بهره می‌برد.
• ذخیره‌ساز حافظه برداری (Qdrant): به‌عنوان حافظه پایدار عامل عمل می‌کند و از تصویر qdrant/qdrant روی پورت ۶۳۳۳ استفاده می‌کند، در حالی که داده‌ها در Volume مربوط به qdrant_data ذخیره می‌شوند.
• محیط اجرای عامل و ابزارها (FastAPI): یک سرویس سفارشی برای اجرای ابزارها و منطق عامل است. این سرویس از یک Dockerfile محلی (واقع در مسیر ./agent_service) ساخته شده، پورت ۸۰۰۰ را مپ می‌کند و برای عملکرد صحیح، به هر دو سرویس llm و memory وابسته است.
• داشبورد نظارتی (Grafana): یک داشبورد مانیتورینگ که از تصویر grafana/grafana:latest روی پورت ۳۰۰۰ استفاده می‌کند. این سرویس برای خودکارسازی فرآیند آماده‌سازی (Provisioning)، از یک Mount Volume خاص برای فایل datasources.yml استفاده می‌نماید.

کانتینری‌سازی، کنترل دقیقی روی منابع مصرفی استک هوش مصنوعی می‌دهد. مدیریت منابع از طریق بلوک deploy.resources.reservations انجام می‌شود که به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — دسترسی انحصاری به تمامی GPUهای میزبان از طریق درایور nvidia را می‌دهد. این کار از تداخل حافظه جلوگیری کرده و سرعت استنتاج (Inference) — یعنی همان لحظه تولید جواب توسط مدل — را به حداکثر می‌رساند.

برای کارهای وابسته به CPU، مانند جست‌وجوهای برداری، این طرح محدودیت‌هایی را برای تضمین پایداری پیشنهاد می‌کند:

• محدودیت CPU: تنظیم cpus: 2 جلوگیری می‌کند که یک سرویس واحد، پردازنده را به طور کامل تصاحب کند.
• محدودیت حافظه: اعمال mem_limit: 4g تضمین می‌کند که یک فرآیند «همسایه پرسرصدا» (Noisy Neighbor)، عملکرد یادآوری (Recall) عامل را تخریب نکند.

توپولوژی شبکه نیز از طریق یک Bridge Network پیش‌فرض ساده شده است. محیط اجرای عامل نیازی به دانستن یک IP متغیر و ناپایدار ندارد؛ بلکه به‌طور مطمئن از طریق نام میزبان llm به مدل زبانی و از طریق memory به ذخیره‌ساز برداری متصل می‌شود. این انتزاع، کد را ساده‌تر کرده و انتقال از یک لپ‌تاپ محلی به یک خوشه کوبرنتیز (Kubernetes) در محیط عملیاتی را تقریباً بی‌درز می‌کند. در سناریوهای پیشرفته‌تر، ترکیب داکر و Traefik می‌تواند تداخل‌های احتمالی در محیط‌های چند-مستاجری (Multi-tenant) را به‌طور کامل مدیریت کند.

امنیت در این طراحی از طریق ایزولاسیون درونی شده است. سرویس agent_runtime نمی‌تواند به‌طور مستقیم به فایل‌سیستم میزبان دسترسی داشته باشد و فقط دایرکتوری‌های مشخصی را می‌بیند، مانند مسیر ./agent_service/app برای بارگذاری زنده کد (Live Reloading). این ایزولاسیون را می‌توان با اجرای کانتینرها توسط کاربرانی غیر از Root و Read-only کردن فایل‌سیستم (به‌جز حجم‌های داده)، بیش‌تر تقویت کرد.

کنترل نسخه اکنون فراتر از کد اپلیکیشن گسترش می‌یابد. توسعه‌دهندگان با تعیین تگ‌های دقیق تصاویر، مانند ollama/ollama:0.1.24، محیط اجرا را روی یک نسخه شناخته‌شده و قابل حسابرسی قفل می‌کنند. به‌روزرسانی استک به یک اقدام آگاهانه و مستند تبدیل می‌شود: تغییر یک تگ در فایل YAML و بازسازی کانتینر. این رویکرد مشکل «روی سیستم من کار می‌کرد» را به‌کلی حذف می‌کند و یک ردپای حسابرسی (Audit Trail) پاک برای رعایت استانداردها فراهم می‌کند.

دستاورد نهایی، ایجاد یک زنجیره بدون گسست از توسعه محلی تا تولید است. همان فایل docker-compose.yml که روی لپ‌تاپ استفاده شده، می‌تواند با ابزارهایی مثل Kompose، پایه و اساس استقرار در کوبرنتیز یا سرویس‌های ابر-پایه‌ای مانند ECS/Fargate باشد.

تصاویر تغییرناپذیر (Immutable Images) تولید شده برای agent_runtime برای خط لوله‌های CI/CD آماده هستند. این تصاویر می‌توانند بدون هیچ تغییری در وابستگی‌های داخلی، تحت اسکن‌های امنیتی، تست‌های یکپارچگی و انتشار‌های Canary قرار گیرند. این تغییر، زیرساخت هوش مصنوعی را از یک «بدهی پنهان» به یک «دارایی نسخه‌بندی شده» تبدیل می‌کند. در نهایت، برنامه‌نویسان به‌جای کلنجار رفتن با درایورهای CUDA، روی منطق، حافظه و ابزارهایی تمرکز می‌کنند که واقعاً هوش یک عامل را تعریف می‌کنند.

گام بعدی شما

• اگر در حال توسعه عامل‌های AI هستید، تمام سرویس‌های خود (از دیتابیس برداری تا مدل) را در یک فایل docker-compose.yml تجمیع کنید.
• تگ‌های :latest را با نسخه‌های دقیق (مثل :0.1.24) جایگزین کنید تا از شکست ناگهانی محیط در اثر به‌روزرسانی‌های خودکار جلوگیری کنید.
• محدودیت‌های CPU و Memory را برای سرویس‌های جانبی تعریف کنید تا منابع GPU به‌طور بهینه به مدل اختصاص یابد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.