নিজের সার্ভারে Private LLM চালানো: হার্ডওয়্যার, RAG ও নিরাপত্তার বাস্তব গাইড

কোনো ক্লায়েন্ট যখন বলেন তাঁদের ডেটা ক্লাউডে যেতে পারবে না, অথচ তাঁরা একটি AI অ্যাসিস্ট্যান্ট চান, তখন আমরা তাঁদের নিজের হার্ডওয়্যারে একটি প্রাইভেট large language model (LLM) চালাই। এটি বেশিরভাগ মানুষের ধারণার চেয়ে সহজ - ডেটা সেন্টার বা গবেষণা দল লাগে না। এই লেখায় আছে সেই বাস্তব গাইড যা আরও বেশি মানুষের হাতে থাকা উচিত ছিল: আসলে কী হার্ডওয়্যার লাগে, কীভাবে মডেল বাছবেন, RAG দিয়ে নিজের ডেটা থেকে উত্তর আনবেন কীভাবে, আর যে নিরাপত্তা কখনও বাদ দেওয়া যায় না। এটি তত্ত্ব থেকে নয়, করে দেখা থেকে লেখা।

প্রাইভেট LLM চালানো আসলে কী

প্রাইভেট LLM জনপ্রিয় AI অ্যাসিস্ট্যান্টগুলোর পেছনের একই ধরনের প্রযুক্তি, তবে ইন্টারনেটের ওপারে কল করার বদলে আপনি নিজেই হোস্ট করেন। এটি আপনার মালিকানার বা প্রাইভেটভাবে ভাড়া নেওয়া একটি সার্ভারে চলে, আপনার নিয়ন্ত্রিত নেটওয়ার্কের ভেতরে। প্রশ্ন ঢোকে, উত্তর বের হয়, আর কোনোটিই আপনার পরিবেশ ছাড়ে না।

ক্লায়েন্টদের আমি সহজ মডেলটি দিই: আপনি স্থানীয়ভাবে একটি সক্ষম, সাধারণ-উদ্দেশ্যের ভাষা-ইঞ্জিন চালাচ্ছেন, আর প্রশ্নের সময় সেটিকে নিজের ডেটা খাওয়াচ্ছেন। ইঞ্জিনটি মডেল; ডেটা আপনার থাকে। বাকি সব প্লাম্বিং আর শৃঙ্খলা।

আসলে যে হার্ডওয়্যার লাগে

এখানেই মানুষ সবচেয়ে বেশি অতিরিক্ত ধরে নেয়। সার্ভারের র‍্যাক লাগে না। সবচেয়ে বড় নিয়ামক মডেলের আকার, যা বিলিয়ন প্যারামিটারে মাপা হয়।

কাজ	মডেল সাইজ	হার্ডওয়্যার
শ্রেণিবদ্ধকরণ, সারাংশ, ড্রাফট, ডকুমেন্ট থেকে উত্তর	3B - 8B	একটি আধুনিক GPU (~24GB)
গভীর যুক্তি, বড় কনটেক্সট	13B - 34B	এক বা দুটি বড় GPU
সবচেয়ে ভারী যুক্তি	70B+	একাধিক GPU / ডেডিকেটেড সার্ভার

আমার সৎ পরামর্শ: যে কাজটি করে এমন সবচেয়ে ছোট মডেল দিয়ে শুরু করুন। তা সস্তা, দ্রুত সাড়া দেয়, আর সহজে সিকিওর করা যায়। আমি দেখেছি টিমগুলো "বড় মানেই ভালো" ধরে নিয়ে প্রয়োজনের চেয়ে অনেক বেশি ক্যাপাসিটি কিনে ফেলে। বেশিরভাগ অভ্যন্তরীণ ব্যবসায়িক কাজে তা মোটেই সত্য নয়।

কেবল-CPU নিয়ে একটি কথা: হালকা বা ব্যাচ কাজে চলে, কিন্তু সাড়া এত ধীর যে মানুষ টুলটি ব্যবহার বন্ধ করে দেয়। ইন্টারেক্টিভ ব্যবহার চাইলে GPU-র বাজেট রাখুন। এটি আমি নিজে GPU-বিহীন সার্ভারে স্থানীয় মডেল পরীক্ষা করে শিখেছি - সক্ষম, কিন্তু ব্যবহারযোগ্য হওয়ার জন্য বড্ড ধীর।

মডেল বাছাই ও চালানো

প্রাইভেটভাবে চালানোর মতো ওপেন মডেলের একটি সুস্থ ইকোসিস্টেম আছে, আর সেগুলো সার্ভ করার টুলিংও সহজ। একটি লোকাল রানটাইম দিয়ে কয়েকটি কমান্ডেই মডেল টেনে এনে অভ্যন্তরীণ API-তে খোলা যায়।

# Example: serve an open model locally with a lightweight runtime
ollama pull llama3.1:8b
ollama run llama3.1:8b

# It exposes a local API your applications call - nothing leaves the host
curl http://localhost:11434/api/generate \
  -d '{"model":"llama3.1:8b","prompt":"Summarise this policy: ..."}'

মূল কথা - আপনার অ্যাপ্লিকেশন আপনার নিজের নেটওয়ার্কের ভেতরের একটি এন্ডপয়েন্টের সঙ্গে কথা বলে। কোনো প্রম্পট, বা সেই প্রম্পটের ডেটা, বাইরের প্রোভাইডারে যায় না।

Quantization: বড় মডেল কীভাবে সাশ্রয়ী GPU-তে ধরে

উপরের সাইজিং টেবিল কাজ করে কেবল quantization-এর কারণে, তাই এর একটি সহজ-ভাষার ব্যাখ্যা প্রাপ্য। Quantization মডেলের weight-গুলো কম precision-এ সংরক্ষণ করে - সাধারণত 16-bit-এর বদলে 4-bit - যাতে মেমরির ব্যবহার প্রায় এক-চতুর্থাংশে নেমে আসে, বিনিময়ে মানের সামান্য ছাড়।

আমি যে মোটা হিসাব ব্যবহার করি: একটি 4-bit মডেলের লাগে তার প্যারামিটার সংখ্যার প্রায় অর্ধেক পরিমাণ গিগাবাইট, সঙ্গে কনটেক্সটের জন্য বাড়তি জায়গা। তাই একটি 8B মডেলের চাই প্রায় 5-6GB GPU মেমরি, 13B-র 8-10GB, আর 70B quantized হয়েও 40GB-র বেশি দাবি করে। এই বাড়তি জায়গাটা জরুরি - RAG পাইপলাইনে লম্বা ডকুমেন্ট দ্রুত মেমরি খেয়ে ফেলে, আর উত্তরের মাঝপথে মেমরি ফুরানো একটি কুৎসিত ব্যর্থতা।

বাস্তবে আমি দৈনন্দিন অ্যাসিস্ট্যান্টের জন্য ডিফল্ট হিসেবে 4-bit রাখি, আর ক্লায়েন্টের কাজে দৃশ্যমান মানের ক্ষতি দেখা দিলে 8-bit-এ উঠি - সাধারণত নিখুঁত extraction বা non-English টেক্সটে, যেখানে আগ্রাসী quantization সবচেয়ে বেশি কামড়ায়। সিদ্ধান্তের আগে নিজের ডকুমেন্ট দিয়ে, নিজের ভাষায় পরীক্ষা করুন। ইংরেজি ট্রিভিয়ার benchmark স্কোর বলবে না একটি quantized মডেল একটি বাংলা ইনভয়েস কেমন সামলায়।

নিজের ডেটা থেকে উত্তর: RAG

একটি বেস মডেল সাধারণ ভাষা জানে, আপনার দাম, পলিসি বা রোগীর রেকর্ড জানে না। এই ফাঁক পূরণের কৌশল retrieval-augmented generation। সহজ কথায়: প্রশ্ন এলে সিস্টেম আগে আপনার নিজের ডেটা থেকে সবচেয়ে প্রাসঙ্গিক অংশগুলো খুঁজে বের করে, তারপর সেগুলো প্রশ্নসহ মডেলকে দেয়, ফলে উত্তরটি আপনার তথ্যে ভিত্তি করে হয়।

রিট্রিভাল ধাপটি আপনার ডকুমেন্টের ওপর একটি vector search ব্যবহার করে। আমি প্রায়ই এটি ডেটাবেজের ভেতরেই রাখি - Oracle-এর in-database vector ও AI ফিচার দিয়ে embedding সংরক্ষণ ও similarity search চালানো যায় ঠিক যেখানে ডেটা আগে থেকেই আছে, ফলে পুরো পাইপলাইন on-premise থাকে। এই প্যাটার্ন আমি Oracle 26ai দিয়ে ERP ডেটায় AI অ্যাসিস্ট্যান্ট লেখায় বর্ণনা করেছি, আর বৃহত্তর সক্ষমতাটি Oracle Database 26ai লেখায়।

RAG-এর সৌন্দর্য হলো আপনি কখনও মডেল রি-ট্রেন করেন না। ডকুমেন্ট যোগ বা হালনাগাদ করেন, রিট্রিভাল স্তর তা তুলে নেয়, আর উত্তর হালনাগাদ থাকে - মডেল স্পর্শ না করেই।

খরচের ছবি

On-premise খরচের ধরন উল্টে দেয়। ক্লাউড AI টোকেন-প্রতি বিল করে, তাই বেশি ব্যবহৃত সফল টুল প্রতি মাসে দামি হয়। প্রাইভেট সেটআপে বড় একটি প্রাথমিক হার্ডওয়্যার খরচ, তারপর ছোট, স্থির চলতি খরচ - বিদ্যুৎ, রক্ষণাবেক্ষণ, আর দেখাশোনার লোক।

নিয়মিত ব্যবহৃত টুলের জন্য স্থির মডেল সাধারণত এক-দুই বছরে জিতে যায় এবং বাজেট অনুমানযোগ্য করে। মাঝেমধ্যের, কম-পরিমাণ ব্যবহারে ক্লাউড হয়তো এখনও সস্তা। ঠিক এ কারণেই আমি সবকিছু এক দিকে ঠেলে না দিয়ে প্রতিটি workload সচেতনভাবে বসাই।

যে নিরাপত্তা চেকলিস্ট আমি বাদ দিই না

AI ঘরের ভেতরে চালালেই তা আপনাআপনি সিকিওর হয় না - বরং নিরাপত্তা তখন আপনার দায়িত্ব হয়ে দাঁড়ায়, আর সেটাই আসল কথা। প্রতিটি ডিপ্লয়মেন্টে আমি এগুলো নিশ্চিত করি:

• অ্যাক্সেস কন্ট্রোল: কেবল অনুমোদিত ব্যবহারকারী ও সিস্টেম মডেলকে প্রশ্ন করতে পারে, আর প্রতিটি অনুরোধ লগ হয়।
• নেটওয়ার্ক আইসোলেশন: মডেল সার্ভার অভ্যন্তরীণ সেগমেন্টে থাকে, কখনও উন্মুক্ত ইন্টারনেটে নয়।
• ডেটা স্কোপিং: রিট্রিভাল স্তর ঠিক কী পড়তে পারবে তা ঠিক করুন, আর মডেলের যা কখনও দেখা উচিত নয় তা মাস্ক বা বাদ দিন।
• প্যাচিং: মডেল সার্ভার ও তার নির্ভরতা যেকোনো গুরুত্বপূর্ণ সিস্টেমের মতোই প্যাচ হয় - এই শৃঙ্খলা আমি ডেটাবেজ সিকিউরিটি হার্ডেনিং থেকে নিয়ে আসি।
• ব্যাকআপ: কনফিগারেশন ও ডকুমেন্ট ইনডেক্স ব্যাকআপ রাখুন যাতে দ্রুত পুনর্গঠন করা যায়।

আমার প্রথম ডিপ্লয়মেন্টে যা ভেঙেছিল - আর যে রুটিন তা ঠিক করেছে

আমার প্রথম on-premise ডিপ্লয়মেন্ট আমাকে তিনটি নির্দিষ্ট জায়গায় নত করেছিল, আর আমি সেগুলো ভাগ করছি কারণ এই তিনটিই বেশিরভাগ টিমকে ধরে।

প্রথমত, concurrency। এক ব্যবহারকারীর জন্য মডেল চমৎকার চলছিল, কিন্তু দ্বিতীয় ও তৃতীয়জন একসঙ্গে প্রশ্ন করতেই ভেঙে পড়ল - এক সেশনের জন্য যে GPU মেমরি স্বচ্ছন্দ ছিল, একসঙ্গে তিনটি কনটেক্সটের জন্য তা ছিল না। সমাধানটি নিরস: সার্ভিং স্তরে একসঙ্গে চলা অনুরোধের সীমা বেঁধে বাকিগুলো কিউতে রাখা, যাতে সিস্টেম ক্র্যাশে না নেমে বড়জোর ধীরে নামে।

দ্বিতীয়ত, বাসি উত্তর। আমরা পলিসি ডকুমেন্ট হালনাগাদ করলেও রিট্রিভাল ইনডেক্সে পুরনো সংস্করণ রয়ে গিয়েছিল, ফলে অ্যাসিস্ট্যান্ট আত্মবিশ্বাসের সঙ্গে একটি বাতিল পলিসি উদ্ধৃত করছিল। এখন প্রতিটি ডকুমেন্ট আপডেট re-indexing চালু করে, আর ইনডেক্স রিবিল্ড একটি নির্ধারিত, লগ-করা জব - কারও মনে রাখার ভরসায় নয়।

তৃতীয়ত, নীরব ভার্সন-বদল। সদিচ্ছার একটি আপগ্রেড নতুন একটি মডেল বিল্ড টেনে আনল, আর রাতারাতি উত্তরের সুর ও ফরম্যাট সূক্ষ্মভাবে বদলে গেল - কেন, তার কোনো রেকর্ড ছাড়াই। আজ আমি মডেলের সঠিক ভার্সন অন্য যেকোনো প্রোডাকশন dependency-র মতোই pin করি, আর মডেল বদল যায় ডেটাবেজ প্যাচের মতোই change control-এর মধ্য দিয়ে।

এই শিক্ষাগুলো থেকেই এসেছে সেই রক্ষণাবেক্ষণ রুটিন, যা আমি এখন প্রতিটি প্রাইভেট LLM স্ট্যাকে চালাই:

1. প্রতি মাসে: মেইনটেন্যান্স উইন্ডোতে হোস্ট OS, GPU driver ও serving runtime প্যাচ করুন - আগে একটি staging মেশিনে পরীক্ষা করে, ঠিক যেভাবে আমি ডেটাবেজ প্যাচকে দেখি।
2. প্রতিটি ডকুমেন্ট বদলে: স্বয়ংক্রিয়ভাবে re-index করে লগ করুন, যাতে রিট্রিভাল কখনও বাসি উপাদান পরিবেশন না করে।
3. প্রতি প্রান্তিকে: নতুন কোনো ওপেন মডেল আপগ্রেডের যোগ্য কি না পর্যালোচনা করুন - যোগ্য হলে বদলের আগে একটি নির্দিষ্ট প্রশ্নের সেটে দুটি মডেল পাশাপাশি চালান।
4. সবসময়: GPU মেমরি, response time ও request log-এ নজর রাখুন; ধীর উত্তর আর প্রায়-ভরা মেমরিই সবচেয়ে গুরুত্বপূর্ণ আগাম সংকেত।

কখন আমি ক্লায়েন্টকে self-host করতে মানা করি

সততার দাবিতেই এই অংশ। ব্যবহার যদি মাঝেমধ্যে হয় আর ডেটা সত্যিই সংবেদনশীল না হয়, ক্লাউড সার্ভিসই সস্তা ও সহজ - পাবলিক উপাদানের দিনে দশটি প্রশ্নের জন্য সার্ভার গড়বেন না।

প্রতিষ্ঠানে যদি এমন কেউ না থাকেন যিনি দীর্ঘমেয়াদে একটি Linux সার্ভারের মালিকানা নিতে পারেন, self-hosting ক্ষয়ে গিয়ে একটি আন-প্যাচড দায়ে পরিণত হবে - আমি তা স্পষ্ট করেই বলি। মেশিনটির স্পেসিফিকেশনের চেয়ে বেশি দরকার একজন মালিক।

আর কাজটি যদি প্রতিটি অনুরোধে সত্যিই frontier-স্তরের যুক্তি দাবি করে, একটি প্রাইভেট মাঝারি মডেল হতাশ করবে। পরে হার্ডওয়্যারকে দোষ দেওয়ার চেয়ে কাজটি নতুন করে সাজানো, বা সেই একটি workload-এর জন্য জেনেবুঝে ক্লাউডের আপস মেনে নেওয়া ভালো।

সাধারণ ভুল

প্রথমেই সবচেয়ে বড় মডেল কেনা। বেশিরভাগ টিমের তা কখনও লাগে না; শুধু খরচ ও জটিলতা বাড়ে। একবারের ইনস্টল ভাবা। প্রাইভেট LLM একটি জীবন্ত সিস্টেম, মনিটরিং ও মাঝেমধ্যে আপগ্রেড লাগে। মানুষকে ভুলে যাওয়া। গুরুত্বপূর্ণ যেকোনো বিষয়ে AI-এর আউটপুট এখনও মানুষের পর্যালোচনা দরকার - on-premise আপনাকে নিয়ন্ত্রণ দেয়, ভাবনা বন্ধ করার লাইসেন্স নয়।

শেষ কথা

প্রাইভেট LLM চালানো একটি সাধারণ এন্টারপ্রাইজের নাগালের মধ্যেই, যদি সেট আপ ও দেখাশোনার জন্য একজন দক্ষ মানুষ থাকেন। ছোট করে শুরু করুন, কাজের মাপে মডেল বাছুন, RAG দিয়ে নিজের ডেটায় ভিত্তি দিন, আর নিরাপত্তাকে পরে-ভাবার বিষয় নয়, নির্মাণের অংশ হিসেবে নিন। তা করলে পাবেন সত্যিই কাজের একটি AI অ্যাসিস্ট্যান্ট, যার ডেটা কখনও আপনার ভবন ছাড়ে না।

কোন ইউজ কেস দিয়ে শুরু করবেন

একটি on-premise AI প্রজেক্ট নষ্ট করার দ্রুততম উপায় হলো একসঙ্গে সবকিছুর দিকে তাক করা। আমি সবসময় ক্লায়েন্টকে একটি সংকীর্ণ, উচ্চ-মূল্যের ইউজ কেস দিয়ে শুরু করাই এবং সেটি প্রমাণ করার পরই সম্প্রসারণে যাই।

ভালো প্রথম প্রার্থীদের তিনটি গুণ মেলে: কাজটি পুনরাবৃত্তিমূলক, এটি এমন ডেটা ছোঁয় যা ক্লাউডে যেতে পারে না, আর মোটামুটি-ভালো একটি উত্তরও সত্যিই কাজের। অভ্যন্তরীণ পলিসি ডকুমেন্ট থেকে কর্মীদের প্রশ্নের উত্তর দেওয়া এতে নিখুঁতভাবে মেলে। আসা ডকুমেন্ট শ্রেণিবদ্ধ বা সারাংশ করা, কিংবা অভ্যন্তরীণ রেকর্ড থেকে রুটিন চিঠিপত্র ড্রাফট করাও তা-ই।

যা নিজে থেকে অপরিবর্তনীয় সিদ্ধান্ত নেয়, বা যেখানে একটি ভুল উত্তর জনসমক্ষে চলে যায় এমন customer-facing কিছু দিয়ে শুরু করতে আমি টিমগুলোকে নিরুৎসাহিত করি। আগে কাজের ও কম-ঝুঁকির কিছুতে একটি স্পষ্ট জয় আনুন। তাতে আস্থা তৈরি হয়, টিম শেখে সিস্টেম কেমন আচরণ করে, আর আপনি পান একটি কার্যকর ভিত্তি - মডেল, রিট্রিভাল স্তর, নিরাপত্তা - যা পরের ইউজ কেস পুনর্ব্যবহার করে।

ভিত্তি একবার দাঁড়ালে প্রতিটি নতুন ইউজ কেস প্রথমটির পরিশ্রমের ভগ্নাংশে হয়। এই চক্রবৃদ্ধিই নিজের AI চালানোর আসল প্রতিদান, আর এ কারণেই একটি মাপা শুরু জমকালো উদ্বোধনকে প্রতিবারই হারায়।

এর কোনোটিই আপনাকে AI গবেষক হতে বলে না। দরকার সেই একই প্রকৌশল-শৃঙ্খলা যা যেকোনো প্রোডাকশন সিস্টেমের লাগে - সঠিক মাপ, বাস্তব ডেটায় ভিত্তি, সীমানার সুরক্ষা আর সময়ের সঙ্গে রক্ষণাবেক্ষণ। সেই শৃঙ্খলা আনুন, প্রাইভেট LLM আর ভীতিকর থাকবে না - হয়ে উঠবে আপনার অবকাঠামোর আরেকটি সুপরিচালিত সিস্টেম, যেটি ঘটনাচক্রে অসাধারণ কাজের।

সাধারণ জিজ্ঞাসা (FAQ)

প্রাইভেট LLM চালাতে কি GPU লাগে?

প্রতিক্রিয়াশীল, ইন্টারেক্টিভ ব্যবহারের জন্য হ্যাঁ - GPU দৃঢ়ভাবে সুপারিশযোগ্য। ছোট মডেল হালকা বা ব্যাচ কাজে CPU-তে চলে, কিন্তু সাড়া এত ধীর যে মানুষ ব্যবহার বন্ধ করে দেয়। হার্ডওয়্যার মেলান আসল ব্যবহারের সঙ্গে; সত্যিকারের অ্যাসিস্ট্যান্টের জন্য GPU-র বাজেট রাখুন।

প্রাইভেটভাবে কত বড় মডেল দরকার?

বেশিরভাগ ব্যবসায়িক কাজ - শ্রেণিবদ্ধকরণ, সারাংশ, ড্রাফট, ডকুমেন্ট থেকে উত্তর - একটি 3B থেকে 8B মডেলেই ভালো চলে, যা একটি আধুনিক GPU-তে ধরে। ছোট মডেলে না কুলালেই কেবল বড় মডেলের দিকে যান। ছোট দিয়ে শুরু সস্তা, দ্রুত ও সহজে সিকিওর।

RAG কী এবং প্রাইভেট LLM-এ কেন গুরুত্বপূর্ণ?

Retrieval-augmented generation মডেলকে কেবল সাধারণ ট্রেনিং নয়, আপনার নিজের ডকুমেন্ট ও ডেটা থেকে উত্তর দিতে দেয়। এটি আগে প্রাসঙ্গিক তথ্য খুঁজে তারপর উত্তর দেয় - তাই মডেল রি-ট্রেন ছাড়াই সঠিক, উৎস-ভিত্তিক উত্তর পান, আর ডেটা আপনার পরিবেশেই থাকে।

প্রাইভেট LLM কি ChatGPT-এর মতো ক্লাউড AI-এর সমান ভালো?

বেশিরভাগ ব্যবসায়িক কাজে একটি ভালো-বাছাই প্রাইভেট মডেল যথেষ্ট সক্ষম। সবচেয়ে বড় ক্লাউড মডেল এখনও কঠিনতম যুক্তিতে এগিয়ে, কিন্তু শ্রেণিবদ্ধকরণ, সারাংশ বা নিজের ডকুমেন্ট থেকে উত্তরে তা বিশেষ গুরুত্ব রাখে না, আর ব্যবধান প্রতি বছর কমছে। গোপনীয়তা ও খরচ-নিয়ন্ত্রণ প্রায়ই সেই পার্থক্য ছাপিয়ে যায়।

অন-প্রিমিস LLM কীভাবে সিকিওর রাখব?

অনুমোদিত ব্যবহারকারীতে অ্যাক্সেস সীমাবদ্ধ রেখে প্রতিটি অনুরোধ লগ করুন; মডেল সার্ভার বিচ্ছিন্ন অভ্যন্তরীণ নেটওয়ার্কে রাখুন; রিট্রিভাল স্তর কী পড়বে তা স্কোপ করে যা উচিত নয় তা মাস্ক করুন; সার্ভার ও নির্ভরতা প্যাচ করুন; আর কনফিগ ও ডকুমেন্ট ইনডেক্স ব্যাকআপ রাখুন। মডেল ভেতরে এলে নিরাপত্তা আপনার দায়িত্ব।