Servir Gemma 4 en una MI300X alquilada a 1,99 dólares la hora
Una guía detalla cómo desplegar Gemma 4 E2B sobre una AMD Instinct MI300X alquilada, con todo el ciclo de vida empaquetado en 21 herramientas MCP y sin GPU local en la máquina que lo lanza.
Un desarrollador ha publicado una guía paso a paso para servir Gemma 4 E2B sobre una AMD Instinct MI300X alquilada, con el proceso automatizado mediante un servidor MCP que expone 21 herramientas por stdio. La tarjeta sale a 1,99 dólares la hora en AMD Developer Cloud, que por debajo es DigitalOcean, y la máquina desde la que se lanza no lleva GPU AMD ni la va a llevar: rocm-smi, amd-smi, rocminfo y hipcc no existen en local, y un comando ROCm en esa shell es un error, no una comprobación.
Qué se despliega
El modelo es google/gemma-4-E2B-it en bf16. La instancia es una gpu-mi300x1-192gb-devcloud con 20 vCPU, 240 GB de RAM y 720 GB de disco en la región atl1, a 1,99 dólares la hora bajo demanda, un precio que se lee del campo price_hourly de la API v2 y que se factura también con la máquina apagada. La imagen elegida es vllm/vllm-openai-rocm:nightly-rocm100, con vLLM 0.3.1.dev3+g0bfc7a15d; la versión se saca del contenedor en marcha y no de la etiqueta, porque un tag nightly se mueve bajo los pies. No cualquier imagen ROCm de vLLM carga este checkpoint: Gemma 4 usa cabezas de 256 anchos en las capas de atención deslizante y de 512 en las de atención completa, y una imagen cuyo vLLM sea anterior a esa división no sabe parsear la configuración.
El servidor arranca con contexto de 32768 y gpu-memory-utilization 0.90. El límite de audio va a cero a propósito: E2B trae un codificador conformer de audio y ninguna imagen ROCm de vLLM incluye los extras vllm[audio], así que un valor distinto de cero reservaría memoria para un camino que no se puede usar.
Contenedor arriba no es modelo sirviendo
docker run vuelve en un segundo, pero el endpoint no responde hasta los 160 segundos, mientras se cargan los pesos, corre torch.compile y se capturan grafos. Por eso la herramienta de estado informa el contenedor y el endpoint como dos hechos separados. Los números medidos: 305 tokens por segundo en un solo stream, 10.284 tokens por segundo con 64 streams, y 2.713 tokens por segundo por dólar-hora.
Todo el toolkit vive en un único server.py que ejecuta cada subproceso con asyncio.create_subprocess_exec, nunca a través de un shell, y el repositorio con las herramientas está disponible junto al código del despliegue. Crear y destruir la instancia se queda fuera a propósito: son decisiones de dólares por hora y no deberían estar al alcance de algo que un agente pueda llamar. La tarjeta se presenta como una función virtual SR-IOV, y el autor avisa de que eso parece una partición y no lo es: están las 304 unidades de cómputo y los 191,7 GiB completos.
Lo aprovechable es el patrón. Si lo que se mide se fija y se verifica, tiene sentido empaquetar el ciclo completo en herramientas MCP y dejar en manos humanas lo que cuesta dinero. Lo que no queda fijado es la imagen nightly, así que cualquier adopción real pasa por medir antes de mover la etiqueta.
