FinOps IA: control costes GPU multi-cloud
La inferencia consume el presupuesto de IA. Tres tablas de precios, cuatro clases de carga de trabajo y una reserva deslizante que sustituye a los…
Una H100 hora cuesta en AWS alrededor de 12 dólares estadounidenses, en Google alrededor de 11, y en Lambda Labs menos de 4. Quien compra inferencia en un hyperscaler y debe explicar en el próximo cierre del cuarto por qué la cuenta de GPU está 40 por ciento por encima del plan, rara vez tiene un problema de modelo. Tiene un problema de presupuesto que se originó en la arquitectura de diseño.
Lo más importante en resumen
- Inferencia no es el primo de entrenamiento: Los ciclos de entrenamiento son cargas de trabajo de lotes planificables, la inferencia es una carga constante a lo largo del tiempo. Quien presupuesta ambos con la misma lógica de capacidad reservada, paga o bien espacio vacío o tarifas de demanda. La separación de las dos categorías de costos debe estar presente en cada tabla de FinOps desde el primer día.
- Multi-nube es un balance de precios, no un objetivo en sí: Entre la hora de GPU de hyperscaler y la hora de neocloud hay un factor de 2 a 3. Quien separa las cargas de trabajo por tolerancia a la latencia, residencia de datos y clase de cumplimiento puede retirar las cargas de costo sensibles de la hyperscaler.
- Economía de unidad batea la planificación de capacidad: Costos por 1.000 tokens, por solicitud o por usuario activo son la única unidad de control que lleva en la dirección de la dirección. Sin esta métrica, cualquier discusión sobre GPU se reduce a un debate sobre la renta de servidores.
RelacionadoLa cuenta de inferencia que nadie ha presupuesto / 38 por ciento menos costos de nube en la fabricación de maquinaria
Dónde el presupuesto se quema en realidad
Tres ítems llenan cada cuenta de GPU que he visto en los últimos meses. Primero: tiempo de inactividad en hardware reservado. Quien ha reservado una instancia H100 por 730 horas al mes y solo ha utilizado 220 horas realmente, está pagando 510 horas de inactividad. Segundo: salidas de demanda en picos de demanda, ya que la capacidad reservada no se puede escalar. Tercero: costos de salida entre regiones, cuando se mueven pesos del modelo de un lugar a otro.
Ninguno de los tres ítems está visible en el modelo. Se originan en la arquitectura. Quien escala la inferencia como un servicio web, ajustando pods arriba y abajo en Kubernetes, obtiene los primeros dos ítems. Quien viaja multi-región por latencia, sin almacenar los pesos del modelo regionalmente, obtiene el tercero.
El duro aprendizaje: la inferencia tiene una curva de carga que no se puede derivar del ciclo de entrenamiento. Se basa en el comportamiento del usuario, en la hora del día, en ondas de marketing. Planificación de capacidad sin datos de curvas de carga es un juego de la suerte con tarifas triple por hora.
Tres tableros de precios que cada tabla FinOps necesita
Quien quiere controlar la inferencia multi-cloud necesita tres tableros de precios en paralelo. A Q2 de 2026, todos los precios como referencia, verificar la situación de negociación por cuenta es obligatorio.
Comparación de horas de GPU H100 80GB
- AWS p5.48xlarge (On-Demand): alrededor de 12 USD / hora, 3 años reservado alrededor de 5,50 USD
- Google A3 High (On-Demand): alrededor de 11 USD / hora, Descuento de Uso Commitido alrededor de 6 USD
- Azure ND H100 v5 (On-Demand): alrededor de 10,50 USD / hora, Reservado alrededor de 5,20 USD
- Lambda Labs / Crusoe / Together (Neocloud): 2,80 a 4,20 USD / hora, facturación más minuciosa a nivel de minuto
- OVH / Scaleway / Hetzner (Europa-Cloud): 3,50 a 5 USD / hora, cobertura de región más limitada
La gama nominal de factor 3 entre el precio on-demand de los hiperescaladores y el neocloud no es el final. Los hiperescaladores agrupan red, almacenamiento e identidad, lo que reduce la diferencia efectiva. Los neoclouds requieren que la identidad, el monitoreo y la conexión VPC se construyan usted mismo. Si se cuenta con esto, la diferencia real está entre el factor 1,8 y el factor 2,4.
Ordenamiento de cargas de trabajo como herramienta FinOps
No todas las cargas de trabajo de inferencia deben estar en el mismo stack. En la práctica, un ordenamiento en cuatro clases es suficiente para abordar entre el 30 y el 50 por ciento de los costos.
Necesario hiperescalador
- Cargas de trabajo con requisitos de latencia sub-100ms y un almacenamiento de datos SaaS estrecho
- Obligaciones de residencia de datos y C5/ISO certificación sin auditoría propia
- Integración profunda en la federación de identidades y la pila de observabilidad
- Cargas de trabajo de cumplimiento con obligación de auditoría BSI
Neocloud útil
- Inferencia por lotes con tolerancia de latencia de más de 500ms
- Ejecuciones de entrenamiento y tareas de fine-tuning sin cláusulas de residencia de datos estrictas
- Generación de embeddings e indexación de vectores
- Cargas de trabajo de investigación interna y de prototipos
El ordenamiento funciona, cuando es obligatorio. Quien lo comunica como recomendación, obtiene la misma distribución tras tres meses, ya que los equipos toman el camino de menor resistencia. Las reglas de ordenamiento deben estar en el flujo de trabajo de despliegue, no en un documento Confluence.
Del Reserved-Block al Sliding-Reserve
La capacidad reservada clásica es la respuesta equivocada para la inferencia de GPU. Los compromisos de tres años para H100 rara vez se amortizan, ya que la generación de GPU se vuelve obsoleta en 18 meses. Mejor arquitectura: una Sliding-Reserve de 30 a 50% de capacidad reservada como base, 20 a 30% de planes de ahorro para flexibilidad, el resto On-Demand o Spot.
Cronograma: Capacidad madura en 12 meses
- Mes 1-2: Medición de curvas de carga, línea de base por carga de trabajo, modelo de costo por unidad de trabajo
- Mes 3-4: Ordenación de cargas de trabajo, primera conexión a la nube para trabajos por lotes
- Mes 5-7: Establecimiento de la Sliding-Reserve, estrategia de Spot para cargas de trabajo de entrenamiento
- Mes 8-10: Enrutamiento entre hiperescaladores para inferencia rentable
- Mes 11-12: Revisión de madurez, recalibración de la oferta reservada, comunicación abierta de precios por token
Lo que a menudo falta en el plan de madurez: un punto explícito sobre plazos de entrega. La capacidad de H100 estará en escasez en algunas regiones hasta 2026. Quien no incluye buffers en su plan para la latencia de provisionamiento, desplaza el problema a la capa de operaciones.
Economía de unidad como moneda de control
La discusión más honesta de FinOps en la dirección no se centra en horas de GPU, sino en costos por unidad de salida. Tres métricas se han probado en la práctica: costos por 1.000 tokens de salida, costos por solicitud de usuario completada, costos por usuario activo y mes. Cuál de ellas se utiliza depende del producto.
Ejemplo de configuración de un cliente: Una aplicación RAG con alrededor de 80.000 solicitudes al día se encontraba en aproximadamente 0,034 EUR por solicitud, de los cuales 0,022 EUR eran inferencia, 0,008 EUR fueron recuperación de vector, 0,004 EUR registro y observabilidad. Solo la desglose reveló que el registro representaba un 18% de crecimiento cada trimestre. La reducción se encontraba allí, no en el modelo.
Quien no reporta la economía de unidad cada mes pierde el control en dos trimestres. Luego viene el mandato de reducción de costos del departamento de finanzas, y la elección será dura: reducir el modelo, cambiar a un proveedor, eliminar características.
Arquitectura de decisiones con el mayor efecto
Tres efectos de arquitectura son promedio. Primero: enrutamiento de modelos en nivel de solicitud. No todas las solicitudes requieren el modelo superior. Un clasificador al inicio que enruta solicitudes simples a un modelo más pequeño o a inferencia de código abierto puede reducir la malla de costos entre 20 y 35%.
Segundo: almacenamiento en caché en niveles de embedding y respuesta. En casos de uso cercanos a FAQ, solicitudes recurrentes suelen estar en el 10% a 20%. Un caché semántico con TTL controlado puede ahorrar el costo del viaje completo al modelo por cada hit.
Tercero: agregación por lotes en nivel de API. Quien envia solicitudes de inferencia individualmente paga el tarifazo premium por token. Quien agrega micro-lotes con ventana de 50ms en la capa de servicio puede aumentar el rendimiento de GPU por hora en un factor 2 a 3 sin cambios en el modelo.
Estos tres factores no son espectaculares. Son parte de la rutina de ingeniería. Eso los hace planificables y repetibles.
Qué contiene el modelo de madurez FinOps
Tres indicadores muestran si un equipo está aprendiendo a manejar los costos de inferencia. Primero: La responsabilidad de FinOps está en el departamento de ingeniería, no en el de control financiero. Los que experimentan revisiones de costos como un audit externo no tienen control. Los que las manejan como una norma estándar de revisión de arquitectura sí tienen control.
Segundo: Los costos por token por característica están visibles en el product backlog. Los product managers que no entienden los costos variables que una nueva función de inteligencia artificial generará planifican a la oscuridad.
Tercero: Hay un camino probado para cambiar de modelo. Los que están 18 meses con un proveedor y no tienen un camino documentado para re-despliegue, pagan el costo del lock-in sin notarlo.
Preguntas frecuentes
Lohnt sich Multi-Cloud-Inferenz auch unter 50.000 EUR Monatsbudget?
Rara vez. El aumento del esfuerzo para la federación de identidades, el monitoreo y el enrutamiento de VPC solo justifica su costo cuando la economía supera el esfuerzo de ingeniería por cada cuartal. Bajo un presupuesto mensual de aproximadamente 50.000 EUR, el camino más práctico es usar un solo hiperescalar con un mix limpio de reservas.
¿Cómo se establece un modelo de costo unitario realista?
Con tres componentes: costo de inferencia por token a partir de los informes del proveedor, costo de infraestructura por solicitud a partir de los datos de rastreo, y costo de registro y observabilidad a partir de las etiquetas de costo asignación. Quien no aplica etiquetas de manera consistente pierde la capacidad de asignación y estima en Excel.
¿Cuál es el mayor error al cambiar a nuevos hiperescalares?
Subestimar la pila de identidad y red. Los hiperescalares proporcionan IAM, VPC-Peering y Service-Mesh como componentes integrados. Los nuevos hiperescalares requieren que estos componentes se construyan usted mismo o se conecten con herramientas de cruz-hiperescalar. Quien no planea este esfuerzo pierde la economía en los primeros tres meses.
¿A qué velocidad se amortiza la capacidad reservada de GPU para 2026?
Con una carga estable del 70% o más, generalmente en 8 a 12 meses. Con una carga del 50% o menos, la capacidad reservada no es rentable en comparación con Spot o On-Demand, ya que la generación de GPU se renovará en 18 meses.
¿Se pueden activar los costos de GPU en la balance?
En general, no en el modelo de alquiler de los hiperescalares, ya que son costos operativos. En GPU propias en colocation o On-Prem, es posible, con las reglas de amortización correspondientes. Desde el punto de vista fiscal y contable, debe coordinarse con el departamento CFO, ya que esto también implica obligaciones de informes.
Más del MBF Media Network
Fuente de la imagen: Generado por IA (Mayo 2026), C2PA-certificado en la imagen
