Linux की बढ़त: AI कर्नेल में बेहतर साँस क्यों लेता है

Windows इंसानों के लिए बढ़िया OS है, लेकिन एजेंटों के लिए घुटन भरा माहौल। मैंने Gekro को WSL2/Ubuntu कोर पर ले जाया क्योंकि AI लाइब्रेरी POSIX-संगत दिल की उम्मीद करती हैं। यह लेख CUDA-पासथ्रू सेटअप को खोलकर समझाता है और बताता है कि स्वायत्त सर्विसों के बढ़ते बेड़े को सँभालने का इकलौता तरीक़ा Linux पर Docker क्यों है।

अगर आप किसी कंज़्यूमर ऑपरेटिंग सिस्टम पर AI लैब बना रहे हैं, तो आप दो मोर्चों पर जंग लड़ रहे हैं: आपका कोड और आपका OS। AI के दौर में Linux बुद्धिमत्ता की मातृभाषा है। मैंने छह महीने जटिल Python डिपेंडेंसी को Windows के पाथ और DLL के साथ निभाने की कोशिश में लगाए, फिर आख़िर सच मान लिया: अगर मॉडल के वेट Linux क्लस्टर पर ट्रेन हुए हैं, तो इन्फ़रेंस भी Linux कर्नेल पर होना चाहिए। DFW में जिस पल मैंने हेडलेस Ubuntu वर्कफ़्लो अपनाया, वह डिबगिंग लगभग पूरी तरह रुक गई जो मेरे कोड के बजाय मेरे ऑपरेटिंग सिस्टम को लेकर थी।

जिस चीज़ ने फ़ैसला पक्का किया, वह थी AI से बनाए गए PowerShell को फ़ेल होते, दोबारा कोशिश करते, फिर फ़ेल होते और इसमें टोकन फूँकते देखना। एक बार नहीं, एक पैटर्न की तरह। यह आज भी होता है, और इसी वजह से मैंने एजेंट के काम के लिए PowerShell छोड़ दिया, उसे ठीक करने की कोशिश करने के बजाय।

आर्किटेक्चर

मेरी लैब में “Edge” का मतलब है हार्डवेयर तक सीधी, बिना बिचौलिये की पहुँच। Windows आपके कोड और आपके GPU के बीच “Desktop Window Manager” (DWM) के शोर की एक परत जोड़ देता है। Linux हार्डवेयर पासथ्रू देता है जो बेयर मेटल जैसा लगता है।

विशेषता	Windows (नेटिव)	WSL2 (Ubuntu 22.04+)	Ubuntu Server (बेयर मेटल)
GPU एक्सेस	DirectX / CUDA (भारी)	CUDA पासथ्रू (लगभग नेटिव)	सीधा CUDA (सबसे तेज़)
I/O प्रदर्शन	तेज़ (NTFS)	तेज़ (VHDX के भीतर)	बेहद तेज़ (ext4/zfs)
Docker इंजन	Hyper-V VM (धीमा)	WSL2 बैकएंड (कुशल)	नेटिव Cgroups (तत्काल)
स्थिरता	ऑटोमैटिक अपडेट (जोखिम)	उपयोगकर्ता द्वारा प्रबंधित	99.9% अपटाइम

अपनी लैब में मैं WSL2 को “ऑपरेटर कंसोल” की तरह और अपने Raspberry Pi क्लस्टर पर Ubuntu Server को “प्रोडक्शन Edge” की तरह इस्तेमाल करता हूँ।

निर्माण

उच्च-रफ़्तार AI एनवायरनमेंट बनाने के लिए सिर्फ़ apt install काफ़ी नहीं है। आपको Windows के हार्डवेयर और Linux के लॉजिक के बीच पुल बनाना होगा।

1. WSL2 में CUDA चालू करना

Windows-आधारित लैब की “सीक्रेट सॉस” NVIDIA का WSL ड्राइवर है। यह Linux कर्नेल को आपके PC का GPU “देखने” देता है, पूरी वर्चुअल मशीन के ओवरहेड के बिना।

# Verify GPU visibility inside WSL2
nvidia-smi

# If you see your GPU here, you're ready for local LLMs
# If not, you need to install the 'NVIDIA Game Ready' or 'Studio' driver on the Windows host.

2. Docker-AI स्टैक

मैं होस्ट पर कभी pip पैकेज इंस्टॉल नहीं करता। हर मॉडल के लिए मैं Docker कंटेनर इस्तेमाल करता हूँ। इससे “डिपेंडेंसी हेल” से बचाव होता है, जहाँ एक एजेंट को Python 3.10 चाहिए और दूसरे को 3.12।

लोकल Gekro नोड के लिए docker-compose.yml:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ./ollama_data:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  summarizer-agent:
    build: ./agents/summarizer
    environment:
      - OLLAMA_HOST=http://ollama:11434
    depends_on:
      - ollama

3. WSL2 नोट: मेमोरी प्रबंधन

डिफ़ॉल्ट रूप से WSL2 आपकी सारी Windows RAM खा जाना चाहता है। मैं उसे 16GB पर सीमित करता हूँ ताकि Windows में चल रही मेरी Tesla टेलीमेट्री स्क्रिप्ट क्रैश न हों। अपने यूज़र फ़ोल्डर में एक .wslconfig बनाइए:

[wsl2]
memory=16GB
processors=8

समझौते

दर्द की बात करते हैं: सिमलिंक और फ़ाइल प्रदर्शन। अगर आप अपना कोड Windows की C: ड्राइव पर रखते हैं लेकिन उसे WSL2 के भीतर चलाने की कोशिश करते हैं, तो 9P प्रोटोकॉल अनुवाद की वजह से वह 10 गुना धीमा होगा। मैंने उत्पादकता का एक हफ़्ता यह सोचते हुए गँवा दिया कि मेरा वेक्टर डेटाबेस रेंग क्यों रहा है, फिर समझ आया कि मुझे पूरा प्रोजेक्ट फ़ोल्डर Linux फ़ाइल सिस्टम के भीतर (/home/rohit/gkro) ले जाना था।

मुझे जिसकी कमी खलती है वह इंटरऑपरेबिलिटी है। Windows पर मैं स्क्रीन के एक तरफ़ अपडेट चलने दे सकता था और दूसरी तरफ़ काम कर सकता था, या कोई जनरेटर चलता छोड़कर कुछ और करने जा सकता था। वह अब काफ़ी हद तक चला गया है, और मुझे उसका कोई साफ़ विकल्प नहीं मिला।

माइग्रेशन ख़ुद मेरी उम्मीद से नरम निकला। मैं इस डर के लिए तैयार था कि नया सिस्टम मुझे पटक देगा, और ज़्यादातर ऐसा हुआ नहीं। जिस चीज़ में बाक़ी सबसे कहीं ज़्यादा समय लगा, वह फ़ाइल सिंक था: OneDrive को क़ायदे से चलाना और फ़ाइलों को भरोसेमंद ढंग से Raspberry Pi तक पहुँचाना। जिसकी कमी अब भी खलती है, वह मसल मेमोरी है। Windows कमांड के दो दशक चले गए, और Linux में सहज हो जाने से वे वापस नहीं मिलते।

इसके अलावा, VRAM एक सीमित संसाधन है। अगर मैंने Windows में Chrome के 50 टैब खोल रखे हैं, तो वह WSL2 में चल रहे मेरे Llama 3 इंस्टेंस से VRAM चुरा रहा है। हाइब्रिड एनवायरनमेंट में आपको मेमोरी का बेरहम खोजी बनना सीखना पड़ता है।

आगे की राह

मैं सिंगल-पेन-ऑफ़-ग्लास मैनेजमेंट लेयर की ओर बढ़ रहा हूँ: Astro में बना एक कस्टम डैशबोर्ड, जो मेरे सभी Linux नोड (Pi और PC) का CPU/GPU तापमान और RAM उपयोग रियल-टाइम में देखता है। लक्ष्य है अपने घर के नेटवर्क को एक मिनी-AWS रीजन की तरह बरतना, जहाँ OS बस एक ब्योरा हो और एजेंट मुख्य नागरिक।

संक्षेप में