La ventaja de Linux: por qué la IA respira mejor en el kernel

Si montas un laboratorio de IA sobre un sistema operativo de consumo, libras una guerra en dos frentes: tu código y tu sistema operativo. En la era de la IA, Linux es la lengua nativa de la inteligencia. Pasé seis meses intentando que dependencias complejas de Python se llevaran bien con las rutas y las DLL de Windows, hasta que acepté la verdad: si los pesos del modelo se entrenaron en clústeres Linux, la inferencia debería ocurrir en kernels Linux. En cuanto me comprometí con un flujo de trabajo de Ubuntu sin interfaz en DFW, la depuración que tenía que ver con mi sistema operativo y no con mi código casi desapareció.

Lo que lo decidió fue ver cómo el PowerShell generado por IA fallaba, reintentaba, volvía a fallar y quemaba tokens en el proceso. No una vez, sino como patrón. Eso sigue ocurriendo hoy, y por eso abandoné PowerShell para el trabajo con agentes en lugar de intentar arreglarlo.

La arquitectura

El “Edge” de mi laboratorio se refiere al acceso directo y sin intermediarios al hardware. Windows añade una capa de ruido del “Desktop Window Manager” (DWM) entre tu código y tu GPU. Linux permite un paso directo de hardware que se siente como bare metal.

En mi laboratorio uso WSL2 como “consola del operador” y Ubuntu Server en mi clúster de Raspberry Pi para el “Edge de producción”.

La construcción

Montar un entorno de IA de alta velocidad requiere algo más que apt install. Hay que tender un puente entre el hardware de Windows y la lógica de Linux.

1. Activar CUDA en WSL2

La “salsa secreta” de un laboratorio basado en Windows es el controlador WSL de NVIDIA. Permite que el kernel de Linux “vea” la GPU de tu PC sin la sobrecarga de una máquina virtual completa.

# 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. La pila Docker-IA

Nunca instalo paquetes pip en el host. Uso contenedores Docker para cada modelo. Así evito el “infierno de dependencias”, donde un agente necesita Python 3.10 y otro necesita 3.12.

docker-compose.yml para un nodo Gekro local:

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. Nota sobre WSL2: gestión de la memoria

Por defecto, WSL2 intenta comerse toda tu RAM de Windows. Yo lo limito a 16GB para que mis scripts de telemetría de Tesla en Windows no se caigan. Crea un .wslconfig en tu carpeta de usuario:

[wsl2]
memory=16GB
processors=8

Las contrapartidas

Hablemos del dolor: los enlaces simbólicos y el rendimiento de archivos. Si guardas tu código en la unidad C: de Windows pero intentas ejecutarlo dentro de WSL2, irá 10 veces más lento por la traducción del protocolo 9P. Perdí una semana de productividad preguntándome por qué mi base de datos vectorial se arrastraba, hasta que me di cuenta de que tenía que mover toda la carpeta del proyecto dentro del sistema de archivos de Linux (/home/rohit/gkro).

Lo que echo de menos es la interoperabilidad. En Windows podía dejar que las actualizaciones se fueran haciendo en una parte de la pantalla mientras trabajaba en la otra, o dejar un generador funcionando e irme a hacer otra cosa. Eso en gran parte se ha acabado, y no he encontrado un sustituto limpio.

La migración en sí fue más suave de lo que esperaba. Me preparé para que el sistema nuevo me desbordara y casi nunca ocurrió. Lo que llevó mucho más tiempo que cualquier otra cosa fue la sincronización de archivos: conseguir que OneDrive se portara bien y llevar archivos a las Raspberry Pi de forma fiable. Lo que sigo echando de menos es la memoria muscular. Dos décadas de comandos de Windows, perdidas, y sentirse cómodo en Linux no la devuelve.

Además, la VRAM es un recurso finito. Si tengo Chrome abierto con 50 pestañas en Windows, le está robando VRAM a mi instancia de Llama 3 en WSL2. Hay que aprender a ser un carroñero implacable de la memoria en un entorno híbrido.

Hacia dónde va esto

Me estoy moviendo hacia una capa de gestión de panel único: un panel personalizado en Astro que monitoriza en tiempo real la temperatura de CPU/GPU y el uso de RAM de todos mis nodos Linux (Pi y PC). El objetivo es tratar mi red doméstica como una mini región de AWS, donde el sistema operativo es un simple detalle y los agentes son los ciudadanos principales.