আপনি যদি আপনার Mac-এ লোকালি লার্জ ল্যাঙ্গুয়েজ মডেল (LLM) চালান, তবে সম্ভবত আপনি কোনো ডাউনলোড পেজ দেখে অবাক হয়েছেন যে কেন একই রকম দেখতে দুটি আলাদা ফোল্ডার রয়েছে। একটির শেষে .gguf আছে এবং এটি একটি বিশাল একক ফাইল হিসেবে থাকে। অন্যটি হলো একটি MLX ডিরেক্টরি যা ওয়েট ফাইল (weights files), একটি টোকেনাইজার (tokenizer) এবং কিছু JSON কনফিগারেশন দিয়ে ঠাসা। উভয়ই Apple Silicon-এ দক্ষতার সাথে চলার দাবি করে। তবে কেবল একটিই প্রকৃতপক্ষে Apple-এর সীমানার ভেতরে থাকে।

এটি কেবল প্যাকেজিংয়ের পার্থক্য নয়। MLX এবং GGUF-এর মধ্যে নির্বাচন আপনার মডেলটি কত দ্রুত চলবে, এটি কতটা মেমরি ব্যবহার করবে এবং আপনার প্রজেক্টটি আদৌ আপনার ল্যাপটপ থেকে বের হতে পারবে কি না, তা নির্ধারণ করে।

GGUF আসলে কী

GGUF এসেছে llama.cpp ইকোসিস্টেম থেকে। এটি একটি বাইনারি কন্টেইনার ফরম্যাট যা মডেল ওয়েট, টোকেনাইজার ভোকাবুলারি, মেটাডেটা এবং হাইপারপ্যারামিটারগুলোকে একটি স্বয়ংসম্পূর্ণ ফাইলের মধ্যে একত্রিত করে। আপনি একটি মাত্র কোয়ান্টাইজড (quantized) ফাইল নিতে পারেন, সেটি একটি ফোল্ডারে রাখতে পারেন এবং যেকোনো সামঞ্জস্যপূর্ণ লোডার আছে এমন মেশিনে চালাতে পারেন। এর মানে হলো macOS-এ Metal, Linux বা Windows-এ CUDA, এমনকি GPU না থাকলে Vulkan বা শুধুমাত্র CPU ব্যাকএন্ড।

এর আসল সুবিধা হলো পোর্টেবিলিটি (portability)। যেহেতু সবকিছু একটি ফাইলের মধ্যে থাকে, তাই GGUF সহজে স্থানান্তর করা যায়। আপনি কোনো কিছু পুনরায় ডাউনলোড না করেই এটি আপনার MacBook থেকে একটি Linux সার্ভারে নিয়ে যেতে পারেন। আপনি এটি একটি NAS-এ আর্কাইভ করে রাখতে পারেন এবং নিশ্চিত থাকতে পারেন যে এক বছর পরেও একটি মাত্র কমান্ড দিয়ে এটি লোড করা যাবে। যে দলগুলোর হার্ডওয়্যার মিশ্রিত, বা যারা এমন ইনফ্রাস্ট্রাকচার তৈরি করছেন যা ভবিষ্যতে ডেটা সেন্টারে ডেপ্লয় করা হতে পারে, তাদের জন্য এই সর্বজনীনতা অতুলনীয়।

GGUF llama.cpp কমিউনিটির বছরের পর বছর ধরে করা সতর্ক কোয়ান্টাইজেশন গবেষণার সুবিধাগুলোও গ্রহণ করেছে। Q4_K_M এবং Q5_K_M-এর মতো মিক্সড-প্রিসিশন স্কিমগুলো খুব কম বিট উইডথ-এও গুণমান বজায় রাখার জন্য টিউন করা হয়েছে। যখন আপনি ৭০ বিলিয়ন প্যারামিটারের একটি মডেলকে ৪০ গিগাবাইট ডিস্ক স্পেসে সংকুচিত করেন, তখন এই ঐতিহ্যটি অত্যন্ত গুরুত্বপূর্ণ হয়ে ওঠে।

MLX কী সুবিধা নিয়ে আসে

MLX কেবল একটি ফাইল ফরম্যাট নয়। এটি Apple-এর তৈরি একটি অ্যারে ফ্রেমওয়ার্ক যা বিশেষভাবে M-series চিপের জন্য মেশিন লার্নিং করার জন্য ডিজাইন করা হয়েছে। একটি MLX মডেল সাধারণত একটি একক ব্লবের পরিবর্তে ফাইলের একটি ডিরেক্টরি হয়। এই ফ্রেমওয়ার্কটি সরাসরি Metal ব্যাকএন্ডের সাথে যোগাযোগ করে এবং CPU ও GPU মেমরিকে একটি ইউনিফাইড পুল (unified pool) হিসেবে বিবেচনা করে। Apple Silicon-এ, CPU এবং GPU একই ফিজিক্যাল মেমরি চিপ শেয়ার করে, তাই MLX সেই ব্যয়বহুল ডেটা কপি করা এড়িয়ে চলে যা প্রসেসর এবং গ্রাফিক্স কার্ডের মধ্যে ডেটা আদান-প্রদানের সময় প্রথাগতভাবে ঘটে থাকে।

সমস্যাটি স্পষ্ট: MLX উইন্ডোজে চলে না। এটি লিনাক্সে চলে না। এটি CUDA মেশিনে চলে না। আপনার কাজের ধারা যদি কখনও Apple ইকোসিস্টেমের বাইরে যায়, তবে আপনাকে মডেলটি অন্য ফরম্যাটে কনভার্ট করতে হবে বা পুনরায় ডাউনলোড করতে হবে।

যারা সম্পূর্ণভাবে একটি Mac Studio বা MacBook Pro ব্যবহার করে কাজ করেন, তাদের জন্য এই সীমাবদ্ধতা কোনো ব্যাপার না হতে পারে। কিন্তু অন্য যে কারো জন্য এটি একটি বাধা।

পারফরম্যান্সের অবস্থান কোথায়

Apple Silicon-এ, MLX সাধারণত দ্রুততর বিকল্প। বেঞ্চমার্ক দেখায় যে একই Mac-এ Metal-ব্যাকড ইঞ্জিনের মাধ্যমে লোড করা GGUF-এর তুলনায় এটি ১৫ থেকে ৪০ শতাংশ দ্রুত চলে। বাস্তবে, এই ব্যবধান একটি ধীরগতির ২০ সেকেন্ডের স্ট্রিমিং রেসপন্সকে একটি দ্রুত ১২ সেকেন্ডের রেসপন্সে পরিণত করে। দীর্ঘ কোডিং সেশন বা দীর্ঘ লেখালেখির কাজের ক্ষেত্রে, এই সেকেন্ডগুলো জমা হয়ে একটি লক্ষণীয় মসৃণ অভিজ্ঞতা প্রদান করে।

মেমরি ব্যবহারের ক্ষেত্রেও একই প্যাটার্ন দেখা যায়। MLX একটি সমতুল্য GGUF মডেলের তুলনায় প্রায় ১০ শতাংশ কম RAM ব্যবহার করে। এই সাশ্রয়টি ইউনিফাইড মেমরি আর্কিটেকচার এবং অতিরিক্ত বাফার কপি না থাকার কারণে হয়। ৬৪ GB RAM বিশিষ্ট একটি মেশিনে, ১০ শতাংশ সাশ্রয় বেশ স্বস্তিদায়ক। কিন্তু ৩২ GB RAM বিশিষ্ট একটি Mac-এর ক্ষেত্রে, এটি একটি 13B মডেল স্বাচ্ছন্দ্যে চালানো এবং সোয়াপ (swap) মেমরিতে পড়ার মধ্যে পার্থক্য তৈরি করতে পারে।

তবে গুণমানের ক্ষেত্রে একটি আপস (trade-off) রয়েছে। ৪-বিট কোয়ান্টাইজেশনে, Q4_K_M পদ্ধতি ব্যবহার করে একটি সুনিপুণ GGUF ফাইল একটি সাধারণ ৪-বিট MLX কনভারশনের তুলনায় কিছুটা উন্নত আউটপুট ফাইডেলিটি (fidelity) বজায় রাখে। GGUF-এর মিক্সড-প্রিসিশন কৌশলগুলো হাজার হাজার ব্যবহারকারীর পরীক্ষার মাধ্যমে উন্নত করা হয়েছে। যদি আপনার কাজের জন্য নিখুঁত রিজনিং (reasoning), কোডিং সিনট্যাক্স বা সূক্ষ্ম নির্দেশাবলী অনুসরণ করার প্রয়োজন হয়, তবে গুণমানের সেই সামান্য পার্থক্যটি কাঁচা থ্রুপুট (raw throughput)-এর চেয়ে বেশি গুরুত্বপূর্ণ হতে পারে।

বাস্তব পরিস্থিতি, বাস্তব পছন্দ

কল্পনা করুন আপনি একজন ডেভেলপার যার একটি M3 Pro MacBook এবং ৩৬ GB ইউনিফাইড মেমরি রয়েছে। আপনি সারাদিন VS Code-এর ভেতরে একটি লোকাল কোডিং অ্যাসিস্ট্যান্ট চালান। আপনি কখনোই উইন্ডোজ মেশিন স্পর্শ করেন না। এখানে MLX ব্যবহার করা যুক্তিযুক্ত। অতিরিক্ত গতিটি অটো-কমপ্লিটকে তাৎক্ষণিক করে তোলে এবং মেমরি সাশ্রয় আপনাকে সিস্টেমকে স্লো না করেই পঞ্চাশটি ট্যাব খোলা রাখা ব্রাউজার ব্যবহার করতে সাহায্য করে।

এখন একজন গবেষকের কথা ভাবুন যার কাছে ১৬ জিবি র‍্যামসহ একটি বেস M1 MacBook Air আছে। তাদের মাঝে মাঝে NVIDIA কার্ডযুক্ত একটি বিভাগীয় Linux সার্ভারে একই অ্যানালাইসিস নোটবুক চালানোর প্রয়োজন হয়। সেক্ষেত্রে GGUF হলো সবচেয়ে স্পষ্ট পছন্দ। একটি মাত্র ফাইল ব্যাকআপের কাজ সহজ করে দেয়, এবং mixed-precision quantization সীমিত মেমরি থেকে সম্ভাব্য সেরা মান বের করে আনে। যখন তারা সার্ভারে SSH করেন, তখন তারা কোনো ফরম্যাট কনভার্সন ছাড়াই ঠিক একই weights চালাতে পারেন।

অথবা একটি ছোট স্টার্টআপের কথা ভাবুন যারা একটি ডেস্কটপ AI টুল তৈরি করছে। তারা Mac-এ প্রোটোটাইপ তৈরি করে কিন্তু জানে যে তাদের গ্রাহকরা Windows ল্যাপটপ এবং Linux ওয়ার্কস্টেশনের মিশ্রণ ব্যবহার করে। শুরুতেই MLX-এর ওপর বাজি ধরা তাদের জন্য সীমাবদ্ধতা তৈরি করতে পারে। GGUF তাদের ডেপ্লয়মেন্টের বিকল্পগুলো উন্মুক্ত রাখে। একটি ফাইল। একটি পাইপলাইন। প্রতিটি প্ল্যাটফর্ম।

কীভাবে সিদ্ধান্ত নেবেন

বেঞ্চমার্কের চেয়ে আপনার হার্ডওয়্যার এবং ভবিষ্যৎ পরিকল্পনা বেশি গুরুত্বপূর্ণ।

আপনি যদি ৩২ জিবি বা তার বেশি মেমরি সম্পন্ন একটি আধুনিক M-series Mac ব্যবহার করেন, শুধুমাত্র লোকাল পারফরম্যান্স নিয়ে ভাবেন এবং আপনার প্রজেক্টটি কখনোই কোনো নন-Apple মেশিনে চালানোর প্রয়োজন না হয়, তবে MLX বেছে নিন। এর স্পিডআপ প্রকৃত এবং এর unified memory integration অত্যন্ত চমৎকার।

আপনার যদি ১৬ জিবি বা তার কম র‍্যাম থাকে, আপনি যদি macOS এবং Linux উভয় ক্ষেত্রেই কাজ করেন, অথবা আপনি এমন কিছু তৈরি করছেন যা ভবিষ্যতে কোনো সার্ভারে চলতে পারে, তবে GGUF বেছে নিন। আপনি যদি সবচেয়ে সহজ সেটআপ চান: একটি ফাইল, একটি মডেল, কোনো ডিপেন্ডেন্সি সংক্রান্ত ঝামেলাহীনতা—তবে এটিই হবে সেরা পছন্দ।

স্টপওয়াচ দিয়ে গতি পরিমাপ করা সহজ। পোর্টেবিলিটি তখনই বোঝা যায় যখন তা হারিয়ে যায়। এক বছর ধরে শুধুমাত্র MLX-ভিত্তিক পাইপলাইন তৈরি করুন, আর যেদিন আপনার inference একটি CUDA সার্ভারে স্থানান্তর করার প্রয়োজন হবে, সেদিন আপনি সমস্যার সম্মুখীন হবেন। আপনার প্রজেক্ট চিরকাল একটি MacBook-এই সীমাবদ্ধ রাখুন, তাহলে আপনি কোনো আফসোস ছাড়াই MLX-এর প্রতিটি স্পিডআপ উপভোগ করতে পারবেন।

মূল কথা

৩২ জিবি বা তার বেশি মেমরির Mac-এ ব্যক্তিগত ব্যবহার? MLX আপনাকে সেরা নেটিভ অভিজ্ঞতা দেবে। ১৬ জিবি র‍্যামে কাজ করা, অপারেটিং সিস্টেম পরিবর্তন করা, বা কোনো সার্ভারে পাঠানো? GGUF হলো নিরাপদ এবং আরও নমনীয় পছন্দ। আপনি যদি সত্যিই সিদ্ধান্ত নিতে না পারেন, তবে GGUF ব্যবহার করাই শ্রেয়। আপনি Apple Silicon-এ কিছুটা গতি বিসর্জন দেবেন, কিন্তু যেকোনো প্ল্যাটফর্মে যাওয়ার স্বাধীনতা পাবেন।

উৎস: MLX vs GGUF on Apple Silicon: Which local LLM format should you actually use?

অন্যদের সাথে লোকাল LLM নিয়ে কথা বলতে চান