اجرای مدل زبانی روی سرور داخلی - راهنمای فنی برای سازمانها
برای بسیاری از سازمانها، سؤال «آیا از هوش مصنوعی استفاده کنیم؟» جای خودش را به سؤال دیگری داده: «چطور استفاده کنیم بدون اینکه دادهمان بیرون برود؟» این مقاله راهنمای فنی برای پاسخ به همان سؤال است.
چه زمانی اجرای داخلی منطقی است؟
اجرای داخلی وقتی منطقی است که یکی از اینها صادق باشد:
- الزام مقرراتی. بانک، بیمه، سلامت، دفاعی، یا هر سازمانی که دادهاش نباید از مرز شبکه خارج شود.
- حجم بسیار بالا. از یک نقطه به بعد، هزینه ثابت سختافزار از هزینه متغیر API کمتر میشود.
- ریسک دسترسی. وابستگی به سرویسی که ممکن است قطع، تحریم یا گران شود.
- تأخیر. وقتی حساسیت به تأخیر بالاست و شبکه محدودیت دارد.
- شبکه ایزوله. جایی که اصلاً اینترنت نیست.
اگر هیچکدام صادق نیست، ابر را انتخاب کنید.
انتخاب مدل: سه معیار
۱. اندازه (تعداد پارامتر)
- کوچک (حدود ۷ تا ۹ میلیارد پارامتر) - سریع، کممصرف. برای دستهبندی، استخراج اطلاعات و پاسخهای ساده کافی است
- متوسط (حدود ۱۳ تا ۳۲ میلیارد) - نقطه تعادل رایج برای پشتیبانی مشتری
- بزرگ (۷۰ میلیارد به بالا) - استدلال پیچیده. هزینه سختافزاری بهشکل چشمگیری بالاتر
۲. کیفیت فارسی
مهمترین معیار برای ما، و کمترین چیزی که در معیارهای بینالمللی دیده میشود. مدلی که در آزمونهای انگلیسی عالی است ممکن است در فارسی ضعیف باشد. حتماً با داده واقعی خودتان تست کنید، نه با نمرات منتشرشده.
آزمون عملی: بیست سؤال واقعی مشتریانتان را با اسناد خودتان بدهید و خروجی را با هم مقایسه کنید.
۳. مجوز
مدلهای متنباز مجوزهای متفاوتی دارند. بعضی برای استفاده تجاری محدودیت دارند. این را قبل از استقرار بررسی کنید، نه بعد از آن.
محاسبه حافظه GPU
این عملیترین بخش برنامهریزی است.
بایت بهازای هر پارامتر بستگی به دقت عددی دارد:
| دقت | بایت/پارامتر | مدل ۷ میلیاردی | مدل ۳۰ میلیاردی |
|---|---|---|---|
| FP16 | ۲ | حدود ۱۴ گیگابایت | حدود ۶۰ گیگابایت |
| INT8 | ۱ | حدود ۷ گیگابایت | حدود ۳۰ گیگابایت |
| INT4 | ۰.۵ | حدود ۳.۵ گیگابایت | حدود ۱۵ گیگابایت |
به این اعداد باید سربار اضافه کرد: حافظه KV Cache (که با طول متن و تعداد درخواست همزمان رشد میکند)، و فضای کاری. یک قاعده سرانگشتی محافظهکارانه: ۲۰ تا ۳۰ درصد بالای عدد پایه.
کوانتیزاسیون: مبادله کیفیت با حافظه
کوانتیزاسیون یعنی کاهش دقت عددی وزنها. INT8 معمولاً افت کیفیت محسوسی ندارد. INT4 حافظه را نصف میکند اما افت کیفیت دارد - که برای بعضی کاربردها قابل قبول است و برای بعضی نه.
توصیه: با INT8 شروع کنید. اگر حافظه کم آوردید، INT4 را تست کنید و با داده واقعی خودتان بسنجید که افت کیفیت قابل قبول است یا نه.
ظرفیت: چند کاربر همزمان؟
اشتباه رایج این است که فقط حافظه مدل حساب شود. اما ظرفیت واقعی به اینها بستگی دارد:
- تعداد درخواست همزمان (نه تعداد کل کاربران)
- طول متن ورودی - در RAG، متن بازیابیشده هم به ورودی اضافه میشود و میتواند طولانی باشد
- طول پاسخ
- حساسیت به تأخیر - پاسخ باید در دو ثانیه بیاید یا ده ثانیه؟
موتورهای استنتاج
مدل خام را مستقیم اجرا نکنید. موتورهای بهینهشده چند برابر توان عملیاتی میدهند:
- vLLM - با مدیریت بهینه حافظه و دستهبندی پویا. رایجترین انتخاب برای سرویسدهی
- TensorRT-LLM - برای سختافزار انویدیا، بهینهسازی عمیق
- llama.cpp - سبک، مناسب مدلهای کوچک و سختافزار محدود
- Ollama - ساده برای شروع و تست، نه برای بار تولیدی سنگین
تفاوت بین اجرای خام و موتور بهینهشده معمولاً چند برابر است - یعنی مستقیماً روی سختافزار لازم اثر میگذارد.
چقدر سختافزار لازم دارید؟
در جلسه فنی، بر اساس حجم واقعی شما یک سند مشخصات سختافزاری ارائه میدهیم - نه یک عدد کلی.
مقایسه هزینه: ابر یا داخلی؟
API ابری
- هزینه متغیر بر اساس مصرف
- بدون سرمایهگذاری اولیه
- بدون بار عملیاتی
- با رشد مصرف، هزینه خطی بالا میرود
داخلی
- سرمایهگذاری اولیه: GPU، سرور، شبکه، برق و خنککننده
- هزینه عملیاتی: تیم نگهداری، برق، بهروزرسانی
- پس از نقطه سربهسر، هزینه هر درخواست بهشدت پایین میآید
نقطه سربهسر به حجم شما بستگی دارد و باید با اعداد واقعی خودتان حساب شود. اما در محاسبه، این سه را فراموش نکنید:
- هزینه تیم. کسی باید این را نگه دارد. این معمولاً بزرگترین هزینه پنهان است
- استهلاک سختافزار. GPU در سه سال ارزشش نصف میشود
- هزینه فرصت. تیم زیرساخت شما بهجای این، چه کار دیگری میتوانست بکند؟
معماری استقرار
اجزای معمول یک استقرار تولیدی:
↓
API Gateway (احراز هویت، محدودسازی نرخ، کش)
↓
لایه بازیابی (پایگاه داده برداری + جستجوی ترکیبی)
↓
موتور استنتاج (vLLM با چند نمونه)
↓
GPU
نکات عملیاتی
- کش پاسخ - سؤالات پرتکرار نباید هر بار پردازش شوند. این سادهترین راه کاهش بار است
- مدلهای چندگانه - مدل کوچک برای کارهای ساده (دستهبندی، تشخیص قصد)، مدل بزرگ فقط برای پاسخ نهایی. صرفهجویی قابل توجه
- صف و پردازش ناهمزمان - برای مدیریت اوج
- مانیتورینگ - تأخیر، توان عملیاتی، مصرف حافظه، و کیفیت خروجی. این آخری معمولاً فراموش میشود
- مسیر بازگشت - اگر مدل داخلی از کار افتاد، چه اتفاقی میافتد؟
اشتباهات رایج
- خرید سختافزار قبل از اندازهگیری بار. ابتدا با نسخه ابری یا محیط آزمایشی، حجم و الگوی واقعی را بسنجید.
- انتخاب بزرگترین مدل ممکن. در RAG معمولاً لازم نیست و هزینه را چند برابر میکند.
- نادیده گرفتن هزینه تیم. سختافزار یک بار خریده میشود؛ نگهداری هر ماه هزینه دارد.
- تست نکردن با داده فارسی واقعی. نمرات بینالمللی درباره عملکرد فارسی روی اسناد شما چیزی نمیگویند.
- فراموش کردن اینکه مدل نصف ماجراست. کیفیت خروجی بیشتر به کیفیت بازیابی و دانش شما بستگی دارد تا به اندازه مدل.
در مانوتل
نسخه نصبی مانوتل با هوش مصنوعی کامل ارائه میشود - نه نسخه ناقص که همچنان به ابر وصل است. مدل زبانی روی همان سرور اجرا میشود.
و انعطاف انتخاب: مدل متنباز محلی، یا مدل ابری دلخواه شما. هر دستیار میتواند مدل متفاوتی داشته باشد - مدل سبک برای سؤالات ساده، مدل قوی برای موارد پیچیده.
پرسشهای متداول
خیر. برای اکثر سازمانها API ابری انتخاب درستتری است: ارزانتر، سریعتر و بدون بار عملیاتی. اجرای داخلی وقتی منطقی است که یکی از این پنج شرط برقرار باشد: الزام مقرراتی، حجم بسیار بالا، ریسک قطع یا تحریم سرویس، حساسیت شدید به تأخیر، یا شبکه ایزوله بدون اینترنت.
در معماری RAG، مدل قرار نیست دانش را حفظ کند - قرار است متن بازیابیشده را بفهمد و از رویش پاسخ بسازد، و این کار به مدل خیلی بزرگی نیاز ندارد. مدلهای کوچک (۷ تا ۹ میلیارد پارامتر) برای دستهبندی و استخراج اطلاعات کافیاند و مدلهای متوسط (۱۳ تا ۳۲ میلیارد) نقطه تعادل رایج برای پشتیبانی مشتریاند.
فرمول تقریبی: حافظه لازم ≈ (تعداد پارامتر × بایت بهازای هر پارامتر) + سربار. در FP16 هر پارامتر ۲ بایت است (مدل ۷ میلیاردی حدود ۱۴ گیگابایت)، در INT8 یک بایت (حدود ۷ گیگابایت) و در INT4 نیم بایت (حدود ۳.۵ گیگابایت). به این اعداد باید حافظه KV Cache و فضای کاری اضافه شود؛ قاعده سرانگشتی محافظهکارانه ۲۰ تا ۳۰ درصد بالای عدد پایه است.
INT8 معمولاً افت کیفیت محسوسی ندارد. INT4 حافظه را نصف میکند اما افت کیفیت دارد که برای بعضی کاربردها قابل قبول است و برای بعضی نه. توصیه این است که با INT8 شروع کنید و اگر حافظه کم آوردید، INT4 را با داده واقعی خودتان بسنجید.
ظرفیت واقعی به تعداد درخواست همزمان (نه تعداد کل کاربران)، طول متن ورودی، طول پاسخ و حساسیت به تأخیر بستگی دارد. نکته کلیدی این است که حجم واقعی معمولاً کمتر از تصور است: سازمانی با ده هزار کاربر روزانه ممکن است در اوج فقط سی گفتگوی همزمان داشته باشد. قبل از خرید سختافزار، توزیع واقعی بار خودتان را اندازه بگیرید.
مدل خام را مستقیم اجرا نکنید. vLLM با مدیریت بهینه حافظه و دستهبندی پویا رایجترین انتخاب برای سرویسدهی است؛ TensorRT-LLM برای سختافزار انویدیا بهینهسازی عمیق دارد؛ llama.cpp سبک و مناسب مدلهای کوچک است؛ و Ollama برای شروع و تست خوب است اما نه برای بار تولیدی سنگین.
نقطه سربهسر به حجم شما بستگی دارد و باید با اعداد واقعی خودتان حساب شود. در محاسبه سه هزینه پنهان را فراموش نکنید: هزینه تیم نگهداری که معمولاً بزرگترین است، استهلاک سختافزار (GPU در سه سال ارزشش نصف میشود) و هزینه فرصت تیم زیرساخت. و اگر انگیزه شما مقرراتی است، این محاسبه اهمیت ثانویه دارد؛ آنجا سؤال «مجاز است؟» است نه «ارزانتر است؟».
درباره کارن تکنولوژی:
کارن تکنولوژی با بیش از یک دهه تجربه در زمینه ارائه راهکارهای فناوری، همواره در صف مقدم نوآوری و پیشرفت تکنولوژیک قرار داشته است. تیم متخصص ما، متشکل از کارشناسان خبره در زمینههای مختلف IT، هوش مصنوعی، اینترنت اشیا، و دیگر فناوریهای پیشرفته، آماده ارائه خدمات منحصر به فرد و متناسب با نیازهای خاص شرکت ها و سازمان های بزرگ و صنایع است.
درباره ما بیشتر بدانید
