Raspberry Pi AI स्वार्म को आर्थिक रूप से एयर-गैप करना

मैंने अपने तीन Raspberry Pi 5 (16GB + M.2 256GB) नोड में से एक को अलग किया ताकि वह मास्टर कंट्रोल प्रोग्राम (MCP) द्वारा संचालित, आर्थिक रूप से एयर-गैप्ड AI ऑर्केस्ट्रेटर की तरह काम करे। लक्ष्य एक सक्षम, बहुउद्देशीय AI सहायक सिस्टम बनाना था जिसे मैं रोज़ इस्तेमाल कर सकूँ, और लगातार स्टेट-मेंटेनेंस के कारण मेरे “Pro” टियर का API बिल पूरी तरह भाप बनकर न उड़ जाए।

इस सिस्टम के वर्कर संकीर्ण, एक-उद्देश्य वाले डेमन नहीं हैं। वे पूरी तरह कार्यशील निजी सहायक हैं जो सक्रिय रूप से सिस्टम पर नज़र रखते हैं, स्वायत्त बैकग्राउंड टास्क चलाते हैं, निजी उत्पादकता टूल से जुड़ते हैं और Telegram के ज़रिए सवालों के जवाब देते हैं। फिर भी इन सक्षम सहायकों को चलाने के लिए एक सुरक्षा-कवच चाहिए। हल एक आक्रामक रूटिंग रणनीति थी: माहौल की निगरानी के लिए एक केंद्रीय MCP का इस्तेमाल, जबकि असली सहायक खाता-स्तर की सख़्त ख़र्च-सीमा वाले एग्रीगेटर के ज़रिए डॉकराइज़्ड बैकग्राउंड प्रोसेस के रूप में चलते हैं। Pi अब कोई सामान्य-उद्देश्य वाली होम लैब नहीं रहा: उसे समर्पित, नेटवर्क से जुड़ा OpenClaw शेल बनाने के लिए बाक़ी हर कंटेनर हटा दिया गया।

आर्किटेक्चर

सिस्टम स्प्लिट-ब्रेन, स्तरीय आर्किटेक्चर पर चलता है। जड़ में MCP बैठा है। किसी एक महँगे मॉडल को हार्डकोड करने के बजाय MCP एक manifest.ai स्किल को बिल्ट-इन राउटर की तरह इस्तेमाल करता है। यह प्रशासनिक काम की जटिलता को गतिशील रूप से परखता है और तय करता है कि कौन-सा Gemini मॉडल बुलाना है, बुनियादी दक्षता के लिए Gemini के नेटिव ऑटो मोड को डिफ़ॉल्ट रखते हुए।

उसके नीचे, एक समर्पित Docker ब्रिज नेटवर्क (claw_net) पर पूरी तरह अलग-थलग, दो काम-विशेष वर्कर बैठे हैं। भारी काम प्रीपेड OpenRouter कनेक्शन के ज़रिए वर्कर करते हैं। MCP उनके लॉग पर नज़र रखता है, विफल होने पर उनके कॉन्फ़िगरेशन दोबारा लिखता है और उनके कंटेनर रीस्टार्ट करता है।

निर्माण

इस बदलाव के लिए Pi 5 को साफ़ करना पड़ा ताकि पोर्ट के टकराव और CPU का ओवरहेड ख़त्म हो। हार्डवेयर अब सिर्फ़ और सिर्फ़ OpenClaw होस्ट है।

पहले मुझे एक साफ़ स्लेट चाहिए थी। मैंने मौजूदा इन्फ़्रास्ट्रक्चर की पूरी सफ़ाई की ताकि कोई भूतिया कंटेनर मेमोरी न चबाए या मेरी रूटिंग परतों से न टकराए। फिर मैंने अलग-थलग नेटवर्क (claw_net) बनाया। वर्कर को Telegram API और OpenRouter के लिए बाहर जाने वाला इंटरनेट चाहिए, लेकिन उन्हें उनके अपने ब्रिज नेटवर्क पर अलग रखने से पक्का होता है कि उन तक कोई इनबाउंड पहुँच नहीं है और वे एक-दूसरे का ट्रैफ़िक नहीं देख सकते।

# Purge all non-essential containers and images
docker stop $(docker ps -aq)
docker rm $(docker ps -aq)
docker system prune -a --volumes -f

# Create the dedicated network for the swarm
docker network create --driver bridge claw_net

मैंने पदानुक्रम को दर्शाने के लिए /opt/openclaw में फ़ाइल सिस्टम को नए सिरे से व्यवस्थित किया, जिससे MCP को वर्कर की कॉन्फ़िगरेशन फ़ाइलों पर पूरी दृश्यता मिल गई।

mkdir -p /opt/openclaw/{mcp,workers/worker-01,workers/worker-02}

इसके बाद मैंने अलग-थलग वर्कर कॉन्फ़िगर किए। मैंने उनका ऑथेंटिकेशन OpenRouter तक सीमित किया और खाता-स्तर पर ही हर महीने की कठोर ख़र्च-सीमा लगा दी। इससे बैकएंड पर लागत का बेक़ाबू बढ़ना रुकता है: अगर कोई लूप चल पड़े, तो अधिकतम नुक़सान साफ़ तौर पर सीमित है, जो मुझे 500 डॉलर के अचानक मासिक बिल से बचाता है। व्यवहार में, इन पूरी तरह सक्षम, रोज़ इस्तेमाल होने वाले AI सहायकों को चलाने में मेरा यथार्थवादी ख़र्च हर महीने 8 से 15 डॉलर के बीच आता है। मनमानी क्षमता-सीमाएँ थोपने के बजाय मैंने उनके maxOutputTokens और maxHistoryTurns को सोचे-समझे प्रदर्शन-कैलिब्रेशन पैरामीटर के रूप में ट्यून किया। ये मान हर वर्कर की भूमिका की प्रकृति से मेल खाते हैं, यानी तेज़ जवाबों बनाम जटिल क्रियाओं के लिए कॉन्टेक्स्ट विंडो का अनुकूलन, ताकि वे गणना का ओवरहेड बर्बाद किए बिना पूरी तरह कार्यशील रहें।

# Configure Worker 01
cd /opt/openclaw/workers/worker-01
openclaw onboard --auth-choice apiKey --token-provider openrouter --token "$OPENROUTER_API_KEY" --non-interactive
openclaw config set agents.defaults.model.primary "openrouter/deepseek/deepseek-chat"
openclaw config set agents.defaults.maxOutputTokens 250
openclaw config set agents.defaults.maxHistoryTurns 5

# Configure Worker 02
cd /opt/openclaw/workers/worker-02
openclaw onboard --auth-choice apiKey --token-provider openrouter --token "$OPENROUTER_API_KEY" --non-interactive
openclaw config set agents.defaults.model.primary "openrouter/deepseek/deepseek-chat"
openclaw config set agents.defaults.maxOutputTokens 600
openclaw config set agents.defaults.maxHistoryTurns 8

मैंने वर्कर को अलग-थलग नेटवर्क से जोड़कर लॉन्च किया। उनकी अपनी कॉन्फ़िगरेशन डायरेक्टरी सीधे कंटेनर में माउंट करने से MCP बाद में दख़ल दे सकता है, Docker सॉकेट से वे कॉन्फ़िग पढ़ सकता है, और अगर कोई वर्कर बिगड़ने लगे तो उन्हें गतिशील रूप से दोबारा लिख सकता है।

docker run -d --name worker-01 \
  --network claw_net \
  -v /opt/openclaw/workers/worker-01:/app/config \
  openclaw/core:latest

docker run -d --name worker-02 \
  --network claw_net \
  -v /opt/openclaw/workers/worker-02:/app/config \
  openclaw/core:latest

आख़िर में, मास्टर कंट्रोल प्रोग्राम। MCP को Google AI क्रेडेंशियल चाहिए, लेकिन टोकन की बेवजह खपत रोकने के लिए मैंने manifest.ai रूटिंग स्किल लागू की। मैंने Docker सॉकेट और रूट /opt/openclaw/workers डायरेक्टरी उसके कंटेनर में माउंट कर दी ताकि वह सब-प्रोसेस की निगरानी नेटिव तरीक़े से कर सके। MCP अकेला कंटेनर है जिसके पास राज्य की चाबियाँ हैं।

cd /opt/openclaw/mcp
openclaw onboard --auth-choice oauth --token-provider google --non-interactive

# Inject the manifest.ai router skill and set dynamic defaults
openclaw skill add manifest.ai/router
openclaw config set agents.defaults.model.primary "google/gemini-auto"
openclaw config set routing.strategy "manifest-dynamic"

docker run -d --name mcp \
  --network claw_net \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /opt/openclaw/workers:/supervised_workers \
  -v /opt/openclaw/mcp:/app/config \
  openclaw/core:latest

समझौते

किसी LLM-संचालित कंटेनर में /var/run/docker.sock माउंट करना प्रोडक्शन माहौल में विनाशकारी सुरक्षा जोखिम है। अगर MCP पर प्रॉम्प्ट इंजेक्शन हमला हो जाए, तो Pi के Docker डेमन पर उसका रूट-स्तर का नियंत्रण है। मैंने यह जोखिम इसलिए स्वीकार किया क्योंकि Pi 5 भौतिक रूप से अलग-थलग है और सिर्फ़ इसी प्रयोग को समर्पित है, लेकिन यह एंटरप्राइज़ तैनाती का पैटर्न नहीं है।

इसके अलावा, manifest.ai राउटर समझदार है, पर अचूक नहीं। जब Worker 02 ने ग़लत बने API पेलोड के कारण विशाल स्टैक ट्रेस फेंका, तो राउटर ने उसे सही ढंग से “जटिल डिबगिंग टास्क” पहचाना और हल्के Flash वेरिएंट के बजाय निष्पादन को भारी रीज़निंग मॉडल तक चढ़ा दिया। सुधार सुझाने से पहले MCP ने एरर लॉग पढ़ने में 40,000 टोकन निगल लिए। उसने Worker 02 का आउटपुट स्कीमा सफलतापूर्वक दोबारा लिखा और कंटेनर रीस्टार्ट किया, लेकिन डिबगिंग की उस अकेली कार्रवाई ने ऑटो मोड की बचत को बेअसर कर दिया और DeepSeek पर Worker 02 के पूरे परिचालन सप्ताह से ज़्यादा ख़र्च कराया।

मैंने क्या सीखा

रूटिंग लॉजिक लागू करने से पहले, Worker 01 वास्तव में चुपचाप फ़ेल हो गया था। वह Telegram से आए बिगड़े JSON पेलोड को पार्स नहीं कर पाया और बस वहीं अटका रहा, API बार-बार टाइमआउट होती रही और वह Pi के मेमोरी संसाधन चुपचाप चबाता रहा। मुझे दो दिन तक पता नहीं चला। वह ख़ामोशी, और उससे जो सिलसिलेवार विफलता का ख़तरा था, वही मुझे पहली जगह MCP बनाने की ओर ले गई।

सिस्टम फ़िलहाल इस पर निर्भर है कि मैं ख़ुद MCP से वर्कर की जाँच करने को कहूँ, जो आधा-अधूरा उपाय है। आर्किटेक्चर का तार्किक निष्कर्ष, और लैब में मेरा अगला प्रोजेक्ट, एक सतत हार्टबीट मॉनिटर बनाना है। वर्कर की हेल्थ चेक को Pi पर एक हल्के लोकल वेक्टर स्टोर में पाइप करके MCP पुराने क्रैश डेटा को अपने आप खँगाल सकेगा और विफलता के सिलसिलेवार फैलने से पहले ही वर्कर के DeepSeek तापमान या टोकन सीमा को सक्रिय रूप से समायोजित कर सकेगा।

इस प्रयोग ने साबित किया कि जटिल AI सिस्टम चलाने के लिए विशाल, मोनोलिथिक क्लाउड इन्फ़्रास्ट्रक्चर की ज़रूरत नहीं है। आर्किटेक्चर को एक अकेले Raspberry Pi 5 की भौतिक सीमाओं और 8–15 डॉलर के मासिक ख़र्च की आर्थिक सीमा में कसने पर नतीजा कोई समझौता किया हुआ या बाँधा हुआ सैंडबॉक्स नहीं निकला। उन बंदिशों ने असल में एक अधिक अनुशासित, बेहद सक्षम ऑर्केस्ट्रेशन सिस्टम गढ़ा। आज ये सिर्फ़ संकीर्ण स्क्रिप्ट नहीं हैं; ये सचमुच कारगर, रोज़ इस्तेमाल होने वाले AI निजी सहायक हैं जो मेरे वर्कफ़्लो को सक्रिय रूप से सँभालते हैं। लैब आख़िरकार समझदारी से चल रही है, सहायक पूरी तरह खुले छोड़ दिए गए हैं, और मेरा बिलिंग पेज आख़िरकार उबाऊ है।