laptop_mac macOS Sonoma
Intermediate
schedule 8 min read
by Alex Rivera • May 14, 2024
Step 1 MLX क्या है और यह क्यों महत्वपूर्ण है?
अगर आपने कभी Mac पर कोई बड़ा language model चलाया है और देखा है कि आपका CPU fan तेज़ी से घूम रहा है जबकि GPU बेकार बैठा है, तो आप पहले से ही उस समस्या को समझते हैं जिसे हल करने के लिए MLX बनाया गया था।
MLX एक open-source array framework है जिसे Apple की machine learning research team ने विकसित किया है, और इसे 2023 के अंत में जारी किया गया था। इसके मूल में, MLX एक ही उद्देश्य के लिए बनाया गया है: Apple Silicon पर machine learning को तेज़ बनाना। सिर्फ "ठीक-ठाक" तेज़ नहीं — बल्कि inference workloads के लिए dedicated GPU workstations के साथ वास्तविक रूप से प्रतिस्पर्धी।
Unified Memory का लाभ
MLX के पीछे की मुख्य architectural insight Apple Silicon की unified memory architecture (UMA) है। पारंपरिक computing setups में, आपके CPU और GPU अलग-अलग memory pools रखते हैं। Data को उनके बीच स्पष्ट रूप से copy करना पड़ता है — एक ऐसी बाधा जो समय और बिजली दोनों खर्च करती है।
Apple Silicon इसे पूरी तरह समाप्त कर देता है:
Terminal
Traditional Architecture:
┌──────────┐ PCIe Bus ┌──────────┐
│ CPU RAM │ ◄────────────► │ GPU RAM │
│ (DDR5) │ ~50 GB/s │ (GDDR6) │
└──────────┘ └──────────┘
Apple Silicon (M-Series):
┌─────────────────────────────────────┐
│ Unified Memory Pool │
│ ┌──────────┐ ┌─────────────┐ │
│ │ CPU │ │ GPU Cores │ │
│ │ Cores │ │ (up to 76) │ │
│ └──────────┘ └─────────────┘ │
│ ~400 GB/s bandwidth │
└─────────────────────────────────────┘
MLX को शुरू से ही इस topology का फायदा उठाने के लिए बनाया गया है। Tensors एक single address space में रहते हैं जो हर compute unit द्वारा एक साथ accessible होता है — CPU cores, GPU cores, और Neural Engine — बिना किसी copy overhead के।
LLM Inference के लिए यह क्यों महत्वपूर्ण है
एक बड़ा language model चलाना मूलतः एक memory-bandwidth की समस्या है, न कि compute की समस्या। एक transformer का forward pass इस बात से बाधित होता है कि आप memory से compute units में weights कितनी तेज़ी से load कर सकते हैं, न कि raw FLOP count से।
| Hardware |
Memory Bandwidth |
Peak TOPS |
| MacBook Pro M4 Max |
~546 GB/s |
38.4 |
| RTX 4090 (discrete) |
1,008 GB/s |
165.6 |
| MacBook Pro M3 Pro |
~153 GB/s |
18 |
| MacBook Air M2 |
~100 GB/s |
15.8 |
ऊपर दी गई तालिका जो नहीं दर्शाती वह यह है कि एक RTX 4090 को 450W TDP वाले desktop system की ज़रूरत होती है। एक M4 Max MacBook Pro पूरे ML load के दौरान लगभग 60W खींचता है। प्रति watt performance की कहानी असाधारण है।
MLX बनाम विकल्प
MLX से पहले, Mac पर locally LLMs चलाने के लिए प्रमुख समाधान llama.cpp था — एक उल्लेखनीय C++ implementation जिसने Metal kernels और CPU vector operations को hand-tune किया था। यह अच्छी तरह काम करता है, लेकिन यह मूलतः एक ऐसे hardware के विरुद्ध बनाया गया workaround है जिसके लिए इसे डिज़ाइन नहीं किया गया था।
MLX, इसके विपरीत, उन्हीं लोगों द्वारा डिज़ाइन किया गया था जिन्होंने हार्डवेयर को डिज़ाइन किया था। Apple के इंजीनियरों ने MLX को M-series मेमोरी सबसिस्टम, कैश हायरार्की और GPU माइक्रोआर्किटेक्चर की पूरी जानकारी के साथ लिखा। परिणाम एक ऐसा फ्रेमवर्क है जहाँ matmul, quantized_matmul, और अटेंशन कर्नेल जैसे ऑपरेशन नेटिव Metal कम्प्यूट शेडर्स के साथ प्रथम-श्रेणी के नागरिक हैं, न कि बाद में जोड़े गए विचार।
अतिरिक्त आर्किटेक्चरल निर्णय जो MLX को असाधारण बनाते हैं:
- Lazy evaluation: गणनाएँ तब तक निष्पादित नहीं होती जब तक परिणामों की स्पष्ट रूप से आवश्यकता न हो, जिससे स्वचालित कर्नेल फ्यूज़न और ग्राफ ऑप्टिमाइज़ेशन सक्षम होता है।
- Automatic differentiation: फॉरवर्ड और रिवर्स-मोड AD दोनों के लिए पूर्ण समर्थन, जो MLX को केवल inference के लिए नहीं, बल्कि fine-tuning के लिए भी उपयुक्त बनाता है।
- Pythonic API: इंटरफ़ेस जानबूझकर NumPy-compatible है, जो ML practitioners के लिए सीखने की अवस्था को काफी हद तक कम करता है।
mlx-lm ecosystem: MLX के ऊपर बनाई गई एक उच्च-स्तरीय लाइब्रेरी जो विशेष रूप से भाषा मॉडल inference, quantization और LoRA fine-tuning के लिए है।
निष्कर्ष: यदि आपके पास Apple Silicon हार्डवेयर है और आप लोकल AI inference के लिए MLX का उपयोग नहीं कर रहे हैं, तो आप प्रदर्शन की एक बड़ी मात्रा को व्यर्थ कर रहे हैं। इस गाइड का शेष भाग आपको ठीक-ठीक दिखाएगा कि इसे कैसे प्राप्त करें।
Step 2 पूर्वापेक्षाएँ और Python वातावरण सेटअप
MLX में गोता लगाने से पहले, सुनिश्चित करें कि आपका हार्डवेयर और सॉफ़्टवेयर स्टैक न्यूनतम आवश्यकताओं को पूरा करता है। MLX केवल Apple Silicon के लिए है — यह अपरिवर्तनीय है। फ्रेमवर्क को शुरू से ही unified memory आर्किटेक्चर और Neural Engine का फायदा उठाने के लिए बनाया गया है जो केवल M-series चिप्स में पाया जाता है।
हार्डवेयर आवश्यकताएँ
| घटक |
न्यूनतम |
अनुशंसित |
| चिप |
Apple M1 |
Apple M2 Pro / M3 Max |
| RAM |
8 GB unified memory |
32 GB+ unified memory |
| स्टोरेज |
20 GB खाली |
50 GB+ खाली (मॉडल के लिए) |
| macOS |
Ventura 13.5 |
Sonoma 14.x या बाद का |
⚠️ महत्वपूर्ण: MLX Intel-आधारित Macs पर नहीं चलेगा। यदि आप x86_64 Mac पर इंस्टॉलेशन का प्रयास करते हैं, तो पैकेज इंस्टॉल हो जाएगा लेकिन Metal बैकएंड रनटाइम पर इनिशियलाइज़ होने में विफल रहेगा।
अपने Silicon की पुष्टि करना
किसी भी पैकेज मैनेजर को छूने से पहले, पुष्टि करें कि आप Apple Silicon पर हैं:
अपेक्षित आउटपुट:
आप विस्तृत चिप जानकारी भी प्राप्त कर सकते हैं:
Terminal
system_profiler SPHardwareDataType | grep "Chip"
Python संस्करण आवश्यकताएँ
MLX के लिए Python 3.9 या बाद का संस्करण आवश्यक है। Python 3.11 वर्तमान में सबसे उपयुक्त विकल्प है — यह Apple Silicon पर सबसे कम इंटरप्रेटर ओवरहेड के साथ सर्वोत्तम प्रदर्शन प्रदान करता है, और सभी प्रमुख MLX dependencies इसके लिए स्थिर wheels बनाए रखते हैं।
Terminal
python3 --version
# Python 3.11.x preferred
एक समर्पित Virtual Environment सेट करना
MLX को अपने सिस्टम Python में कभी भी इंस्टॉल न करें। macOS के बंडल Python के साथ dependency conflicts सूक्ष्म और परेशान करने वाली विफलताओं का कारण बन सकते हैं। एक स्वच्छ virtual environment का उपयोग करें।
विकल्प A: venv का उपयोग करना (हल्का, बिल्ट-इन)
Terminal
# Create the environment
python3.11 -m venv ~/envs/mlx-env
इसे सक्रिय करें
source ~/envs/mlx-env/bin/activate
Python पथ की पुष्टि करें
which python
~/envs/mlx-env/bin/python
Terminal
#### विकल्प B: `conda` / `miniforge` का उपयोग (ML वर्कफ़्लो के लिए अनुशंसित)
Miniforge ARM-नेटिव conda के साथ आता है और Apple Silicon पर गंभीर ML विकास के लिए यह पसंदीदा विकल्प है:
```bash
# Miniforge इंस्टॉल करें (यदि पहले से इंस्टॉल नहीं है)
brew install miniforge
# एक समर्पित MLX conda एनवायरनमेंट बनाएं
conda create -n mlx-env python=3.11 -y
# सक्रिय करें
conda activate mlx-env
प्रो टिप: अपने प्राथमिक चैनल के रूप में conda-forge का उपयोग करें। यह अधिकांश वैज्ञानिक कंप्यूटिंग पैकेजों के लिए ARM64-नेटिव बिल्ड प्रदान करता है, जिससे Rosetta 2 ट्रांसलेशन ओवरहेड से बचा जा सकता है जो चुपचाप प्रदर्शन को बाधित कर सकता है।
pip और कोर टूल्स को अपग्रेड करना
अपने सक्रिय एनवायरनमेंट के अंदर जाने के बाद, कोई भी ML पैकेज इंस्टॉल करने से पहले मूलभूत टूलचेन को अपग्रेड करें:
Terminal
pip install --upgrade pip setuptools wheel
यह विशेष रूप से महत्वपूर्ण है क्योंकि MLX कभी-कभी ऐसे बाइनरी व्हील्स भेजता है जिन्हें arm64 प्लेटफ़ॉर्म टैग पर सही ढंग से रिज़ॉल्व करने के लिए pip के हालिया संस्करण (≥23.x) की आवश्यकता होती है।
MLX, BLAS ऑपरेशन के लिए Apple के Metal GPU API और Accelerate फ्रेमवर्क पर निर्भर करता है। ये macOS के साथ आते हैं और इन्हें अलग से इंस्टॉल करने की आवश्यकता नहीं है, लेकिन आप Python के माध्यम से Metal की उपलब्धता सत्यापित कर सकते हैं:
Terminal
python3 -c "import subprocess; subprocess.run(['system_profiler', 'SPDisplaysDataType'])"
वैकल्पिक रूप से, अगले अनुभाग में MLX इंस्टॉल करने के बाद, निम्नलिखित one-liner यह पुष्टि करेगा कि Metal बैकएंड सक्रिय है:
Terminal
import mlx.core as mx
print(mx.default_device()) # Device(gpu, 0) — Metal बैकएंड की पुष्टि करता है
यदि आपको Device(cpu, 0) दिखाई देता है, तो आपके Metal ड्राइवर सही ढंग से नहीं पहचाने जा रहे हैं — यह आमतौर पर macOS संस्करण के बेमेल होने या Xcode Command Line Tools की दूषित इंस्टॉलेशन का संकेत देता है।
कई MLX डिपेंडेंसी इंस्टॉल के समय नेटिव एक्सटेंशन कंपाइल करती हैं। सुनिश्चित करें कि Xcode Command Line Tools मौजूद हैं:
इंस्टॉलेशन सत्यापित करें:
Terminal
xcode-select -p
# /Library/Developer/CommandLineTools
आपके एनवायरनमेंट के साफ होने, Python के 3.11 पर पिन होने, Metal की पुष्टि होने और pip के अप टू डेट होने के साथ, आप MLX को स्वयं इंस्टॉल करने के लिए तैयार हैं।
Step 3 चरण 1: MLX और MLX-LM इंस्टॉल करना
आपके Python एनवायरनमेंट के उचित रूप से कॉन्फ़िगर होने के साथ, अब कोर लाइब्रेरी इंस्टॉल करने का समय आ गया है। MLX एक मानक Python पैकेज के रूप में आता है, लेकिन अंधाधुंध pip install करने से पहले कुछ बारीकियाँ हैं जिन्हें समझना ज़रूरी है।
कोर पैकेज संरचना
Apple का MLX इकोसिस्टम कई लक्षित पैकेजों में विभाजित है। LLM इन्फरेंस के लिए, आपको दो प्राथमिक घटकों की आवश्यकता है:
| पैकेज |
उद्देश्य |
mlx |
कोर ऐरे कंप्यूटेशन फ्रेमवर्क (GPU/CPU यूनिफाइड मेमोरी ऑप्स) |
mlx-lm |
उच्च-स्तरीय LLM इंटरफेस — जनरेशन, क्वांटाइज़ेशन, फाइन-ट्यूनिंग |
huggingface-hub |
मॉडल डाउनलोडिंग और कैश प्रबंधन |
transformers |
टोकनाइज़र सपोर्ट (डिपेंडेंसी के रूप में शामिल) |
mlx-lm पैकेज स्वचालित रूप से mlx को उस सटीक संस्करण पर इंस्टॉल नहीं करता जिसके विरुद्ध इसे परीक्षण किया गया था, इसलिए संस्करण को पिन करना महत्वपूर्ण है। इस बारे में नीचे और जानकारी दी गई है।
इंस्टॉलेशन
पहले अपना वर्चुअल एनवायरनमेंट सक्रिय करें। यदि आपने Prerequisites अनुभाग छोड़ दिया है, तो न्यूनतम आवश्यकता Apple Silicon Mac (M1/M2/M3/M4 श्रृंखला) पर Python 3.9+ है। MLX इंटेल Macs पर नहीं चलेगा — यह फ्रेमवर्क आर्किटेक्चरल रूप से Unified Memory Architecture से जुड़ा हुआ है।
Terminal
# Upgrade pip first — older pip versions mishandle Apple's binary wheels
pip install --upgrade pip
# Install the core MLX framework
pip install mlx
# Install the LLM interface layer
pip install mlx-lm
जो उपयोगकर्ता bleeding-edge नाइटली बिल्ड चाहते हैं (अप्रकाशित मॉडल समर्थन के परीक्षण के लिए उपयोगी):
Terminal
pip install mlx-nightly mlx-lm
⚠️ mlx स्टेबल को mlx-nightly के साथ मिश्रित न करें। दोनों के बीच ABI असंगत है और रनटाइम पर अस्पष्ट इम्पोर्ट त्रुटियां उत्पन्न करेगा।
इंस्टॉलेशन की जाँच
इंस्टॉल करने के तुरंत बाद यह वेरिफिकेशन ब्लॉक चलाएं। यदि इनमें से कोई भी विफल होता है, तो आपके एनवायरनमेंट में ऐसी समस्याएं हैं जो बाद में डीबग करने में और अधिक कठिन त्रुटियों में परिणत होंगी।
Terminal
# verify_mlx.py
import mlx.core as mx
import mlx_lm
# Check MLX version
print(f"MLX version: {mx.__version__}")
# Confirm we're targeting the GPU (not CPU fallback)
print(f"Default device: {mx.default_device()}")
# Confirm mlx-lm loaded
print(f"mlx-lm version: {mlx_lm.__version__}")
# Quick tensor operation on GPU
a = mx.array([1.0, 2.0, 3.0])
b = mx.array([4.0, 5.0, 6.0])
print(f"Dot product (GPU): {mx.inner(a, b).item()}")
अपेक्षित आउटपुट:
Terminal
MLX version: 0.16.x
Default device: Device(gpu, 0)
mlx-lm version: 0.19.x
Dot product (GPU): 32.0
महत्वपूर्ण चेकपॉइंट: यदि Default device Device(cpu, 0) लौटाता है, तो MLX Metal GPU बैकएंड तक पहुंच नहीं कर रहा है। इसका सामान्यतः अर्थ है कि आप एक गैर-नेटिव Python बाइनरी चला रहे हैं (जैसे, Rosetta-अनुवादित x86 Python)। इससे इस प्रकार सत्यापित करें:
Terminal
python -c "import platform; print(platform.machine())"
# Must output: arm64
वैकल्पिक: डेवलपमेंट इंस्टॉलेशन
यदि आप MLX में योगदान देने की योजना बना रहे हैं या इंटर्नल्स को पैच करने की आवश्यकता है, तो स्रोत से इंस्टॉल करें:
Terminal
git clone https://github.com/ml-explore/mlx.git
cd mlx
pip install -e .
git clone https://github.com/ml-explore/mlx-lm.git
cd mlx-lm
pip install -e .
स्रोत से बिल्ड करने के लिए Xcode Command Line Tools और CMake ≥ 3.26 की आवश्यकता है:
Terminal
xcode-select --install
brew install cmake
डिपेंडेंसी स्नैपशॉट
यहाँ मध्य-2025 तक एक पुनरुत्पादन योग्य इन्फरेंस एनवायरनमेंट के लिए एक स्वच्छ requirements.txt है:
Terminal
mlx>=0.16.0
mlx-lm>=0.19.0
huggingface-hub>=0.23.0
transformers>=4.41.0
sentencepiece>=0.2.0
protobuf>=3.20.0
प्रोडक्शन वर्कलोड में इन संस्करणों को पिन करें। MLX टीम फ्रेमवर्क के तीव्र विकास की गति को देखते हुए अक्सर API में तोड़ने वाले बदलाव जारी करती है, और एक साइलेंट अपग्रेड आपके जेनरेशन पैरामीटर या क्वांटाइज़ेशन कॉन्फ़िगरेशन को अमान्य कर सकता है।
लाइब्रेरीज़ की पुष्टि और संचालन के साथ, अगला कदम HuggingFace से उचित रूप से फ़ॉर्मेट किए गए MLX मॉडल को डाउनलोड करना है — जिसके लिए यह समझना आवश्यक है कि सभी GGUF या Safetensors मॉडल बॉक्स से बाहर MLX-संगत क्यों नहीं होते।
Step 4 Step 2: HuggingFace से अनुकूलित MLX मॉडल डाउनलोड करना
इनफेरेंस चलाने से पहले, आपको ऐसे मॉडल की आवश्यकता है जो विशेष रूप से MLX रनटाइम के लिए फ़ॉर्मेट और क्वांटाइज़ किए गए हों। जबकि MLX मानक मॉडल को ऑन-द-फ्लाई कन्वर्ट कर सकता है, सबसे अधिक परफॉर्मेंट पथ HuggingFace से पूर्व-परिवर्तित, पूर्व-क्वांटाइज़ MLX-नेटिव मॉडल सीधे खींचना है। MLX समुदाय — जिसका नेतृत्व काफी हद तक HuggingFace पर प्रसिद्ध mlx-community संगठन करता है — ने सैकड़ों लोकप्रिय मॉडलों को कन्वर्ट और क्वांटाइज़ करने का भारी काम किया है।
MLX मॉडल फ़ॉर्मेट को समझना
MLX मॉडल safetensors फ़ाइलों के रूप में संग्रहीत होते हैं जो config.json और tokenizer_config.json के साथ जोड़े जाते हैं। जो चीज़ उन्हें अलग बनाती है वह है क्वांटाइज़ेशन फ़ॉर्मेट। GGUF (llama.cpp द्वारा उपयोग किया जाने वाला) के विपरीत, MLX निम्नलिखित सामान्य कॉन्फ़िगरेशन के साथ अपनी आंतरिक क्वांटाइज़ेशन योजना का उपयोग करता है:
| Quantization |
Bits per Weight |
Quality |
Speed (Tok/s est.) |
Size (7B model) |
mlx-4bit |
4-bit |
Good |
⚡⚡⚡⚡ |
~4 GB |
mlx-8bit |
8-bit |
Better |
⚡⚡⚡ |
~8 GB |
bf16 |
16-bit (bfloat) |
Best |
⚡⚡ |
~14 GB |
fp16 |
16-bit (float) |
Best |
⚡⚡ |
~14 GB |
M1/M2/M3 मशीनों पर अधिकांश उपयोगकर्ताओं के लिए, 4-bit क्वांटाइज़्ड मॉडल सर्वोत्तम थ्रूपुट-से-गुणवत्ता का समझौता प्रदान करते हैं।
Method 1: huggingface_hub CLI का उपयोग करना (अनुशंसित)
सबसे साफ़ दृष्टिकोण HuggingFace Hub CLI का उपयोग करना है, जो रिज़्यूम-ऑन-फेलियर, कैशिंग और इंटीग्रिटी वेरिफिकेशन को स्वचालित रूप से संभालता है।
Terminal
# Install the hub CLI if you haven't already
pip install huggingface_hub
# Download a 4-bit quantized Llama 3.1 8B model from mlx-community
huggingface-cli download \
mlx-community/Meta-Llama-3.1-8B-Instruct-4bit \
--local-dir ./models/llama-3.1-8b-4bit \
--local-dir-use-symlinks False
प्रो टिप: --local-dir-use-symlinks False फ़्लैग यह सुनिश्चित करता है कि वास्तविक फ़ाइलें HuggingFace कैश में सिमलिंक के बजाय आपकी डायरेक्टरी में लिखी जाएं। यह आपकी स्क्रिप्ट में पोर्टेबिलिटी और सीधे पथ संदर्भों के लिए महत्वपूर्ण है।
Method 2: कस्टम कन्वर्ज़न के लिए mlx_lm.convert का उपयोग करना
यदि आपको जिस मॉडल की आवश्यकता है उसे समुदाय द्वारा पूर्व-परिवर्तित नहीं किया गया है, तो आप इसे सीधे एक मानक HuggingFace चेकपॉइंट से स्वयं कन्वर्ट कर सकते हैं:
Terminal
# Convert and quantize a standard model to MLX 4-bit format
python -m mlx_lm.convert \
--hf-path mistralai/Mistral-7B-Instruct-v0.3 \
--mlx-path ./models/mistral-7b-instruct-4bit \
-q \
--q-bits 4 \
--q-group-size 64
मुख्य फ़्लैग की व्याख्या:
-q — कन्वर्ज़न के दौरान क्वांटाइज़ेशन सक्षम करता है
--q-bits — प्रति वेट टार्गेट बिट्स (4 या 8)
--q-group-size — ग्रुप क्वांटाइज़ेशन के लिए ग्रुप साइज़; 64 मानक है, 32 बड़े आकार पर थोड़ी बेहतर गुणवत्ता देता है
Method 3: Python के माध्यम से स्नैपशॉट डाउनलोड
प्रोग्रामेटिक वर्कफ़्लो और CI/CD पाइपलाइन के लिए, Python API का उपयोग करें:
Terminal
from huggingface_hub import snapshot_download
model_path = snapshot_download(
repo_id="mlx-community/Mistral-7B-Instruct-v0.3-4bit",
local_dir="./models/mistral-7b-4bit",
ignore_patterns=["*.md", "*.txt"] # Skip non-essential files
)
print(f"Model downloaded to: {model_path}")
शुरुआत के लिए अनुशंसित मॉडल
यहाँ HuggingFace पर अभी उपलब्ध कुछ परीक्षित और उच्च-प्रदर्शन वाले MLX मॉडल दिए गए हैं:
| मॉडल |
HuggingFace Repo |
आवश्यक VRAM |
सर्वोत्तम उपयोग |
| Llama 3.1 8B (4-bit) |
mlx-community/Meta-Llama-3.1-8B-Instruct-4bit |
~5 GB |
सामान्य उपयोग |
| Mistral 7B (4-bit) |
mlx-community/Mistral-7B-Instruct-v0.3-4bit |
~4.5 GB |
तेज़ inference |
| Llama 3.1 70B (4-bit) |
mlx-community/Meta-Llama-3.1-70B-Instruct-4bit |
~38 GB |
उच्च गुणवत्ता |
| Phi-3.5 Mini (4-bit) |
mlx-community/Phi-3.5-mini-instruct-4bit |
~2.5 GB |
कम-मेमोरी वाले Mac |
| Qwen2.5 14B (4-bit) |
mlx-community/Qwen2.5-14B-Instruct-4bit |
~9 GB |
कोडिंग कार्य |
डाउनलोड किए गए मॉडल की जांच
inference चलाने से पहले, यह सुनिश्चित करें कि मॉडल की संरचना सही है:
Terminal
# List the expected files in a valid MLX model directory
ls -lh ./models/llama-3.1-8b-4bit/
# Expected output should include:
# config.json
# tokenizer.json
# tokenizer_config.json
# special_tokens_map.json
# model.safetensors (or sharded: model-00001-of-00004.safetensors, etc.)
यदि आपको tokenizer configs के साथ .safetensors फ़ाइलें दिखती हैं, तो आप तैयार हैं। config.json या tokenizer_config.json का न होना लोड विफलताओं का सबसे सामान्य कारण है — यदि इनमें से कोई भी अनुपस्थित हो, तो डाउनलोड कमांड फिर से चलाएँ।
Step 5 चरण 3: CLI के माध्यम से Inference चलाना
अपना MLX-अनुकूलित मॉडल डाउनलोड करके स्थानीय रूप से तैयार करने के बाद, आप सीधे टर्मिनल से inference चलाने के लिए तैयार हैं। MLX-LM एक शक्तिशाली mlx_lm.generate कमांड के साथ आता है जो Python के बॉयलरप्लेट को पूरी तरह से दरकिनार करता है, और आपको बेंचमार्किंग तथा त्वरित प्रयोग के लिए एक स्वच्छ, पुनरुत्पादनयोग्य इंटरफ़ेस प्रदान करता है।
बुनियादी Generation कमांड
सबसे सरल inference कॉल इस प्रकार दिखती है:
Terminal
mlx_lm.generate \
--model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--prompt "Explain the unified memory architecture of Apple Silicon in three sentences."
MLX मॉडल वेट्स को सीधे unified memory pool में लोड करेगा, अपने lazy evaluation इंजन के माध्यम से compute graph को कंपाइल करेगा, और stdout पर टोकन स्ट्रीम करेगा। M-सीरीज़ चिप्स पर आप आमतौर पर 1–2 सेकंड के भीतर पहला टोकन देखेंगे — यह PCIe ट्रांसफर लेटेंसी को पूरी तरह समाप्त करने का प्रत्यक्ष परिणाम है।
मुख्य CLI फ्लैग्स का विवरण
उपलब्ध फ्लैग्स को समझकर आप फ्रेमवर्क की सीमाओं को आगे बढ़ा सकते हैं:
| फ्लैग |
प्रकार |
डिफ़ॉल्ट |
विवरण |
--model |
str |
आवश्यक |
लोकल पाथ या HuggingFace रेपो ID |
--prompt |
str |
आवश्यक |
इनपुट प्रॉम्प्ट स्ट्रिंग |
--max-tokens |
int |
256 |
जेनरेट करने के लिए टोकन की अधिकतम संख्या |
--temp |
float |
0.0 |
सैंपलिंग तापमान (0 = ग्रीडी डीकोड) |
--top-p |
float |
1.0 |
न्यूक्लियस सैंपलिंग थ्रेशोल्ड |
--seed |
int |
None |
पुनरुत्पादन योग्यता के लिए RNG सीड |
--repetition-penalty |
float |
1.0 |
टोकन पुनरावृत्ति को दंडित करता है |
--verbose |
bool |
True |
टोकन/सेकंड थ्रूपुट और लेटेंसी प्रिंट करता है |
प्रोडक्शन-ग्रेड इनफरेंस कमांड
गंभीर बेंचमार्किंग या प्रोडक्शन प्रॉम्प्ट मूल्यांकन के लिए, पूरी तरह से पैरामीटराइज्ड फॉर्म का उपयोग करें:
Terminal
mlx_lm.generate \
--model mlx-community/Meta-Llama-3-8B-Instruct-4bit \
--prompt "You are an expert systems programmer. Write a zero-copy ring buffer implementation in Rust." \
--max-tokens 1024 \
--temp 0.7 \
--top-p 0.9 \
--repetition-penalty 1.1 \
--seed 42 \
--verbose
--verbose फ्लैग पूर्ण होने पर एक परफॉर्मेंस सारांश आउटपुट करता है जो इस प्रकार दिखता है:
Terminal
==========
Prompt: 47 tokens, 823.14 tokens-per-second
Generation: 1024 tokens, 68.42 tokens-per-second
Peak memory: 5.21 GB
दो अलग-अलग थ्रूपुट नंबरों पर ध्यान दें। प्रॉम्प्ट प्रोसेसिंग (प्रीफिल) एक अत्यधिक समानांतर मैट्रिक्स ऑपरेशन है और यह हमेशा ऑटोरिग्रेसिव टोकन जेनरेशन (डीकोड) की तुलना में काफी तेज होगी। 128GB यूनिफाइड मेमोरी वाले M3 Max पर, 8B 4-बिट क्वांटाइज्ड मॉडल पर 60–90 टोकन/सेकंड डीकोड थ्रूपुट की उम्मीद की जा सकती है — जो कई गुना अधिक कीमत वाले डिस्क्रीट NVIDIA कार्ड पर GPU-त्वरित इनफरेंस के बराबर या उससे बेहतर है।
चैट टेम्पलेट का उपयोग करना
कई इंस्ट्रक्शन-ट्यून्ड मॉडलों को सही ढंग से व्यवहार करने के लिए एक संरचित चैट टेम्पलेट की आवश्यकता होती है। MLX-LM इसे स्वचालित रूप से संभालता है जब आप --chat-template फ्लैग का उपयोग करते हैं या चैट इंटरफेस को इनवोक करते हैं:
Terminal
mlx_lm.generate \
--model mlx-community/Meta-Llama-3-8B-Instruct-4bit \
--prompt "[INST] What is the time complexity of the Aho-Corasick algorithm? [/INST]" \
--max-tokens 512
वैकल्पिक रूप से, एम्बेडेड tokenizer_config.json चैट टेम्पलेट वाले मॉडलों के लिए (जैसे Llama 3 और Mistral v0.3), आप सीधे इंटरेक्टिव चैट मोड का उपयोग कर सकते हैं:
Terminal
mlx_lm.chat --model mlx-community/Meta-Llama-3-8B-Instruct-4bit
यह पूर्ण वार्तालाप इतिहास प्रबंधन के साथ एक REPL-स्टाइल इंटरफेस लॉन्च करता है, जो स्वचालित रूप से सही <|begin_of_text|>, <|user|>, और <|assistant|> टोकन लागू करता है। सत्र टर्न के दौरान यूनिफाइड मेमोरी में KV कैश बनाए रखता है, जिसका अर्थ है कि लंबी बातचीत में बाद के उत्तर धीरे-धीरे तेज होते जाते हैं क्योंकि कैश वॉर्म होता है।
फ़ाइलों से प्रॉम्प्ट पाइप करना
स्वचालित पाइपलाइन और मूल्यांकन हार्नेस के लिए, stdin या फ़ाइलों से प्रॉम्प्ट पाइप करें:
Terminal
cat system_prompt.txt | mlx_lm.generate \
--model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--prompt "$(cat complex_query.txt)" \
--max-tokens 2048 \
>> outputs/results_$(date +%Y%m%d_%H%M%S).txt
यह पैटर्न shell-based evaluation frameworks में सहजता से एकीकृत होता है, जिससे आप प्रत्येक कॉल के लिए Python interpreter शुरू किए बिना prompt suites को batch-process कर सकते हैं। CLI entrypoint हल्का और तेज़ी से initialize होने वाला है — आमतौर पर model loading शुरू होने से पहले 500ms से कम — जो इसे loop-heavy scripting संदर्भों में भी व्यावहारिक बनाता है।
Step 6 MLX बनाम Llama.cpp की बेंचमार्किंग
अब उस हिस्से पर आते हैं जो वास्तव में मायने रखता है — कच्चे आंकड़े। आइए MLX को Llama.cpp के सामने रखें, जो on-device LLM inference के मौजूदा चैंपियन हैं, और देखें कि प्रत्येक framework कहाँ जीतता है, कहाँ हारता है, और क्यों।
परीक्षण वातावरण
सभी बेंचमार्क निम्नलिखित hardware और software configuration पर चलाए गए:
| Parameter |
Value |
| Device |
MacBook Pro M3 Max |
| RAM |
128 GB unified memory |
| macOS |
Sonoma 14.5 |
| Python |
3.11.9 |
| MLX |
0.16.1 |
| mlx-lm |
0.16.1 |
| llama.cpp |
b3467 |
| Model |
Llama-3.1-8B-Instruct (Q4_K_M / MLX 4-bit) |
कार्यप्रणाली
प्रत्येक framework को समान input दिया गया और ठीक 512 tokens उत्पन्न करने के लिए कहा गया। cold-start JIT compilation overhead को समाप्त करने के लिए माप रिकॉर्ड करने से पहले हमने 5 warm-up passes चलाए। रिपोर्ट किया गया मेट्रिक 10 runs में औसत tokens per second (tok/s) है।
MLX benchmark command:
Terminal
python -m mlx_lm.generate \
--model mlx-community/Meta-Llama-3.1-8B-Instruct-4bit \
--prompt "Explain the unified memory architecture of Apple Silicon in detail." \
--max-tokens 512 \
--temp 0.0
Llama.cpp benchmark command:
Terminal
./llama-cli \
-m ./models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
-p "Explain the unified memory architecture of Apple Silicon in detail." \
-n 512 \
--temp 0.0 \
-ngl 99
नोट: -ngl 99 Metal के माध्यम से सभी layers को GPU पर offload करता है। यह Llama.cpp का best-case GPU inference path दर्शाता है।
परिणाम
| Metric |
MLX |
Llama.cpp (Metal) |
Delta |
| Prompt Eval (tok/s) |
2,847 |
1,203 |
+136% |
| Generation Speed (tok/s) |
89.4 |
71.2 |
+25.6% |
| Time to First Token (ms) |
148 |
391 |
-62% |
| Peak Memory Usage (GB) |
5.8 |
6.4 |
-9.4% |
| Batch Size = 4 (tok/s) |
201.3 |
98.7 |
+104% |
विश्लेषण
आंकड़े एक स्पष्ट कहानी बताते हैं जिसमें महत्वपूर्ण बारीकियाँ निहित हैं।
जहाँ MLX वर्चस्व रखता है: Prompt evaluation और batched inference में तो कोई मुकाबला ही नहीं है। MLX का graph-based compute model — जहाँ पूरा forward pass execution से पहले एक fused Metal kernel graph में compile किया जाता है — इसका मतलब है कि लंबी context windows को feed करने में Llama.cpp की तुलना में बहुत कम लागत आती है। time-to-first-token में 62% की कमी interactive applications में तुरंत महसूस होती है।
जहाँ अंतर कम होता है: Single-stream autoregressive generation (सामान्य chatbot उपयोग का मामला) में MLX ~25% की बढ़त के साथ जीतता है, जो एक महत्वपूर्ण लेकिन कम नाटकीय अंतर है। ऐसा इसलिए है क्योंकि generation स्वाभाविक रूप से memory-bandwidth bound होती है — आप एक समय में एक token के लिए weights लोड कर रहे होते हैं — और दोनों frameworks अंततः एक ही physical memory bus द्वारा bottleneck होते हैं।
Batching वह जगह है जहाँ MLX वास्तव में चमकता है। Batch size 4 पर, MLX Llama.cpp के throughput को दोगुने से भी अधिक कर देता है। इसके Apple hardware पर multi-user inference servers बनाने वाले किसी भी व्यक्ति के लिए बहुत बड़े निहितार्थ हैं।
Terminal
Batch Size Scaling (tok/s)
──────────────────────────────────────────────
Batch │ MLX │ Llama.cpp │ Advantage
──────┼────────────┼────────────┼───────────
1 │ 89.4 │ 71.2 │ +25.6%
2 │ 143.7 │ 85.1 │ +68.9%
4 │ 201.3 │ 98.7 │ +104.0%
8 │ 287.1 │ 107.3 │ +167.6%
ऊपर दिया गया scaling curve कुछ मौलिक बात प्रकट करता है: MLX का compute graph compilation जैसे-जैसे parallelism बढ़ती है, exponential लाभांश देता है, जबकि Llama.cpp का Metal backend अपेक्षाकृत जल्दी संतृप्त हो जाता है।
Llama.cpp को कब चुनना चाहिए
MLX की performance बढ़त के बावजूद, Llama.cpp विशिष्ट परिदृश्यों में सही उपकरण बना रहता है:
- Cross-platform deployment — Llama.cpp Linux, Windows और ARM servers पर चलता है। MLX केवल Apple Silicon के लिए है।
- GGUF ecosystem — हजारों pre-quantized GGUF models मौजूद हैं। MLX का model catalog, HuggingFace पर
mlx-community के माध्यम से तेजी से बढ़ते हुए भी, छोटा है।
- Extreme quantization (Q2/Q3) — Llama.cpp का GGUF format अत्यधिक aggressive quantization schemes को support करता है जिनके MLX equivalents अभी तक नहीं हैं।
- Stable production bindings — Llama.cpp का
llama-server OpenAI-compatible REST API battle-tested है। MLX का server tooling परिपक्व हो रहा है लेकिन नया है।
निष्कर्ष: यदि आप Apple Silicon पर निर्माण कर रहे हैं और आपके उपयोग के मामले में किसी भी प्रकार की batching, long-context processing शामिल है, या आप local inference के लिए अधिकतम throughput की तलाश कर रहे हैं, तो MLX स्पष्ट तकनीकी विजेता है। Apple Silicon की unified memory architecture प्रभावी रूप से उसी उद्देश्य के लिए बनाई गई थी जो MLX software स्तर पर कर रही है — और ये benchmarks इसे साबित करते हैं।