Unidad 6.5: Inferencia de IA: Centro de modelos gestionado

Introducción

FinCorp quiere un asistente interno que responda a las preguntas del personal desde su propia documentación de políticas y productos. La decisión arquitectónica no es cuál modelo es el más inteligente, sino dónde se ejecuta la inferencia y quién lleva el peso operativo. Para una empresa de servicios financieros alemana bajo GDPR y obligaciones BSI, la opción predeterminada debería ser la que mantiene los datos en el país, no agrega infraestructura para operar y solo factura por lo que se consume. Esa opción es la inferencia gestionada AI Model Hub. Esta unidad establece por qué la inferencia gestionada es la opción predeterminada para empresas, cuándo un servidor GPU dedicado justifica su existencia y cómo FinCorp construye generación aumentada de recuperación a partir de primitivas de plataforma. Termina levantando una llamada de inferencia funcionando para que la forma API sea concreta.

1. Inferencia gestionada como predeterminada para empresas

AI Model Hub es un servicio de inferencia: sirve modelos preentrenados detrás de un API para que usted pueda implementar características de inteligencia artificial sin aprovisionar ni mantener el hardware subyacente. Para un arquitecto, el atractivo es que elimina toda una superficie operativa, GPU controladores, carga de modelos, capacidad de cabeza, parches, del diseño. Cuatro propiedades lo convierten en la elección predeterminada para un Workload regulado.

API compatible con OpenAI. El hub expone dos superficies de API: un API nativo de IONOS y un API compatible con OpenAI que refleja la estructura de solicitud y respuesta de OpenAI. La URL base compatible con OpenAI es https://openai.inference.de-txl.ionos.com/v1, y sirve las rutas familiares: lista de modelos, POST /v1/chat/completions para texto, POST /v1/embeddings para vectores y POST /v1/images/generations para imágenes. La consecuencia arquitectónica es la portabilidad. Cualquier cliente, biblioteca o framework ya escrito contra el API de OpenAI puede apuntar al hub cambiando la URL base y el token, por lo que la elección de FinCorp no bloquea su código de aplicación a un proveedor.

Precios por token. La facturación es por millón de tokens, dividida entre entrada y salida, y varía según el modelo. Las siguientes cifras son las tarifas documentadas para dos modelos de texto representativos:

Como muestra la tabla, el control de costos es el Volume de tokens, no una instancia aprovisionada. No hay GPU inactivo entre solicitudes y no hay compromiso de tamaño de antemano. Para un asistente interno de carga irregular cuya carga sigue el día laborable, pagar por token es estructuralmente más barato que reservar hardware de acelerador que está ocupado unas pocas horas de veinticuatro.

Sin estado. El servicio descarta las solicitudes y salidas al final de cada sesión. Las interacciones no se registran, no se graban y no se reutilizan para el entrenamiento de modelos, y los datos del cliente no se utilizan para el entrenamiento bajo ninguna circunstancia. La falta de estado es una propiedad de cumplimiento, no solo de eficiencia: no hay almacén de contenido retenido para que el oficial de protección de datos de FinCorp lo razonable, y no hay ciclo de vida de datos de inferencia para gobernar.

Procesado en el país. Todo el procesamiento y la inferencia se realizan exclusivamente en Alemania, en el centro de datos de Berlín. Los servicios de AI Model Hub, incluidos los puntos de conexión de inferencia, se alojan en centros de datos alemanes certificados por ISO 27001. Para FinCorp, esto cierra la pregunta de soberanía que impulsó la elección de la plataforma en primer lugar: la llamada al modelo nunca sale de la jurisdicción alemana. Delimitar esta afirmación con precisión. La certificación de ISO 27001 se adjunta a los centros de datos alemanes que alojan el hub; no es una declaración a nivel de plataforma, y el análisis de la frontera de soberanía y el papel de la Ley de Inteligencia Artificial de la UE pertenece a la Unidad 6.6.

Dos límites operativos pertenecen al diseño. El SLA de tiempo de actividad por servicio es del 99,9% y su alcance es solo los puntos de conexión de API de AI Model Hub, no la disponibilidad por modelo o la calidad de la inferencia. El API general lleva una tasa base de 5 solicitudes por segundo con un techo de explosión de 10; superarlo devuelve HTTP 429 Too Many Requests. Un cliente de producción debe implementar, por lo tanto, un retraso y una repetición en lugar de asumir un rendimiento ilimitado, y un Workload con un gran abanico necesita una capa de ritmo de solicitud frente al hub.

2. Cuando el servicio de GPU alojado en el propio servidor está justificado

El centro de modelos administrado sirve un catálogo fijo de modelos alojados en la plataforma. Cuando un cliente necesita implementar su propio modelo preentrenado, ajustar con datos propietarios o ejecutar un modelo que el catálogo no ofrece, IONOS ofrece servidores dedicados GPU-habilitados Compute Engine en su lugar. Estos ofrecen acceso de root a hardware GPU de clase empresarial con un pago por uso, por lo que el Workload se ejecuta en una infraestructura que el cliente controla.

El intercambio es la propiedad de todo lo que el servicio administrado ocultaba. La presentación honesta para un arquitecto es la siguiente: en el momento en que se aloja en el propio servidor, el SLA de inferencia se convierte en responsabilidad del cliente, no del centro de modelos. Un servidor GPU único es hardware dedicado de un solo inquilino sin migración en vivo, por lo que un error del host o un evento de mantenimiento interrumpe el servicio a menos que se haya construido redundancia por cuenta propia. Lograr el tipo de disponibilidad que proporciona el punto de conexión administrado significa ejecutar al menos dos nodos de servicio detrás de un Load Balancer de Capa 4, más la carga de modelos, comprobación de estado, escalado automático y actualización por su cuenta, pero el límite de cuota por contrato predeterminado es solo una instancia H200-S (los modelos más grandes o instancias adicionales requieren un aumento de los límites de recursos mediante un ticket de soporte antes de la implementación) y la colocación de la zona de disponibilidad está fija en Auto, por lo que no se puede forzar explícitamente que los dos nodos estén en zonas separadas. El costo predecible es la ventaja que la documentación destaca, una tarifa fija para el servicio siempre activo en lugar de una facturación variable por token, por lo que la alojación en el propio servidor tiende a ganar solo para cargas de trabajo de estado estable, con alta utilización o para modelos que el centro de modelos no sirve.

Mantenga separadas dos preguntas de tamaño. El tamaño de la inferencia está impulsado por la concurrencia, los objetivos de latencia y la memoria de la ventana de contexto, y para una carga alta constante, un GPU dedicado puede ser más barato que la facturación por token. El tamaño del entrenamiento y la ajuste fino es un régimen diferente y más pesado: requiere cálculo sostenido de varios GPU contra conjuntos de datos propietarios, y el camino de la plataforma para eso es el servidor GPU, no el centro de inferencia. No dimensione una implementación de inferencia como si fuera un entrenamiento Cluster, y no suponga que un GPU de tamaño de inferencia ajustará un modelo grande en un tiempo razonable. El asistente de FinCorp es una inferencia pura con una carga modesta y de ráfagas, que es exactamente el perfil que el centro de modelos administrado sirve mejor, por lo que FinCorp se mantiene en el centro de modelos y no configura servidores GPU. El servidor GPU es adecuado para el entrenamiento y la ajuste fino de modelos, y el servidor GPU puede ser más barato que la facturación por token para cargas de trabajo de estado estable y alta utilización, por lo que el cliente debe considerar cuidadosamente sus necesidades antes de decidir entre el centro de modelos administrado y el servidor GPU.

3. Generación mejorada con recuperación para el cliente

El asistente de FinCorp debe responder a partir de los propios documentos de FinCorp, no de la formación general del modelo. El patrón para ello es la generación mejorada con recuperación (RAG): combinar la capacidad lingüística del modelo con pasajes relevantes recuperados de una base de conocimientos en el momento de la consulta. El centro de conexión proporciona las piezas del lado del modelo; el arquitecto compone las piezas del lado de almacenamiento a partir de primitivas de plataforma.

Construya RAG como infraestructura de propiedad del cliente con tres componentes de plataforma:

• Incrustaciones del centro de conexión. Convierta cada fragmento de documento en un vector denso con POST /v1/embeddings, utilizando un modelo de incrustación del centro de conexión como BAAI/bge-m3 (documentado a 0,02 EUR por millón de tokens). El mismo punto final incrusta la consulta del usuario en el momento de recuperación, por lo que la consulta y el corpus viven en el mismo espacio vectorial.
• Vectores en Managed PostgreSQL. Almacene las incrustaciones en una instancia de Managed PostgreSQL con la extensión pgvector. Esto le da una base de datos relacional que ya sabe cómo operar, respaldar y colocar en el nivel de datos privado, con la búsqueda de similitud vectorial como una consulta de primera clase. Se compone limpiamente con todo lo que el Módulo 5 estableció sobre el nivel relacional.
• Corpus en Object Storage. Mantenga los documentos de origen en Object Storage como el sistema de registro, utilizando sus características de ciclo de vida y bloqueo de objetos para la retención. El almacén de vectores mantiene las incrustaciones y referencias; el texto autorizado permanece en el cubo compatible con S3.

En el momento de la consulta, el flujo es: incrustar la pregunta, ejecutar una búsqueda de similitud en PostgreSQL para recuperar los fragmentos más cercanos, y luego pasar esos fragmentos como contexto a POST /v1/chat/completions. Nada en este bucle requiere un almacén de vectores administrado, y usted mantiene el control total de dónde viven los vectores y el corpus.

Esta es una elección arquitectónica deliberada. AI Model Hub históricamente ofreció una función de colecciones de documentos administradas, un almacén de vectores integrado con fragmentación y un punto final de consulta semántica nativa, con un backend chromadb predeterminado y un backend pgvector opcional. Esa función de almacén de vectores administrado se está retirando y no debe diseñarse como una opción para seguir adelante. Construya RAG en su lugar sobre las primitivas duraderas anteriores: incrustaciones del centro de conexión, su propio pgvector en Managed PostgreSQL, y su corpus en Object Storage. El resultado es idéntico en capacidad, se encuentra completamente en servicios que FinCorp ya opera, y no conlleva ningún riesgo de deprecación.

DCD Implementación paso a paso

La construcción de esta unidad es deliberadamente ligera porque AI Model Hub se consume a través de su API en lugar de provisionarse como infraestructura Data Center Designer. El objetivo es probar un modelo y realizar una llamada compatible con OpenAI que funcione, de modo que la forma de API sea concreta y el equipo de aplicaciones de FinCorp pueda conectarla al asistente. El único requisito previo es el acceso a la gestión de tokens del contrato.

Objetivo de la construcción: Probar un modelo y realizar una llamada compatible con OpenAI que funcione.

Pasos:

1. Generar un token API. En el DCD, abra la gestión de acceso (gestión de tokens) y cree un nuevo token API para el AI Model Hub. El centro de datos autentica con un token Bearer, y el token es un token Web JSON (JWT) con una fecha de caducidad. Copie el token de inmediato, porque se muestra solo una vez.
2. Mantener el token en la variable de entorno esperada. Los tutoriales del centro de datos suponen que el token se mantiene en la variable de entorno IONOS_API_TOKEN. Establezca el token en su shell en lugar de pegar el token literal en scripts o control de versiones.
3. Listar los modelos disponibles. Confirme la conectividad y descubra los identificadores de modelo llamando a la ruta de modelos compatibles con OpenAI en la URL base https://openai.inference.de-txl.ionos.com/v1. Una respuesta exitosa prueba el token, el punto de conexión y la región antes de que envíe cualquier prompt.
4. Enviar una finalización de chat. Llame a POST /v1/chat/completions contra la URL base con un identificador model del paso 3 y una matriz messages. Esta es la llamada de inferencia central que realizará el asistente de FinCorp.
5. Elevar la llamada que funciona a la aplicación. Una vez que la llamada regrese, entréguesela al equipo de aplicaciones como la configuración de cliente canónica: URL base, identificador de modelo y la convención del token Bearer. Ahora cualquier biblioteca compatible con OpenAI funciona estableciendo solo la URL base y el token.

Una llamada de finalización de chat mínima ilustra la forma compatible con OpenAI. El punto arquitectónico es el contrato de solicitud, no el script: cambiar solo la URL base y el token redirige cualquier cliente OpenAI al centro de datos del país.

curl https://openai.inference.de-txl.ionos.com/v1/chat/completions \
  -H "Authorization: Bearer $IONOS_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.3-70B-Instruct",
    "messages": [{"role": "user", "content": "Summarise our refund policy."}]
  }'

Errores comunes:

• Pegar un token caducado o de tipo incorrecto. El token Bearer es un JWT con una reclamación exp. Los fallos de autenticación suelen ser un token caducado, regenerearlo y vuelva a establecer IONOS_API_TOKEN, no una solicitud malformada.
• Codificar el token en scripts o repositorios. El token se muestra una vez y otorga acceso de inferencia pagada. Manténgalo en IONOS_API_TOKEN, manténgalo fuera del control de código fuente y rotúelo en el horario habitual.
• Apuntar el cliente a la URL base incorrecta. La base compatible con OpenAI es https://openai.inference.de-txl.ionos.com/v1. Un cliente configurado para el host genérico de OpenAI fallará; solo la URL base y el token deben cambiar al migrar un cliente de OpenAI.
• Suponer un rendimiento ilimitado. La tasa de límite base es 5 solicitudes por segundo, salto 10, y el servicio devuelve HTTP 429 cuando se excede. Incorpore la retirada y la repetición en el cliente y controle las cargas de trabajo de alta propagación; no trate el punto de conexión como elástico.
• Diseñar en el vector de almacenamiento de colecciones de documentos administrado. Está siendo retirado. Construya RAG en embeddings de hub más sus propios pgvector en Managed PostgreSQL más Object Storage en su lugar.
• Leer el SLA del 99,9% como una garantía de calidad o por modelo. Cubre solo los puntos de conexión de API, no la disponibilidad de un modelo específico o la calidad de la inferencia.

Resumen

Para una empresa regulada, la inferencia gestionada en AI Model Hub es el valor predeterminado: un API compatible con OpenAI, precios por token sin GPU inactivos que financiar, un servicio sin estado que no retiene nada y el procesamiento se limita a centros de datos alemanes. El servicio de GPU autohospedado en hardware dedicado solo está justificado cuando necesita un modelo que el centro no ofrece, está afinando, o una carga de utilización alta y constante hace que el cálculo de tarifa fija sea más barato, y asume la responsabilidad de la SLA de inferencia y la redundancia. El asistente de FinCorp se ajusta al perfil gestionado, por lo que consume el centro directamente y crea generación mejorada con recuperación desde incrustaciones del centro, pgvector en Managed PostgreSQL, y un corpus en Object Storage, evitando por completo el almacén de vectores gestionado en desuso.

Puntos clave:

• La URL base compatible con OpenAI es https://openai.inference.de-txl.ionos.com/v1; redirigir un cliente de OpenAI solo necesita la URL base y un token Bearer.
• El precio es por millón de tokens y varía según el modelo; no hay instancia provisionada, por lo que el token Volume es el elemento de costo.
• El centro es sin estado y procesa exclusivamente en Alemania; los datos nunca se utilizan para capacitación. La SLA del 99,9% cubre solo los puntos de conexión de API.
• Autohospede en servidores de GPU solo para modelos no compatibles, afinación o carga de utilización alta y constante, aceptando que entonces es dueño de la SLA y la redundancia.
• Cree RAG como propiedad del cliente: incrustaciones del centro, vectores en pgvector en Managed PostgreSQL, corpus en Object Storage. No adopte el almacén de vectores gestionado en desuso.

Terminología importante:

• API compatible con OpenAI: una superficie de API que refleja la estructura de solicitud y respuesta de OpenAI, lo que permite que los clientes de OpenAI existentes funcionen cambiando solo la URL base y el token.
• Precio por token: facturación medida por millón de tokens de entrada y salida en lugar de por instancia provisionada.
• Generación mejorada con recuperación (RAG): combina un modelo de lenguaje con pasajes recuperados de una base de conocimientos en el momento de la consulta para que las respuestas estén basadas en los documentos del cliente.
• pgvector: una extensión de PostgreSQL que almacena vectores de incrustación y admite la búsqueda de similitud, lo que permite un almacén de vectores creado por el cliente en Managed PostgreSQL.

Lectura adicional

• Unidad 6.6: Soberanía de la IA y la Ley de IA de la UE (el límite de soberanía y los roles de la Ley de IA de la UE detrás de la inferencia gestionada)
• Unidad 5.3: Bases de datos relacionales (Managed PostgreSQL) y Unidad 5.2: Object Storage (el nivel de almacenamiento RAG)
• Centro de Arquitectura de IONOS Cloud