نویسنده (ها): دانیل وویس
در ابتدا منتشر شده در به سمت هوش مصنوعیبشر
اگر هر یک از مقالات قبلی من را خوانده اید ، خواهید دید که بیشتر از آنکه سعی کنم زیرساخت های خود را حفظ کنم (زیرا به عنوان یک راه اندازی دائمی CTO ، من طبیعتاً ارزان هستم).
من برای یک سال گذشته به شدت از Graphrag (هم نسخه مایکروسافت و هم نسخه خانگی خودم) استفاده کرده ام و همیشه از اینکه چقدر افزایش اندک پیچیدگی اسناد می تواند بودجه را منفجر کند ، شگفت زده شده ام.
بازگشت وقتی که من استفاده می کردم gpt-4.1-mini از OpenAi – یک مجموعه از اسناد به تنهایی برای من بیش از 200 دلار (!!).
حتی با gpt-4.1-nano (ارزانترین مدل مرزی در حال حاضر) بودجه من مسخره بود. 215 میلیون نشانه برای چند سند (مسلماً بزرگ) پوچ است و این واقعیت که چندین روز برای پردازش طول می کشد بیش از حد طول کشید.
وقتی برای اولین بار شروع به استقرار محلی کردم مدل های بزرگ زبان (LLMS) در مورد NAS قابل اعتماد من ، اولما بلافاصله به عنوان گزینه ای برای انجام این کار ایستاد. راه اندازی آن با Docker ساده بود ، و پشتیبانی از ویندوزهای زمینه عظیم را ارائه می داد – مناسب برای موارد استفاده خواستار Graphrag. امکان رسیدگی به علائم حداکثر 128K با استفاده از جدیدترین مدل های منبع باز Gemma3 از Google به ویژه جذاب بود.
با این حال ، از آنجا که من شروع به فشار دادن اولاما به حد آن کردم ، مسائل به سرعت ظاهر شد. محاسبات پنجره زمینه آن به طرز عجیبی متناقض بود ، و اغلب در اندازه های تصادفی مانند 35.567 توکن به جای پیکربندی 128K حل و فصل می شد. این به طور مرتب باعث می شود که این مدل در زیر بارهای سنگین تر یخ زده یا یخ بزند.
با افزایش ترافیک ، اوضاع بدتر شد. اولاما غالباً قفل می شد ، زمینه ها را رها می کرد و نیاز به راه اندازی مجدد دستی مداوم داشت و به سرعت روشن شد که این تولید در تولید نخواهد بود. من یک آداپتور سفارشی را امتحان کردم تا مستقیماً ویندوزهای زمینه اولما را مدیریت کنم و پیش فرض های ایمن را تنظیم کنم. در حالی که این پچ کمی کمک کرد ، بیشتر از یک مشکل اصلی احساس می کرد. نی آخر وقتی فهمیدم که اولاما برای هر آنچه که تمام وقت آن بود ، قفل می شود – این زمان در 48 ساعت تنظیم شد که بسیار مسخره است!
سرانجام ، عملکرد و توان قابل اعتماد ضروری شد ، نه اختیاری. VLLM به عنوان یک راه حل قوی تر به رادار من آمد ، نوید بخش کارآمد ، کنترل بهتر حافظه و عملکرد مداوم در مقیاس.
تفاوت بین VLLM و اولاما
یک میلیون مقاله دیگر در این مورد وجود دارد ، بنابراین من آن را مجدداً تنظیم نمی کنم – من به خصوص این را دوست دارم:
VLLM در مقابل اولاما: انتخاب چارچوب LLM سبک وزن مناسب برای برنامه های هوش مصنوعی شما
چرا چارچوب راست LLM اهمیت دارد
blog.stackademic.com
به طور خلاصه VLLM یک روش آماده تولید بیشتر با توان بالاتر با هزینه از دست دادن برخی از راحتی ها (بدون مدل چند مدل ، بدون GGUF ، محدودیت های کمی) ارائه می دهد.
این اساساً به این معنی است که شما 1 ظرف را که 1 مدل را در آن بارگیری می کند ، مستقر می کنید GPU برای استنباط
گرفتن VLLM و در حال اجرا با Docker Compose
جابجایی به VLLM شامل تکرار تنظیمات Ollama موجود من با استفاده از آهنگسازی Docker است. با استفاده از رسمی vllm/vllm-openai:latest تصویر Docker ، من خودم را تنظیم کردم Gemma-3 مدل به سرعت ، من یک مدل کوچکتر از حد معمول را انتخاب کردم زیرا 4B یکی برای نیازهای من به اندازه کافی هوشمند است و عملکرد معقول را در 2 x RTX A2000 12 گیگابایت من می دهد GPU‘s.
این تنظیم شامل نصب حافظه نهان بغل من ، تزریق چهره در آغوش گرفتن من به طور ایمن از طریق اسرار داکر و پیکربندی پارامترهای ضروری GPU و متن است.
تا به شما TLDR بدهد. (برای کسانی که به اینجا آمده اند و سعی می کنند یک روش ساده برای انجام همان کار پیدا کنند) ، در اینجا همان چیزی است که پرونده Docker Docker به نظر می رسد:
services:
vllm:
image: vllm/vllm-openai:latest
container_name: vllm
ipc: host
ports:
- "28888:8000"
volumes:
- ~/.cache/huggingface:/root/.cache/huggingface
environment:
NVIDIA_VISIBLE_DEVICES: "0,1"
HUGGING_FACE_HUB_TOKEN: "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"
PYTORCH_CUDA_ALLOC_CONF: "max_split_size_mb:64,expandable_segments:True"
command: >
--model unsloth/gemma-3-4b-it
--max-model-len 56000
--max-num-seqs 2
--tensor-parallel-size 2
--gpu-memory-utilization 0.88
--swap-space 16
--enable-chunked-prefill
--trust-remote-code
--quantization bitsandbytes
--enforce-eager
networks:
- rag
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]networks:
ragflow:
external: true
name: docker_rag
من از ارسال مطالب مانند آن متنفرم ، زیرا همیشه به نظر می رسد بسیار ساده پیشانی است اما ساعت ها به این مرحله رسیده است. (چرا nccl_p2p_disable؟ ، چرا باید از آن مدل خاص استفاده کنم؟ و غیره)
خرابی و تنظیمات
در حالی که تنظیم به اندازه کافی آسان به نظر می رسید ، استقرار در دنیای واقعی به سرعت برخی از چالش ها را به سطح می آورد. اولین مانع با محدودیت های حافظه مشترک در تنظیمات چند GPU بود. به طور خاص ، اجرای VLLM بر روی دو GPU RTX A2000 منجر به خطاهای NCCL مربوط به حافظه مشترک کافی نشده است (/dev/shm). حد پیش فرض 64 مگابایت داکر تقریباً کافی نبود – هر GPU به حدود 33 مگابایت نیاز داشت و باعث تصادف در هنگام راه اندازی شد. من تا به حال مجبور نشده ام با تنظیمات IPC در Docker اشتباه بگیرم اما بعد از چند عقب و عقب با چتپپ ، اضافه کردم ipc: host برای دسترسی به ظروف به حافظه مشترک بزرگتر میزبان ، حل مسئله اولیه سازی NCCL.
مشکل دیگری با تخصیص حافظه GPU پدید آمد. تنظیمات پیش فرض به سرعت در هنگام بارگذاری مدل خطاهای خارج از حافظه (OOM) را ایجاد کرد. این راه حل شامل ترفند پارامتر استفاده از حافظه VLLM پایین از 0.98 پیش فرض به محدوده ایمن تر در حدود 0.85 بود. این تنظیم یک بافر در برابر سنبله های حافظه گذرا فراهم می کند که به آن اجازه می دهد تا با موفقیت راه اندازی شود.
حافظه به اشتراک گذاشته شده در 2 GPU در مقابل بار متعادل کردن GPU با nginx
در ابتدا من قصد داشتم کپی کنم که چگونه اولاما کارها را انجام داده است (به عنوان مثال آن را شروع کنید و آن را فراموش کنید) اما VLLM یک جانور متفاوت است ، زیرا من 2 GPU داشتم که ظاهراً یکسان بودند ، برای من معقول بود که با استفاده از nginx برای دور زدن درخواست ها ، 2 مورد از آنها را تعادل برقرار کنم. متأسفانه این به آسانی به نظر نمی رسید.
اجرای دو ظروف جداگانه ، یکی در هر GPU ، مشاجره حافظه GPU غیر منتظره ، به ویژه با GPU0 همچنین وظایف نمایش را انجام می دهد. در ابتدا ، GPU0 به دلیل VRAM اشغال شده توسط نمایشگر گرافیکی سیستم با تعادل حافظه موجود بین 2 GPU ، به درستی بارگیری نکرد. تنظیم gpu-memory-utilization کمی برای GPU0 کمی پایین تر است ، در حالی که به GPU1 اجازه می دهد تا از حافظه موجود به طور کامل استفاده کند ، به طور مؤثر مسئله را برطرف کرده و به هر دو GPU اجازه می دهد تا به درستی عملکرد داشته باشند.
خوب به نظر می رسد؟ هنگام آزمایش با یک خط لوله گرافراگ سنگین ، مشخص شد که در حالی که تعادل بار مبتنی بر NGINX سهولت اولیه استقرار را ارائه می دهد ، اما در عملکرد پایدار ، به ویژه در زیر بارهای استنباط موازی ، کوتاهتر شد.
در پایان ، به اشتراک گذاری حافظه اتخاذ در هر دو GPU با استفاده از موازی Tensor VLLM نسبت به تعادل بار مبتنی بر NGINX حس بیشتری می کند-نه فقط به خاطر عملکرد خام بلکه برای اطمینان از قابلیت اطمینان طولانی مدت و سادگی عملیاتی.
فرم نهایی
بسته شدن ، سفر به مجموعه نهایی VLLM ما به برخی تصمیمات عملی و واضح رسید. انتخاب unsloth/gemma-3-4b-it مدل انعطاف پذیری مورد نیاز ما را به ما داد. به جای استفاده از یک مدل از پیش کوتاه ، ما تصمیم گرفتیم که مقدار کمی پویا را با --quantization bitsandbytesبشر این رویکرد به ما اجازه می دهد تا حافظه GPU را بهتر مدیریت کنیم بدون اینکه ما را در محدودیت های سفت و سخت قرار دهیم.
ما تنظیم کردیم PYTORCH_CUDA_ALLOC_CONF به max_split_size_mb:64,expandable_segments:True به طور خاص برای مقابله با تکه تکه شدن حافظه CUDA. این تغییر به Pytorch اجازه می دهد تا حافظه GPU را به طور مؤثرتری اداره کند ، و خطاهای حافظه مورد آزار و اذیت را کاهش داده و مطمئن شود که همه چیز در طول جلسات طولانی به راحتی اجرا می شود.
با استفاده از --enforce-eager معلوم شد که بسیار مفید است. این باعث می شود اشکال زدایی آسانتر و رفتار GPU قابل پیش بینی تر شود. مطمئناً ، کمی سربار اضافه شده است ، اما عیب یابی ساده تر ارزش آن را داشت.
تصمیم به درپوش حداکثر طول مدل در 56،000 توکن با دقت در نظر گرفته شد. حتی اگر حافظه نهان KV ما هنوز جایی برای پس انداز داشته باشد ، این طول مانند تعادل مناسب احساس می شود – به اندازه کافی طولانی برای نیازهای ما بدون کند کردن عملکرد ، خراب می شود ، هنگامی که یک سریع به خصوص بزرگ تحت فشار قرار می گیرد یا پیچیدگی های غیر ضروری را اضافه می کند. همچنین در صورت نیاز ما اتاق را برای افزایش این حد در آینده فراهم کرد – اما در حال حاضر من به ثبات احتیاج داشتم تا بتوانم برخی از کارها را در طول شب انجام دهم!
نتایج
بنابراین ، آیا کار کرد؟
بله من اکنون گرافراگ را بیش از برخی از مجموعه های بسیار سنگین از اسناد با هزینه اصلی صفر (برق شامل نمی شود) اجرا کرده ام. نمودار دانش کاملاً تمیز می شود و بازیابی عالی است!
و در واقع ، در مقایسه با استفاده از OpenAI ، با وجود داشتن نرخ توکن در حدود 16t/s ، در واقع سریعتر است:
درباره نویسنده
دن بنیانگذار Mindlattice است که به نوسازی مناظر داده مشتری اختصاص داده شده است تا بتواند آن را فعال کند یادگیری ماشین و AI
او یک جانباز نوپا با بیش از 20 سال تجربه ارائه راه حل برای برخی از بزرگترین شرکت های استرالیا و انگلیس است.
منتشر شده از طریق به سمت هوش مصنوعی
