দুশো নথি সহ একটি ল্যাপটপে RAG ডেমো অনায়াস লাগে। তারপর আপনি সেটিকে একটি আসল corpus-এর দিকে তাক করেন — একটি কোম্পানির নথি, বছরের পর বছরের টিকিট, একটি সত্যিকারের knowledge base — আর পুরো ব্যাপারটা একটি memory সমস্যা হয়ে যায়। CPU সমস্যা নয়। memory-র।
এই অংশটা বেশিরভাগ হোস্টিং পেজ এড়িয়ে যায়: দ্রুত retrieval চায় index-টি RAM-এ থাকুক। টেক্সটের প্রতিটি chunk হয়ে যায় একটি embedding — কয়েকশো থেকে কয়েক হাজার সংখ্যা-প্রশস্ত একটি vector — আর search মানে আপনার query-কে সব কটির সাথে দ্রুত তুলনা করা। ডিস্কে কাজ করে, কিন্তু প্রতিটি query একটি latency-কর দেয়, আর কম-latency retrieval-ই তো প্রথমে সেলফ-হোস্ট করার কারণ ছিল।
sizing-এর হিসাব, সৎভাবে
নিজের corpus মাপুন — dimension ও index-টাইপ এটিকে অনেকটা দোলায় — তবে শুরুর অনুভূতি হিসেবে:
- কয়েক লক্ষ embedding — 2–4 GB। একটি ব্যক্তিগত knowledge base। এর জন্য Pro লাগে না; একটি ছোট প্ল্যানই ঠিক।
- কয়েক মিলিয়ন — চারপাশে app, model client ও OS সহ, ধরুন 16–32 GB। একটি গুরুতর কোম্পানি knowledge base। এখানেই Pro-32 বা Pro-48 মানাতে শুরু করে।
- কয়েক কোটি, বা high-dimension vector — 48 GB ও তার বেশি, আর ~80 GB-র পরে আপনি index-টি একাধিক সার্ভারে ভাগ করছেন। বড় নথি-ভান্ডার, multi-tenant retrieval, একসাথে একাধিক index গরম।
আপনি বিস্তারিত চাইলে আমরা সম্পূর্ণ RAM curve এখানে লিখেছি।
কেন high-memory এবং no-KYC একসাথে
48 GB RAM ভাড়া নেওয়া সহজ। ক্রিপ্টো ও পরিচয়-যাচাই ছাড়া ভাড়া নেওয়া নয় — যেসব হোস্ট গুরুতর memory সস্তায় বেচে তার বেশিরভাগ তা করে একটি কার্ড ও একটি KYC ফর্মের আড়ালে। আপনার embeddings বিমূর্ত সংখ্যা নয়; এরা এনকোড করে সেই টেক্সট যা থেকে এসেছে। আপনার নথি, আপনার গ্রাহকের কনটেন্ট, vector-এ রূপান্তরিত। সেই ডেটা যদি এতই সংবেদনশীল যে আপনি প্রাইভেটভাবে পরিশোধ করছেন, একটি managed vector cloud পুরো উদ্দেশ্যটাই নষ্ট করে — আর তেমনই করে সেই হোস্ট যে সার্ভারটিকে আপনার পরিচয়ের সাথে বাঁধে।
সেই সংমিশ্রণ — high memory, dedicated IP, ক্রিপ্টো, no KYC, রাত্রিকালীন ব্যাকআপ — এর জন্যই Pro লাইন। এটি প্রতি গিগাবাইটে সবচেয়ে সস্তা নয়, আর প্রাইভেসি না লাগলে অন্যত্র RAM সস্তায় পাবেন। কিন্তু index-টি যদি ই আপনার প্রোডাক্ট হয় আর সেটি বেরোতে না পারে, এটাই সেই আকার যা মানায়।
কোথায় শুরু করবেন
index plus চারপাশের সবকিছুর জন্য headroom সহ একটি প্ল্যান বাছুন — app, model client, বাড়ার জায়গা। বেশিরভাগ আসল corpus-এর জন্য সেটি Pro-48 (48 GB); বড় একটি যায় Pro-64 বা Pro-80-তে। আগে একটি নমুনা load করুন, memory দেখুন, যে সংখ্যা মেপেছেন তা থেকে size বাছুন — যে সংখ্যাকে ভয় পেয়েছিলেন তা থেকে নয়।
আপনার retrieval যদি একটি বড় agent সিস্টেমের অংশ হয়, একই বক্স প্রায়ই agent fleet-ও ধরে রাখে — এভাবেই একটি 48 GB প্ল্যান নিঃশব্দে 64 GB হয়ে যায়।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।