Enfoque de precios
Esta página detalla los principios de precios de la implementación: metodología, nunca una lista de precios - sin cifras económicas sin respaldo, sin alzas proyectadas sin evidencia y sin porcentajes que hagan de precio. Los tres pilares son la metodología de ROI y plazo de retorno, la comparación entre la nube y su red, y la guía de dimensionamiento de GPU para su infraestructura privada.
Los tres métodos
Cada una de las tres tablas siguientes recoge únicamente metodología. Los números corresponden a rangos de dimensionamiento, multiplicadores, bandas de confianza y ciclos de retorno - la dimensión frente a la que se evalúa cada punto de control o decisión, nunca un precio. Lea cada tabla en el orden en que aparece. Primero, la metodología de ROI y de período de retorno que rige las entregas por fases. Después, la comparación entre la nube y la infraestructura dentro de su red exigida por el modelo de residencia. Por último, la guía de dimensionamiento de GPU que establece la infraestructura dentro de su red.
Metodología de ROI y período de retorno
Cuatro dimensiones de método - cada puerta de fase medida contra la línea base de Evaluación.
| Dimensión de puerta | Lo que mide | Cómo se compara con la línea base de la Evaluación |
|---|---|---|
| Retorno esperado | El multiplicador de retorno medido del artefacto producido en cada fase - la ganancia de throughput, de ciclo o de costo evitado - referido a la unidad de Evaluación documentada antes de escribir una sola línea de código. | Artefacto por fase medido contra la línea base de 1.0× fijada en la Evaluación. El capital solo se vuelve a comprometer cuando el artefacto supera la banda proyectada para esa puerta. |
| Rango de confianza | Banda de mínimo a máximo informada en torno al múltiplo de retorno esperado, más amplia en las puertas alejadas de producción y más estrecha conforme se acumula la evidencia dentro de su red. | Banda inicial de 0.40 a 0.60 en la primera fase con puerta. Se estrecha en cada puerta conforme el prototipo validado reemplaza los supuestos de la planificación. |
| Puerta Go/No-Go | Decisión tomada en la transición entre fases, sobre el artefacto que cada fase produce - avanzar, replantear o retirar - y nunca sobre un flujo de trabajo abierto. | La puerta solo se abre cuando el retorno medido del artefacto supera su banda. La fase que no supera su puerta se retira y no se traslada a un trimestre posterior. |
| Frecuencia de revaluación | Cada iniciativa activa se vuelve a medir contra la línea base vigente de la Evaluación, al ritmo de informes establecido para la entrega, de modo que la desviación reajusta las condiciones antes de la entrega en producción. | Se activa ante una desviación de la línea base de 0.10× o más respecto al informe anterior, y en cada transición de fase, con independencia de la desviación. |
Nube frente a infraestructura dentro de su red
Cinco dimensiones de compra - control, residencia, latencia, rendimiento, operaciones.
| Dimensión | Inquilino de nube genérico | Infraestructura dentro de su red |
|---|---|---|
| Modelo de control | Límite de responsabilidad compartida. El proveedor actualiza componentes y retira funciones a su propio ritmo. | Límite bajo control del operador. La entrega instala, actualiza y da de baja los componentes dentro de la red del cliente. |
| Residencia de los datos | La ruta de solicitud y respuesta atraviesa la región del proveedor de forma predeterminada. | La ruta de solicitud y respuesta permanece dentro de la jurisdicción elegida por el cliente. Ninguna llamada de inferencia sale de su red. |
| Latencia de ida y vuelta | Salto WAN medido en decenas o del orden de cien a doscientos milisegundos frente a la región del proveedor. | Salto LAN de pocos milisegundos con la inferencia dentro de su red. |
| Techo de throughput | Limitado por la cuota del inquilino en la nube y degradado por los vecinos ruidosos que comparten la flota del proveedor. | Dimensionado a la concurrencia validada por la entrega. Sin contención por vecinos dentro de la infraestructura del cliente. |
| Telemetría operacional | Actualizaciones gestionadas por el proveedor y flujos opacos de telemetría enviados al proveedor. | Actualizaciones gestionadas por el operador y telemetría retenida dentro de su red. Ninguna señal sale de la infraestructura del cliente. |
Guía de dimensionamiento de GPU
Tres datos de entrada determinantes - clase de modelo, carga concurrente, contexto máximo - que determinan el dimensionamiento del hardware.
| Clase de modelo | Concurrencia | Contexto máximo | Configuración sugerida |
|---|---|---|---|
| Recuperación y embedding | Hasta 256 consultas en paralelo | 32K tokens | Un único acelerador dentro de su red. Se fragmenta en dos para redundancia interregional. |
| Modelos de 30B a 100B | De 5 a 10 solicitudes en paralelo | 256K tokens | Un único acelerador dentro de su red. Se fragmenta en dos para mayor concurrencia y disponibilidad. |
| Modelos de 100B a 200B | De 10 a 20 solicitudes en paralelo | 512K tokens | Dos aceleradores dentro de su red con inferencia por lotes. Se fragmenta en tres para mayor calidad de servicio. |
| Modelos de 200B a 500B | De 20 a 100 solicitudes en paralelo | 1M tokens | Conjunto multiacelerador con paralelismo tensorial entre cuatro y ocho aceleradores. |
| Modelo afinado a medida | Dimensionado según el prototipo validado en Desarrollo y validación | Dimensionado según los parámetros propios del proyecto | Se dimensiona solo tras la aprobación en Desarrollo y validación. Nunca se estima a partir de una tabla de dimensionamiento. |
Rangos de dimensionamiento validados en hardware real - clase RTX Pro - en nuestro laboratorio GPU. Desarrollo y validación Laboratorio GPU
Pasos siguientes
Cada número en esta página tiene un origen. Las puertas provienen de una hoja de ruta y los rangos de dimensionamiento se prueban en hardware real. Vea ambas etapas a continuación o agende una reunión para analizarlo.