EQVPS

RAG באחסון-עצמי בקנה-מידה: כמה RAM אינדקס וקטורי באמת אוכל

9 באוג׳ 2026 · 2 דק' קריאה · EQVPS Team

כל מדריך RAG רץ על מחשב נייד עם כמה מאות מסמכים, וזה מרגיש ללא מאמץ. ואז אתם מכוונים אותו לקורפוס אמיתי — המסמכים של חברה, שנים של תיקטים, בסיס-ידע — ופתאום זיכרון הוא כל השיחה.

RAG לא מתרחב לפי CPU. הוא מתרחב לפי RAM.

למה האינדקס רוצה זיכרון

אחזור עובד על ידי הפיכת כל chunk של טקסט ל-embedding — וקטור, כמה מאות עד כמה אלפי מספרים ארוך. חיפוש אומר להשוות את וקטור השאילתה שלכם מול כולם, מהר. "מהר" היא מילת המפתח: להשהיה נמוכה האינדקס צריך לחיות ב-RAM. על דיסק זה עובד, אבל כל שאילתה משלמת קנס, ואחזור בהשהיה-נמוכה היה הנקודה של אחסון-עצמי מלכתחילה.

אז חשבון הזיכרון מתרחב עם שני דברים: כמה chunks יש לכם, וכמה רחב כל וקטור.

מספרים אמיתיים, בערך

מדדו את שלכם — מימד וסוג אינדקס מזיזים את זה הרבה — אבל כתחושת התחלה:

מערכת רב-סוכנית שגם מחזיקה אינדקס גדול עורמת את שתי העלויות על אותו ארגז — כך תוכנית של 32 GB הופכת ל-64 GB בשקט.

בחירת המנוע, בקצרה

אם אתם כבר מריצים Postgres, pgvector היא האופציה עם הכי פחות מאמץ — זו הרחבה, לא שירות חדש לעשות לו בייביסיטר. כשיש לכם מיליוני וקטורים ואתם רוצים חיפוש מסונן מהיר, מנוע ייעודי כמו Qdrant או Weaviate מרוויח את התהליך הנפרד. אל תעשו over-engineering ביום הראשון; הריצו את מה שאתם כבר מפעילים ופצלו כשהחיפוש באמת מאט.

למה בכלל לאחסן-בעצמי

שתי סיבות שאנשים באמת עושים את זה, ואף אחת מהן אינה "כדי לחסוך כמה דולרים":

פרטיות. embeddings אינם מופשטים — הם מקודדים את הטקסט שממנו באו. המסמכים שלכם, התוכן של הלקוחות שלכם, ההערות הפנימיות שלכם, הפכו לווקטורים ונשלחו לשרתים של צד שלישי. אחסון-עצמי שומר את זה על מכונה שאתם שולטים בה. אם הנתונים רגישים מספיק שאתם גם משלמים בקריפטו ללא KYC, ענן וקטורי מנוהל מבטל את כל הנקודה.

עלות קבועה. שירותים וקטוריים מנוהלים מחייבים לפי וקטורים מאוחסנים ושאילתות שרצות. VPS הוא מספר חודשי אחד ואתם יכולים להכות בו כמה שתרצו. בקנה-מידה, צפוי מנצח נמדד.

מה זה אומר למדידה

התחילו על ידי מדידת הקורפוס שלכם, לא על ידי ניחוש. השיגו את ספירת ה-embeddings והמימד שלכם, טענו מדגם, צפו בזיכרון-התושב, גזרו. ואז בחרו תוכנית עם מרווח לאינדקס בתוספת כל מה שסביבו — האפליקציה, לקוח המודל, מקום לגדול.

לכל דבר מעבר לכמה מיליוני וקטורים המוחזקים בפרטיות, קו ה-Pro מריץ 32 עד 80 GB עם IP ייעודי וגיבויים לילִיים, מה שחשוב כשהאינדקס הוא המוצר ואיבודו כואב.

שאלות נפוצות

למה RAG צריך כל כך הרבה RAM?

חיפוש וקטורי מהיר רוצה את האינדקס תושב בזיכרון. כל chunk של מסמך הופך ל-embedding — וקטור של כמה מאות עד כמה אלפי floats — ובמיליוני chunks זה מצטבר. דחפו את האינדקס לדיסק והשהיית החיפוש קופצת; לשמור את כל הסיבה שאיחסנתם-בעצמכם (מהירות + שליטה) אומר לשמור אותו ב-RAM.

כמה RAM לקורפוס נתון?

תחושה גסה: כמה מאות אלפי embeddings יושבים בסדר ב-2–4 GB. מיליונים בודדים, עם האפליקציה ומערכת ההפעלה סביבם, ואתם ב-16–32 GB. עשרות מיליונים או וקטורים בעלי מימד-גבוה ואתם בתוך 48–80 GB, ומעבר לזה אתם מפצלים על פני שרתים. מימד וסוג אינדקס מנדנדים את זה הרבה, אז מדדו את שלכם.

pgvector או מנוע ייעודי כמו Qdrant?

אם אתם כבר מריצים Postgres, pgvector הוא הנתיב עם הכי פחות מאמץ — הרחבה אחת, מסד נתונים אחד. למיליוני וקטורים עם סינון כבד, מנוע בנוי-למטרה מרוויח את השירות הנפרד שלו. התחילו עם מה שאתם כבר מפעילים; עברו רק כשהחיפוש נעשה איטי.

למה לאחסן-בעצמי במקום שירות וקטורי מנוהל?

שתי סיבות אמיתיות: ה-embeddings שלכם לעתים קרובות מקודדים נתונים פרטיים (מסמכים, הערות, תוכן לקוחות), ואחסון-עצמי שומר את זה על שרת שאתם שולטים בו. וזה עלות קבועה — שירותים מנוהלים מודדים לפי וקטורים ושאילתות, VPS הוא מספר חודשי אחד ללא חשבון לכל-שאילתה.

← חזרה לבלוגראו תוכניות ומחירים →

תגובות

אין עדיין תגובות. היו הראשונים.

השאירו תגובה

התגובות עוברות מודרציה לפני שהן מופיעות.