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

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

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 आप support कर सकते हैं। एक tag चुनें, उसे दर्ज करें, और उसी string का उपयोग अपने clone, अपनी binary के नाम और अपने notes में करें।

प्रत्येक 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 की list देखें, ताकि आपको पता रहे कि files कहाँ save होंगी। ये binaries उस image की C library से linked होती हैं जिसमें उन्हें build किया गया था, इसलिए पुराने distribution पर ये startup के समय एक ऐसी GLIBC_ version की error के साथ fail हो जाती हैं जो installed नहीं है। एक छोटे VPS पर source से build करने में कुछ ही मिनट लगते हैं और इससे इस तरह की पूरी समस्या खत्म हो जाती है, इसलिए नीचे वही तरीका दिया गया है।

Pinned tag से llama-server को build करना

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 clone पर उस विशिष्ट tag को checkout करें। इससे यह सुनिश्चित होता है कि काम करते समय build में कोई बदलाव न आए।

libssl-dev महत्वपूर्ण है क्योंकि LLAMA_OPENSSL विकल्प डिफ़ॉल्ट रूप से चालू रहता है। यही विकल्प बाद में binary को HTTPS के माध्यम से models download करने की अनुमति देता है। headers के बिना configure चरण विफल हो जाता है।

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

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

-j 2 जानबूझकर किया गया है। प्रत्येक parallel compile job अपनी memory का उपयोग करती है, इसलिए छोटे plan पर -j $(nproc) चलाने से c++: fatal error: Killed signal terminated program cc1plus की स्थिति उत्पन्न हो सकती है, जहाँ kernel का out-of-memory killer compiler को रोक देता है। job की संख्या कम करें या build के लिए swap जोड़ें।

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

इसे ऐसे नाम से install करें जिसमें tag का उल्लेख हो।

./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 build number और commit को print करता है। इसे आपके द्वारा checkout किए गए tag से मेल खाना चाहिए। यदि ऐसा नहीं है, तो आपने कुछ और build किया है। filename में number रखने और उस पर symlink point करने का अर्थ है कि upgrade केवल एक ln -sfn और एक restart की प्रक्रिया है, और rollback भी पुराने number के साथ वही command है।

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 में चली जाती है जिसने कमांड रन की है, जो उस सर्विस के लिए गलत स्थान है जिसकी होम डायरेक्टरी को आप अनरीडेबल बनाने वाले हैं। इसके बाद 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 का है, जो कई एंट्री-लेवल प्लान्स पर डिस्क में फिट नहीं होता है, और उसके बाद भी इसे मेमोरी में लोड करना पड़ता है। यदि आप किसी विशिष्ट फैमिली पर विचार कर रहे हैं, तो GLM के लिए समान साइज़िंग अभ्यास दिखाता है कि कैसे मुख्य मॉडल जल्दी ही VPS की कीमत से बाहर हो जाता है जबकि एक छोटा मॉडल फिट हो जाता है।

प्रत्येक डाउनलोड से पहले 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 हमेशा इसे भेजते हैं। इस सर्वर में एक ही model लोड है, इसलिए इस value का उपयोग किसी चीज़ को चुनने के लिए नहीं किया जाता है।

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

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

कोई भी OpenAI SDK तब काम करता है जब आप base URL को http://127.0.0.1:8080/v1 पर सेट करते हैं और एक non-empty API key स्ट्रिंग पास करते हैं। जब तक आप स्वयं --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

/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, जो कि प्रत्येक active 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 से भी बदतर है। Limit या 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 को disk पर रखना, idle model को unload करना और rebuild करने के बजाय एक ही command से upgrade करना। यह वह वास्तविक कार्य है जिसे अन्यथा आपको खुद script करना पड़ता। VPS पर Ollama चलाना इसी कार्य का दूसरा पहलू है जहाँ प्राथमिकताएं अलग हैं। दोनों ही OpenAI-compatible API प्रदान करते हैं, इसलिए client code किसी भी दिशा में स्विच करने पर काम करता रहता है।

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

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

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 के लूपबैक एड्रेस पर लिसन (listen) करता है। VPS पर ही टेस्ट करें, या ssh -L 8080:127.0.0.1:8080 user@your-vps के साथ टनल खोलें और स्थानीय रूप से http://127.0.0.1:8080 का उपयोग करें।

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

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

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

FAQ

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

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

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

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

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

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

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

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

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

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