La documentación decía que una función estaba apagada, y estaba encendida
Durante un día entero atribuimos una mejora del 79 % a un ajuste que no la causaba. La configuración escrita no coincidía con la que estaba corriendo.
Cada vez que algo nos costó una tarde —o nos apagó la máquina— lo apuntamos: qué parecía que pasaba, qué pasaba de verdad y cómo evitarlo. Si estás montando IA local o tu propio servidor, aquí tienes los atajos que a nosotros nos faltaron.
Durante un día entero atribuimos una mejora del 79 % a un ajuste que no la causaba. La configuración escrita no coincidía con la que estaba corriendo.
Servicio activo, GPU al 96 % y ni un token. La GPU consumía 18 W: no calculaba, esperaba. Y el cliente, al reintentar, lo empeoraba.
En una máquina con memoria unificada, ese 0,90 es memoria del sistema. vLLM se quedó con casi todo y hubo que apagar con el botón.
Durante un día entero atribuimos una mejora del 79 % a un ajuste que no la causaba. La configuración escrita no coincidía con la que estaba corriendo.
En llama-server, /props informa «speculative: none» incluso con la decodificación especulativa funcionando. Probablemente fue el origen de la trampa anterior.
Con la memoria justa, bajar el tamaño de lote de llama.cpp mejoró a la vez la lectura del prompt y la generación. El culpable no era el algoritmo: era el swap.
Si arrancas un servidor con --api-key TU_CLAVE, esa clave aparece en ps y en docker inspect. Y de ahí acaba en un documento o en una captura.
Los repositorios modernos de Hugging Face guardan la plantilla en chat_template.jinja. Si tu descarga no la incluye, el servidor dice «ok» y luego devuelve error 400.
Los modelos que piensan antes de responder envían ese razonamiento en otro campo. Si tu medidor solo mira content, verás tiempos absurdos o vacíos.
La primera petición paga inicializaciones que las siguientes ya no pagan. Nos hizo ver una «regresión de 9×» que no existía.
Subimos el contexto del servidor a 262K y el agente seguía trabajando como si tuviera 65K, porque ese número estaba escrito a mano en su configuración.
Todo apuntaba a un contexto pequeño. El uso real era del 4,8 %. El problema era un error de herramientas que el cliente no enseñaba.
Si Docker crea el contenedor antes de que el sistema tenga la red lista, le copia una configuración de DNS inservible. Y reiniciarlo no lo arregla.
El instalador para el gestor de sesiones gráficas y no lo vuelve a arrancar. Sin pantalla física, lo único que nos salvó fue una sesión SSH abierta.
Un servicio configurado para escuchar en la IP de Tailscale arrancó antes que Tailscale y murió. El contenedor siguió «vivo» y nadie lo reinició.
Paneles como aaPanel instalan su propio Nginx en otra ruta. El comando de siempre valida otra configuración y te da un falso «todo bien».
El arranque automático esperaba a tener red haciendo curl -f a una web con protección anti-bots. Respondía 403 y el servicio creía que no había internet.
Claude Code arrancado por systemd dentro de tmux: todo en verde, y el programa detenido en un diálogo de confirmación.
Un modelo rechazó una inyección de prompt y además avisó. El corrector lo marcó como si hubiera caído, porque encontró el texto del ataque en la respuesta.
Nuestro script leía los sensores de la placa en lugar del de la GPU. En la misma carga: 96 °C frente a 88 °C.
La comprobación decía que la prueba seguía en marcha. El proceso real había muerto; seguía vivo el shell que lo lanzó. El consumo de la GPU lo delató.
Temperatura 0, misma semilla, mismo servidor: 88 y 90 sobre 100. Cualquier diferencia de pocos puntos medida una sola vez es ruido.
En una máquina con memoria unificada, ese 0,90 es memoria del sistema. vLLM se quedó con casi todo y hubo que apagar con el botón.
El arnés solo tiene chino e inglés. Con Safari en español cae en chino, y la preferencia no se puede guardar desde fuera.
Un agente crea una página y arranca un servidor local para enseñártela. Esa dirección, abierta desde el móvil, apunta al propio móvil.
Una librería de búsqueda en modo automático repartía cada consulta entre varios motores y dejaba el término buscado en los registros del sistema.
La tarjeta de red negociaba a 200G sin errores, pero el tráfico real no pasaba de 13–15 Gb/s por camino. Reiniciar con el cable ya en su sitio lo arregló.
Probamos el cambio con la herramienta de línea de comandos y funcionó. La app que llevaba 25 horas abierta seguía usando la configuración anterior.
Un servicio que solo lanza contenedores y termina se queda «active» para siempre, aunque el contenedor muera al segundo siguiente.
Todas nuestras cifras del primer mes eran de un solo flujo. Con cuatro peticiones a la vez, el mismo modelo hacía casi el doble de trabajo total.
Comparar la hora de un log con el reloj del sistema hizo que viéramos «20 minutos parado» donde había «23 segundos». Tres veces el mismo día.
Cambiamos el portátil de habitación y se cayó el acceso remoto a nuestro agente. El Programador de tareas detiene las tareas en batería por defecto.
El índice GID de RoCE que usa NCCL puede moverse al reiniciar. El error que ves no dice nada; la causa está una línea más arriba.
Servicio activo, GPU al 96 % y ni un token. La GPU consumía 18 W: no calculaba, esperaba. Y el cliente, al reintentar, lo empeoraba.
Generábamos prompts de prueba con la misma semilla aleatoria. El corto era el principio exacto del largo, y la caché se ahorraba ese trabajo.
El chequeo de memoria de vLLM cuenta la memoria usada por procesos. Dos servicios del sistema hinchados bastaron para tumbar tres arranques seguidos.
La pantalla de login carga en el iPhone, metes la contraseña y el servidor responde «Invalid origin». En el ordenador funciona.
La lección que se repite: casi todas estas trampas nacen de fiarse de algo que dice «todo bien» —un documento, un /health, un systemctl que marca «active»—. Antes de creerte una configuración, compruébala contra lo que está funcionando de verdad.