Generar imágenes por IA en tu propio ordenador

Ya vimos en la entrada anterior como poder tener nuestro propio chat-gpt sin pagar nada a nadie usando modelos opensource y nuestra GPU, ahora le toca el turno a la posibilidad de generar imágenes por Inteligencia Artificial mediante el mismo método, en casa, de forma privada y sin tener que pagar licencias. Al lío…

La imagen anterior ha sido generada en mi ordenador, con mi tarjeta gráfica y con un prompt muy sencillito, básicamente le he pedido un robot pintando con pinceles en la pantalla del ordenador… Y me ha salido esto (hay más parámetros, pero no he tocado nada especial). Para generar estas imágenes vamos a utilizar Stable Diffussion, que es un modelo de aprendizaje automático para generar imágenes digitales de alta calidad a partir de descripciones en lenguaje natural (wikipedia). Es de código abierto y no impone restricciones a las imágenes que produce.

Como somos hombres (y mujeres) de acción os voy a dar la receta rápida para tener stable difussion y un interfaz de usuario (automatic1111) funcionando en cuestión de minutos (bueno, esto depende de vuestra conexión a internet que hay muchos gigas que descargarse). La receta original, que os recomiendo seguir si queréis experimentar un poco más con el tema, la saqué de aquí: https://github.com/AbdBarho/stable-diffusion-webui-docker pero yo he preparado una imagen que ya tiene todo lo necesario, así que lo único que tenéis que hacer es crear un archivo docker-compose.yml con este contenido:

services:
  sd-auto:
    image: yoprogramo/sd-auto:78
    ports:
      - "7860:7860"
    volumes:
      - ./data:/data
      - ./output:/output
    stop_signal: SIGKILL
    environment:
      - CLI_ARGS=--allow-code --medvram --xformers --enable-insecure-extension-access --api
      - COMMANDLINE_ARGS=--share
    restart: unless-stopped
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids:
                - "0"
              capabilities:
                - compute
                - utility

Luego, estoy suponiendo que usáis linux y tenéis la configuración de docker y de la tarjeta gráfica que ya vimos en el anterior post, solo hay que ejecutar:

docker compose up -d

Como os he dicho el proceso de descarga inicial de la imagen y del modelo van a tardar un poco (reservaos mínimo 20Gb para todo), pero si todo va bien en unos minutos podréis acceder a la url http://localhost:7860 y veréis la interfaz de AUTOMATIC1111 para stable difussion.

Inicialmente el modelo descargado es sdv1.5-pruned-emaonly que tiene sus limitaciones pero cabe en casi todas la memorias. Ya solo queda hacer la prueba, poniendo algo en el prompt y dandole a Generate.

Si no tienes demasiada memoria en tu tarjeta gráfica te saldrá algo como esto:

Pero si has sido capaz de generar una imagen, se abre todo un abanico de modelos que probar y opciones con las que trastear… El primer sitio para visitar es este:

https://civitai.com

Como tener tu propia IA en casa

Todos hemos oído y probado las bondades de chat-gpt o usado github copilot con tremendo éxito, pero estos sistemas tienen un problema principal, que son de pago. Sus modelos son cerrados y hay que pagar una licencia para poder utilizarlos en cosas útiles. Sin embargo, existe otra manera de experimentar con la Inteligencia Artificial generativa en casa, sin pagar licencias y teniendo todo el control. Solo necesitas un equipo medianamente moderno, una GPU y una cantidad de memoria abundante (o no tanta, pero podrás jugar con menos modelos). Te cuento aquí como instalar tu propio servicio de IA en tu ordenador.

Eso si, te lo cuento solo para Linux, si tienes algún otro sistema operativo de esos de juguete tendrás que buscarte la vida (te dejo enlaces para que puedas hacerlo por tu cuenta).

Como modelo de AI vamos a utilizar llama, modelo opensource de Meta y lo vamos a instalar con ollama. Hay varias guías para instalarlo directamente en tu ordenador, pero las últimas versiones de ubuntu (yo tengo la 24.04) son ciertamente reticentes a instalar paquetes python en el sistema, por lo que la solución más sencilla será usar docker para ello. Vamos a suponer que tenemos una GPU nvidia, y la porción de docker-compose necesaria para instalarte ollama sería esta:

  ollama:
    volumes:
      - ./ollama:/root/.ollama
    container_name: ollama
    pull_policy: always
    tty: true
    ports:
      - "11434:11434"
    restart: unless-stopped
    image: ollama/ollama:${OLLAMA_DOCKER_TAG-latest}
    deploy:
      resources:
        reservations:
          devices:
            - driver: ${OLLAMA_GPU_DRIVER-nvidia}
              count: ${OLLAMA_GPU_COUNT-1}
              capabilities:
                - gpu

Con esta configuración lo que hacemos es lanzar un servidor ollama accesible desde el puerto 11434 donde podemos usar el tty o el api. No voy a entrar en muchos detalles de cómo usar ollama, pero os recomiendo que le echéis un vistazo porque es la «madre del cordero» o de la llama, en este caso.

Para que esto funcione correctamente con la gpu hay que hacer un par de cositas previamente. Os recomiendo que miréis este repositorio para ver si se ha mejorado/modificado algo: https://github.com/valiantlynx/ollama-docker pero básicamente consiste en ejecutar lo siguiente:

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

# Configure NVIDIA Container Toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Dado que vamos a necesitar un interfaz para gestionar los modelos y tener chats y demás lo siguiente que vamos a incluir en nuestro docker-compose es open-webui, modificamos nuestro docker-compose.yml para agregar lo siguiente (yo ya he contruido la imagen y la he subido a docker hub):

  open-webui:
    image: yoprogramo/open-webui:${WEBUI_DOCKER_TAG-latest}
    container_name: open-webui
    volumes:
      - ./open-webui:/app/backend/data
    depends_on:
      - ollama
    ports:
      - ${OPEN_WEBUI_PORT-3000}:8080
    environment:
      - 'OLLAMA_BASE_URL=http://ollama:11434'
      - 'WEBUI_SECRET_KEY='
    extra_hosts:
      - host.docker.internal:host-gateway
    restart: unless-stopped

Y creamos un archivo .env con el siguiente contenido:

OLLAMA_GPU_COUNT=all
SCARF_NO_ANALYTICS=true
DO_NOT_TRACK=true
ANONYMIZED_TELEMETRY=false

Y lanzar las imágenes si todo ha ido bien:

docker compose up -d

Con esto ya tendríamos corriendo nuestro servidor ollama y open-webui en nuestro propio ordenador… Simplemente tenemos que acceder con el navegador a localhost:3000

Lo primero que tenéis que hacer, una vez creado un usuario en el sistema (si, el primer usuario que se crea es administrador) es descargarse algún modelo de IA, para eso hay que entrar en la página de administración y acceder a la opción que pone «Obtener un modelo de Ollama.com», escribir el deseado y darle al botón de la derecha para descargarlo. En la imagen por ejemplo nos descargamos el modelo llama3.1 de 70B (son cerca de 42Gb, así que deberías tener espacio de sobra).

Una vez descargado ya estamos listos para usarlo, vete a la opción «nuevo Chat», selecciona el modelo en el desplegable superior y chatea con tu nueva AI…

En próximas entregas ya entraremos en más cosas que podemos hacer con nuestra IA local, seguro que no nos deja indiferentes.

De puertas traseras y software libre

Es casi imposible que no hayas oido hablar del backdoor xz, no es que yo pueda darte más información sobre el tema, os dejo un video de alguien que os cuenta el caso completo como si de un episodio de serie negra se tratase:

El caso es que, alguien durante tres años ha ido infiltrándose en un repositorio de un elemento pequeño pero crítico de software libre llamado xz, de tal manera que consiguió, no solo quedarse como mantenedor de ese repositorio sino que fue introduciendo, poco a poco, una puerta trasera que permitía el acceso remoto (todavía hay que ver el payload real lo que llegaba a hacer) y conseguir que ese backdoor se distribuyese en algunas de las más importantes distribuciones.

Por suerte, o mejor dicho, por la misma estructura del software libre, esta versión no pasó de las versiones inestables de las distribuciones y se descubrió el pastel porque una persona notó que algo iba más lento de lo que debía después de la actualización. Esta persona (Andres Freund) no se paró en medir el tiempo de respuesta sino que terminó encontrando la causa subyacente y la puerta trasera que habían metido (aquí el aviso que dió a la comunidad) y, obviamente, la reacción de los mantenedores de la distribución, e incluso del antiguo mantenedor del repositorio fue inmediata y reliminó todas las trazas del código dañino.

Hay varias cosas que podemos destacar, pero yo me quedo con un par de ellas:

  1. La dependencia que tenemos de código que han escrito terceros y que pueden estar bien mantenidos o no (dependiendo del ánimo de esa persona o de sus circunstancias personales)
  2. La potencia del ecosistema open source para descubrir y arreglar este tipo de problemas. Todos los sistemas operativos actuales, desde mac os hasta windows usan componentes externos, no hay ninguno 100% original y tampoco es que se pueda saber qué es lo que usan exactamente. Si hay un backdoor en windows o en macos nos lo tendremos que comer con patatas porque nadie puede mirar lo que hay dentro.

Estoy seguro de que esta forma de actuar, por muy inteligente y paciente que sea, no deja de ser un ataque en toda regla con unas finalidades seguramente malvadas (crear una botnet inmensa, por ejemplo) y no creo que sepamos realmente quien está detrás de ello y, posiblemente, nos de para una docuserie de Netflix un día de estos.

En fin, no ha pasado nada, todo está en orden de nuevo y lo malo es que nos deja un regusto amargo y hace bajar un peldaño la confianza que teníamos en el ecosistema (pero no mucho, oye, que seguimos estando a salvo).

Pasar a producción un API en python con flask / connexion

Hacer un servicio que sirva un API en python es muy, muy sencillo usando flask o connexion. Mi método favorito de hoy (esto cambia día a día) es usar connexion que nos permite crear un servidor teniendo su definición en un archivo openapi con simplemente tres líneas de código:

app = connexion.App(__name__,specification_dir='./')
CORS(app.app)
app.add_api('openapi.yml')
app.run(port=8080)

Con estas cuatro líneas de código (además de los imports correspondientes) ya tendríamos un servidor web en el puerto 8080 de la máquina. Luego basta con tener en el openapi.yml definido el nombre de las operationId e implementarlas adecuadamente… Me tienta, pero en este momento no voy a hacer un tutorial sobre connexion o sobre cómo generar un proyecto python usable. Para esta entrada supongamos que ya tenemos el servidor implementado y corriendo… Veremos que cuando lo arrancamos nos muestra este mensaje:

 * Serving Flask app 'app'
 * Debug mode: off
2024-01-25 20:57:13,203 - werkzeug - INFO - WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:8080
 * Running on http://172.18.0.20:8080
2024-01-25 20:57:13,204 - werkzeug - INFO - Press CTRL+C to quit

Si nos fijamos nos está advirtiendo de que el servidor que está usando es el propio de Flask y no es muy adecuado para entornos de producción. ¿Qué significa esto? Que si recibe muchas peticiones el tiempo de proceso de las mismas va a ser muy alto. El mismo mensaje nos recomienda usar un servidor WSGI para entornos de producción.

De hecho, si estás ejecutando una versión más moderna de connexion te aparecerá este mensaje en su lugar:

2024-01-25 22:05:31,351 - connexion.middleware.main - WARNING - `ConnexionMiddleware.run` is optimized for development. For production, run using a dedicated ASGI server.

Que es lo mismo pero con ASGI en lugar de WSGI. La receta para ejecutarlo mas en «producción» en este caso sería instalar gunicorn y lanzarlo con un tipo de worker ASGI (uvicorn en este caso) teniendo en cuenta que app está definido dentro del archivo app.py:.

pip install gunicorn
gunicorn -k uvicorn.workers.UvicornWorker --bind "0.0.0.0:8080" app:app

Con eso ya lanzamos un proceso, si queremos lanzar más lo podemos hacer con el parámetro -w poniendo, por ejemplo:

gunicorn -k uvicorn.workers.UvicornWorker -w 4 --bind "0.0.0.0:8080" app:app

Con esto ya se lanza 4 procesos para dar servicio al API… Esto debería mejorarlo.

Y una cosa más… Si tenéis algún proceso en la aplicación que no deba replicarse con cada worker (un scheduler por ejemplo), tenéis que lanzar gunicorn con el parámetro --preload para que se ejecute solo una instancia de la aplicación (de todo lo que no dependa de las peticiones)

Cómo dar de alta tu propia librería en el gestor de librerías de Arduino

De un tiempo a esta parte he estado haciendo cositas con microcontroladores y Ardunio (ultimamente con platformio), y el caso es que he querido dejar como librerías libres algunos de los códigos que he generado (o mejorado), como por ejemplo la librería para generar códigos QR en displays OLED o TFT (https://github.com/yoprogramo/QRcodeDisplay). La gestión de librerías en Arduino es una de las cosas que hacen el entorno interesante (en platformio mejor todavía) y es muy interesante tener disponible tu librería en el gestor de librerías de arduino.

Hasta hace poco el hacer que tu librería estuviese disponible para todo el mundo en el gestor de librerías de Arduino IDE era una tarea muy «manual», básicamente poner un mensaje en los foros de soporte de Arduino y esperar por la respuesta… Esto ha cambiado un poquito y podemos encontrar un nuevo método aquí:

https://github.com/arduino/library-registry#readme

Os lo resumo para los que seais impacientes. Los pasos una vez que tengáis el código de la librería en github son los siguientes:

  • Crear una release en github y darle un número
  • Crear un archivo llamado library.properties con el número de versión y los datos correspondientes de las plataformas y dependencias
  • Abrir este enlace para hacer un fork del repositorio: https://github.com/arduino/library-registry/edit/main/repositories.txt
  • Hacer fork del repositorio
  • Editar el archivo repositories.txt añadiendo la url de github del repositorio
  • Hacer click en «Proponer cambios»
  • Crear un pull request

El pull request genera una petición para que un bot revise los cambios, si todo está ok la librería aparecerá al día siguiente en el gestor de arduino, si hay algún problema se puede poner un comentario mencionando a @ArduinoBot o hacer un commit con las modificaciones en el archivo (en la rama de nuestro fork).

Nuestra librería en el gestor de librerías de Arduino