আমাদের Ollama ও ছোট মডেলের জন্য আলাদা একটি পেজ আছে — সেটি $12 CPU বক্স যা 1B–8B ও embeddings চালায়। এই পেজ অন্য প্রান্ত: সেই মডেলগুলো এত বড় যে CPU নয়, RAM-ই আপনাকে থামায়।
শুরুতেই সৎ থাকি, সব জায়গার মতোই: আমাদের সার্ভার CPU-only, কোনো GPU নেই। এখানে একটি বড় মডেল ধীরে চলে। একটি 30B মডেলে দ্রুত ইন্টারঅ্যাক্টিভ চ্যাট চাইলে GPU হোস্ট দরকার — ভিন্ন প্রোডাক্ট, ভিন্ন প্রোভাইডার। একটি high-memory CPU বক্স যা ভালো করে তা হলো একটি বড় quantized মডেল প্রাইভেটভাবে চালানো — এমন কাজের জন্য যা চ্যাট উইন্ডো নয়।
RAM-এর হিসাব
মডেলটি memory-তে বসে, quantized হোক বা না, plus context ও runtime-এর overhead:
- 13B, 4-bit — মোটামুটি 10–16 GB। একটি মাঝারি প্ল্যানেই চলে।
- 30B-শ্রেণির, quantized — quantization অনুসারে 24–48 GB। এটি Pro-32 থেকে Pro-64-এর এলাকা।
- আরও বড় বা উচ্চ-নির্ভুলতা — 64–80 GB, আর 80 GB-র পরে আমাদের কোনো একক বক্সে আঁটে না। এখানে Pro-80 হলো সীমা।
এজন্যই "একটি বড় local মডেল চালাই" আসলে একটি high-memory প্রশ্ন। মডেলটি ই হলো memory footprint। একই হোস্টে একটি RAG index যোগ করুন — সংখ্যাগুলো জমতে থাকে।
যেখানে private-first সত্যিই জেতে
মূল কথাটা গতি নয়, খরচও নয় — কিছু ডেটা বেরোতেই পারে না। আইনি নথি। চিকিৎসা রেকর্ড। মালিকানাধীন কোড। যেখানে prompt একটি তৃতীয় পক্ষের API-তে পাঠানোই অসম্ভব। যে ধীর মডেল পুরোপুরি আপনার মেশিনে চলে, সে সেই দ্রুত মডেলকে হারায় যা আপনার পাঠানো সব log করে। আমরা পূর্ণ চিত্রটি এখানে লিখেছি।
আর ডেটা যদি এতই সংবেদনশীল হয়, পেমেন্টও সম্ভবত প্রাইভেট হওয়া উচিত। বক্সটি ক্রিপ্টো ও no KYC-তে ভাড়া নিলে পুরো চেইন — সার্ভার, মডেল, prompt, বিলিং — কারো পরিচয়-রেকর্ডের বাইরে থাকে। এটাই মূল প্রস্তাব: সস্তা ইনফারেন্স নয়, বরং এমন ইনফারেন্স যা আর কেউ দেখতে পায় না।
কী বাছবেন
context-এর জায়গা সহ একটি 30B-শ্রেণির মডেলের জন্য Pro-64 (64 GB) আরামদায়ক পছন্দ; আঁটসাঁট quantization Pro-32 বা Pro-48-এ আঁটে, বড়টি যায় Pro-80-তে। আগে মডেল load করুন, resident memory দেখুন, মেপে-নেওয়া সংখ্যা থেকে size বাছুন। আর প্রত্যাশা ঠিক রাখুন: এটি প্রাইভেট batch ইনফারেন্স, দ্রুত চ্যাট উইন্ডো নয়।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।