Unidad 6.5: Inferencia de IA: Hub de modelos administrado

Introducción

FinCorp desea un asistente interno que responda a las preguntas del personal a partir de su propia documentación de políticas y productos. La decisión arquitectónica no es qué modelo es el más inteligente; se trata de dónde se ejecuta la inferencia y quién asume la carga operativa. Para una empresa alemana de servicios financieros sujeta al RGPD y a las obligaciones del BSI, la opción predeterminada debe ser aquella que mantenga los datos dentro del país, no añada infraestructura que operar y facture únicamente por lo que se consume. Esa opción es el AI Model Hub gestionado. Esta unidad establece por qué la inferencia gestionada es la opción predeterminada para empresas, cuándo un servidor GPU dedicado justifica su inversión y cómo FinCorp construye la generación aumentada por recuperación a partir de los elementos básicos de la plataforma. Concluye al presentar una llamada de inferencia funcional para que la forma de la API sea concreta.

1. Inferencia administrada como predeterminado empresarial

AI Model Hub es un servicio de inferencia: sirve modelos preentrenados a través de una API, lo que le permite implementar funciones de IA sin aprovisionar ni mantener el hardware subyacente. Para un arquitecto, el atractivo radica en que elimina toda una superficie operativa, como los controladores de GPU, la carga de modelos, el margen de capacidad y la aplicación de parches, del diseño. Cuatro propiedades lo convierten en la opción predeterminada para una carga de trabajo regulada.

API compatible con OpenAI. El centro expone dos superficies de API: una API nativa de IONOS CLOUD y una API compatible con OpenAI que replica 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 habituales: listar 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 marco de trabajo ya escrito para la API de OpenAI puede dirigirse al centro cambiando la URL base y el token, de modo que la elección de FinCorp no vincula su código de aplicación a un solo proveedor.

Precios por token. La facturación se realiza 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 palanca de coste es el volumen de tokens, no una instancia aprovisionada. No hay ninguna GPU ociosa entre solicitudes y no hay compromiso de dimensionamiento previo. Para un asistente interno con picos de carga que sigue la jornada laboral, pagar por token es estructuralmente más barato que reservar hardware de aceleración que está ocupado unas pocas horas de las veinticuatro.

Sin estado. El servicio descarta los prompts y las 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 en ninguna circunstancia. La ausencia de estado es una propiedad de cumplimiento, no solo de eficiencia: no hay un almacén de contenido retenido sobre el que el responsable de protección de datos de FinCorp tenga que razonar, ni un ciclo de vida de datos en el lado de la inferencia que gobernar.

Procesado en el país. Todo el procesamiento y la inferencia ocurren exclusivamente en Alemania, en el centro de datos de Berlín. Los servicios de AI Model Hub, incluidos los puntos de acceso de inferencia, están alojados en centros de datos alemanes certificados bajo ISO 27001. Para FinCorp, esto cierra la cuestión de soberanía que impulsó en primer lugar la elección de la plataforma: la llamada al modelo nunca sale de la jurisdicción alemana. Delimite esta afirmación con precisión. La certificación ISO 27001 se aplica a los centros de datos alemanes que alojan el centro; no es una declaración a nivel de plataforma, y el análisis más profundo de los límites de soberanía y el papel de la Ley de IA de la UE corresponde a la Unidad 6.6.

Dos límites operativos deben incluirse en el diseño. El SLA de tiempo de actividad por servicio es del 99,9%, y su alcance se limita a los puntos de acceso de la API de AI Model Hub, no a la disponibilidad por modelo ni a la calidad de la inferencia. La API general tiene un límite de velocidad base de 5 solicitudes por segundo, con un máximo de ráfaga de 10; superarlo devuelve HTTP 429 Too Many Requests. Por lo tanto, un cliente de producción debe implementar retroceso y reintentos en lugar de suponer un rendimiento ilimitado, y una carga de trabajo con alto abanico de solicitudes necesita una capa de ritmo de solicitudes delante del centro.

2. Cuándo se justifica la ejecución de GPU autoalojada

El centro gestionado ofrece un catálogo fijo de modelos alojados en la plataforma. Cuando un cliente necesita desplegar su propio modelo preentrenado, realizar un ajuste fino con datos propietarios o ejecutar un modelo que el catálogo no ofrece, IONOS CLOUD posiciona servidores Compute Engine dedicados con GPU habilitada. Estos proporcionan acceso de root a hardware de GPU de clase empresarial con un modelo de pago por uso, de modo que la carga de trabajo se ejecuta en infraestructura que el cliente controla.

La contrapartida es la responsabilidad de todo lo que el servicio gestionado ocultaba. La formulación honesta para un arquitecto es la siguiente: en el momento en que se autoaloja, el SLA de inferencia pasa a ser responsabilidad del cliente, no del centro. Un solo servidor GPU es hardware dedicado de un solo inquilino sin migración en vivo, por lo que una falla del host o un evento de mantenimiento interrumpe la ejecución a menos que se haya construido redundancia por cuenta propia. Alcanzar el tipo de disponibilidad que el punto de acceso gestionado proporciona significa ejecutar al menos dos nodos de ejecución detrás de un equilibrador de carga de capa 4, además de realizar por cuenta propia la carga del modelo, las comprobaciones de estado, el escalado automático y la aplicación de parches. Sin embargo, la cuota predeterminada por contrato es de solo una instancia H200-S (plantillas más grandes o instancias adicionales requieren un aumento del límite de recursos mediante un ticket de soporte antes del despliegue) y la colocación en la zona de disponibilidad está fija en Auto, por lo que no se puede forzar explícitamente que los dos nodos se ubiquen en zonas separadas. El costo predecible es la ventaja que la documentación destaca: una tarifa fija para una ejecución sostenida y permanente, en lugar de una facturación variable por token. Por lo tanto, la autoalojación tiende a ser más ventajosa solo para cargas de trabajo en estado estable y de alta utilización, o para modelos que el centro no sirve.

Mantenga separadas dos preguntas de dimensionamiento. El dimensionamiento de inferencia está determinado por la concurrencia, los objetivos de latencia y la memoria de la ventana de contexto, y para una carga alta y estable, una GPU dedicada puede ser más económica que la facturación por token. El dimensionamiento para entrenamiento y ajuste fino es un régimen diferente y más exigente: requiere cómputo sostenido con múltiples GPUs frente a conjuntos de datos propietarios, y la ruta de la plataforma para ello es el servidor GPU, no el centro de inferencia. No dimensione un despliegue de inferencia como si fuera un clúster de entrenamiento, y no asuma que una GPU dimensionada para inferencia podrá realizar el ajuste fino de un modelo grande en un tiempo razonable. El asistente de FinCorp es de inferencia pura con una carga moderada y con picos, que es exactamente el perfil que el centro gestionado atiende mejor, por lo que FinCorp se mantiene en el centro y no establece servidores GPU.

3. Generación aumentada por recuperación construida por el cliente

El asistente de FinCorp debe responder a partir de los propios documentos de FinCorp, no del entrenamiento general del modelo. El patrón para ello es la generación aumentada por 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 hub proporciona los componentes del lado del modelo; el arquitecto compone los componentes del lado del almacenamiento a partir de primitivas de la plataforma.

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

• Embeddings desde el hub. Convierta cada fragmento de documento en un vector denso con POST /v1/embeddings, utilizando un modelo de embeddings del hub como BAAI/bge-m3 (documentado a 0,02 EUR por millón de tokens). El mismo punto de finalidad incrusta la consulta del usuario en el momento de la recuperación, de modo que la consulta y el corpus existan en el mismo espacio vectorial.
• Vectores en Managed PostgreSQL. Almacene los embeddings en una instancia de PostgreSQL administrada con la extensión pgvector. Esto le proporciona una base de datos relacional que ya sabe cómo operar, respaldar y colocar en la capa de datos privada, con la búsqueda de similitud vectorial como consulta de primera clase. Se combina de manera limpia con todo lo que el Módulo 5 estableció sobre la capa relacional.
• Corpus en Object Storage. Mantenga los documentos fuente en Object Storage como sistema de registro, utilizando sus funciones de ciclo de vida y bloqueo de objetos para la retención. El almacén de vectores contiene embeddings y referencias; el texto autoritativo 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 residen los vectores y el corpus.

Esta es una elección arquitectónica deliberada. AI Model Hub ofreció históricamente una función de colecciones de documentos administradas, un almacén de vectores integrado con segmentación y un punto de finalidad nativo de consulta semántica, con un backend predeterminado de chromadb y un backend opcional de pgvector. Esa función de almacén de vectores administrado está siendo retirada y no debe diseñarse como una opción para el futuro. Construya RAG en su lugar sobre las primitivas duraderas anteriores: embeddings del hub, su propio pgvector en Managed PostgreSQL y su corpus en Object Storage. El resultado es idéntico en capacidad, reside por completo en servicios que FinCorp ya opera y no conlleva riesgo de obsolescencia.

Recorrido de implementación de DCD

La construcción de esta unidad es deliberadamente ligera, ya que AI Model Hub se consume a través de su API en lugar de aprovisionarse como infraestructura de Data Center Designer. El objetivo es probar un modelo y obtener una llamada compatible con OpenAI que funcione, de modo que la forma de la API sea concreta y el equipo de aplicaciones de FinCorp pueda integrarla en el 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 obtener una llamada compatible con OpenAI que funcione.

Pasos:

1. Genere un token de API. En el DCD, abra Access Management (gestión de tokens) y cree un nuevo token de API para AI Model Hub. El hub autentica mediante un token Bearer, y el token es un JSON Web Token (JWT) con fecha de expiración. Copie el token de inmediato, ya que solo se muestra una vez.
2. Mantenga el token en la variable de entorno esperada. Las guías de uso del hub suponen que el token se mantiene en la variable de entorno IONOS_API_TOKEN. Establezca el valor en su shell en lugar de pegar el token literal en scripts o en el control de código fuente.
3. Liste los modelos disponibles. Confirme la conectividad y descubra los identificadores de modelo llamando a la ruta de modelos compatible con OpenAI en la URL base https://openai.inference.de-txl.ionos.com/v1. Una respuesta exitosa demuestra que el token, el punto de acceso y la región son correctos antes de enviar cualquier indicación.
4. Envíe una finalización de chat. Llame a POST /v1/chat/completions contra la URL base con un identificador model del paso 3 y un arreglo messages. Esta es la llamada central de inferencia que realizará el asistente de FinCorp.
5. Incorpore la llamada funcional en la aplicación. Una vez que la llamada devuelva una respuesta, entréguela al equipo de aplicaciones como la configuración canónica del cliente: URL base, identificador de modelo y la convención de token Bearer. Cualquier biblioteca compatible con OpenAI funcionará ahora estableciendo solo la URL base y el token.

Una llamada mínima de finalización de chat 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 de OpenAI hacia el hub dentro 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 afirmación exp. Las fallas de autenticación suelen deberse a un token caducado; regenérelo y vuelva a establecer IONOS_API_TOKEN. No se trata de una solicitud mal formada.
• Codificar el token de forma estática en scripts o repositorios. El token se muestra una sola vez y otorga acceso a inferencia de pago. Guárdelo en IONOS_API_TOKEN, manténgalo fuera del control de versiones y rótelo según el programa 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. El límite de velocidad base es de 5 solicitudes por segundo, con ráfagas de 10, y el servicio devuelve HTTP 429 cuando se supera. Implemente retroceso y reintentos en el cliente y regule las cargas de trabajo con alto abanico de conexiones; no trate el punto de acceso como elástico.
• Diseñar sobre el almacén vectorial de colecciones de documentos administradas. Este servicio está en proceso de retiro. Construya RAG con embeddings de hub junto con su propio pgvector en Managed PostgreSQL y Object Storage.
• Interpretar el SLA del 99,9% como una garantía de calidad o por modelo. Este cubre únicamente los puntos de acceso de la API, no la disponibilidad de ningún modelo específico ni la calidad de la inferencia.

Resumen

Para una empresa sujeta a regulación, la inferencia administrada en AI Model Hub es la opción predeterminada: una API compatible con OpenAI, un precio por token sin necesidad de financiar un GPU inactivo, un servicio sin estado que no retiene nada y un procesamiento limitado a centros de datos alemanes. La inferencia autoalojada en GPU sobre hardware dedicado solo está justificada cuando se necesita un modelo que el hub no ofrece, cuando se realiza ajuste fino o cuando una carga de alta utilización constante hace que la computación con tarifa fija sea más económica, y en ese caso, la responsabilidad del SLA de inferencia y de la redundancia recae en el usuario. El asistente de FinCorp encaja en el perfil administrado, por lo que consume directamente el hub y construye la generación aumentada por recuperación a partir de los embeddings del hub, pgvector en Managed PostgreSQL y un corpus en Object Storage, evitando por completo el almacén vectorial administrado que está en proceso de deprecación.

Puntos clave:

• La URL base compatible con OpenAI es https://openai.inference.de-txl.ionos.com/v1; para reconfigurar un cliente de OpenAI solo se necesita la URL base y un token Bearer.
• El precio se calcula por millón de tokens y varía según el modelo; no hay instancia aprovisionada, por lo que el volumen de tokens es el palanca de costo.
• El hub es sin estado y procesa exclusivamente en Alemania; los datos nunca se utilizan para el entrenamiento. El SLA del 99,9% cubre únicamente los puntos de acceso de la API.
• Aloje usted mismo en servidores GPU solo para modelos no compatibles, ajuste fino o carga de alta utilización constante, aceptando que en ese caso usted asume la responsabilidad del SLA y de la redundancia.
• Construya la RAG como propiedad del cliente: embeddings del hub, vectores en pgvector en Managed PostgreSQL y corpus en Object Storage. No adopte el almacén vectorial administrado que está en proceso de deprecación.

Terminología importante:

• API compatible con OpenAI: una superficie de API que replica la estructura de solicitud y respuesta de OpenAI, permitiendo que los clientes existentes de OpenAI funcionen cambiando únicamente 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 aprovisionada.
• Generación aumentada por recuperación (RAG): combinación de un modelo de lenguaje con pasajes recuperados de una base de conocimientos en el momento de la consulta, de modo que las respuestas se basen en los propios documentos del cliente.
• pgvector: una extensión de PostgreSQL que almacena vectores de embedding y admite la búsqueda de similitud, lo que permite construir un almacén vectorial por parte del 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 administrada)
• Unidad 5.3: Bases de datos relacionales (Managed PostgreSQL) y Unidad 5.2: Object Storage (la capa de almacenamiento de RAG)
• IONOS CLOUD Architecture Center