VPS पर llama.cpp सर्वर कैसे सेटअप करें

आप क्या बना रहे हैं

VPS पर llama.cpp सर्वर चलाने का अर्थ है एक सिंगल बाइनरी, llama-server, जो एक GGUF मॉडल फ़ाइल लोड करती है और OpenAI-compatible API पर HTTP अनुरोधों का उत्तर देती है। किसी भी OpenAI क्लाइंट को http://127.0.0.1:8080/v1 पर पॉइंट करें और यह काम करने लगेगा। इंस्टॉलेशन इसका आसान हिस्सा है।

बाकी काम ऑपरेशंस का है: एक वर्ज़न पिन करना, पोर्ट को localhost पर रखना, एक systemd यूनिट लिखना, और यह तय करना कि जब सर्वर की मेमोरी खत्म हो जाए तो क्या होगा। यह गाइड इसी बारे में है। यदि आपने अभी तक दो स्पष्ट विकल्पों के बीच निर्णय नहीं लिया है, तो पहले Ollama और llama.cpp के बीच के अंतर को पढ़ें, क्योंकि यह वह 'हाउ-टू' है जिसे उस तुलना में जानबूझकर छोड़ दिया गया है।

एक release tag चुनें और उसे नोट करें

llama.cpp लगभग हर merge के लिए एक release tag बनाता है, इसलिए ये tags वास्तव में build numbers हैं। 18 August 2026 तक b10488 सबसे नया है। इसमें कोई long-lived stable branch नहीं है, जिसका अर्थ है कि "latest" एक बदलता हुआ लक्ष्य है और जिस version का आपने परीक्षण किया है, केवल वही version समर्थित है। एक tag चुनें, उसे रिकॉर्ड करें और उसी string का उपयोग अपने clone, binary नाम और नोट्स में करें।

प्रत्येक tag के साथ prebuilt archives भी आते हैं। CPU-only x86 VPS के लिए यह llama-b10488-bin-ubuntu-x64.tar.gz है, और यदि आप x86 के बजाय ARM VPS पर हैं, तो arm64 archive उसके बगल में उपलब्ध है।

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10488/llama-b10488-bin-ubuntu-x64.tar.gz
tar tf llama-b10488-bin-ubuntu-x64.tar.gz | head

extract करने से पहले archive की सूची देखें, ताकि आपको पता चल सके कि फाइलें कहाँ save होंगी। ये binaries उस image की C library से linked होती हैं जिसमें उन्हें build किया गया था, इसलिए पुराने distribution पर ये startup के समय एक ऐसी GLIBC_ version त्रुटि के साथ fail हो सकती हैं जो install नहीं है। एक छोटे VPS पर source से build करने में कुछ मिनट लगते हैं और यह इस तरह की पूरी समस्या को खत्म कर देता है, इसलिए नीचे वही तरीका दिया गया है।

एक pinned tag से llama-server को बिल्ड करना

sudo apt update
sudo apt install -y build-essential cmake git libssl-dev
git clone --depth 1 --branch b10488 https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2

--branch b10488 का उपयोग करके --depth 1 क्लोन पर केवल उस विशिष्ट tag को चेकआउट करें, ताकि काम करते समय बिल्ड में कोई बदलाव न आए।

libssl-dev महत्वपूर्ण है क्योंकि LLAMA_OPENSSL विकल्प डिफ़ॉल्ट रूप से चालू रहता है, और यही वह विकल्प है जो बाद में बाइनरी को HTTPS के माध्यम से मॉडल डाउनलोड करने की अनुमति देता है। हेडर के बिना, कॉन्फ़िगरेशन चरण विफल हो जाता है।

-DBUILD_SHARED_LIBS=OFF आपको एक आत्मनिर्भर बाइनरी देता है। डिफ़ॉल्ट बिल्ड में साझा लाइब्रेरी (shared libraries) निष्पादन योग्य फ़ाइल (executable) के साथ रखी जाती हैं, इसलिए केवल निष्पादन योग्य फ़ाइल को /usr/local/bin पर कॉपी करने से error while loading shared libraries: libllama.so त्रुटि आती है।

-t llama-server केवल सर्वर टारगेट को बिल्ड करता है। डिफ़ॉल्ट बिल्ड अन्य टूल्स और टेस्ट्स को भी कंपाइल करता है, जिसमें दो-कोर वाले VPS पर उन फ़ाइलों के लिए कई अतिरिक्त मिनट लग जाते हैं जिन्हें आप कभी नहीं चलाएंगे।

-j 2 जानबूझकर किया गया है। प्रत्येक समानांतर कंपाइल जॉब अपना वर्किंग सेट रखती है, इसलिए छोटे प्लान पर -j $(nproc) का उपयोग करने से c++: fatal error: Killed signal terminated program cc1plus की स्थिति उत्पन्न होती है, जहाँ कर्नेल का आउट-ऑफ़-मेमोरी किलर कंपाइलर को रोक देता है। जॉब काउंट कम करें, या बिल्ड के लिए स्वैप (swap) जोड़ें।

एक फ्लैग जिसे आप बदलना चाह सकते हैं: GGML_NATIVE डिफ़ॉल्ट रूप से चालू रहता है, इसलिए कंपाइलर उसी CPU को टारगेट करता है जिस पर बिल्ड किया जा रहा है। यदि आप उसी मशीन पर बिल्ड कर रहे हैं जहाँ इसे चलना है, तो यही सही है। यदि आप एक बार बिल्ड करके बाइनरी को किसी अन्य होस्ट पर कॉपी करते हैं, तो -DGGML_NATIVE=OFF जोड़ें, क्योंकि यदि बाइनरी उन निर्देशों का उपयोग करती है जो दूसरे CPU में नहीं हैं, तो पहली बार इन्फरेंस (inference) के दौरान वह Illegal instruction (core dumped) के साथ क्रैश हो जाएगी।

इसे ऐसे नाम से इंस्टॉल करें जिसमें टैग का उल्लेख हो।

./build/bin/llama-server --version
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-b10488
sudo ln -sfn /usr/local/bin/llama-server-b10488 /usr/local/bin/llama-server

--version बिल्ड नंबर और कमिट को प्रिंट करता है। इसे आपके द्वारा चेकआउट किए गए टैग से मेल खाना चाहिए। यदि ऐसा नहीं है, तो आपने कुछ और बिल्ड किया है। फ़ाइल नाम में नंबर रखना और उस पर एक सिमलिंक (symlink) पॉइंट करना यह सुनिश्चित करता है कि अपग्रेड केवल एक ln -sfn और एक रीस्टार्ट की प्रक्रिया है, और रोलबैक भी पुराने नंबर के साथ वही कमांड है।

GGUF मॉडल प्राप्त करें और सबसे पहले डिस्क की जाँच करें

GGUF वह एकल फ़ाइल प्रारूप है जिसे llama.cpp लोड करता है। एक ही फ़ाइल में वेट्स (weights), टोकनाइज़र और मेटाडेटा होते हैं, इसलिए इंस्टॉल करने के लिए कुछ और नहीं बचता। फ़ाइल नाम का सफ़िक्स क्वांटाइज़ेशन है, जो वह प्रिसिजन है जिस पर वेट्स स्टोर किए जाते हैं: Q4_K_M एक 4-बिट मिक्स है, Q8_0 8-बिट है, और f16 अनक्वांटाइज़्ड हाफ-प्रिसिजन फ़ाइल है।

कुछ भी डाउनलोड करने से पहले एक सर्विस अकाउंट और एक मॉडल डायरेक्टरी बनाएँ।

sudo useradd --system --home /srv/llama --create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
df -h /srv

सर्वर -hf के साथ स्वयं मॉडल फ़ेच कर सकता है, जो यह साबित करने का सबसे तेज़ तरीका है कि आपका बिल्ड काम कर रहा है।

sudo -u llama env LLAMA_CACHE=/srv/models /usr/local/bin/llama-server \
  -hf ggml-org/gemma-3-1b-it-GGUF:Q4_K_M --host 127.0.0.1 --port 8080

LLAMA_CACHE डाउनलोड डायरेक्टरी सेट करता है। इसके बिना फ़ाइल ~/.cache/llama.cpp में उस अकाउंट के अंतर्गत जाती है जिसने कमांड चलाई है, जो उस सर्विस के लिए गलत स्थान है जिसकी होम डायरेक्टरी को आप अनरीडेबल (unreadable) बनाने वाले हैं। इसके बाद ls -lh /srv/models चलाएँ, क्योंकि कैश किया गया फ़ाइल नाम साधारण फ़ाइल नाम के बजाय रिपॉजिटरी नाम से लिया जाता है।

एक सर्विस के लिए, अपने चुने हुए पथ पर डाउनलोड करें, ताकि यूनिट फ़ाइल के पास पॉइंट करने के लिए कुछ स्थिर हो।

sudo -u llama curl -L --output-dir /srv/models -O \
  https://huggingface.co/ggml-org/gemma-3-1b-it-GGUF/resolve/main/gemma-3-1b-it-Q4_K_M.gguf

डिस्क वह सीमा है जिसका सामना लोग सबसे पहले करते हैं। ये दो मॉडलों के लिए प्रकाशित फ़ाइल आकार हैं, जिनकी जाँच 18 अगस्त 2026 को की गई थी।

[
  {
    "label": "gemma-3-1b-it Q4_K_M",
    "size_gb": 0.81
  },
  {
    "label": "gemma-3-1b-it Q8_0",
    "size_gb": 1.07
  },
  {
    "label": "gemma-3-1b-it f16",
    "size_gb": 2.01
  },
  {
    "label": "gpt-oss-20b MXFP4",
    "size_gb": 12.11
  }
]

1B मॉडल के लिए 4-बिट फ़ाइल 0.81 GB की है। बिना क्वांटाइज़ेशन वाला वही मॉडल 2.01 GB का है, इसलिए प्रारूप का चुनाव संख्या को दो गुना से अधिक बदल देता है। MXFP4 पर 20B मॉडल 12.11 GB का है, जो कई एंट्री-लेवल प्लान्स पर डिस्क में फिट नहीं होता है, और उसके बाद भी इसे मेमोरी में लोड करना पड़ता है।

हर डाउनलोड से पहले df -h की जाँच करें। 12 GB के ट्रांसफर के दौरान भर जाने वाला रूट फ़ाइलसिस्टम उन सभी चीज़ों को तोड़ देता है जिन्हें लिखने की आवश्यकता होती है, जिसमें जर्नल भी शामिल है।

इसे एक बार मैन्युअल रूप से चलाएं और जांचें

sudo -u llama /usr/local/bin/llama-server \
  --model /srv/models/gemma-3-1b-it-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 4096 --parallel 1 --threads 2 --no-webui

दूसरे session में, सर्वर से पूछें कि क्या वह तैयार है।

curl -s http://127.0.0.1:8080/health

जब फाइल लोड हो रही होती है, तो आपको HTTP 503 और यह body प्राप्त होती है:

{"error":{"code":503,"message":"Loading model","type":"unavailable_error"}}

जब यह तैयार हो जाता है, तो body {"status": "ok" } होती है। इसके बाद एक वास्तविक request भेजें।

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"local","messages":[{"role":"user","content":"Say hello in five words."}]}'

choices array वाला एक JSON object यह दर्शाता है कि सर्वर काम कर रहा है। model field वहां इसलिए है क्योंकि OpenAI clients हमेशा एक भेजते हैं। इस सर्वर में एक single model लोड है, इसलिए इस value का उपयोग किसी भी चीज़ को select करने के लिए नहीं किया जाता है।

OpenAI-compatible API, और port पर उपलब्ध अन्य चीजें

POST /v1/chat/completions, POST /v1/completions और POST /v1/embeddings OpenAI-compatible routes हैं, और GET /v1/models लोड किए गए model की जानकारी देता है। GET /health ऊपर बताया गया readiness check है, GET /props सर्वर की वर्तमान settings लौटाता है, और GET /metrics तब Prometheus counters को expose करता है जब आप --metrics के साथ शुरुआत करते हैं।

कोई भी OpenAI SDK तब काम करता है जब आप base URL को http://127.0.0.1:8080/v1 पर सेट करते हैं और एक non-empty API key string पास करते हैं। जब तक आप स्वयं --api-key सेट नहीं करते, तब तक कोई भी key की जाँच नहीं करता।

किसी और के throughput दावे को अपनी योजना के लिए आधार न मानें। CPU inference की गति core count, memory bandwidth और उन पड़ोसियों पर निर्भर करती है जिनके साथ आप host साझा करते हैं, इसलिए अपने सिस्टम पर tokens per second मापें और उस परिणाम को ही सत्य मानें। Noisy neighbour से मिलने वाला Steal time यहाँ generation speed के रूप में दिखाई देता है जो हर घंटे बदलती रहती है।

इसे 127.0.0.1 पर रखें और सामने एक proxy लगाएँ

--host पहले से ही डिफ़ॉल्ट रूप से 127.0.0.1 पर सेट होता है, इसलिए जब तक आप इसे बदलते नहीं हैं, तब तक सर्वर बाहर से एक्सेस नहीं किया जा सकता। इसे ऐसे ही रहने दें। llama-server में कोई user model, rate limit या उपयोगी audit log नहीं है, और इसमें एकमात्र इन-बिल्ट कंट्रोल --api-key है, जो केवल एक स्ट्रिंग की तुलना करता है। एक खुला inference port किसी के भी उपयोग के लिए मुफ्त compute संसाधन है, और Ollama के साथ की गई वैसी ही गलती यहाँ भी समान रूप से लागू होती है: self-hosted model API को सुरक्षित करना यहाँ पूरी तरह से लागू होता है।

nginx में TLS (transport layer security) को terminate करें और loopback port पर proxy करें।

server {
    listen 443 ssl;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

streaming के लिए proxy_buffering off आवश्यक है। यदि buffering चालू है, तो nginx server-sent events (SSE) को तब तक रोक कर रखता है जब तक कि response पूरा न हो जाए, जिससे client को प्रतीक्षा करनी पड़ती है और अंत में पूरा उत्तर एक साथ मिलता है। proxy_read_timeout 600s लंबी generations के लिए आवश्यक है, क्योंकि 60 सेकंड का डिफ़ॉल्ट समय एक धीमी प्रतिक्रिया को 504 Gateway Time-out में बदल देता है। nginx पर Certbot और Let's Encrypt का उपयोग करके certificate प्राप्त करें।

systemd unit

Write /etc/systemd/system/llama-server.service लिखें।

[Unit]
Description=llama.cpp server
After=network-online.target
Wants=network-online.target

[Service]
User=llama
Group=llama
Environment=LLAMA_ARG_MODEL=/srv/models/gemma-3-1b-it-Q4_K_M.gguf
Environment=LLAMA_ARG_HOST=127.0.0.1
Environment=LLAMA_ARG_PORT=8080
Environment=LLAMA_ARG_CTX_SIZE=4096
Environment=LLAMA_ARG_N_PARALLEL=1
Environment=LLAMA_ARG_THREADS=2
ExecStart=/usr/local/bin/llama-server --no-webui
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
MemoryHigh=3G
MemoryMax=3500M
OOMPolicy=stop
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

सेटिंग्स Environment= लाइनों में रहती हैं क्योंकि llama-server अधिकांश फ्लैग्स के लिए LLAMA_ARG_* वेरिएबल्स को पढ़ता है, और कमांड लाइन आर्ग्युमेंट मेल खाने वाले वेरिएबल को ओवरराइड कर देता है। यह आपको कॉन्टेक्स्ट साइज बदलने के लिए एक ही स्थान देता है, और यह ExecStart को इतना संक्षिप्त रखता है कि उसे एक नज़र में पढ़ा जा सके।

ProtectSystem=strict इस यूनिट के लिए पूरे फाइलसिस्टम को रीड-ओनली बना देता है, जो कि ठीक है क्योंकि सर्वर केवल मॉडल को पढ़ता है। यदि आप चाहते हैं कि सर्विस स्वयं -hf के साथ मॉडल डाउनलोड करे, तो ReadWritePaths=/srv/models जोड़ें। ProtectHome=yes, /home और /root को छिपा देता है, और यही कारण है कि मॉडल्स को /srv में रखना बेहतर है: ProtectHome ऑन होने पर, डिफ़ॉल्ट ~/.cache/llama.cpp पाथ प्रोसेस को बिल्कुल दिखाई नहीं देता है।

sudo systemctl daemon-reload
sudo systemctl enable --now llama-server
systemctl status llama-server
curl -s http://127.0.0.1:8080/health
journalctl -u llama-server -n 50 --no-pager

enable --now वह हिस्सा है जिसे लोग छोड़ देते हैं। enable के बिना, अगले रीबूट के बाद सर्वर गायब हो जाता है। यदि आप सर्विस के आसपास निर्धारित कार्य चाहते हैं, जैसे कि नए रिलीज के लिए रात में जांच करना, तो a systemd service plus timer इसके लिए सही मैकेनिज्म है।

OOM होने से पहले निर्णय लें कि क्या करना है

Memory के उपयोग के दो भाग होते हैं और एक सीमा के तहत वे अलग-अलग व्यवहार करते हैं। Model file डिफ़ॉल्ट रूप से memory-mapped होती है, इसलिए इसके pages file-backed होते हैं: kernel इन्हें हटा सकता है और disk से दोबारा पढ़ सकता है। KV cache, जो कि हर सक्रिय conversation के लिए सर्वर द्वारा रखा गया per-token state है, anonymous memory है। इसे हटाया नहीं जा सकता, इसलिए इसी कारण से process को kill किया जाता है।

यही कारण है कि unit में दी गई दो सीमाएं अलग-अलग काम करती हैं। MemoryHigh=3G एक soft limit है: इससे ऊपर जाने पर kernel cgroup पर reclaim pressure डालता है, जिससे mapped model pages को हटा दिया जाता है और अगले token पर उन्हें disk से वापस पढ़ा जाता है। Service काम करती रहती है लेकिन धीमी हो जाती है। MemoryMax=3500M एक hard limit है: इससे ऊपर जाने पर process को kill कर दिया जाता है और journal में यह स्पष्ट रूप से दिखाई देता है।

llama-server.service: A process of this unit has been killed by the OOM killer.

--ctx-size को स्वयं सेट करें। डिफ़ॉल्ट मान 0 है, जिसका अर्थ है वह context जिसके साथ model को train किया गया था, और एक आधुनिक long-context model startup पर ही बहुत बड़ा KV cache allocate कर लेता है। इसके बाद service एक भी request serve करने से पहले ही बंद हो जाती है। --parallel इसी लागत को गुणा करता है, क्योंकि प्रत्येक slot अपना conversation state रखता है, इसलिए इसे 1 पर ही रहने दें जब तक कि आपको concurrency की आवश्यकता न हो।

Restart=on-failure के साथ एक killed service वापस आ जाती है। यदि यह हर start पर kill हो जाती है, तो systemd प्रयास करना छोड़ देता है और systemctl status पर start request repeated too quickly प्रिंट होता है। यह सही व्यवहार है: एक restart loop जो हर पांच सेकंड में 12 GB की file को दोबारा पढ़ता है, वह outage से भी बदतर है। सीमा या context size को ठीक करें, फिर sudo systemctl reset-failed llama-server के साथ state को clear करें।

Request चलने के दौरान systemctl show llama-server -p MemoryCurrent के साथ वास्तविक संख्या पर नज़र रखें। systemd के साथ process memory और CPU को सीमित करना इन directives को अधिक विस्तार से कवर करता है।

इस workload के लिए swap का उपयोग न करें। Swapped-out model हर token को random-offset disk reads में बदल देता है। Model file को memory map करने से कम नुकसान के साथ वही प्रभाव प्राप्त होता है, क्योंकि kernel अपनी ज़रूरत के pages को सीधे file से पढ़ लेता है।

जहाँ Ollama एक बेहतर विकल्प है

यह एक महत्वपूर्ण निर्णय बिंदु है। llama-server को तब चुनें जब आप एक ऐसी प्रक्रिया चाहते हैं जिसमें आपके द्वारा सेट किए गए flags, एक निश्चित build और आपकी चुनी हुई file हो, जहाँ कुछ भी अपने आप न बदले क्योंकि कोई अन्य प्रक्रिया नहीं चल रही है।

Ollama को तब चुनें जब आप model management चाहते हैं: नाम से models को pull करना, डिस्क पर कई models रखना, idle model को unload करना और rebuild करने के बजाय एक ही command से upgrade करना। यह वह वास्तविक कार्य है जिसे अन्यथा आपको स्वयं script करना पड़ता। VPS पर Ollama चलाना इसी कार्य का दूसरा पहलू है जहाँ प्राथमिकताएँ अलग हैं। दोनों ही OpenAI-compatible API प्रदान करते हैं, इसलिए client code किसी भी दिशा में बदलाव के बाद काम करता रहता है।

Pinned build को अपग्रेड करना

bNNNNN को उस टैग से बदलें जिस पर आप जा रहे हैं।

cd llama.cpp
git fetch --tags
git checkout bNNNNN
cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build build --config Release -t llama-server -j 2
sudo install -m 755 build/bin/llama-server /usr/local/bin/llama-server-bNNNNN
sudo ln -sfn /usr/local/bin/llama-server-bNNNNN /usr/local/bin/llama-server
sudo systemctl restart llama-server

पुरानी binary डिस्क पर ही रहती है, इसलिए rollback करने के लिए केवल ln -sfn को llama-server-b10488 पर वापस ले जाना और एक बार restart करना पर्याप्त है। आगे बढ़ने से पहले release notes पढ़ें। GGUF files versioned होती हैं और पुरानी files load होती रहेंगी, लेकिन flags के नाम बदल दिए जाते हैं: --mlock और --no-mmap को अब --load-mode के पक्ष में deprecated कर दिया गया है, और यदि कोई unit file हटाए गए flag को pass करती है, तो वह start होते समय unrecognised argument संदेश के साथ fail हो जाएगी।

विफलता के प्रकार और वे स्ट्रिंग्स जो आपको दिखाई देंगी

error while loading shared libraries: libllama.so बाइनरी को कहीं और कॉपी करने के बाद। डिफ़ॉल्ट बिल्ड इसके साथ ही shared libraries भी बनाता है। -DBUILD_SHARED_LIBS=OFF के साथ फिर से बिल्ड करें, या पूरे build/bin डायरेक्टरी को कॉपी करें।

Illegal instruction (core dumped) स्टार्टअप पर या पहली रिक्वेस्ट पर। बाइनरी को GGML_NATIVE ऑन करके, उस CPU से अलग CPU के लिए कंपाइल किया गया था जिस पर यह चल रहा है। इस मशीन पर फिर से बिल्ड करें, या -DGGML_NATIVE=OFF के साथ कॉन्फ़िगर करें।

c++: fatal error: Killed signal terminated program cc1plus बिल्ड के दौरान। बहुत अधिक मेमोरी इस्तेमाल करने के कारण कंपाइलर को बंद कर दिया गया। -j को कम करें, या बिल्ड के लिए swap जोड़ें और बाद में उसे हटा दें।

curl: (7) Failed to connect ... Connection refused आपके लैपटॉप से। यह सही है: सर्वर VPS के loopback एड्रेस पर listen कर रहा है। VPS पर ही टेस्ट करें, या ssh -L 8080:127.0.0.1:8080 user@your-vps के साथ टनल खोलें और स्थानीय रूप से http://127.0.0.1:8080 का उपयोग करें।

HTTP 503 और "message":"Loading model" रीस्टार्ट के बाद शुरुआती कुछ सेकंड या मिनटों के लिए। मल्टी-गीगाबाइट फ़ाइल को पढ़ने में समय लगता है, और systemd यूनिट को सक्रिय (active) तब रिपोर्ट करता है जब प्रोसेस शुरू होती है, जबकि मॉडल मेमोरी में आने में काफी समय लेता है।

रिक्वेस्ट हैंग हो जाती हैं और फिर 504 Gateway Time-out रिटर्न करती हैं। मॉडल के पूरा होने से पहले ही प्रॉक्सी ने प्रयास छोड़ दिया। proxy_read_timeout को बढ़ाएं, और proxy_buffering को बंद करें ताकि टोकन उत्पन्न होते ही क्लाइंट तक पहुँच सकें।

यूनिट फ्लैप करती है और फिर start request repeated too quickly के साथ रुक जाती है। हर बार शुरू होने पर कोई चीज़ इसे मार देती है। OOM killer लाइन के लिए journalctl -u llama-server की जाँच करें, फिर --ctx-size को कम करें, --parallel को कम करें, या MemoryMax को बढ़ाएं।

FAQ

क्या मुझे अपने VPS पर llama.cpp का server चलाना चाहिए या Ollama?

जब आप किसी विशिष्ट build को पिन करना चाहते हैं, सटीक flags पास करना चाहते हैं, और एक ही फाइल में एक मॉडल रखना चाहते हैं जिसे कोई और अपडेट न करे, तो llama-server चलाएं। जब आप मॉडल प्रबंधन और एक-कमांड अपग्रेड चाहते हैं, तो Ollama चलाएं, क्योंकि मॉडल को नाम से खींचना, डिस्क पर कई मॉडल रखना और बेकार पड़े मॉडलों को अनलोड करना ऐसा काम है जिसे आपको अन्यथा खुद स्क्रिप्ट करना पड़ेगा। दोनों ही OpenAI-compatible API प्रदान करते हैं, इसलिए यदि आप बाद में स्विच करते हैं तो client code में कोई बदलाव नहीं करना पड़ता।

मुझे llama.cpp के किस version को पिन करना चाहिए?

कोई भी tag जिसे आपने वास्तव में build और test किया है। llama.cpp लगभग हर merge को tag करता है और नाम build numbers होते हैं जैसे कि b10488, जो 18 अगस्त 2026 को सबसे नया था। इसमें कोई अलग stable branch नहीं है, इसलिए "current" दिन में कई बार बदलता है। --branch <tag> के साथ clone करें, binary को उस tag वाले filename के तहत install करें, और उस पर एक symlink पॉइंट करें, ताकि अपग्रेड और रोलबैक प्रत्येक एक कमांड में हो सकें।

llama-server को कितनी RAM की आवश्यकता होती है?

GGUF फाइल के आकार से शुरुआत करें, फिर KV cache जोड़ें, जो --ctx-size और --parallel slots की संख्या के साथ बढ़ता है। प्रकाशित आंकड़े आपके अपने सेटअप को मापने का विकल्प नहीं हैं, क्योंकि कुल RAM मॉडल, quantisation और आपके द्वारा अनुमति दी गई context पर निर्भर करती है। जब request चल रही हो तो systemctl show llama-server -p MemoryCurrent चलाएं और जो संख्या आप देखते हैं उसका उपयोग करें।

/health "Loading model" के साथ 503 क्यों लौटाता है?

process शुरू हो गई है लेकिन मॉडल फाइल अभी तक memory में नहीं है, इसलिए server {"error":{"code":503,"message":"Loading model","type":"unavailable_error"}} का उत्तर देता है। यह हर restart के बाद सामान्य है, और यह उतना ही समय लेता है जितना फाइल को पढ़ने में लगता है। यह समस्या तब बनती है जब कोई client या proxy उस पहले 503 को hard failure मानता है। /health को तब तक poll करें जब तक कि वह {"status": "ok" } न लौटा दे।

क्या मैं llama-server को सीधे इंटरनेट पर expose कर सकता हूँ?

इसे 0.0.0.0 पर bind न करें और port न खोलें। इसमें कोई accounts, कोई rate limiting और ऑडिट करने योग्य कोई request log नहीं है, और एकमात्र built-in check --api-key है, जो एक single string की तुलना करता है। default 127.0.0.1 bind रखें, सामने TLS के साथ nginx लगाएं, और --api-key भी सेट करें, ताकि proxy config में एक गलती मॉडल को सभी के लिए खुला न छोड़ दे।