La capacidad y el control que un stack de IA privada entrega en operación
Cuando un stack de IA privada entra en operación, sus ganancias se reducen a dos propiedades que un evaluador puede inspeccionar: la capacidad, como cómputo propio delimitado por pisos y techos medidos y contrastado con precios de tokens por consumo; y el control, como gobernanza sobre los datos, los modelos, la configuración y los cambios. Ninguna depende del calendario de un proveedor. Ambas aparecen en la operación, con una cadencia regular, en evidencia que la propia organización genera.
El argumento de la etapa de decisión a favor de una IA privada y local, planteado en el lenguaje de la custodia y del riesgo, se trata en lo que ganan las organizaciones cuando la IA opera dentro de su red. Este artículo baja un nivel. El stack está dimensionado, el hardware está desplegado y el equipo de operación ha tomado el relevo. En la operación, lo que la organización ha ganado se reduce a dos propiedades: capacidad y control. La capacidad es lo que el sistema puede hacer por el negocio, delimitado por el cómputo físico que la organización posee. El control es quién decide qué hace el sistema después. Ambas se pueden inspeccionar con una cadencia regular. Ninguna depende del calendario de un proveedor.
La capacidad es lo que el sistema puede hacer por el negocio. El control es quién decide qué hace el sistema después.
La capacidad es cómputo propio, no una asignación
Un servicio de IA tarificado por consumo otorga la capacidad como una asignación. Cuotas, límites de tasa, disponibilidad regional y condiciones que pueden cambiar en la renovación fijan el techo, y el proveedor puede mover ese techo sin consultar al cliente. Un stack propio también tiene techo, pero es físico, se midió antes de la compra, y la organización fija su punto de operación contra él.
La metodología para establecer ese techo se describe en el dimensionamiento de una configuración GPU on-premises frente a la carga de trabajo real: reproducir la carga de trabajo real, medir los presupuestos de latencia, rendimiento y memoria, y leer de la ejecución un piso y un techo. Lo que importa aquí es en qué se convierten esos dos números en la operación. El piso es la configuración más pequeña que cumple el objetivo de nivel de servicio. El techo es el punto a partir del cual más hardware no compra nada. Entre ambos, la organización posee una envolvente de capacidad que ningún proveedor puede reducir en la renovación.
La envolvente se mantiene a través de los regímenes de trabajo que definen la carga corporativa. Las cargas reguladas no son tráfico de internet en estado estable. Tienen picos alrededor del cierre de trimestre, los plazos de presentación y las horas pico del horario laboral, y esos picos se conocen de antemano porque siguen el calendario del negocio. Una capacidad dimensionada al pico medido atiende el ciclo completo. La capacidad aparentemente ociosa en los valles no es desperdicio. Es margen para un pico que la organización ya puede nombrar y fechar.
La objeción estándar es la elasticidad: la capacidad alquilada crece bajo demanda y la propia no. La elasticidad tiene un precio calibrado para cargas que nadie puede predecir. Una carga corporativa de IA depende de la cantidad de personal, del volumen de los procesos y del calendario del negocio, y los tres son predecibles dentro de la organización. Cuando la carga realmente crece más allá de la envolvente, la ampliación es un ejercicio de dimensionamiento con un método conocido, ejecutado en el mismo entorno de reproducción de la carga, y el hardware existente sigue atendiendo la producción mientras corre la evaluación.
La economía marginal apunta entonces en la dirección correcta. En un servicio tarificado por consumo, el crecimiento del uso eleva el gasto, porque cada solicitud lleva un precio fijado por el proveedor. En hardware propio, la inferencia adicional tiende al costo de la electricidad y de la operación, así que una adopción creciente mejora el retorno del capital que la organización ya comprometió. La presión por la utilización también se invierte. Un entorno tarificado desalienta sutilmente saturar el cómputo alquilado. Un stack propio premia empujar hacia el techo medido, porque el margen por encima del techo se identificó como innecesario antes de la compra y nunca se compró.
La factura de tokens frente a la factura del hardware
El argumento de economía marginal anterior puede concretarse con números. Dos configuraciones iniciales ilustran el rango. Una es un clúster de dos o tres máquinas NVIDIA DGX Spark, hardware de escritorio que agrupa su memoria a través de los enlaces de clustering de NVIDIA. La otra es un único servidor con tres tarjetas NVIDIA RTX Pro 6000, el formato que una empresa pequeña monta una sola vez en el rack y al que luego crece. Las tablas siguientes indican qué cuesta cada configuración y qué genera en un mes. Luego contrastan ese volumen mensual con los precios de lista de las APIs en la nube y muestran cuándo el hardware se paga solo con el gasto evitado. Una tabla final mantiene constante el presupuesto anual en la nube de la organización y pregunta qué compra ese dinero en tokens o en hardware.
Qué cuesta el hardware y qué entrega
| Configuración | Inversión estimada | Velocidad de generación | Ventana de contexto |
|---|---|---|---|
| 2x NVIDIA DGX Spark | USD 13.000 | ~170 tok/s | ~800 mil tokens |
| 3x NVIDIA DGX Spark | USD 19.500 | ~220 tok/s | ~1 millón de tokens |
| Servidor con 3x RTX Pro 6000 | USD 52.000 | ~470 tok/s | ~1 millón de tokens |
Las cifras de velocidad y de contexto son estimaciones para uso concurrente y sostenido de un equipo. Como referencia, los niveles tarificados de las APIs en la nube de vanguardia aceptan aproximadamente un millón de tokens de contexto. Una licencia de suscripción en la nube entrega en el uso diario una ventana del orden de 200 mil tokens, así que las ventanas de la tabla son de cuatro a cinco veces más anchas.
Velocidad con una ventana amplia
Las configuraciones sostienen aproximadamente de 170 a 470 tokens por segundo en uso concurrente de un equipo, con ventanas de contexto de 800 mil a un millón de tokens. Eso es unas cuatro a cinco veces la ventana que una licencia de equipo en la nube entrega en la práctica.
Qué cuestan los mismos tokens en las APIs en la nube
| Proveedor | Nivel | Modelo | Entrada USD/1M | Salida USD/1M |
|---|---|---|---|---|
| Anthropic | Insignia | Claude Fable 5.1 | USD 10 | USD 50 |
| Anthropic | Medio-alto | Claude Opus 5.5 | USD 4 | USD 20 |
| Anthropic | Medio | Claude Sonnet 5 | USD 2 | USD 10 |
| Anthropic | Compacto | Claude Haiku 4.5 | USD 1 | USD 5 |
| OpenAI | Insignia | gpt-6-astra | USD 10 | USD 50 |
| OpenAI | Medio-alto | gpt-5.6-sol (promo, garantizado hasta el 21 de noviembre de 2026) | USD 4 | USD 20 |
| OpenAI | Medio | gpt-6-sol | USD 2 | USD 10 |
Con una combinación típica de cinco tokens de entrada por cada token de salida, los precios de lista anteriores se promedian en unos USD 20 por millón de tokens de salida en el nivel medio, unos USD 40 en el nivel medio-alto y unos USD 100 en el nivel insignia. Ambos proveedores reducen a la mitad sus precios de lista en las APIs de procesamiento por lotes para trabajos tolerantes a la latencia.
Hay tres formas de comprar tokens: licencias de suscripción, la API tarificada con los precios anteriores y hardware propio. A septiembre de 2026, una licencia cuesta de USD 20 a 25 al mes, y alrededor de USD 100 en los niveles premium. En el uso diario, una licencia entrega una ventana del orden de 200 mil tokens en un grifo que se restablece cada 5 horas y se cierra de nuevo cada semana. El hardware propio no tiene grifo. Sus ventanas van de 800 mil a un millón, y el único techo es el rendimiento.
Un presupuesto o un techo
Una licencia de suscripción en la nube, de USD 20 a 25 al mes y alrededor de USD 100 en los niveles premium, compra una ventana del orden de 200 mil tokens en un grifo que se restablece cada 5 horas y se cierra cada semana. Las ventanas autohospedadas van de 800 mil a un millón, sin presupuesto semanal y limitadas solo por el rendimiento, y diez licencias premium a USD 100 cuestan USD 12.000 al año, aproximadamente lo que cuesta una sola vez el clúster inicial completo de dos máquinas.
Qué produce el hardware en un mes
La tabla siguiente indica la producción mensual de cada configuración en régimen de horario laboral, y cuánto costaría ese volumen en las APIs en la nube a los tres anclajes promediados.
| Configuración | Tokens de salida al mes | Nivel medio | Nivel medio-alto | Nivel insignia |
|---|---|---|---|---|
| 2x NVIDIA DGX Spark | unos 135 millones | unos USD 2.700 | unos USD 5.400 | unos USD 13.500 |
| 3x NVIDIA DGX Spark | unos 175 millones | unos USD 3.500 | unos USD 7.000 | unos USD 17.400 |
| Servidor con 3x RTX Pro 6000 | unos 370 millones | unos USD 7.400 | unos USD 14.900 | unos USD 37.200 |
Régimen de horario laboral significa aquí diez horas al día en días hábiles, aproximadamente 22 días al mes. Operando de forma continua, el mismo hardware genera aproximadamente tres veces más: unos 440 millones, 570 millones y 1.200 millones de tokens de salida al mes.
Cuándo se amortiza el hardware
Meses hasta que cada configuración recupera su inversión con el gasto evitado en tokens, en régimen de horario laboral:
| Configuración | Nivel medio | Nivel medio-alto | Nivel insignia |
|---|---|---|---|
| 2x NVIDIA DGX Spark | 4,8 | 2,4 | 1,0 |
| 3x NVIDIA DGX Spark | 5,6 | 2,8 | 1,1 |
| Servidor con 3x RTX Pro 6000 | 7,0 | 3,5 | 1,4 |
Incluso con precios de nivel medio, cada configuración se paga en siete meses o menos. Contra precios insignia, el par de Spark se recupera en cerca de un mes y el servidor en unas seis semanas. La electricidad está incluida en la recuperación y desplaza cada cifra en menos de una décima de mes. El régimen continuo acorta cada recuperación aproximadamente al triple: quedan en 0,3 a 1,5 meses para el par de Spark, en 0,3 a 1,7 para el clúster de tres unidades y en 0,4 a 2,2 para el servidor.
El medidor se detiene
El clúster inicial de dos máquinas se amortiza en unos cinco meses a precios de tokens de nivel medio, y el servidor de tres tarjetas en unos siete. Después de eso, la inferencia tiende al costo de la electricidad.
Qué compra el mismo presupuesto anual con 15, 50 y 100 usuarios
Tome el gasto anual en la nube de la organización como una constante y pregunte qué compra ese dinero en cada caso: tokens de una API, o hardware capaz de generarlos. La tabla siguiente ejecuta esa comparación con 15, 50 y 100 usuarios.
Se asume que cada usuario genera 25.000 tokens de salida por día hábil en régimen de horario laboral, una carga completa de asistente agéntico. Cada tamaño se asigna al nivel que cubre su demanda con margen duradero: el par de Spark con 15 usuarios, el clúster de tres Spark con 50, el servidor RTX Pro con 100. Las asignaciones dejan margen a propósito, con una utilización promedio de entre el 6 % y el 16 %. La comparación cuenta lo que el hardware puede generar, no lo que la carga de trabajo exige.
La columna del primer año compara la capacidad anual de tokens del hardware en régimen de horario laboral contra los tokens que el mismo presupuesto compra en una API. Ese múltiplo se mantiene en cada ancla de precios, porque el presupuesto es, por definición, el precio de los tokens demandados. La columna de tres años compara los tokens por dólar en ambos lados: lo que el hardware genera por dólar de precio de compra más electricidad, y lo que la API devuelve por dólar de gasto.
| Usuarios | Costo anual en la nube: medio / medio-alto / insignia | Costo del hardware / tokens al año | Capacidad por el mismo dinero, año 1 | Tokens por dólar en 3 años: medio / insignia |
|---|---|---|---|---|
| 15 | USD 1.980 / USD 3.960 / USD 9.900 | USD 13.000 - unos 1.620 millones de tokens al año | 16,3 veces | 7,3 veces / 36,6 veces |
| 50 | USD 6.600 / USD 13.200 / USD 33.000 | USD 19.500 - unos 2.090 millones de tokens al año | 6,3 veces | 6,3 veces / 31,6 veces |
| 100 | USD 13.200 / USD 26.400 / USD 66.000 | USD 52.250 (estimación) - unos 4.470 millones de tokens al año | 6,8 veces | 5,0 veces / 25,2 veces |
La fila de 50 usuarios lleva el resultado más simple. En el ancla media, tres años de gasto en la nube suman USD 19.800, y el clúster de tres Spark cuesta USD 19.856 en el mismo periodo, precio de compra más electricidad. Es el mismo dinero dentro del 0,3 %, y el clúster puede generar 6,3 veces los tokens.
El ancla media también contiene las brechas honestas del primer año. El presupuesto de USD 1.980 para 15 usuarios y el de USD 6.600 para 50 no alcanzan para ninguna de las tres configuraciones en el primer año. Comprar el hardware asignado por completo requiere USD 11.020 adicionales con 15 usuarios y USD 12.900 adicionales con 50. Con 100 usuarios, el presupuesto de nivel medio de USD 13.200 cubre solo la configuración más pequeña. El servidor al que corresponde esa fila requiere USD 39.050 adicionales.
En el ancla insignia, los presupuestos de 50 y 100 usuarios compran el hardware por completo en el primer año, con USD 13.500 y USD 13.750 sin gastar. El presupuesto insignia de 15 usuarios queda USD 3.100 por debajo del par de Spark en el primer año. El ancla medio-alto cae entre las dos columnas: 14,6, 12,6 y 10,1 veces a tres años. Los múltiplos de tres años no dependen del supuesto por usuario. Se mantienen en cualquier perfil de carga de trabajo, más ligero o más pesado.
Capacidad que crece con usted
Medido contra el mismo presupuesto anual en la nube, el hardware puede generar de 6,3 a 16,3 veces los tokens en el primer año. A tres años devuelve de 5 a 36,6 veces los tokens por dólar, en cualquier perfil de carga de trabajo.
Las advertencias que acompañan a estas cifras
Todos los precios son cifras de terceros en USD, capturadas al momento de la redacción. Los precios de lista y las promociones en la nube cambian, y los precios del hardware varían según el vendedor y la región. Las cifras de velocidad, capacidad y recuperación son agregados estimados para planificación, no una oferta ni una cotización de sistemas entregados. Repita la aritmética contra la carga de trabajo real antes de comprometerse con cualquiera de las dos partes.
El control son cuatro capas gobernables
En el material de los proveedores, «control» es una palabra más vaga de lo que el concepto merece. En la operación se reduce a cuatro capas que una organización gobierna o no gobierna.
Datos
La gobernanza de datos empieza por la ubicación. La inferencia opera dentro de la red, así que las preguntas sobre qué sistemas procesaron una consulta tienen una sola respuesta, y es local. No hay telemetría del proveedor sobre el contenido de las consultas, porque no hay proveedor de por medio. La retención sigue los calendarios de la propia organización. La pista de auditoría se genera en el punto de trabajo, bajo controles de acceso que la organización ya opera, y eso mantiene los libros financieros reportables y reconstruibles bajo demanda. Para las plataformas de tecnología, los datos de los inquilinos y la propiedad intelectual del código fuente quedan bajo los mismos controles de separación que la plataforma ya debe a cada contrato de cliente.
Modelos
La gobernanza de modelos significa que la organización decide qué versión del modelo sirve la producción. Los proveedores hospedados descontinúan modelos según sus propios calendarios y pueden cambiar el comportamiento detrás de un nombre de punto de conexión estable, lo que convierte la fijación de versiones en una esperanza de nivel de servicio. En un stack propio, la versión que sirve en producción queda fijada de forma explícita. Las actualizaciones ocurren en el calendario de la organización, después de que el reemplazo se haya evaluado contra los datos de referencia propios y no contra una prueba pública de rendimiento. El hardware no se mueve durante el cambio: los mejores modelos llegan como software y corren en las mismas máquinas. Los modelos de pesos abiertos con licencias comerciales flexibles mantienen amplio el conjunto de opciones, y la postura de licenciamiento sigue siendo de la organización.
En un stack propio, la versión en producción queda fijada de forma explícita. Las actualizaciones ocurren en el calendario de la organización.
Configuración
La gobernanza de la configuración cubre todo lo que da forma al comportamiento en tiempo de ejecución: parámetros de muestreo, reglas de enrutamiento, barreras de seguridad, fuentes de recuperación y prompts. En un stack privado son artefactos versionados bajo el control de cambios de la organización. Una salida determinada puede rastrearse hasta la configuración exacta que la produjo, y esa misma configuración puede reproducirse. En un punto de conexión hospedado, parte de la configuración pertenece al proveedor, y la reproducibilidad depende de la política de versiones del proveedor y no del cliente.
Cambios
La gobernanza de cambios es la capa que decide cuándo se mueve cualquiera de las capas anteriores. En un stack privado, los lanzamientos pasan por las puertas de aprobación y los turnos de guardia de la propia organización, los mismos que ya atraviesa cualquier otro sistema en producción. Ningún proveedor puede retirar un punto de conexión por debajo de un flujo de trabajo en marcha. El trabajo de migración ocurre porque la organización lo programó, no porque llegó un aviso de descontinuación.
Las dos propiedades se refuerzan entre sí
El control hace legible la capacidad. Como las versiones y la configuración quedan fijadas, las mediciones de rendimiento y de latencia significan lo mismo trimestre tras trimestre, y la telemetría que lo demuestra pertenece a la organización y no a un tablero de proveedor. La disciplina de medición es la que se expone en las métricas que hacen defendible una inversión en IA tras la puesta en producción: precisión, tiempo de ciclo, costos evitados y adopción, leídos contra la línea base tomada antes de la construcción.
La capacidad hace accesible el control. Evaluar un modelo nuevo, una barrera de seguridad modificada o un flujo de trabajo ampliado ocurre en el mismo hardware propio, contra la carga de trabajo real y sin un medidor corriendo sobre el experimento. Las decisiones de gobernanza descansan, por lo tanto, en evidencia medida que la organización produjo ella misma.
La prueba para cualquier arquitectura candidata
Para un evaluador técnico, la distinción se condensa en dos verificaciones. Primero, pregunte quién fija el techo: ¿el rendimiento máximo es una propiedad medida del hardware que la organización posee, o una asignación que un proveedor puede redimensionar? Segundo, pregunte quién firma el cambio: ¿las decisiones de modelo, configuración y lanzamiento pasan por las puertas de la organización, o por las de un proveedor? En un stack privado, ambas respuestas quedan del lado de la organización. La capacidad y el control dejan de ser argumentos de adquisición. Se convierten en propiedades operativas, inspeccionadas en cada ciclo de revisión, sobre evidencia que el propio stack produce.
Pregunte quién fija el techo, y qué cambios en la IA impulsan a su empresa hacia el futuro.