أفضلية Linux: لماذا يتنفس الذكاء الاصطناعي بشكل أفضل في النواة

إذا كنت تبني مختبر ذكاء اصطناعي على نظام تشغيل استهلاكي، فأنت تخوض حربًا على جبهتين: شيفرتك ونظام التشغيل. في عصر الذكاء الاصطناعي، Linux هو اللسان الأم للذكاء. قضيت ستة أشهر أحاول جعل تبعيات Python المعقدة تتوافق مع مسارات Windows وملفات DLL، قبل أن أقبل الحقيقة أخيرًا: إذا كانت أوزان النموذج قد دُرّبت على عناقيد Linux، فيجب أن يحدث الاستدلال على نوى Linux. ومنذ اللحظة التي التزمت فيها بسير عمل Ubuntu بلا واجهة في DFW، توقف تقريبًا كل ذلك التنقيح الذي كان يتعلق بنظام التشغيل لا بشيفرتي.

الشيء المحدد الذي حسم الأمر كان مشاهدة PowerShell المولَّد بالذكاء الاصطناعي يفشل ويعيد المحاولة ويفشل مجددًا ويحرق الرموز في أثناء ذلك. ليس مرة واحدة، بل كنمط. وما زال ذلك يحدث اليوم، ولهذا تخليت عن PowerShell في عمل الوكلاء بدل أن أحاول إصلاحه.

البنية

يشير “Edge” في مختبري إلى الوصول المباشر وغير الوسيط إلى العتاد. يضيف Windows طبقة من ضجيج “Desktop Window Manager” (DWM) بين شيفرتك ووحدة GPU. أما Linux فيتيح تمرير العتاد الذي يبدو كأنه عتاد مجرد.

في مختبري أستخدم WSL2 بوصفه “وحدة تحكم المشغّل” وUbuntu Server على عنقود Raspberry Pi لدي بوصفه “Edge الإنتاج”.

البناء

إعداد بيئة ذكاء اصطناعي عالية السرعة يتطلب أكثر من مجرد apt install. عليك أن تجسّر بين عتاد Windows ومنطق Linux.

1. تفعيل CUDA في WSL2

“الصلصة السرية” لمختبر قائم على Windows هي برنامج تشغيل NVIDIA الخاص بـ WSL. فهو يتيح لنواة Linux أن “ترى” وحدة 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.

ملف docker-compose.yml لعقدة Gekro محلية:

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 التهام كل ذاكرة RAM في Windows. أحدّه بـ 16GB حتى لا تنهار سكربتات قياسات Tesla لدي في Windows. أنشئ ملف .wslconfig في مجلد المستخدم:

[wsl2]
memory=16GB
processors=8

المفاضلات

لنتحدث عن الألم: الروابط الرمزية وأداء الملفات. إذا خزّنت شيفرتك على قرص C: في Windows لكنك حاولت تشغيلها داخل WSL2، فستكون أبطأ بـ 10 مرات بسبب ترجمة بروتوكول 9P. خسرت أسبوعًا من الإنتاجية وأنا أتساءل لماذا قاعدة بياناتي المتجهية تزحف، قبل أن أدرك أنني بحاجة إلى نقل مجلد المشروع بأكمله إلى داخل نظام ملفات Linux (/home/rohit/gkro).

ما أفتقده هو التشغيل البيني. في Windows كنت أترك التحديثات تعمل في جانب من الشاشة بينما أعمل في الجانب الآخر، أو أترك مولّدًا يعمل وأذهب لأفعل شيئًا آخر. هذا اختفى إلى حد كبير، ولم أجد له بديلًا نظيفًا.

كانت عملية الانتقال نفسها ألطف مما توقعت. استعددت لأن يربكني النظام الجديد، ومعظم الوقت لم يحدث ذلك. أما ما استغرق وقتًا أطول بكثير من أي شيء آخر فكان مزامنة الملفات: إقناع OneDrive بأن يتصرف جيدًا، ونقل الملفات إلى أجهزة Raspberry Pi بشكل موثوق. وما زلت أفتقد الذاكرة العضلية. عقدان من أوامر Windows ذهبا، ولا يعيدهما إليّ ارتياحي في Linux.

كذلك، VRAM مورد محدود. إذا كان لدي Chrome مفتوح بـ 50 تبويبًا في Windows، فهو يسرق VRAM من نسخة Llama 3 لدي في WSL2. عليك أن تتعلم أن تكون جامعًا لا يرحم للذاكرة في بيئة هجينة.

إلى أين يتجه هذا

أتجه نحو طبقة إدارة بنافذة واحدة: لوحة تحكم مخصصة في Astro تراقب في الوقت الفعلي درجة حرارة CPU/GPU واستخدام RAM في جميع عقد Linux لدي (أجهزة Pi والحواسيب). الهدف هو معاملة شبكتي المنزلية كأنها منطقة AWS مصغّرة، حيث نظام التشغيل مجرد تفصيل والوكلاء هم المواطنون الأساسيون.