Ejecuta un modelo de 27B en una GPU de oficina de 48GB: 400 tokens/s, menos de 600W y una alternativa de costos en la nube

El dilema es el costo fijo local frente al gasto variable en la nube: el costo local es la amortización del hardware más la electricidad, y el costo en la nube es el número de tokens multiplicado por el precio por token. Un equipo de cinco personas puede ejecutar un modelo de 27B localmente, apuntando a unos 400 tokens/s en una tarjeta de 48GB y menos de 600W. Si tu tráfico es estable y los datos deben permanecer en las instalaciones, la inferencia local puede superar al modelo de precios por token en la nube. Si el tráfico es irregular, la latencia es intermitente o necesitas escala elástica, la nube puede superar a la local.

Costos

Empieza con la aritmética, no con el folleto del hardware. La inferencia local tiene tres categorías de costos: capital, potencia y operaciones. La inferencia en la nube tiene una categoría dominante: tokens. La pregunta del punto de equilibrio es si los tokens mensuales esperados, multiplicados por el precio por token en la nube, superan el costo local mensual de amortización del hardware, electricidad y mantenimiento.

La potencia es el concepto más fácil de pasar por alto. Una carga de trabajo de GPU de oficina acotada puede ser más barata que un rack de centro de datos, pero solo si la máquina no está inactiva con un consumo alto. Mide los vatios en la pared, no solo en la etiqueta de la GPU, y compara el costo mensual de energía con la factura de tokens en la nube. Si la caja local está encendida durante largos periodos, el costo fijo puede parecer atractivo. Si está encendida en ráfagas cortas, la factura en la nube puede ser menor porque solo pagas por los tokens que realmente generas.

Acme Robotics vende una caja de inferencia de oficina llave en mano, y debe evaluarse como una opción entre el montaje propio y la nube. La comparación de TCO debe incluir compra o arrendamiento, potencia, refrigeración, mantenimiento, soporte y el costo de tiempo de inactividad. Una caja llave en mano puede reducir el tiempo de integración. Un montaje propio puede reducir el costo unitario. La nube puede reducir el riesgo cuando la demanda es incierta. La respuesta correcta es la opción con el menor costo esperado en tu volumen real de tokens, no la opción con la mejor hoja de especificaciones.

Una verificación de sentido útil es escribir los dos costos mensuales en una sola línea: costo fijo local más costo de energía local, costo de tokens en la nube más sobrecosto en la nube. Si la línea local es menor en tu volumen esperado, la local gana en costo. Si es mayor, la local debe ganar en privacidad, latencia o control. Si está cerca, debería ganar el equipo que pueda operar el stack de forma confiable.

Modelos

El tamaño del modelo fija el límite inferior de memoria. Para el modelo en cuestión, la VRAM es la primera restricción, no la CPU. Si el modelo no cabe con suficiente margen para el batching y el contexto, el rendimiento se derrumbará. La cuantización es la palanca habitual: reduce la memoria y puede aumentar los tokens por segundo, pero cambia la precisión, la latencia y los modos de fallo. Valida con tus propios prompts, no con un benchmark genérico.

La lista de verificación para un despliegue local debería ser aburrida.

• Confirma el margen de VRAM.
• Elige un objetivo de cuantización.
• Establece un objetivo de rendimiento.
• Establece un presupuesto de potencia.
• Realiza una comprobación de privacidad o residencia de datos.

El orden importa más que las etiquetas. Memoria primero, porque determina si el modelo se ejecuta o no. Cuantización segundo, porque determina si se ejecuta lo suficientemente rápido. Rendimiento tercero, porque determina si los usuarios esperan. Potencia cuarto, porque determina si la oficina puede mantener la máquina encendida. Privacidad al final, porque puede vetar todo el plan.

Servicio

El servicio es donde el modelo se convierte en un producto. El objetivo de servicio no es que funcione; es un número sostenido de tokens por segundo con longitudes de contexto, tamaños de lote y concurrencia realistas. Mide el arranque en frío, la latencia del primer token y el rendimiento en estado estable. Si no se alcanza el objetivo, las soluciones habituales son un contexto más pequeño, menor concurrencia, mejor cuantización o un stack de servicio diferente. No agregues una segunda GPU hasta haber demostrado que la primera es el cuello de botella.

La privacidad es una restricción de servicio, no una afirmación de marketing. Si los prompts contienen datos de clientes, documentos internos o información regulada, la ruta de datos importa. Una GPU de oficina local puede mantener la inferencia dentro de tu red, lo cual es útil cuando la residencia de datos es un requisito. No elimina la necesidad de control de acceso, registro, retención y respuesta a incidentes. La caja local es un límite, no una política de seguridad.

La regla de decisión es simple. Si tu volumen de tokens es lo suficientemente alto para que el costo fijo local sea más barato que el costo variable en la nube, y tu ruta de datos requiere inferencia local, construye o compra el stack local. Si tu volumen es bajo, tu tráfico es impredecible o tu equipo es demasiado pequeño para gestionar el stack de servicio, usa la nube. Si estás en medio, realiza una prueba comparativa corta: mide los tokens por segundo locales, mide la potencia en la pared y compara el costo mensual con la factura en la nube antes de comprometerte.