VPS पर LLM होस्ट करें।
कोई GPU नहीं। कोई API key नहीं। कोई prompt कभी बिल्डिंग से बाहर नहीं जाता।

इस section का ईमानदार version किसी उत्साही version से कहीं ज़्यादा काम का है, क्योंकि किसी self-hosted मॉडल को छोड़ देने का सबसे तेज़ तरीक़ा उसे उसी एक काम पर लगाना है जिसमें वह सबसे कमज़ोर है, और फिर यह मान लेना कि पूरा idea ही बेवक़ूफ़ी था।

आराम से फ़िट होता है। कोई भी ऐसा काम जिसमें output छोटा हो और value prose में नहीं बल्कि judgement में हो। किसी message को मुट्ठी-भर buckets में से एक में classify करना। यह तय करना कि कोई support ticket urgent है या नहीं। किसी invoice से पाँच fields को JSON के रूप में निकालना। किसी thread को तीन वाक्यों में summarise करना। किसी document को tag करना। किसी product description को rewrite करना। किसी छोटी string का अनुवाद करना। यह पता लगाना कि दो records एक ही व्यक्ति के बारे में हैं या नहीं। किसी paragraph के कहीं और जाने से पहले उसमें से नाम redact करना। इनमें से हर एक काम एक लंबा input खाता है और एक छोटा output देता है, और यही वह असंतुलन है जिसे एक CPU अच्छे से संभालता है।

फ़िट होता है, पर धैर्य के साथ। ऐसा काम जिस पर कोई इंसान इंतज़ार नहीं कर रहा। रात भर चलने वाले batches, queue workers, दिन भर के documents पर एक रात वाला pass, एक scheduled report। अगर जवाब पर कुछ भी नहीं रुका है, तो जो token rate किसी chat window में असहनीय होगी वह बिलकुल भी मायने नहीं रखती — रात के तीन बजे छह मिनट चलने वाला काम बस एक ऐसा काम है जो चल गया।

फ़िट नहीं होता। एक ऐसा interactive assistant जिसे लोग सचमुच पसंद करके इस्तेमाल करें: इन rates पर cursor रेंगता है और experience बिना assistant से भी बुरा हो जाता है। Long-form generation — मुझे दो हज़ार शब्द लिख दो — जहाँ पूरा output ही धीमा हिस्सा है। Coding agents जो किसी बड़े repository पर iterate करते हैं, जहाँ context और quality bar दोनों एक छोटे मॉडल की क्षमता से ज़्यादा हैं। कोई भी चीज़ जिसे एक लाख-टोकन context चाहिए, जहाँ अकेला cache ही machine से बड़ा हो जाता है। और image या video मॉडल, जो पूरी तरह एक अलग discipline हैं और जिन्हें सचमुच GPU चाहिए।

अगर आपका workload उस आख़िरी group में आता है, तो समझदारी भरा जवाब बड़ा CPU box ख़रीदना नहीं है — यह एक hybrid है। ज़्यादातर calls के लिए एक local मॉडल रखें और जिन थोड़े-से को frontier reasoning चाहिए उन्हें किसी hosted API पर भेजें, जो ठीक वही shape है जो AI एजेंट को 24/7 चलाने की गाइड runtime वाले हिस्से के लिए बताती है। उस गाइड ने जानबूझकर मॉडल को ही scope से बाहर रखा था। यह गाइड वही बाक़ी आधा हिस्सा है।

पहले machine को सख़्त करें — सिर्फ़ key वाला SSH, एक ऐसा firewall जो वही चीज़ जाने दे जो आपने माँगी हो, unattended security upgrades। पहले घंटे की checklist में क़रीब एक घंटा लगता है, और यह वह box है जो जल्द ही आपके पूछे हर सवाल को संभालेगा।

फिर runner install करें। Ollama दरअसल llama.cpp ही है जिसके चारों ओर एक model registry, एक REST API और एक systemd unit लिपटी हुई है, और एक-लाइन का installer तीनों को सेट कर देता है:

apt update && apt install -y curl
curl -fsSL https://ollama.com/install.sh | sh

systemctl status ollama --no-pager
ss -ltnp | grep 11434
# → 127.0.0.1:11434 — loopback only. Leave it that way.

वह आख़िरी लाइन ऐसी है जिसे दो बार पढ़ना चाहिए। out of the box यह service loopback interface पर सुनती है, जो बिलकुल सही है, और अगले दस मिनट में होने वाली सबसे आम ग़लती OLLAMA_HOST को 0.0.0.0 पर set कर देना है, क्योंकि किसी दूसरी machine से यह पहुँच में नहीं आ रहा था। चरण 04 यही बताता है कि इस तक सही तरीक़े से कैसे पहुँचा जाए; इसका कोई भी version ऐसा नहीं है जहाँ port 11434 सीधे internet के सामने हो।

दो settings ऐसी हैं जिन्हें बाद में खोजने के बजाय अभी जगह पर लगा देना बेहतर है। मॉडल default रूप से /usr/share/ollama के नीचे store होते हैं और वे बड़े होते हैं, इसलिए इसे वहाँ point करें जहाँ आपके पास जगह हो। और default आख़िरी request के बाद पाँच मिनट तक मॉडल को RAM में resident रखता है, जो उस box पर काफ़ी उदार है जो और भी काम कर रहा है:

systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/var/lib/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

systemctl daemon-reload && systemctl restart ollama

Parallel requests और एक साथ कई loaded मॉडल दोनों ही memory का इस्तेमाल गुणा कर देते हैं, और ठीक एक मॉडल के हिसाब से sized machine पर दूसरी copy के लिए एक भी अतिरिक्त gigabyte नहीं बचता। queue को serialise करना इस hardware की कोई सीमा नहीं है; यही वह अकेला configuration है जो गिरता नहीं।

गाइड का यह हिस्सा किसी बुरी चीज़ को होने से रोकता है, इसलिए इसे बिना लाग-लपेट के कहा जा रहा है: Ollama के API में कोई password नहीं, कोई टोकन नहीं, कोई user मॉडल नहीं और कोई permission system नहीं है। जो कुछ भी port 11434 पर TCP connection खोल सकता है वह आपके CPU पर text generate कर सकता है, आपके pull किए मॉडलों की गिनती कर सकता है, नए pull कर सकता है और जिन्हें आप इस्तेमाल करते हैं उन्हें मिटा सकता है। यहाँ चालू करने के लिए कोई setting नहीं है, क्योंकि चालू करने के लिए कोई mechanism ही नहीं है।

Port 11434 लगातार scan होता है, एक साफ़ वजह से: एक खुला model runner किसी और का free compute है। इसका लक्षण कोई alert नहीं होता। यह एक ऐसी machine होती है जो दो हफ़्ते तक धीमी महसूस होती है और एक bandwidth graph जो आपके किए किसी भी काम से मेल नहीं खाता। service को loopback पर ही रखें, और उसके आगे कुछ ऐसा लगाएँ जो पूछे कि call कौन कर रहा है।

अगर इस machine के बाहर किसी को भी मॉडल की ज़रूरत नहीं, तो यहीं रुक जाएँ — आपका काम पहले ही पूरा हो चुका है। Loopback के साथ एक firewall ही पूरा जवाब है, और उसी VPS पर चल रहा कोई एजेंट, कोई automation stack या कोई web app आगे बताई किसी भी चीज़ के बिना 127.0.0.1 पर मॉडल तक पहुँच जाता है। आगे तभी बढ़ें जब किसी दूसरी machine पर मौजूद किसी चीज़ को इसे call करना हो।

proxy, और टोकन। एक लंबा random टोकन generate करें, एक A record को box पर point करें, और certificate व दरवाज़ा दोनों Caddy को संभालने दें:

openssl rand -hex 32      # → the bearer token, store it in a password manager
apt install -y caddy

/etc/caddy/Caddyfile

llm.example.com {
    @unauthorised not header Authorization "Bearer PASTE_THE_HEX_TOKEN_HERE"
    respond @unauthorised "unauthorised" 401

    reverse_proxy 127.0.0.1:11434 {
        # Generation is slow by nature — do not let the proxy give up first.
        transport http {
            read_timeout 10m
        }
    }
}

systemctl reload caddy
ufw allow 80,443/tcp
ufw status                # 11434 must appear nowhere

basic authentication के बजाय bearer टोकन चुनने में एक छोटी-सी elegance है। Ollama एक OpenAI-compatible API देता है, हर OpenAI client अपनी key को ठीक उसी header के रूप में भेजता है, तो जो टोकन आपने अभी generate किया वही वह API key बन जाता है जिसे आपके applications पहले से carry करना जानते हैं। किसी custom header की ज़रूरत नहीं, और access को rotate करना बस Caddyfile की एक लाइन और caller पर एक environment variable भर है।

किसी ऐसी machine से verify करें जो server न हो। पहली call को मना कर देना चाहिए और दूसरी को जवाब देना चाहिए:

curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
# → 401

curl -s https://llm.example.com/api/tags -H "Authorization: Bearer THE_TOKEN" | jq '.models[].name'
# → the list of models you pulled

अगर मॉडल को आपकी बजाय एजेंटों द्वारा call किया जाना है, तो exposure वाला सवाल remote MCP server होस्ट करने की गाइड में ज़्यादा पूरी तरह से समझाया गया है — TLS, टोकन और कहाँ से क्या reachable होना चाहिए, इसी तर्क को उस service पर लागू करते हुए जो टोकन नहीं बल्कि tools देती है।

context को cap करें। context की लंबाई ही memory के इस्तेमाल का मुख्य dial है, और default एक छोटे box को जितनी ज़रूरत है उससे ज़्यादा उदार है। इसे globally उतना ही set करें जितना आपके सबसे लंबे वास्तविक prompt को असल में चाहिए — ज़्यादातर classification और extraction का काम चार हज़ार टोकन के अंदर आराम से हो जाता है — और उस दुर्लभ call पर per request इसे बढ़ा लें जिसे ज़्यादा चाहिए:

Environment="OLLAMA_CONTEXT_LENGTH=4096"

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "…a long document…",
  "options": { "num_ctx": 16384 },
  "stream": false
}'

तय करें कि मॉडल कितनी देर memory में रहेगा। resident मॉडल को call करना तुरंत होता है और यह कई gigabyte को बंधक बना लेता है। किसी ऐसी machine पर जो सिर्फ़ inference के लिए है, इसे हमेशा loaded रखें; किसी shared machine पर, कुछ समय बाद इसे गिर जाने दें। यह value per request भी तय होती है, तो एक nightly batch अपने run के लिए मॉडल को pin कर सकता है और अंत में release कर सकता है:

OLLAMA_KEEP_ALIVE=-1     # resident until the service restarts
OLLAMA_KEEP_ALIVE=30m    # a sensible default on a shared box
OLLAMA_KEEP_ALIVE=0      # unload immediately after each request

ollama ps                # what is resident right now, and how much it holds

queue को serialise करें। एक ही मॉडल पर दो concurrent requests दोगुनी रफ़्तार से नहीं चलतीं; वे एक ही saturated memory path के लिए होड़ करती हैं और हर एक धीमी हो जाती है, और अगर Ollama उन्हें serve करने के लिए दूसरी copy load करने का फ़ैसला करे तो box का RAM ख़त्म हो जाता है। इस तरह के hardware पर एक बार में एक request, आगे एक queue के साथ, ही सबसे तेज़ भी है और अकेला safe configuration भी — यही वजह है कि OLLAMA_NUM_PARALLEL और OLLAMA_MAX_LOADED_MODELS को चरण 02 में ही एक पर pin कर दिया गया था।

disk पर नज़र रखें। चार मॉडलों को compare करने पर चार मॉडल पीछे रह जाते हैं, और पाँच-पाँच gigabyte के हिसाब से एक disk चुपचाप भरती जाती है जबकि कोई शिकायत नहीं करता। cleanup को comparison का ही हिस्सा बनाएँ, बाद के किसी काम की तरह नहीं:

ollama list
du -sh /var/lib/ollama/models
ollama rm mistral:7b qwen2.5:14b

आख़िर में, उसी चीज़ का backup लें जो reproducible नहीं है। मॉडल weights reproducible हैं — एक pull उन्हें वापस ला देता है। जो चीज़ किसी repository के लायक़ है वह है configuration, Caddyfile, टोकन, वे prompt जिन्हें आपने तीन हफ़्तों में refine किया, और अगर आपने एक बनाया है तो आपके retrieval के पीछे का vector index। encrypted backups गाइड इसकी mechanics बताता है; इस box के लिए include list छोटी है और लिख रखने लायक़ है।

लोग मॉडल की privacy के बारे में ऐसे सोचते हैं जैसे risk output में हो। ऐसा नहीं है। output तो सामान्य text है; हज़ार और लोगों को भी कुछ मिलता-जुलता ही मिला होगा। जो चीज़ असल में सब कुछ खोल देती है वह है input — और एक साल के inputs किसी संस्था की एक हैरान करने वाली मुकम्मल तस्वीर बन जाते हैं।

सोचिए कि एक request log में असल में क्या होता है। वह contract जो आपने summarise कराने के लिए paste किया था। वह customer email जिसे classify करने को कहा, जिसमें customer भी मौजूद है। medical letter, salary का आँकड़ा, वह resignation जो आप draft कर रहे थे, किसी ऐसे repository का code जो public नहीं है। फिर उसके आसपास का metadata: कौन-से सवाल, किस क्रम में, किस समय, किस address से, कितने महीनों में। कोई भी दस्तावेज़ पर यह लिखकर sign नहीं करता कि “यह हमारी strategy है” — लेकिन सवालों का क्रम ही वह दस्तावेज़ है, जो आपके द्वारा, एक बार में एक call, ईमानदारी से बनाया गया है।

पहली परत — endpoint क्या रखता है। गंभीर providers गंभीर policies छापते हैं, और अच्छे providers सचमुच business API traffic पर train नहीं करते। पर यह retain न करने जैसा वादा नहीं है। Requests आमतौर पर abuse monitoring के लिए कुछ समय तक store होती हैं, तय शर्तों के तहत staff तक पहुँच में रहती हैं, और legal process के तहत produce की जा सकती हैं — यही एक बड़े platform को चलाने का सही तरीक़ा है, और यही उस text के लिए बिलकुल ग़लत जगह है जिसे आप किसी अजनबी को email नहीं करेंगे। आपकी अपनी machine पर चलने वाले मॉडल के पास ऐसा कोई log नहीं होता, जब तक आप ख़ुद एक न बनाएँ।

दूसरी परत — वह पहचान जिससे log जुड़ा होता है। सिर्फ़ retention exposure का आधा हिस्सा है। दूसरा आधा वह key है जिससे यह जुड़ता है: एक account, एक company का नाम, एक billing address, एक card। यही जोड़ है जो “किसी ने competitor ख़रीदने के बारे में पूछा” को बदलकर “उस मंगलवार को इस company ने पूछा” बना देता है। equation से मॉडल हटाने से retention हट जाता है; machine से पहचान हटाने से वह जोड़ हट जाता है। बिना email address या identity document के, किसी Nordic jurisdiction में खोला गया, Monero में settle किया गया एक VPS, उसी क़दम का दूसरा आधा हिस्सा है।

तीसरी परत — वे logs जो आप ख़ुद लिखते हैं। Self-hosting risk को मिटाता नहीं, बस उसकी जगह बदल देता है, और यह साफ़-साफ़ देखने लायक़ है कि वह कहाँ जाकर टिकता है। आपका application शायद अपने ही prompts log करता होगा। आपका reverse proxy हर request line log करता है। दो महीने पहले किसी debugging session ने journal में verbose output छोड़ दिया था। मॉडल ख़ुद calls के बीच कुछ नहीं रखता, लेकिन उसके आसपास की मशीनरी सब कुछ रख सकती है — इसलिए जान-बूझकर तय करें कि क्या लिखा जाए, उस पर retention set करें, और उस log को उसी standard पर रखें जिसे आप किसी और से मानने को तैयार नहीं थे।

इनमें से कुछ भी एक local मॉडल को अपने-आप privacy की गारंटी नहीं बनाता। यह इसे बस वह एक architecture बनाता है जहाँ गारंटी देना आपके हाथ में है: text उसी hardware पर रहता है जो आपने rent किया, उसी jurisdiction के तहत जो आपने चुना, उसी टोकन के पीछे जो आपने ख़ुद जारी किया, और यह किसी और के आगे जवाबदेह नहीं है।