SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor

हिंदी के लिए ओपन-सोर्स LLM: अपने VPS पर कौन सा चलेगा

Sarvam-30B, Sarvam-105B, Nemotron 3.5 Super VL और Qwen3.8-27B को अपने सर्वर पर चलाने से पहले: लाइसेंस, GGUF साइज़ से RAM का हिसाब, और हिंदी व Hinglish की अपनी जाँच।

हिंदी के लिए ओपन-सोर्स LLM: छोटा जवाब

हिंदी के लिए ओपन-सोर्स LLM (large language model) अपने VPS पर चलाना हो, तो बिना GPU वाले सर्वर पर सबसे व्यावहारिक उम्मीदवार Sarvam-30B है। इसकी आधिकारिक Q4_K_M GGUF फ़ाइलें कुल 19.57 GB की हैं, और हर टोकन पर इसके सिर्फ़ 2.4B पैरामीटर काम करते हैं। Sarvam-105B और NVIDIA का Nemotron 3.5 Super VL बहुत बड़ी RAM या GPU वाले सर्वर का काम हैं। इन मॉडलों के जो स्रोत यहाँ पढ़े गए, उनमें हिंदी का अलग benchmark कहीं नहीं मिला। इसलिए "हिंदी में कौन बेहतर है", इसका जवाब आपको अपने prompts से खुद निकालना होगा।

यह गाइड उस डेवलपर या छोटे कारोबार के लिए है जो ग्राहकों को हिंदी में जवाब देने वाला assistant चाहता है। जवाब देवनागरी में भी चाहिए, और उस Hinglish में भी जो ग्राहक असल में टाइप करते हैं। Hinglish का मतलब है रोमन अक्षरों में लिखी हिंदी, जैसे "order kab aayega"। साथ ही हर chat किसी विदेशी API को नहीं भेजनी है।

नीचे के सारे तथ्य 17 अक्टूबर 2026 को खोले गए model card और Hugging Face की file listing से हैं। यहाँ tokens per second, RAM की कोई reading या quality score नहीं है। वजह सीधी है: इनमें से कुछ भी यहाँ मापा नहीं गया। जो मापना ज़रूरी है, उसके कमांड दिए गए हैं, ताकि आप अपने सर्वर पर खुद माप सकें।

चार मॉडल: लाइसेंस, पैरामीटर और भाषा के दावे

Sarvam-30B

Sarvam-30B का लाइसेंस Apache-2.0 है। नाम में 30B है, पर Hugging Face के safetensors आँकड़े में कुल 32,152,650,368 पैरामीटर हैं, यानी लगभग 32B। यह MoE (mixture of experts) मॉडल है। Card के अनुसार इसमें 128 experts और एक shared expert हैं, हर टोकन के लिए top-6 routing होती है, और 19 layers हैं। Embedding को छोड़कर हर टोकन पर सक्रिय (active) पैरामीटर 2.4B हैं।

भाषा का दावा: card कहता है कि मॉडल 22 भारतीय भाषाओं में state-of-the-art प्रदर्शन देता है। Card में भाषाओं की सूची वाक्यों में नहीं है। Repo के language tags में 23 codes हैं: en, hi, bn, ta, te, mr, gu, kn, ml, pa, or, as, ur, sa, ne, sd, kok, mai, doi, mni, sat, ks, bo। इनमें अंग्रेज़ी (en) और bo भी शामिल हैं। Card में Hinglish या रोमन लिपि में लिखी हिंदी का कोई ज़िक्र नहीं है।

Benchmarks: card नतीजों को श्रेणियों में रखता है (Knowledge & Coding, Reasoning & Math, Agentic)। MILU सूची में है, पर उसका भाषा-वार स्कोर नहीं है। हिंदी का अलग कोई आँकड़ा card पर नहीं है, और model-index metadata भी खाली है। Benchmarks 65,536 टोकन के अधिकतम context पर चलाए गए थे।

GGUF: मूल weights वाले repo में GGUF नहीं है, सिर्फ़ 26 safetensors shards हैं। Sarvam ने अलग repo sarvamai/sarvam-30b-gguf में सिर्फ़ एक quant दिया है: Q4_K_M, जो 6 हिस्सों (shards) में बँटा है। GGUF का architecture नाम bailingmoe2 है, और metadata में context length 131,072 है।

Sarvam-105B

लाइसेंस Apache-2.0 है। कुल 106,031,767,424 पैरामीटर हैं (लगभग 106B), और हर टोकन पर 10.3B सक्रिय। यह भी MoE है, और YaRN scaling (factor 40) से 128K context तक जाता है। Language tags वही 23 codes हैं, और card वही 22 भारतीय भाषाओं वाला वाक्य दोहराता है। आधिकारिक GGUF repo sarvamai/sarvam-105b-gguf में भी सिर्फ़ Q4_K_M है, 9 shards में। इसका architecture नाम deepseek2 है।

एक सावधानी: card की manual download वाली पंक्ति में repo का नाम sarvam/sarvam-105-gguf लिखा है। यह असली repo से मेल नहीं खाता। असली नाम sarvamai/sarvam-105b-gguf है। इस card पर भाषा-वार नतीजे हैं या नहीं, यह यहाँ पूरी तरह जाँचा नहीं गया, इसलिए card खुद पढ़ें।

Nemotron 3.5 Super VL

NVIDIA का यह मॉडल Apache-2.0 के तहत नहीं है। Card के अनुसार इसका इस्तेमाल OpenMDW License Agreement, version 1.1 से तय होता है। व्यावसायिक इस्तेमाल से पहले इसकी शर्तें openmdw.ai/license/1-1 पर खुद पढ़ें। यहाँ उनका सार नहीं दिया गया, क्योंकि लाइसेंस का पाठ खोला नहीं गया।

Card कहता है कि इसमें 120B कुल और 12B सक्रिय पैरामीटर हैं। Hugging Face का safetensors आँकड़ा 124,453,395,976 दिखाता है, क्योंकि उसमें C-RADIO vision encoder और vision-language connector भी गिने गए हैं। नाम में VL (vision-language) इसी वजह से है।

हिंदी की स्थिति ध्यान से पढ़ें। Card के language metadata में en, es, fr, de, it, ja हैं। Card का focus भाषाओं वाला वाक्य अंग्रेज़ी के अलावा French, German, Italian, Japanese, Spanish और Chinese गिनाता है। इन दोनों जगह हिंदी नहीं है। Card एक जगह यह भी कहता है कि training corpus में अंग्रेज़ी के अलावा 19 बोली जाने वाली भाषाएँ हैं। उन 19 की पूरी सूची यहाँ नहीं देखी गई, इसलिए उसमें हिंदी है या नहीं, यह खुला सवाल है।

Indic हिस्सा: card के अनुसार मॉडल 100B टोकन के एक continued pre-training चरण से गुज़रा। उस चरण में 10B चुने हुए Indic टोकन थे, और 90B टोकन पिछले मिश्रण से। यानी 100B Indic टोकन नहीं, बल्कि 100B के चरण में 10B Indic। NVIDIA के 15 अक्टूबर 2026 के developer blog के अनुसार ये 10B टोकन Nemotron-pretraining-Indic-v1 dataset की 12 भाषाओं वाले उपसमूह और प्राकृतिक Indic text से लिए गए।

NVIDIA और AI4Bharat का 16 अक्टूबर 2026 का पोस्ट उसी dataset के बारे में है। उसमें लगभग 2.8 ट्रिलियन टोकन हैं, 22 भाषाओं का अपनी लिपि वाला data है, और बारह भाषाओं का रोमन लिपि वाला data है। हिंदी उन बारह में है। ध्यान दें: यह training data की बात है। इससे यह साबित नहीं होता कि मॉडल Hinglish में अच्छा जवाब देता है।

नतीजे: NVIDIA का blog पाँच Indic benchmarks पर नतीजे देता है (MILU 1.5, Indic GPQA, Indic AIME, Indic FrontierMath, Indic MBPP)। तुलना Sarvam-105B और Gemma-4-31B-It से है, और NVIDIA का दावा है कि उसका मॉडल पाँचों पर सबसे ऊपर है। पर नतीजे भाषा-वार नहीं हैं, और blog हिंदी का नाम नहीं लेता। Dataset वाला पोस्ट भी हर benchmark का नतीजा देता है, हर भाषा का नहीं।

Card पर deployment hardware "4× H100 or 2× GB200" लिखा है। Card का Quick Start Guide दो runtimes बताता है: vLLM और SGLang, दोनों के Docker container images के साथ।

Qwen3.8-27B: तुलना के लिए एक आम मॉडल

हर Indic मॉडल को किसी आम multilingual मॉडल के सामने परखना चाहिए। अगर आपके prompts पर Indic मॉडल आम मॉडल से बेहतर नहीं निकलता, तो उसकी विशेषज्ञता से आपको कुछ नहीं मिला। Qwen3.8-27B यहाँ वही आधार रेखा (baseline) है।

लाइसेंस Apache-2.0 है। यह dense मॉडल है, MoE नहीं। इसलिए हर टोकन पर इसके सारे पैरामीटर काम करते हैं (safetensors आँकड़ा 27,781,427,952)। Context 262,144 टोकन native है, और 1,000,000 तक बढ़ाया जा सकता है। Model card में कोई भाषा सूची नहीं है, और हिंदी का ज़िक्र नहीं है। इसका मतलब सिर्फ़ इतना है कि card में यह नहीं लिखा। इसकी हिंदी को आपकी अपनी जाँच ही परखेगी।

GGUF: Qwen/Qwen3.8-27B-GGUF खोलने पर access error मिला। इसलिए यहाँ यह दावा नहीं है कि Qwen GGUF नहीं देता। सबसे ज़्यादा download होने वाली GGUF तीसरे पक्ष unsloth की है (unsloth/Qwen3.8-27B-GGUF, Apache-2.0)। उसकी UD-Q4_K_M फ़ाइल 16.46 GB की है। UD का मतलब unsloth का dynamic mixed-bit quant है, इसलिए यह सादा Q4_K_M नहीं है।

चार्टकुल और सक्रिय पैरामीटर (B = अरब)
इस चार्ट के पीछे का डेटा
[
  {
    "label": "Sarvam-30B",
    "total_params_b": 32.15,
    "active_params_b": 2.4
  },
  {
    "label": "Qwen3.8-27B (dense)",
    "total_params_b": 27.78,
    "active_params_b": 27.78
  },
  {
    "label": "Sarvam-105B",
    "total_params_b": 106.03,
    "active_params_b": 10.3
  },
  {
    "label": "Nemotron 3.5 Super VL",
    "total_params_b": 120,
    "active_params_b": 12
  }
]

Qwen की पंक्ति में कुल और सक्रिय बराबर हैं, क्योंकि dense मॉडल में हर टोकन पूरे मॉडल से गुज़रता है। Nemotron की पंक्ति card का 120B आँकड़ा है, vision encoder और connector के बिना।

किस मॉडल को कितनी RAM चाहिए?

हिसाब सर्वर की RAM में कितना बड़ा LLM आएगा वाली गाइड के तरीके से है: कुल RAM = weights + KV cache + runtime buffers + OS के लिए खाली जगह। GGUF फ़ाइल का साइज़ weights का सच्चा आँकड़ा है, क्योंकि फ़ाइल में ठीक वही tensor data है जो RAM में लोड होगा। उस गाइड के अनुसार एक user और छोटे मॉडल के लिए runtime buffers लगभग 1 GiB रखें, और OS के लिए 2 GiB खाली छोड़ें।

इकाई का फ़र्क ध्यान रखें। Hugging Face फ़ाइल साइज़ GB में दिखाता है (1 GB = 10^9 bytes)। free -h GiB में दिखाता है (1 GiB = 1,073,741,824 bytes)। इसलिए नीचे bytes को GiB में बदला गया है, फिर 3 GiB (1 runtime + 2 OS) जोड़े गए हैं। KV cache इसमें नहीं है, क्योंकि वह आपके context length पर निर्भर है। बड़े मॉडल के लिए runtime buffers 1 GiB से ज़्यादा भी हो सकते हैं, इसलिए आख़िरी कॉलम को न्यूनतम मानें।

चार्टGGUF फ़ाइल साइज़ और KV cache से पहले की न्यूनतम RAM (फ़ाइल साइज़ से अनुमान)
इस चार्ट के पीछे का डेटा
[
  {
    "label": "Qwen3.8-27B UD-Q4_K_M (unsloth)",
    "file_gb": 16.46,
    "file_gib": 15.33,
    "ram_before_kv_gib": 18.3
  },
  {
    "label": "Sarvam-30B Q4_K_M",
    "file_gb": 19.57,
    "file_gib": 18.23,
    "ram_before_kv_gib": 21.2
  },
  {
    "label": "Qwen3.8-27B Q8_0 (unsloth)",
    "file_gb": 29.05,
    "file_gib": 27.05,
    "ram_before_kv_gib": 30.1
  },
  {
    "label": "Sarvam-105B Q4_K_M",
    "file_gb": 64.2,
    "file_gib": 59.79,
    "ram_before_kv_gib": 62.8
  },
  {
    "label": "Nemotron 3.5 Super VL Q4_0 (ggml-org)",
    "file_gb": 71.8,
    "file_gib": 66.87,
    "ram_before_kv_gib": 69.9
  },
  {
    "label": "Nemotron 3.5 Super VL NVFP4 (ggml-org)",
    "file_gb": 76.92,
    "file_gib": 71.64,
    "ram_before_kv_gib": 74.6
  },
  {
    "label": "Nemotron 3.5 Super VL Q8_0 (ggml-org)",
    "file_gb": 128.47,
    "file_gib": 119.65,
    "ram_before_kv_gib": 122.6
  }
]

Sarvam-30B के weights 18.23 GiB हैं। 3 GiB जोड़ने पर KV cache से पहले ही 21.2 GiB बनता है। इसलिए यह 16 GiB RAM में पूरा नहीं समाएगा, और 24 GiB पर KV cache के लिए बहुत कम जगह बचती है। 32 GiB वाले सर्वर पर छोटे context के साथ जगह बचती है। Qwen3.8-27B की unsloth UD-Q4_K_M फ़ाइल भी लगभग उसी श्रेणी में है (18.3 GiB)। पर अगला भाग बताता है कि बराबर RAM का मतलब बराबर काम नहीं है।

Sarvam-105B को KV cache से पहले 62.8 GiB चाहिए, यानी 64 GiB RAM भी काफ़ी नहीं है। Nemotron 3.5 Super VL की सबसे छोटी GGUF (ggml-org की Q4_0) 69.9 GiB माँगती है, और Q8_0 122.6 GiB। ये आम VPS के आँकड़े नहीं हैं।

ggml-org के Nemotron GGUF repo में एक विरोधाभास है। Card पेज Q4_0 को 76.9 GB और NVFP4 को 71.8 GB बताता है। File listing में उल्टा है: NVFP4 फ़ाइल 76.92 GB की है और Q4_0 फ़ाइल 71.8 GB की। ऊपर के आँकड़े file listing के bytes से हैं। Download से पहले repo का Files tab खुद देखें।

KV cache का हिस्सा खुद निकालें

KV cache हर टोकन के लिए हर layer की key और value रखता है। इसलिए यह context length के साथ बढ़ता है। Linked गाइड का सूत्र है: kv bytes per token = 2 x layers x kv_heads x head_dim x bytes per element। Sarvam-30B के card में 19 layers और 4 KV heads हैं। head_dim यहाँ निकाला नहीं गया, इसलिए उसे pinned revision की config.json से पढ़ें:

curl -sL https://huggingface.co/sarvamai/sarvam-30b/raw/071ae95e933605ca1104a6b4524a36a98488efa4/config.json |
  python3 -m json.tool | grep -E '"(num_hidden_layers|num_key_value_heads|head_dim|hidden_size|num_attention_heads)"'

f16 cache (2 bytes प्रति element) पर Sarvam-30B के लिए प्रति टोकन KV होगा: 2 × 19 × 4 × head_dim × 2 bytes। इसे अपने context length से गुणा करें। Card के अपने llama-server उदाहरण -c 4096 इस्तेमाल करते हैं, जबकि GGUF metadata 131,072 तक context बताता है। बड़ा context चुनेंगे तो KV cache उसी अनुपात में बढ़ेगा। Ollama में context length (num_ctx) सेट करना और KV cache को quantize करके RAM बचाना इसी हिस्से पर काम करते हैं।

Sarvam-105B और Nemotron के लिए यह सूत्र मान कर न चलें। उनकी config.json देखें, और मॉडल लोड होने पर llama.cpp का startup log पढ़ें, जो KV cache के लिए रखी गई memory छापता है।

Disk भी देखें। Download से पहले df -h से खाली जगह जाँचें। Sarvam-30B के लिए कम से कम 19.57 GB चाहिए। अगर आप फ़ाइलें download करके Ollama में import करते हैं, तो import के बाद df -h फिर चलाएँ और देखें कि कितनी जगह गई।

सिर्फ़ 2.4B सक्रिय पैरामीटर CPU वाले VPS के लिए क्यों मायने रखते हैं?

LLM जवाब टोकन-दर-टोकन बनाता है। हर नए टोकन के लिए उन सभी weights को RAM से CPU तक पढ़ना पड़ता है जो उस टोकन के हिसाब में शामिल हैं। CPU वाले सर्वर पर यह पढ़ाई (memory bandwidth) आम तौर पर रफ़्तार की सीमा बनती है, गणना नहीं।

Dense Qwen3.8-27B में हर टोकन पर लगभग 27.8B पैरामीटर पढ़े जाते हैं। Sarvam-30B में router हर टोकन के लिए 128 में से 6 experts और shared expert चुनता है। इसलिए हर टोकन पर लगभग 2.4B पैरामीटर ही काम करते हैं। दोनों की RAM लगभग बराबर है, पर Sarvam-30B में हर टोकन पर पढ़ा जाने वाला data बहुत कम है। यही वजह है कि बिना GPU वाले VPS पर यह MoE मॉडल व्यावहारिक है।

फिर भी पूरी फ़ाइल RAM में रहनी चाहिए। अगला टोकन कौन से experts चुनेगा, यह पहले से पता नहीं होता। इसलिए कोई भी expert किसी भी पल चाहिए हो सकता है। सक्रिय पैरामीटर रफ़्तार तय करते हैं। कुल पैरामीटर RAM तय करते हैं।

यह बात आप खुद माप सकते हैं। दोनों मॉडल एक ही सर्वर पर चलाएँ और local LLM के tokens per second मापने के तरीके से तुलना करें। यहाँ कोई आँकड़ा नहीं दिया गया, क्योंकि रफ़्तार आपके CPU, RAM और context पर निर्भर है।

Nemotron 3.5 Super VL में भी सिर्फ़ 12B सक्रिय हैं। पर इसकी सबसे छोटी GGUF ही 71.8 GB की है, और card का reference deployment चार H100 या दो GB200 GPU का है। NVFP4 NVIDIA का 4-bit फ़ॉर्मेट है। NVIDIA के अनुसार Blackwell GPU पर weights और activations दोनों 4-bit में चलते हैं, और दूसरे platforms पर वही checkpoint 4-bit weights और 16-bit activations के साथ चलता है। NVFP4 safetensors repo लगभग 75.06 GB का है, और BF16 repo लगभग 248.91 GB का। यह GPU का काम है। CPU वाले VPS पर इसकी योजना न बनाएँ।

Sarvam-30B को Ollama से कैसे चलाएँ?

Ollama को Linux पर उसके docs के इस कमांड से install करें, फिर version देखें:

curl -fsSL https://ollama.com/install.sh | sh
ollama -v

ollama -v को version छापना चाहिए। Docs यह जाँचने के लिए एक terminal में ollama serve और दूसरे में ollama -v चलाने को कहते हैं। अगर server न मिलने की चेतावनी आए, तो यही करें। VPS पर पूरी setup के लिए VPS पर Ollama से अपना LLM चलाने की गाइड देखें।

सबसे छोटा रास्ता Sarvam का अपना GGUF card देता है:

ollama run hf.co/sarvamai/sarvam-30b-gguf:Q4_K_M

Hugging Face के docs के अनुसार hf.co/{username}/{repository}:{quantization} वाला रूप Hub से GGUF चलाता है। Ollama chat template GGUF के tokenizer.chat_template metadata से लेता है। Download पूरा होने पर prompt खुलेगा, जहाँ आप एक हिंदी सवाल लिख सकते हैं। दूसरे terminal में ollama ps चलाएँ: मॉडल वहाँ loaded दिखना चाहिए।

Card यह नहीं बताता कि llama.cpp या Ollama का कौन सा संस्करण bailingmoe2 architecture को पहली बार लोड कर सका। अगर लोड करते समय error आए, तो error की पंक्ति पढ़ें और अपने Ollama संस्करण के release notes देखें।

Revision pin करके चलाना

hf.co/...:Q4_K_M repo की ताज़ा फ़ाइल लेता है। Production में आप चाहेंगे कि आज जाँचा गया मॉडल ही कल भी चले। इसके लिए फ़ाइलें एक तय commit से download करें। पहले एक Python venv में Hugging Face का hf CLI और transformers डालें। transformers बाद में tokenizer गिनने के काम आएगा:

sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/llm-tools
~/llm-tools/bin/pip install -U huggingface_hub transformers

फिर 17 अक्टूबर 2026 को देखा गया commit pin करके shards download करें:

~/llm-tools/bin/hf download sarvamai/sarvam-30b-gguf \
  --revision 54e15edbbcb112e7d6c69b612e5041973e953c2f \
  --include "*.gguf" --local-dir ~/models/sarvam-30b-gguf
# अपेक्षित कुल: 19570785664 bytes (6 shards)
du -cb ~/models/sarvam-30b-gguf/*.gguf | tail -n 1

आख़िरी पंक्ति का total ऊपर के अपेक्षित आँकड़े से मिलना चाहिए। कम आँकड़ा मतलब कोई shard अधूरा है, इसलिए download दोबारा चलाएँ। अब एक Modelfile बनाएँ और मॉडल Ollama में import करें:

printf 'FROM %s/models/sarvam-30b-gguf/sarvam-30b-Q4_K_M.gguf-*.gguf\n' "$HOME" > ~/models/Modelfile.sarvam-30b
ollama create sarvam-30b-q4 -f ~/models/Modelfile.sarvam-30b
ollama show sarvam-30b-q4 --modelfile
ollama run sarvam-30b-q4

Ollama के import docs कहते हैं कि split GGUF के shards के नाम न बदलें, और Modelfile की FROM पंक्ति में ऐसा wildcard दें जो हर shard से मेल खाए। Ollama import के दौरान GGUF को फिर से quantize नहीं करता, इसलिए मॉडल वही Q4_K_M रहता है। ollama show --modelfile के output में TEMPLATE पंक्ति देखें, और जवाबों की तुलना hf.co वाले रास्ते से करें। पूरा तरीका GGUF मॉडल को Ollama में import करने की गाइड में है।

llama.cpp से चलाना, और vLLM का सवाल

llama.cpp का README यह install script देता है। उसके बाद llama serve एक OpenAI-compatible API server चलाता है। Sarvam का card Sarvam-30B के लिए यही रूप देता है:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf sarvamai/sarvam-30b-gguf:Q4_K_M

llama.cpp के server README के अनुसार server डिफ़ॉल्ट रूप से 127.0.0.1:9931 पर सुनता है। आपके संस्करण का startup log जो पता छापे, वही मानें। README और build docs में binary के नाम अलग लिखे हैं (llama serve और llama-server)। इसलिए port और context के flags के लिए अपने install किए संस्करण पर llama serve --help चलाएँ। सर्वर चलने पर एक chat request भेजें:

curl -s http://127.0.0.1:9931/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"messages":[{"role":"user","content":"दिल्ली से जयपुर ट्रेन से जाने के दो फ़ायदे बताइए।"}]}'

जवाब JSON में आएगा। choices के अंदर message.content में हिंदी text होना चाहिए। Server 127.0.0.1 पर है, इसलिए internet से नहीं दिखता। अपने laptop से इस्तेमाल करना हो, तो port खोलने की बजाय SSH tunnel लें: ssh -L 9931:127.0.0.1:9931 user@your-vps। Production में llama.cpp का संस्करण pin करें। सर्वर पर llama.cpp release pin करना बताता है कैसे, और VPS पर llama.cpp server चलाने की गाइड systemd service तक ले जाती है।

vLLM के बारे में card के शब्द देखें: Sarvam-30B के card के अनुसार vLLM में native support के लिए एक PR खुला है। Card दो रास्ते देता है: source से build किया गया custom vLLM fork, या एक hot-patch script जो vllm 0.15.0 install करके model registry बदलती है। Card आख़िरी बार 23 मार्च 2026 को बदला गया था। vLLM की आज की supported-models सूची में Sarvam के नाम सिर्फ़ "Sarvam 2" ids के साथ हैं (जैसे sarvamai/sarvam2-30b-a3b), sarvam-30b के साथ नहीं। Sarvam 2 का repo यहाँ खोला नहीं जा सका, इसलिए उस पर कोई दावा नहीं है।

इसलिए Sarvam-30B की GGUF के साथ llama.cpp या Ollama सीधा रास्ता है। Card खुद quantized फ़ाइलों के लिए llama.cpp, Ollama और LM Studio का नाम लेता है। जब कई users एक साथ आने लगें, तब vLLM का सवाल दोबारा उठता है। उस फ़ैसले के लिए Ollama और vLLM का फ़र्क पढ़ें।

एक हिंदी वाक्य कितने टोकन खाता है?

मॉडल text को टोकन में तोड़ता है। एक ही हिंदी वाक्य अलग tokenizers में अलग संख्या के टोकन बन सकता है। ज़्यादा टोकन का मतलब है context में कम जगह, और जवाब बनने में ज़्यादा कदम। यहाँ कोई संख्या नहीं दी जा रही। नीचे के दो तरीकों से इसे खुद गिनें।

पहला तरीका चल रहे llama.cpp server का /tokenize endpoint है। Server README के अनुसार यह content लेता है और tokens नाम की सूची लौटाता है:

curl -s http://127.0.0.1:9931/tokenize \
  -H 'Content-Type: application/json' \
  -d '{"content": "मेरा ऑर्डर तीन दिन से अटका है, रिफ़ंड कब मिलेगा?"}' |
  python3 -c 'import json,sys; print(len(json.load(sys.stdin)["tokens"]))'

यह सिर्फ़ उस मॉडल का tokenizer गिनता है जो server पर लोड है। दूसरा तरीका चारों मॉडल एक साथ गिनता है, बिना weights download किए, क्योंकि AutoTokenizer सिर्फ़ tokenizer की फ़ाइलें लाता है:

cat > ~/count_tokens.py <<'EOF'
import sys
from transformers import AutoTokenizer

REPOS = [
    ("sarvamai/sarvam-30b", "071ae95e933605ca1104a6b4524a36a98488efa4", True),
    ("sarvamai/sarvam-105b", "abe264bdb8fb2244daadaa59ebc2020b3c139e89", True),
    ("Qwen/Qwen3.8-27B", "1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0", False),
    ("nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-BF16", "1f8953f7f0935358e3605150d22bc15df062061c", False),
]

text = sys.argv[1]
for repo, rev, remote in REPOS:
    try:
        tok = AutoTokenizer.from_pretrained(repo, revision=rev, trust_remote_code=remote)
        print(f"{len(tok.encode(text, add_special_tokens=False)):>5}  {repo}")
    except Exception as e:
        print(f"  ERR  {repo}: {e}")
EOF
~/llm-tools/bin/python ~/count_tokens.py "मेरा ऑर्डर तीन दिन से अटका है, रिफ़ंड कब मिलेगा?"
~/llm-tools/bin/python ~/count_tokens.py "mera order teen din se atka hai, refund kab milega?"
~/llm-tools/bin/python ~/count_tokens.py "My order has been stuck for three days. When will I get a refund?"

Sarvam के repos के लिए trust_remote_code=True है, क्योंकि card मॉडल लोड करने के लिए यही माँगता है। इसका मतलब है कि repo का Python code आपके सर्वर पर चलेगा। इसी वजह से हर repo का revision pin किया गया है। कोई tokenizer लोड न हो, तो ERR वाली पंक्ति पढ़ें, या उस मॉडल के लिए पहला तरीका इस्तेमाल करें।

तीनों वाक्य एक ही बात कहते हैं: देवनागरी, Hinglish और अंग्रेज़ी में। हर मॉडल के लिए तीनों संख्याएँ एक साथ लिखें। किसी hosted मॉडल से तुलना करनी हो, तो वही तीन वाक्य उस API के अपने token counter में डालें।

अपने prompts से हिंदी quality कैसे परखें?

Model card से हिंदी quality का अंदाज़ा नहीं लगता, क्योंकि यहाँ देखे गए किसी स्रोत में हिंदी का अलग आँकड़ा नहीं है। इसलिए अपना छोटा test set बनाएँ, जिसे हर नए मॉडल पर दोहराया जा सके। शुरुआत में देवनागरी का एक सवाल, Hinglish में ग्राहक को जवाब, और अंग्रेज़ी से हिंदी अनुवाद रखें। फिर अपनी असली chats से 10 से 20 prompts जोड़ें, नाम और फ़ोन नंबर हटाकर।

mkdir -p ~/hindi-eval
cat > ~/hindi-eval/prompts.txt <<'EOF'
UPI से पेमेंट कट गया लेकिन ऑर्डर कन्फ़र्म नहीं हुआ। ग्राहक को तीन छोटे वाक्यों में क्या बताना चाहिए?
Customer ne likha: bhai mera order 3 din se pending hai, refund kab milega? Iska jawab Hinglish mein do, polite tone mein, 2-3 lines.
Translate into Hindi for a shop notice: "We will be closed on Sunday for maintenance. Online orders will ship on Monday."
EOF

अब हर prompt एक मॉडल पर चलाएँ और जवाब तारीख वाली फ़ाइल में रखें:

MODEL=hf.co/sarvamai/sarvam-30b-gguf:Q4_K_M
OUT=~/hindi-eval/$(date +%F)-$(echo "$MODEL" | tr '/:' '__').txt
while IFS= read -r p; do
  printf '### %s\n' "$p" >> "$OUT"
  ollama run "$MODEL" "$p" < /dev/null >> "$OUT"
  printf '\n' >> "$OUT"
done < ~/hindi-eval/prompts.txt

< /dev/null ज़रूरी है। Loop के अंदर ollama run का stdin खुला रहे, तो वह prompts फ़ाइल की अगली पंक्तियाँ पढ़ सकता है, और फिर loop अधूरा रह जाता है। दूसरे मॉडल के लिए सिर्फ़ MODEL बदलें, जैसे hf.co/unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_M। Hugging Face के docs के अनुसार quant का नाम case-insensitive है, और पूरा फ़ाइल नाम भी tag के रूप में दिया जा सकता है।

हर जवाब को इन चार बातों पर 0, 1 या 2 अंक दें:

  • लिपि: देवनागरी वाले सवाल का जवाब देवनागरी में आया, और Hinglish वाले का रोमन में।
  • अर्थ: जवाब सही है, और उसी सवाल का जवाब है जो पूछा गया।
  • लहजा: ग्राहक से बात के लायक विनम्र और साफ़ है।
  • सहजता: वाक्य स्वाभाविक हिंदी हैं, अंग्रेज़ी वाक्य-रचना का शब्दशः अनुवाद नहीं लगते।

Scoring blind रखें। फ़ाइलों के नाम छिपाकर किसी दूसरे व्यक्ति से अंक दिलवाएँ, ताकि मॉडल का नाम फ़ैसले पर असर न डाले। हर run में वही settings रखें, क्योंकि temperature बदलने से एक ही prompt का जवाब बदल जाता है। इसके लिए Ollama में temperature और sampling देखें। जिस मॉडल को आपके test पर सबसे ज़्यादा अंक मिलें, वह आपके काम के लिए सबसे अच्छा है। यह दावा उसी test तक सीमित है।

भारत में self-host क्यों करें, और कब hosted API बेहतर है?

DPDP (Digital Personal Data Protection) Act, 2023 और DPDP Rules, 2025 ग्राहकों के निजी डेटा से जुड़े भारतीय नियम हैं। इस गाइड के लिए इनका मूल पाठ नहीं खोला जा सका, इसलिए यहाँ कोई duty, तारीख या जुर्माना नहीं लिखा गया। इन्हें meity.gov.in पर मूल पाठ से पढ़ें। Self-hosting से chat text किसी model provider के पास नहीं जाता। पर डेटा फिर भी आपके सर्वर, logs और backups में रहता है, और उसकी ज़िम्मेदारी आपकी है। अपना सर्वर होना अपने आप किसी नियम का पालन नहीं है।

Latency दूसरी वजह है। ग्राहक भारत में हैं, तो भारत के डेटा सेंटर (जैसे मुंबई) वाला सर्वर हर request का network समय घटाता है। अंदाज़ा न लगाएँ। अपने ग्राहकों के शहर से ping और mtr चलाकर नापें। CPU पर जवाब बनने का समय network के समय से कहीं ज़्यादा हो सकता है, इसलिए दोनों को अलग नापें।

Hosted API ईमानदारी से बेहतर सौदा इन हालात में है:

  • आपकी जाँच में Sarvam-105B या Nemotron जैसा बड़ा मॉडल ही काम का निकला, और आपके पास GPU या 64 GiB से कहीं ज़्यादा RAM वाला सर्वर नहीं है।
  • Chats कम हैं, इसलिए महीने भर चलता सर्वर ज़्यादातर समय खाली बैठा रहेगा।
  • सर्वर, security updates और मॉडल upgrades संभालने वाला कोई नहीं है।
  • कई users एक साथ आते हैं, और CPU पर उनकी कतार लंबी हो जाती है।

कीमतें यहाँ नहीं दी गईं, क्योंकि किसी vendor का pricing page आज नहीं खोला गया। Vendor के अपने pricing page की दर को ऊपर गिने हुए अपने टोकन से गुणा करें। Ollama Cloud और अपने सर्वर की तुलना और क्या Claude को self-host किया जा सकता है इसी फ़ैसले के दो पहलू हैं।

इस गाइड में इस्तेमाल हुए repo revisions (17 अक्टूबर 2026)
# sarvamai/sarvam-30b         071ae95e933605ca1104a6b4524a36a98488efa4  (2026-03-23)
# sarvamai/sarvam-30b-gguf    54e15edbbcb112e7d6c69b612e5041973e953c2f  (2026-03-23)
# sarvamai/sarvam-105b        abe264bdb8fb2244daadaa59ebc2020b3c139e89  (2026-09-21)
# sarvamai/sarvam-105b-gguf   d4cbfe90292fa78f119ff088201df1901f5a6525  (2026-03-23)
# Qwen/Qwen3.8-27B            1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0  (2026-08-14)
# unsloth/Qwen3.8-27B-GGUF    4ca720788d1e01f1bff70c033e0d0028fd02e502
# nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-BF16   1f8953f7f0935358e3605150d22bc15df062061c  (2026-10-16)
# nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4  59b8721646c38111a242da18218859fb2b454322  (2026-10-16)
# ggml-org/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-GGUF 3c91ad1be60865386af92e8147dafb32470b097d  (2026-10-15)

Nemotron के repos 16 अक्टूबर 2026 को बदले गए थे, इसलिए उनका sha जल्दी बदल सकता है। Download से पहले repo पेज पर ताज़ा commit देखें।

FAQ

क्या Sarvam-30B बिना GPU वाले VPS पर चल सकता है?

हाँ, अगर RAM काफ़ी हो। आधिकारिक Q4_K_M GGUF फ़ाइलें कुल 19.57 GB की हैं, यानी 18.23 GiB। Runtime और OS के लिए लगभग 3 GiB जोड़ें, तो KV cache से पहले 21.2 GiB बनता है। यह MoE मॉडल है, इसलिए हर टोकन पर सिर्फ़ 2.4B पैरामीटर काम करते हैं, जो CPU पर इसे व्यावहारिक बनाता है। रफ़्तार अपने सर्वर पर खुद मापें।

क्या ये ओपन-सोर्स मॉडल Hinglish समझते हैं?

यहाँ देखे गए किसी model card में Hinglish पर मापा गया नतीजा नहीं है। Sarvam-30B का card रोमन लिपि वाली हिंदी का ज़िक्र नहीं करता। NVIDIA और AI4Bharat का Indic dataset हिंदी समेत बारह भाषाओं का रोमन लिपि वाला data रखता है, पर यह training data है, मापा गया नतीजा नहीं। अपने ग्राहकों के असली Hinglish संदेशों से test set बनाकर हर मॉडल को जाँचें।

हिंदी के लिए सबसे अच्छा ओपन-सोर्स LLM कौन सा है?

इसका जवाब सिर्फ़ आपका अपना test दे सकता है। Sarvam-30B का card और NVIDIA का Nemotron blog, दोनों में नतीजे भाषा-वार नहीं हैं, और Qwen3.8-27B का card भाषाओं की सूची ही नहीं देता। CPU वाले VPS पर Sarvam-30B और Qwen3.8-27B की Q4 फ़ाइलें फ़िट हो सकती हैं। इन दोनों को एक ही prompts पर चलाएँ और blind scoring करें।

क्या अपने सर्वर पर मॉडल चलाने से DPDP Act की शर्तें पूरी हो जाती हैं?

अपने आप नहीं। Self-hosting से chat text किसी model provider के पास नहीं जाता, पर डेटा आपके सर्वर, logs और backups में रहता है, और उसकी ज़िम्मेदारी आपकी है। DPDP Act, 2023 और DPDP Rules, 2025 की असली शर्तें और तारीखें meity.gov.in पर मूल पाठ से पढ़ें, या किसी वकील से पूछें।

Sarvam-30B को vLLM की जगह llama.cpp या Ollama से क्यों चलाएँ?

Sarvam-30B का card कहता है कि vLLM में native support का PR खुला है, और काम चलाने के लिए एक custom fork या एक hot-patch script देता है। vLLM की आज की supported-models सूची में Sarvam के नाम सिर्फ़ Sarvam 2 ids के साथ हैं। Sarvam की अपनी GGUF फ़ाइल ollama run hf.co/sarvamai/sarvam-30b-gguf:Q4_K_M या llama serve -hf sarvamai/sarvam-30b-gguf:Q4_K_M से सीधे चलती है, जो एक सर्वर पर शुरुआत का सबसे सीधा रास्ता है।