VPS vs VDS para inferencia de IA en el edge: cómo elegir el nivel de cómputo adecuado para modelos con baja latencia

Desplegar un modelo cuantizado de 8B parámetros en el edge parece sencillo hasta que tu latencia P99 supera los 200 ms en un pico de carga que tú no provocaste. El culpable rara vez es el modelo, el framework de inferencia o la ruta de red. Casi siempre es el nivel de cómputo subyacente, y la distinción entre un VPS y un VDS es exactamente donde vive ese problema.

A medida que los equipos despliegan modelos de pesos abiertos como Meta Llama 3.1 8B Instruct, Qwen3-8B y GLM-4-9B en nodos edge para inferencia en tiempo real, la decisión entre VPS y VDS deja de ser una partida presupuestaria y se convierte en una decisión de arquitectura genuina. La respuesta equivocada no solo cuesta dinero: rompe los SLA de latencia de maneras que son realmente difíciles de diagnosticar.

Este artículo explica el mecanismo, te da los números con los que razonar y te indica dónde está la frontera entre los niveles que pueden mantener un objetivo de latencia y los que no.

Qué significan realmente VPS y VDS (definiendo los términos)

El marketing de los proveedores ha convertido estos términos en casi intercambiables, así que conviene ser precisos. En un VPS, varias máquinas virtuales comparten el mismo host físico. Puedes recibir RAM dedicada y una cuota de vCPU, pero los ciclos de CPU, las colas de I/O de almacenamiento y, con frecuencia, el ancho de banda de la NIC permanecen compartidos entre inquilinos. En un VDS, un hipervisor de virtualización completa (KVM, Xen o Hyper-V) asigna una porción fija y exclusiva del hardware a una única VM. El VDS se comporta como un servidor físico: ninguna carga de trabajo de otro inquilino toca su planificador de CPU, su bus de memoria ni su cola de almacenamiento.

Esa distinción importa enormemente para la inferencia, y aquí está la razón.

CPU steal time: el asesino silencioso de la latencia

El mecanismo técnico detrás de la varianza de latencia en un VPS tiene nombre: CPU steal time. Es el tiempo de reloj que tu VM pasa esperando la CPU física mientras el hipervisor atiende a otra VM. En un entorno tranquilo, el steal time es insignificante. Cuando un vecino ejecuta un trabajo de backup, absorbe un pico de tráfico o simplemente tiene un cron ruidoso, el steal time sube rápido.

Una regla práctica que vale la pena interiorizar: un steal time sostenido por encima del 10 % aproximadamente es señal de contención en el host. Para un proceso de model serving donde un único forward pass puede tardar entre 30 y 80 ms, añadir entre un 10 y un 20 % de espera impredecible encima de eso es la diferencia entre cumplir o incumplir un objetivo de 100 ms en tiempo real.

La contención de almacenamiento agrava el problema específicamente en cargas de inferencia. Los pesos de los modelos son grandes. Un modelo cuantizado de 8B en precisión de 8 bits ocupa aproximadamente 8 GB en disco. En un VPS respaldado por un pool de NVMe compartido o un volumen SAN, la latencia de cargar esos pesos al inicio, o al reiniciar el contenedor tras un fallo, está sujeta a la misma contención de cola de I/O que el steal time de CPU. Los cold starts en instancias GPU ya tardan entre 60 y 180 segundos para cargar el modelo en condiciones ideales; la presión sobre el almacenamiento compartido lo empeora y lo hace menos predecible.

El overselling de los proveedores amplifica ambos efectos. Los materiales de marketing prometen recursos garantizados, y esa promesa solo se cumple cuando el host no está sobrevendido. Cuando la demanda es alta en toda la máquina física, todos los inquilinos lo sienten simultáneamente, y no existe ningún mecanismo en un VPS estándar que proteja tu VM del efecto agregado.

Qué requiere realmente la inferencia de IA en el edge

Los requisitos de latencia para la inferencia en el edge varían según la aplicación, pero los objetivos publicados son ilustrativos. La visión por computadora en tiempo real para aplicaciones de AR/VR requiere una latencia extremo a extremo inferior a 100 ms. La asignación de recursos de radio mediante inferencia de deep learning debe completarse dentro del tiempo de coherencia del canal, que puede ser tan corto como 10 ms. La inferencia en dispositivo en hardware móvil moderno ha cruzado el umbral de los 20 ms para modelos de visión por computadora en producción. Los modelos adaptados con LoRA en configuraciones edge optimizadas han demostrado latencias de inferencia en torno a los 45 ms.

Incluso en el extremo más relajado de ese rango, los números son ajustados. Si el forward pass de tu modelo tarda 40 ms en un host limpio, un VPS bajo contención que añade entre 15 y 25 ms de steal y jitter de I/O te lleva más allá de un presupuesto de 60 ms antes de contar siquiera el tránsito de red. Un VDS, sin fuente de contención, mantiene los 40 ms de línea base de forma consistente.

El argumento de que la inferencia en el edge es más rápida que un round-trip a la nube (en términos direccionales, P99 en el edge por debajo de 100 ms frente a entre 300 y 800 ms de round-trip en la nube) solo se sostiene cuando el cómputo edge en sí no introduce la varianza. Un nodo edge mal aprovisionado no es más rápido que un endpoint cloud bien aprovisionado; simplemente es lento de otra manera y más difícil de depurar.

Cuándo el VPS sigue siendo la respuesta correcta

No toda carga de inferencia necesita un VDS. Un VPS es adecuado cuando:

• El modelo es pequeño y está cuantizado hasta el punto en que un forward pass se completa en menos de 10 ms, dejando margen suficiente para absorber la varianza del steal.
• El caso de uso tolera una latencia P99 de entre 200 y 500 ms, como el procesamiento asíncrono de documentos o la clasificación por lotes.
• El tráfico es muy predecible y el host tiene poca carga, lo que significa que el steal time se mantiene consistentemente bajo.
• El despliegue es exploratorio y se prioriza el coste mientras se valida la arquitectura del modelo antes de comprometerse con producción.

El problema es que los equipos suelen empezar en un VPS por razones de coste y descubren el problema de contención solo cuando ya están en producción, momento en el que la migración es urgente en lugar de planificada.

Cuándo el VDS se vuelve innegociable

Pasa a un VDS cuando la carga de trabajo tiene alguna de las siguientes características:

• SLA de latencia estrictos. Si el contrato del producto especifica un tiempo de respuesta, la varianza por recursos compartidos es un riesgo no controlado. Un VDS elimina la variable de contención.
• Modelos de entre 7B y 9B parámetros con serving en tiempo real. Modelos como Llama 3.1 8B Instruct, incluso tras la cuantización a 8 bits, consumen suficiente cómputo por token como para que el steal time no se absorba con capacidad de sobra; se acumula sobre el tiempo de inferencia.
• Inferencia GPU en el edge. La planificación de GPU en un entorno compartido introduce una segunda superficie de contención más allá de la CPU. La asignación dedicada de GPU es la única forma de mantener una tasa de tokens por segundo consistente bajo carga de solicitudes concurrentes.
• Frameworks como llama.cpp o MLC-LLM en modo híbrido CPU/GPU. Estos frameworks están diseñados para extraer el máximo rendimiento del hardware disponible. Se benefician de los recursos dedicados porque están escritos para usar todo lo disponible; la contención de otros inquilinos limita directamente su techo.
• Serving con estado y cachés de modelo en caliente. Mantener los pesos residentes en memoria para evitar cold starts requiere que esa memoria esté genuinamente reservada. En un VPS, la presión de memoria de los vecinos puede forzar su desalojo incluso cuando tu asignación parece suficiente sobre el papel.

Cómo hacer benchmarking de tu nivel real antes de comprometerte

No te fíes de la etiqueta del proveedor. Antes de desplegar una carga de inferencia en producción, mide el steal time bajo carga sintética usando el campo %st en top o vmstat. Ejecuta tu secuencia de carga del modelo y registra el tiempo de reloj para la carga de pesos, no solo el tiempo del forward pass. Mide la latencia P50, P95 y P99 bajo carga de solicitudes concurrentes, no el rendimiento en hilo único. Un número de rendimiento agregado oculta la distribución que determina realmente si cumples o incumples un SLA de latencia.

Ejecutamos cargas de inferencia y entrenamiento GPU en nuestra infraestructura europea y el patrón es consistente: los equipos que hacen benchmarking de su nivel antes de comprometerse con una arquitectura de serving detectan el problema de contención en staging, no en producción. La pregunta entre VPS y VDS se puede responder con unas pocas horas de medición; nunca debería descubrirse por una queja de un cliente.

La conclusión de arquitectura

Para inferencia de IA en el edge con modelos de pesos abiertos de entre 7B y 9B parámetros, sirviendo tráfico en tiempo real contra un SLA de latencia, un VDS no es una opción premium; es el nivel mínimo de cómputo viable. El VPS ahorra dinero hasta el primer incidente en producción, momento en el que el coste del diagnóstico, la migración y el impacto en el cliente supera cualquier ahorro. La mejor decisión es dimensionar correctamente el nivel desde el principio, medir la distribución de latencia real en staging y tratar el nivel de cómputo como parte de la arquitectura de inferencia, no como un detalle de aprovisionamiento que se decide al final.