Creando tu Home Lab para Agentes IA: Ollama + Proxmox en 2026

octubre 12, 2026 Alfonso Moreno | Sysadmin Senior 30 Visitas 18 min de lectura

Después de tres meses corriendo modelos LLM locales (Mistral, Llama 3, DeepSeek) en Ollama sobre un Proxmox con dos GPUs RTX 3090, llegué a una configuración estable que sirve a mi homelab como un servicio más: endpoints HTTP compatibles con la API de OpenAI, swap caliente entre modelos, integración con n8n y Open WebUI, y todo respaldado por PBS. Esta guía documenta esa configuración, con los benchmarks reales (no los de marketing), el truco de pasar GPUs a un LXC para no pagar el costo de una VM completa, y los gotchas de VRAM cuando quieres correr dos modelos en paralelo.

Si tienes Proxmox y al menos una GPU decente (RTX 3060 12GB como mínimo), puedes tener tu propio endpoint LLM local. Si no tienes Proxmox, la parte de Docker Compose aplica igual — solo cambia el deployment target.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 2-3 horas para el primer LLM funcionando, 1 hora para agregar modelos adicionales.
Requisitos: Proxmox 8+ con GPU NVIDIA (RTX 3060 12GB mínimo, RTX 3090/4090 ideal), drivers NVIDIA + Container Toolkit.
Resultado: Ollama sirviendo modelos LLM 7B-70B según VRAM, endpoint API compatible OpenAI, ~15-50 tokens/s en modelos 7B.
Troubleshooting típico: GPU no detectada en LXC (nvidia.runtime + drivers), OOM con modelos grandes, swap lento. Diagnosticables con `nvidia-smi` + `ollama ps`.

Por qué los agentes IA se han mudado al home lab

Hace dos años correr un agente de IA en casa significaba comprar una RTX 3090 de segunda mano, instalar llama.cpp compilado a mano y rezar para que el modelo de 7B no se cayera cada veinte tokens. Eso ya quedó atrás. En 2026 los modelos abiertos razonables viven en un servidor x86 con una sola GPU de 24 GB, el software maduró (Ollama 0.40 con Modelfiles declarativos, MLX en Apple Silicon, Vulkan por defecto en Linux), y la mayoría de los agentes de código que usas a diario — Claude Code, Codex, Continue, Open Code — ya aceptan un endpoint OpenAI-compatible como el que expone Ollama sin tocar una línea de configuración.

El catalizador real fue económico. Suscribir OpenAI, Anthropic o Gemini a escala de un equipo chico cuesta entre 200 y 800 USD/mes por usuario. Un homelab con una sola RTX 4090 usada se paga en seis meses si tu equipo usa agentes más de dos horas al día. Y hay un beneficio que las suscripciones no compran: privacidad real. Los prompts y el contexto del proyecto no salen de tu red, no se usan para entrenar modelos de nadie y no aparecen en una brecha de seguridad externa tres meses después.

El ecosistema open source del agente local se consolidó. ollama es la opción obvia para servir modelos, open-webui es la interfaz conversacional, litellm agrega múltiples modelos bajo un único endpoint, y todo corre sobre Proxmox 9.0 con GPU passthrough en un contenedor LXC privileged. Esta guía arma exactamente eso: un stack completo, reproducible, con la potencia y el aislamiento de un servidor dedicado, montado en una tarde.

Qué vas a montar exactamente

El target es un homelab que ejecute agentes IA 24/7 sin rezar para que la GPU se libere. La arquitectura es deliberadamente simple: Proxmox expone los recursos, un LXC privileged corre el stack de inferencia y otro LXC monta la UI conversacional + gateway. Si te quedas sin GPU el resto del servidor sigue funcionando; si rompes el stack de IA el resto del homelab ni se entera.

Componente	Rol	Dónde corre
Proxmox VE 9.0	Hypervisor + IOMMU + GPU passthrough	Host físico (bare metal Debian 13)
LXC 100 — `ollama`	Motor de inferencia (sirve modelos, API OpenAI-compatible, VRAM dedicada)	Privileged LXC con GPU NVIDIA asignada
LXC 101 — `open-webui`	Interfaz tipo ChatGPT, gestión de modelos, RAG local	Privileged LXC, sin GPU
LiteLLM	Gateway multi-modelo: enruta a Ollama, OpenAI, Anthropic por nombre	Dentro del mismo LXC que Open WebUI
Caddy	Reverse proxy HTTPS + emisión automática de certificados	Dentro del LXC de UI
Tailscale	Acceso remoto cifrado, sin abrir puertos al WAN	LXC UI + cada portátil del equipo

Todo el software vive como código en un directorio /opt/ai-stack versionado en git. Si pierdes el servidor restauras todo en menos de quince minutos con tres comandos. La alternativa basada en Docker Compose es perfectamente válida (mucha gente la prefiere), pero ocupa un poco más de RAM y suma una capa de abstracción innecesaria para un stack que solo tú vas a administrar.

Hardware mínimo y dimensionamiento de VRAM

El error más común al armar un homelab para IA es comprar la GPU equivocada. Una RTX 3060 de 12 GB sirve para chatear con Llama 3.1 8B en Q4_K_M; una RTX 4090 de 24 GB corre modelos de 30B sin quejarse y permite contexto largo. La regla empírica que mejor funciona: cuenta 2 GB de VRAM por cada billón de parámetros del modelo más un 30% de headroom para el KV cache y la sobrecarga de CUDA. Para un Qwen3 de 30B cuantizado en Q4_K_M necesitas 24 GB; para Llama 3.3 70B cuantizado en Q4 necesitas 48 GB y eso ya son dos RTX 3090 o una RTX 6000 Ada.

Modelo típico	Tamaño cuantizado	VRAM mínima	GPU recomendada
Gemma 4 9B (multimodal)	Q4_K_M	8 GB	RTX 3060 12G, RTX 4060 Ti 16G
Qwen3-Coder 30B	Q4_K_M	22 GB	RTX 4090 24G, RTX 5090 32G
Llama 3.3 70B	Q4_K_M	48 GB	RTX 6000 Ada, 2× RTX 3090
NVIDIA Nemotron 3 Ultra	FP8	32 GB	RTX 5090 32G, RTX PRO 4500 Blackwell
Muse Glimmer 30B (multimodal)	BF16	60 GB	RTX 6000 Ada 48G × 2

Si todavía no tienes GPU, compra usada: una RTX 3090 de 24 GB anda USD 550-650 en eBay a octubre 2026 y rinde casi como una 4090 para inferencia. Si quieres soporte oficial NVIDIA y driver propietario sin peleas, la RTX PRO 4500 Blackwell (32 GB) fue certificada en mayo 2026 como GPU de inferencia Ollama en Proxmox 9.1.1 (verificado por el repositorio fidpa/proxmox-gpu-passthrough). Evita GPUs de laptop, GPUs sin ECC y cualquier cosa basada en driver nouveau — el soporte en producción todavía es irregular.

El resto del servidor es más modesto. Para Proxmox + dos LXC + stack de IA: CPU x86 con IOMMU y al menos 8 cores (Intel VT-d o AMD-Vi, en BIOS encendido), 64 GB de RAM DDR5 (los modelos grandes pueden desbordan a memoria del sistema), almacenamiento NVMe para /var/lib/ollama (los modelos pesan entre 4 GB y 60 GB; un SSD de 1 TB es razonable para empezar) y una UPS básica porque un corte en mitad de una inferencia larga puede corromper el contexto del modelo. El consumo total del stack ronda los 80-120 W en idle y picos de 450 W cuando la GPU está al 100%; una sola RTX 4090 promedia 380 W en inferencia continua.

Proxmox 9.0 + IOMMU + GPU passthrough

El primer paso del día es verificar que el hardware expone IOMMU. Sin IOMMU no hay passthrough y la GPU queda inaccesible al LXC o la VM. Intel expone VT-d, AMD expone AMD-Vi; los dos se llaman intel_iommu=on y iommu=pt en GRUB. Reiniciar la máquina después del cambio, no solo recargar GRUB.

sudo nano /etc/default/grub
# AGREGAR a GRUB_CMDLINE_LINUX_DEFAULT:
#   intel_iommu=on iommu=pt
sudo update-grub
sudo reboot
dmesg | grep -e DMAR -e IOMMU

Si el comando dmesg devuelve líneas con DMAR: IOMMU enabled (Intel) o AMD-Vi: IOMMU performance counters (AMD), el kernel está viendo el hardware. Si devuelve nada, casi siempre es que el BIOS tiene la opción apagada — revisa Advanced → CPU Configuration → IOMMU, o en placas ASUS/Gigabyte la llaman Above 4G Decoding. Resizable BAR conviene activarla también, principalmente porque reduce latencia en cargas pequeñas.

El segundo paso es identificar las PCI IDs de la GPU. Cada función (gráfica, audio, USB-C) tiene su propio ID; Proxmox necesita todos para asignar el dispositivo completo al invitado.

lspci -nn | grep -i nvidia
# 01:00.0 VGA: NVIDIA RTX 4090 [10de:2684]
# 01:00.1 Audio: NVIDIA RTX 4090 High Definition Audio [10de:22ba]

Con esa lista en mano, se bindean las funciones a vfio-pci y se bloquea nouveau para que el driver open source no se apropie de la GPU antes que el invitado. El comando se ejecuta una sola vez y queda persistente después del reboot.

echo "options vfio-pci ids=10de:2684,10de:22ba" | sudo tee /etc/modprobe.d/vfio.conf
echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nvidia.conf
echo "blacklist nvidia" | sudo tee -a /etc/modprobe.d/blacklist-nvidia.conf
echo "blacklist nvidiafb" | sudo tee -a /etc/modprobe.d/blacklist-nvidia.conf
sudo update-initramfs -u
sudo reboot

Después del reinicio verifica que lspci -k -s 01:00 muestre Kernel driver in use: vfio-pci al lado de la GPU. Si muestra nvidia o nouveau, el blacklist no se aplicó y la GPU queda atrapada en el host —la guía específica de PCI passthrough en Proxmox tiene los pasos finos para cada familia de GPU.

Crear el LXC privileged con acceso a la GPU

Para inferencia de IA el patrón dominante en producción ya no es una VM con driver NVIDIA instalado: es un LXC privileged al que se le pasan los /dev/nvidia* y las librerías de CUDA del host. Arrancar el driver de NVIDIA dentro de un contenedor es problemático porque cada kernel de Proxmox rompe la compilación del módulo; pasarlo del host es trivial y soportado.

Crea el LXC desde la UI web de Proxmox con Debian 13 (trixie), 16 GB de RAM, 4 cores y el directorio /opt/ai-stack/ollama como punto de montaje NFS o un subvolumen ZFS. En la pestaña Resources tilda Device Passthrough y agrega todas las entradas NVIDIA que devolvió el comando anterior:

# Desde el HOST — confirmar qué devices existen
ls -la /dev/nvidia*
# Esperado: /dev/nvidia0 /dev/nvidiactl /dev/nvidia-modeset /dev/nvidia-uvm /dev/nvidia-uvm-tools

Una vez arrancado el contenedor y antes de seguir, monta el driver NVIDIA del host como read-only dentro del LXC. Es exactamente la receta documentada en el artículo de rovingclimber.com sobre GPU passthrough a LXC no privilegiadas — funcionan igual para privileged y es lo que evita que cada apt upgrade del kernel rompa CUDA.

# DENTRO del LXC — instalar runtime NVIDIA
sudo apt update
sudo apt install -y curl wget gnupg lsb-release
wget https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y nvidia-driver-cuda nvidia-kernel-open-dkms

Si el dkms build falla durante la instalación, lo más probable es que falten headers del kernel del host. Vuelve al Proxmox host y ejecuta apt install proxmox-default-headers "proxmox-headers-$(uname -r)", después reintenta dentro del LXC. La instalación termina con nvidia-smi mostrando la GPU desde adentro del contenedor — ese es el smoke test de que todo está conectado.

sudo nvidia-smi
# Esperado: tabla con la GPU, driver version, temperatura

Si nvidia-smi devuelve command not found, el PATH no incluye /usr/local/cuda/bin. Agregalo al ~/.bashrc con export PATH=/usr/local/cuda/bin:$PATH y reabre el shell. Si devuelve NVML: initialization failed, los devices no se pasaron correctamente al LXC; revisa la pestaña Resources del contenedor.

Instalar Ollama 0.40 y descargar un primer modelo

Ollama cambió mucho en 2026. La versión 0.30 (junio 2026) habilitó Vulkan por defecto — lo que significa que GPUs AMD e Intel discretas ahora aceleran inferencia sin parchar nada. La 0.40 (actual a octubre 2026) agregó Modelfiles con declaraciones CAPABILITY, soporte para modelos lanzados en gguf gracias al back-end de llama.cpp actualizado, y MLX madurado para Apple Silicon con embeddings y visión. Si vienes de un tutorial de 2024, olvida la mayoría de los flags.

La instalación es la misma de siempre: script oficial, gestor systemd, puerto 11434 escuchando en todas las interfaces. El archivo de configuración vive en /etc/ollama/ollama.conf o vía variable de entorno en el unit de systemd.

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama
ollama --version
# Esperado: ollama version 0.40.x
# Baja un modelo razonable para arrancar
ollama pull qwen3:8b
ollama run qwen3:8b "Explicame la diferencia entre IOMMU y SR-IOV en una frase"

Por defecto Ollama escucha en 127.0.0.1:11434. Para que el LXC de UI pueda consultarlo hay que editar el unit de systemd y exponer el puerto a la red interna. La forma soportada es crear un override: systemctl edit ollama, y agregar las variables OLLAMA_HOST=0.0.0.0:11434 y OLLAMA_KEEP_ALIVE=24h (mantiene el modelo en VRAM, evita recargar cada consulta).

sudo systemctl edit ollama
# Pega esto:
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
# Environment="OLLAMA_KEEP_ALIVE=24h"
# Environment="OLLAMA_NUM_PARALLEL=4"
sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -tlnp | grep 11434

La variable OLLAMA_NUM_PARALLEL=4 permite hasta cuatro conversaciones simultáneas contra el mismo modelo, útil cuando tres personas del equipo están usando el agente a la vez. La VRAM se reparte, así que ten en cuenta el costo: cada request concurrente ocupa ~500 MB adicionales de KV cache. Si ss no muestra el puerto, journalctl -u ollama -n 50 te dice por qué Ollama arrancó pero no está escuchando — suele ser un typo en la variable de entorno o un firewall dentro del LXC.

Open WebUI + LiteLLM: una sola URL, muchos modelos

Open WebUI es la interfaz de chat que usa tu equipo. Se conecta a Ollama por HTTP, sirve una UI tipo ChatGPT, maneja conversaciones, RAG local contra tus documentos y por extensión administración de modelos. LiteLLM es la capa que va delante cuando quieres mezclar modelos: /ollama/qwen3:8b para el día a día, /openai/gpt-4o-mini para algo puntual y /anthropic/claude-haiku-4-5 cuando necesitas un fallback frontier. Tu software (Claude Code, Codex CLI, Continue) le pega a LiteLLM con la API key de OpenAI y se olvida del resto.

# DENTRO del LXC 101 — UI
sudo apt update
sudo apt install -y python3-pip python3-venv
sudo useradd -m -s /bin/bash ai-ui
sudo -u ai-ui -i
python3 -m venv ~/stack
source ~/stack/bin/activate
pip install open-webui litellm[proxy]

El comando open-webui serve arranca la UI en el puerto 8080, espera la conexión con Ollama y crea un usuario admin con la primera visita. La configuración de URL del backend vive en OPEN_WEBUI_OLLAMA_BASE_URL=http://10.0.5.50:11434, donde la IP corresponde al LXC de Ollama de la tabla inicial. Si quieres que Open WebUI se conecte a LiteLLM en vez de Ollama directamente, reemplazas esa variable por el endpoint de LiteLLM y LiteLLM rutea a quien corresponda.

LiteLLM vive en el mismo LXC y se configura con un YAML simple. El ejemplo siguiente le da a http://litellm:4000 tres modelos: uno local, uno de OpenAI y uno de Anthropic, todos bajo la misma API key. Sirve para que el día de mañana un agente pueda elegir el modelo sin que cambie nada en el cliente.

# /opt/ai-stack/litellm/config.yaml
model_list:
  - model_name: qwen3-local
    litellm_params:
      model: openai/qwen3:8b
      api_base: http://10.0.5.50:11434/v1
      api_key: ollama
  - model_name: gpt4omini
    litellm_params:
      model: gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY
  - model_name: claude-haiku
    litellm_params:
      model: claude-haiku-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
litellm_settings:
  drop_params: true
  set_verbose: false
general_settings:
  master_key: sk-local-homelab-XXXXXXXX

El master_key es la API key que consumen tus herramientas (Claude Code, Continue, OpenCode). Reemplaza XXXXXXXX por 24 caracteres aleatorios generados con openssl rand -hex 24. Arranca LiteLLM con litellm --config /opt/ai-stack/litellm/config.yaml --host 0.0.0.0 --port 4000, valida con curl http://localhost:4000/v1/models -H "Authorization: Bearer sk-local-..." y ya tienes un gateway multi-modelo local.

Exposición segura con Tailscale: cero puertos abiertos

El paso más subestimado del stack. Si abres el puerto 8080 a internet, los bots llegan en minutos y los intentos de prompt injection empiezan a las pocas horas. La solución honesta es no abrir nada al WAN y entrar a Open WebUI por Tailscale, que monta una red privada cifrada entre tus dispositivos sin tocar el firewall de tu proveedor.

# DENTRO del LXC 101
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --hostname=ai-homelab
sudo tailscale ip -4
# Devuelve 100.x.y.z — esa es la IP que usas en tu navegador portátil

En cada portátil del equipo instalas Tailscale, inicias sesión con la misma identidad, y Open WebUI queda accesible en http://100.x.y.z:8080 desde cualquier red. Si necesitas HTTPS, Caddy delante del puerto 8080 con un cert de Tailscale usando el módulo ts-net es la forma más limpia — pero el HTTP plano sobre Tailscale es perfectamente válido porque el tráfico ya está cifrado por el túnel WireGuard.

Para evitar exponer accidentalmente el puerto a internet (algún día olvidas el firewall), deja el puerto 8080 atado a la interfaz de Tailscale, no a 0.0.0.0. En el unit de Open WebUI, agrega --host 100.x.y.z al comando open-webui serve. La verificación con curl http://10.0.5.51:8080 desde el LXC de Ollama sigue funcionando porque ambos comparten la red interna de Proxmox.

Troubleshooting común: los seis errores que vas a ver

Cualquiera que monte este stack choca con los mismos seis problemas. Vale la pena tener el diagnóstico memorizado.

1. nvidia-smi dentro del LXC dice Failed to initialize NVML. Causa clásica: los /dev/nvidia* no están bindeados al contenedor. Vuelve a Proxmox → Container → Resources → Device Passthrough y agrega todos los nodos manualmente. Si sigues en lo mismo, revisa los logs del contenedor con pct enter 100 seguido de journalctl -k | grep -i nvidia.

2. Ollama arranca pero ollama pull muere con connection refused. Casi siempre es el firewall dentro del LXC. sudo ufw allow from 10.0.5.0/24 to any port 11434 abre el rango de la red interna de Proxmox sin exponer al WAN. Si no usas ufw, iptables -A INPUT -p tcp -s 10.0.5.0/24 --dport 11434 -j ACCEPT.

3. Open WebUI muestra el modelo pero las respuestas tardan 60 segundos. Lo que ves en la VRAM cuando el modelo se carga por primera vez. La segunda consulta debe bajar a 1-3 segundos para prompts cortos y 10-20 para contexto largo. Si la lentitud es persistente, el modelo se está descargando en cada arranque — agrega OLLAMA_KEEP_ALIVE=24h como vimos antes.

4. Claude Code tira 401 Unauthorized al pegarle a LiteLLM. El header Authorization no llega porque LiteLLM está esperando un Bearer token y Claude Code está mandando un header de otra forma. En el YAML de LiteLLM, agrega litellm_settings.api_version: "2024-01-01" y reinicia. Si sigues con 401, curl -v http://localhost:4000/v1/models -H "Authorization: Bearer sk-local-..." — si eso devuelve 200, el problema es del cliente, no del gateway.

5. La GPU está al 100% pero las respuestas son lentas. Batch size demasiado chico o número de requests concurrentes demasiado alto. Baja OLLAMA_NUM_PARALLEL=2 en systemd, monitorea con watch -n 1 nvidia-smi. Si la utilización sigue al 100% con un solo request, tienes demasiadas capas litellm en el medio — la primera inferencia siempre es lenta por la compilación JIT, las siguientes no deberían.

6. La página de Open WebUI carga vacía después de login. La base SQLite de Open WebUI se corrompió (suele pasar tras un corte de energía). mv ~/.open-webui/data/webui.db /tmp/ y reinicia Open WebUI; vas a perder el historial pero el stack vuelve a funcionar. Para evitarlo, monta la base en un volumen ZFS con replicación o, mejor, haz un snapshot diario del LXC desde Proxmox.

Vale la pena: para quién y para quién no

Para un equipo de dos a cinco personas que usan agentes IA más de dos horas por día, un homelab como este se paga solo en menos de un año. La inversión inicial ronda los 1.800 USD (servidor usado + RTX 4090 24 GB + 64 GB RAM + NVMe 1 TB), el costo eléctrico mensual es de 25 a 35 USD según la tarifa, y el retorno está en no pagar suscripciones individuales de 20-100 USD por usuario por mes.

Para un equipo de uno solo que quiere chatear con un agente tres veces por semana, no vale la pena. La API de OpenAI o Anthropic con uso bajo cuesta 5-20 USD/mes, configurar todo este stack son dos tardes, y mantenerlo (updates de Proxmox, driver NVIDIA, modelos nuevos) son tres horas al mes. Comprar el servidor y dedicar el domingo a instalar todo solo tiene sentido si vas a usarlo a diario.

Para un equipo grande (>10 personas), el cálculo se vuelve favorable otra vez, pero hay que subir de nivel: dos GPUs, modelos servidos con vLLM en vez de Ollama (más rendimiento por GPU), LiteLLM con rate limiting y un Open WebUI detrás de un SSO corporativo. Eso ya no es un proyecto de domingo — es un servicio interno con dueño, runbook y monitoring.

En cualquier caso, lo que está claro es que el agente IA local ya es viable en 2026. La curva de hardware bajó de RTX A100 (USD 10k) a RTX 4090 (USD 1.8k) en tres años; el software maduró de llama.cpp compilado a mano a ollama pull; el ecosistema de agentes se estandarizó sobre el endpoint OpenAI, lo que significa que cualquier herramienta nueva que aparezca funciona con tu homelab desde el día uno. La pregunta no es si montar un homelab para IA es posible, es para quién vale la pena el domingo que lleva armarlo.

Preguntas frecuentes

¿Por qué Creando tu Home Lab para Agentes IA: Ollama + Proxmox en 2026 es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Creando tu Home Lab para?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Creando tu Home Lab para?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Creando tu Home Lab para y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Creando tu Home Lab para?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.