درون محاسبات هزینه رم برای جلوگیری از سقوط سرعت پاسخ‌دهی بردارها

اگر برای استقرار یک سیستم بازیابی اطلاعات برنامه‌ریزی می‌کنید، احتمالاً هزینه سخت‌افزاری را کمتر از آنچه هست تخمین زده‌اید. واقعیت این است که برای یک میلیون بردار استاندارد OpenAI، رم ۸ گیگابایتی که در ظاهر کافی به نظر می‌رسد، در محیط عملیاتی منجر به شکست کامل سیستم می‌شود.

بسیاری از توسعه‌دهندگان به اشتباه اندازه پاسخ JSON یک API را با فضای اشغال‌شده در پایگاه‌داده یکی می‌دانند. در حالی که یک میلیون بردار ۱۵۳۶-بعدی مدل OpenAI text-embedding-3-small تنها ۶.۱۴ گیگابایت فضای خام اشغال می‌کنند، اما برای حفظ عملکرد در محیط Production، به میزبانی با ۱۶ گیگابایت رم نیاز است. به نقل از راهنمای فنی TankDev، نادیده گرفتن سربار ایندکس و فضای مورد نیاز سیستم‌عامل منجر به فشار مداوم بر حافظه و سقوط شدید تأخیر در پاسخ‌دهی (p99 latency) می‌شود.

در واقعیت، نوع داده فیزیکی (Physical Datatype) مانند float32, float16 یا int8 است که مصرف واقعی رم را تعیین می‌کند. ارقام متنی و چارچوب‌های پروتکل (Protocol Framing) بر اندازه انتقال داده اثر می‌گذارند، اما بر فضای ذخیره‌سازی فیزیکی تأثیری ندارند. در یک خط لوله تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — محاسبه فضای خام بر اساس فرمول N × D × B انجام می‌شود. برای کسانی که به دنبال پیاده‌سازی‌های محلی و بهینه هستند، استفاده از مدل‌های سبک‌تر مانند EmbeddingGemma امکان جست‌وجوی معنایی آفلاین را حتی در مخازن گیت‌هاب فراهم کرده است.

در این فرمول، N تعداد بردارها، D تعداد ابعاد و B تعداد بایت‌های هر المان است. برای دقت float32، مقدار B برابر ۴ بایت است؛ برای float16 مقدار B برابر ۲ بایت و برای int8 یا SQ8 مقدار B برابر ۱ بایت است. برای تبدیل بایت‌های حاصل به گیگابایت اعشاری (Decimal GB)، باید عدد را بر 10^9 تقسیم کنید؛ اما برای گیبی‌بایت باینری (Binary GiB)، تقسیم بر 2^30 لازم است. این تمایز حیاتی است زیرا قیمت‌گذاری سرویس‌های ابری اغلب بر اساس GB است، در حالی که ابزارهای سیستم‌عامل مقادیر را به GiB نمایش می‌دهند که منجر به تفاوتی حدود ۷٪ می‌شود.

تصور کنید در حال گسترش یک پایگاه دانش هستید. اگر از float32 (۴ بایت) استفاده کنید، یک میلیون بردار ۱۵۳۶-بعدی مجموعاً ۶,۱۴۴,۰۰۰,۰۰۰ بایت یا ۶.۱۴۴ گیگابایت (۵.۷۲ گیبی‌بایت) فضا می‌گیرند. با این حال، این مقدار تنها داده‌های «خام» است. برای اینکه بتوانید روی این بردارها به‌صورت بهینه جست‌وجو کنید، به یک ایندکس نیاز دارید که رایج‌ترین آن‌ها گراف HNSW (Hierarchical Navigable Small World) است.

هزینه پنهان ایندکس‌های HNSW

ایندکس HNSW نقاط داده را از طریق یک گراف چندلایه متصل می‌کند تا جست‌وجوی نزدیک‌ترین همسایه سریع‌تر شود. این گراف سربار حافظه قابل‌توجهی ایجاد می‌کند که به تعداد بردارها و ضریب اتصال (M) وابسته است، نه تعداد ابعاد (D). در مقابل، برخی رویکردهای پیشرفته‌تر مانند مدل‌های گرافی در NylonME توانسته‌اند با تغییر ساختار حافظه، سقف ظرفیت گفتگوهای طولانی را جابه‌جا کنند.

• سربار گراف: مقاله اصلی HNSW پیشنهاد می‌کند که بسته به پیاده‌سازی، هر شیء بین ۶۰ تا ۴۵۰ بایت سربار (جدا از خود بردار) داشته باشد.
• تفاوت موتورها: پایگاه‌داده Qdrant هزینه HNSW را با فرمول N × M × 2 × 4 bytes × 1.2 محاسبه می‌کند. این ضرایب نشان‌دهنده لینک‌های دوطرفه، شناسه‌های چهار بایتی نقاط و فضای مدیریت لایه‌ها هستند. برای یک میلیون نقطه با M=16، این مقدار حدود ۱۵۳.۶ مگابایت و برای M=32 حدود ۳۰۷.۲ مگابایت است.
• مجموع نهایی: برای مدل کوچک OpenAI، مجموع بردارهای خام (۶.۱۴ گیگابایت) به‌اضافه گراف HNSW و ۲۵٪ فضای رزرو برای عملیات (Working Headroom)، به حدود ۷.۹ گیگابایت حافظه فعال (Resident Set) می‌رسد.
• تأثیر ابعاد: هیچ قاعده ثابتی وجود ندارد که HNSW همیشه ۲۰ تا ۵۰ درصد اندازه بردارها باشد. درصد اشغال حافظه توسط گراف در ابعاد پایین (مثلاً ۳۸۴) بزرگتر و در ابعاد بالا (مثلاً ۳۰۷۲) کوچکتر به نظر می‌رسد.

سطح‌بندی میزبان و ظرفیت عملیاتی

قرار دادن یک مجموعه داده ۷.۹ گیگابایتی در رم ۸ گیگابایتی، دستورالعمل قطعی برای شکست است. محیط‌های عملیاتی باید فضای پردازش‌های پایگاه‌داده، متادیتا، ایندکس‌های فیلتر و سیستم‌عامل را در نظر بگیرند. برای یک مجموعه RAG با ابعاد ۱۵۳۶، اگر هر نقطه به‌طور متوسط ۱ کیلوبایت داده همراه (Payload) داشته باشد، ۱ گیگابایت دیگر به فضای خام اضافه می‌شود. اگرچه لازم نیست تمام Payloadها در رم باشند، اما ایندکس‌های فیلتر «داغ» (Hot Filter Indexes) ممکن است نیاز به حضور در رم داشته باشند.

• سطح ایمن: برای یک میلیون بردار کوچک OpenAI، میزبان ۱۲ گیگابایتی حداقل است، اما ۱۶ گیگابایت برای محیط Production توصیه می‌شود تا از فشار حافظه جلوگیری شود.
• مقیاس مدل‌های بزرگ: برای مدل text-embedding-3-large با ۳۰۷۲ بعد، فضای خام به ۱۲.۲۹ گیگابایت (۱۱.۴۴ گیبی‌بایت) می‌رسد. با احتساب HNSW و فضای رزرو، مجموعه جست‌وجو به ۱۵.۶ گیگابایت می‌رسد که نیازمند میزبان ۲۴ تا ۳۲ گیگابایت رم است.
• مدل‌های کوچک: استفاده از All-MiniLM-L6-v2 با ۳۸۴ بعد تنها به ۱.۵۴ گیگابایت (۱.۴۳ گیبی‌بایت) فضای خام نیاز دارد و در میزبان ۴ تا ۸ گیگابایتی به‌راحتی جای می‌گیرد.
• کلاس BGE-base: بردارهای ۷۶۸ بعدی به ۳.۰۷ گیگابایت (۲.۸۶ گیبی‌بایت) فضای خام و حدود ۴ گیگابایت فضای جست‌وجو نیاز دارند که در رم ۸ گیگابایتی می‌گنجد.

کوانتش: معامله دقت در برابر رم

کوانتش (Quantization) — که شبیه تبدیل یک عکس باکیفیت به فرمت JPEG برای کاهش حجم است — می‌تواند کپی بردارها را با تبدیل float32 به int8 (Scalar Quantization یا SQ8) تا ۷۵٪ کاهش دهد. این کار باعث می‌شود لایه جست‌وجو برای یک میلیون بردار OpenAI به ۲.۱ تا ۲.۵ گیگابایت کاهش یابد. Qdrant از ساختاری ترکیبی استفاده می‌کند که در آن کپی کوانتیده در رم سنجاق (Pinned) می‌شود، در حالی که بردارهای اصلی برای بازرتبه‌بندی (Rescoring) روی دیسک باقی می‌مانند.

اما کوانتش رایگان نیست و باعث افت کیفیت می‌شود. راهنمای فنی هشدار می‌دهد که ادعاهای «افت ۱ تا ۲ درصدی در Recall» قابل تعمیم نیستند؛ زیرا افت واقعی به توزیع بردارها، متریک فاصله، کوانتیل و عمق بازرتبه‌بندی بستگی دارد. برای بهبودی این دقت بدون افزایش تأخیر، رویکردهای جست‌وجوی ترکیبی (Hybrid Search) جایگزین‌های کارآمدی برای سیستم‌های بازرتبه‌بندی پیچیده ارائه می‌دهند. گزینه‌های دیگر عبارت‌اند از:

• دقت ترکیبی (float16): کاهش ۵۰ درصدی حجم (2 × D بایت). pgvector از این قابلیت از طریق نوع halfvec برای ابعاد تا ۴۰۰۰ پشتیبانی می‌کند.
• کوانتش باینری: فشرده‌سازی شدید (D/8 بایت) که معمولاً برای تولید کاندیداهای اولیه و سپس بازرتبه‌بندی با دقت کامل استفاده می‌شود.
• کوانتش محصول (PQ): از فرمول ceil(subquantizers × bits / 8) بایت به ازای هر بردار به‌اضافه Codebookها استفاده می‌کند. این روش نیازمند آموزش، تنظیم دقیق و اعتبارسنجی کیفیت است.

رفتارهای خاص پایگاه‌داده‌ها

موتورهای مختلف مدیریت حافظه متفاوتی دارند. PostgreSQL با افزونه pgvector درون مکانیزم صفحات و ایندکس‌های پستگرس عمل می‌کند. این سیستم به shared_buffers (که برای سرورهای اختصاصی ۲۵٪ رم توصیه می‌شود) و کش صفحات سیستم‌عامل متکی است. توجه داشته باشید که effective_cache_size تنها یک فرض برای برنامه‌ریز (Planner) است و حافظه‌ای رزرو شده نیست.

• محدودیت‌های pgvector: ایندکس HNSW در pgvector تنها تا ۲۰۰۰ بعد را پشتیبانی می‌کند. بنابراین خروجی ۳۰۷۲ بعدی مدل large را نمی‌توان مستقیماً به عنوان vector(3072) ایندکس کرد. کاربران باید یا ابعاد کمتری (۲۰۰۰ یا کمتر) را از OpenAI درخواست کنند یا از ایندکس halfvec(3072) استفاده کنند.
• عملکرد: ساخت HNSW زمانی سریع‌تر است که گراف در maintenance_work_mem جای بگیرد. مقادیر پیش‌فرض آن M=16 و ef_construction=64 است.

موتورهای تخصصی مثل Qdrant و Milvus کنترل دقیق‌تری دارند و ساختارها را به سه دسته «سنجاق‌شده» (Pinned)، «کش‌شده» (Cached) و «سرد» (Cold) تقسیم می‌کنند. ساختارهای کش‌شده و سرد از mmap استفاده می‌کنند. Milvus کنترل‌های mmap جداگانه‌ای برای فیلدهای برداری و ایندکس‌ها ارائه می‌دهد. این مدل اجازه می‌دهد کپی کوانتیده در رم بماند و اصل داده‌ها فقط برای نهایی کردن نتایج (Top-candidate rescoring) از دیسک خوانده شوند.

خطر Swap دیسک

وقتی ایندکس برداری از رم موجود بیشتر شود، سیستم به mmap یا کش صفحات برای خواندن از دیسک متکی می‌شود. چون پیمایش HNSW شامل خواندن‌های تصادفی و پراکنده برای دسترسی به همسایه‌ها است، هر Cache Miss باعث افزایش تأخیر می‌شود. اگر مجموعه کاری (Working Set) به‌طور قابل‌توجهی بزرگتر از رم باشد، خطاهای صفحه (Major Page Faults) و عمق صف دیسک افزایش می‌یابد.

در این سناریوها، تأخیر p50 ممکن است خوب به نظر برسد، اما تأخیر p99 (تجربه ۱٪ کندترین کاربران) سقوط می‌کند. پرش از ۵ میلی‌ثانیه به ۴۰۰ میلی‌ثانیه بسته به سرعت NVMe و هم‌زمانی درخواست‌ها محتمل است. اگر Swap فعال باشد، صفحات Heap پایگاه‌داده نیز ممکن است Swap شوند و وضعیت را بدتر کنند. مانیتورینگ Major Page Faults و Read IOPS بسیار حیاتی‌تر از مانیتورینگ ساده نرخ Cache Hit است.

مقایسه IVFFlat در برابر HNSW

ایندکس IVFFlat معمولاً سربار کمتری دارد چون لینک‌های گراف را ذخیره نمی‌کند. این روش بردارها را در لیست‌هایی دور مراکز (Centroids) گروه‌بندی می‌کند و در هر پرس‌وجو، تعداد nprobe لیست را اسکن می‌کند. کتابخانه Faiss هزینه IVFFlat را تقریباً 4D + 8 بایت به ازای هر بردار تخمین می‌زند، در حالی که HNSW Flat به 4D به‌اضافه لینک‌های گراف نیاز دارد.

در حالی که IVFFlat از نظر حافظه برای ایندکس بهینه‌تر است، اما برای آموزش به داده‌های نماینده نیاز دارد و در صورت تغییر توزیع داده‌ها باید بازسازی شود. در مقابل، HNSW بدون نیاز به مرحله آموزش، به‌صورت آنلاین رشد می‌کند و موازنه سرعت-دقت بهتری برای جست‌وجوی تعاملی ارائه می‌دهد، هرچند حافظه گراف بیشتر و سرعت ساخت کمتری دارد.

تکثیر و هزینه کل مالکیت (TCO)

برنامه‌ریزی ظرفیت باید در سطح خوشه (Cluster) انجام شود. ضریب تکثیر (Replication) دو، تقریباً حجم کپی‌های بردار و ایندکس را در کل خوشه دوبرابر می‌کند. شاردها (Shards) داده‌ها را توزیع می‌کنند، اما رپلیکاها تاب‌آوری را فراهم می‌کنند؛ در صورت خرابی یک گره، گره‌های باقی‌مانده باید بار را جذب کنند.

هزینه‌های سرویس‌های مدیریت‌شده همچنین تحت تأثیر موارد زیر است:

• سطوح IOPS: بردارهای سرد روی دیسک برای جلوگیری از پرش تأخیر در هنگام خواندن‌های تصادفی به IOPS بالاتری نیاز دارند.
• سربار عملیاتی: ادغام سگمنت‌ها (Segment Merges)، Snapshotها و مهاجرت‌های باز-برداری باعث ایجاد پیک‌های موقت در رم و دیسک می‌شوند. برای مثال، بهینه‌سازهای Qdrant می‌توانند در حین عملیات، سگمنت‌های جدیدی ایجاد کنند.
• موازنه CPU: استفاده از PQ رم را کاهش می‌دهد اما بار CPU را برای رمزگشایی (Decompression) افزایش می‌دهد. همچنین مقادیر بالاتر ef_search باعث بهبود Recall می‌شود اما بار CPU و تأخیر را افزایش می‌دهد.

چارچوب تصمیم‌گیری نهایی

در نهایت، این راهنما استدلال می‌کند که «بایت بر هر بردار» تنها معیار صادقانه برای مقایسه هزینه‌های پایگاه‌داده است. مهندسان نباید بر اساس ضرایب بازاری تصمیم بگیرند، بلکه باید از بنچمارک‌های اندازه‌گیری شده با صدها هزار بردار نماینده استفاده کنند.

برای تبدیل بایت به هزینه ماهانه، موازنه بین کاهش ابعاد (D) که حجم خام را نصف می‌کند اما ممکن است کیفیت بازیابی را کاهش دهد، و استفاده از SQ8 که رم را کم می‌کند اما خواندن از دیسک را زیاد می‌کند، بسنجید. همچنین ادغام با pgvector باعث حذف یک سرویس مجزا می‌شود اما ترافیک تراکنشی و پرس‌وجوهای ANN را مجبور می‌کند از CPU و کش مشترک استفاده کنند.

مهندسان باید مقدار index_size / live_vector_count را محاسبه کرده و resident_RSS / live_vector_count را در کنار تأخیر p95 و Recall@k منتشر کنند. این کار یک تخمین ظرفیت را به یک تصمیم مهندسی تکرارپذیر تبدیل می‌کند.

گام بعدی شما

• محاسبه دقیق index_size / live_vector_count برای تخمین واقعی رم.
• مانیتورینگ Major Page Faults و Read IOPS به‌جای اکتفا به نرخ Cache Hit.
• تست تأخیر p99 در شرایطی که حجم داده‌ها ۱۰٪ بیشتر از رم در دسترس است.

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