Elegir infraestructura para LLM implica decidir dónde funciona cada parte y quién la mantiene. Gestionada, híbrida y on-premise son enfoques útiles, pero una etiqueta arquitectónica no identifica por sí sola el destino de instrucciones, archivos, resultados de herramientas o registros operativos.
Dibuja por separado el servicio del modelo, el entorno del agente, los almacenes de datos y las conexiones con herramientas. Después marca cada límite que atraviesa la tarea.
Define dónde se ejecutan el modelo, el entorno, los datos y los registros antes de elegir una etiqueta.
Compara cinco opciones de despliegue
Cada opción reparte el trabajo entre tu equipo y tus proveedores. También pueden combinarse: un agente que ejecutas tú puede llamar a un modelo en la nube y un modelo que alojas tú puede estar en servidores alquilados.
Desplázate horizontalmente para ver todas las columnas.
| Opción | Dónde se ejecuta el modelo | Quién lo mantiene en funcionamiento | Costos que debes planificar |
|---|---|---|---|
| Servicio de modelo gestionado | Los servidores del proveedor, con los modelos que ofrece. | El proveedor opera el modelo. Tu equipo aún controla quién lo usa y qué hace el agente. | Cargos de uso, límites de uso, regiones permitidas y un respaldo si el modelo no está disponible. |
| Modelo alojado por un proveedor de nube | La plataforma de tu proveedor de nube. | Compartida. El contrato determina quién hace qué. | Compromisos de capacidad, redes y conservación de registros. |
| Modelo autogestionado | Servidores que alquilas o posees. | Tu equipo: ejecutar, actualizar y restaurar el modelo. | Servidores, escalado, almacenamiento, supervisión y tiempo del personal. |
| Híbrido | Algunas partes en tu entorno y otras fuera. | Varios responsables que deben coordinar acceso, redes, transferencias de datos e incidentes. | Demoras y cargos de transferencia entre entornos y dónde irá el trabajo si falla un enlace. |
| En instalaciones propias | Tu propio centro de datos. | Tu equipo: capacidad, actualizaciones, acceso, supervisión y recuperación. | Margen de hardware, mantenimiento, energía, instalaciones y el hardware que necesita el modelo elegido. |
Cuando alguien diga «on-premise», pregunta qué incluye: el modelo, el agente, los datos almacenados, los registros de actividad o todo el trayecto de una solicitud. Un modelo local no mantiene los datos locales si las herramientas del agente siguen llamando a servicios externos.
Una plataforma de despliegue puede cubrir solo parte de este trabajo. Pregunta qué configura, actualiza, escala, registra y restaura por ti. Más opciones no significan menos trabajo para tu equipo.
Decide cuándo conviene el despliegue local
El despliegue en instalaciones propias tiene sentido cuando un requisito escrito, como dónde deben permanecer los datos, una conectividad poco fiable o una regla operativa, exige sistemas locales y tienes un equipo que los opere. Comprueba que un modelo aprobado funcione con el hardware que tienes y decide cómo lo actualizarás y probarás.
Antes de comprometerte, sigue el trayecto de los datos en una solicitud normal y durante un fallo. Nombra quién resuelve problemas de hardware y decide cómo seguirá trabajando la gente cuando falte capacidad. El lugar donde se ejecuta un sistema no lo vuelve, por sí solo, compatible ni rápido.
Planifica más allá del modelo
Ejecutar un modelo es solo una parte de un agente. El agente también necesita información aprobada, permiso para usar sus herramientas, una forma de seguir el trabajo en curso, un punto donde una persona revise el resultado y reglas seguras para recuperarse de un fallo. La hoja de requisitos de infraestructura enumera estas partes para que detectes lo que falta antes de comparar precios de alojamiento.
Empieza por el recorrido de los datos
Para una tarea representativa, enumera:
- Los documentos de entrada y dónde se cargan.
- El contexto preparado para el modelo, incluidos los resultados de herramientas.
- Dónde se realiza la inferencia.
- Qué sistemas puede consultar o modificar el agente.
- Dónde se conservan conversaciones, resultados y registros operativos.
Revisa la ruta habitual y las alternativas. Aprobar la ubicación principal no aprueba automáticamente un destino de respaldo. Utiliza la guía de revisión de seguridad para convertir el mapa en preguntas para cada responsable.
Ejemplo: un piloto de operaciones financieras
Un equipo financiero ficticio quiere que un agente redacte explicaciones internas de diferencias de conciliación. El primer piloto usa registros inventados y produce borradores para revisión. Antes de utilizar registros reales, el equipo identifica el destino del modelo, el entorno de ejecución, el almacén de referencia y los registros operativos.
Compara tres propuestas con la misma tarea. Para cada una, pregunta quién puede actualizar el entorno, restablecer el acceso a los datos de referencia, investigar un borrador incompleto y sustituir un modelo no disponible. También comprueba si el modelo necesario puede funcionar con la capacidad propuesta.
El documento de decisión recoge la ruta de datos aprobada, los responsables, el esfuerzo operativo y las preguntas pendientes. Elegir una opción de despliegue no satisface por sí solo a un regulador. Para conocer el contexto del producto, consulta agentes de IA en servicios financieros.
Incluye el costo de operar la opción elegida
Compara el uso del modelo con el resto del trabajo: capacidad de cómputo, almacenamiento, conectividad, supervisión, actualizaciones y tiempo del personal. La infraestructura operada por el cliente necesita mantenimiento; un servicio gestionado sigue requiriendo que tu equipo configure el acceso y evalúe su adecuación.
Prueba el diseño ante una dependencia no disponible y una actualización programada. Define quién decide si el piloto puede reanudarse. Un despliegue que parece sencillo en un diagrama puede requerir una coordinación compleja durante un incidente.
El tiempo de preparación depende de lo que siga abierto: acceso a fuentes, inicio de sesión y redes, pruebas del modelo, pruebas de conexión y recuperación, y capacitación de quienes lo operarán. Estima esos pasos para tu tarea en vez de adoptar un plazo genérico.
Vincula la arquitectura con una oferta documentada
Pide al proveedor que identifique por escrito los componentes admitidos, las obligaciones del cliente, los destinos de datos y el comportamiento de recuperación. Separa las ideas arquitectónicas opcionales de los despliegues que se ofrecen actualmente.
En AgentShelf
La oferta documentada incluye servicios gestionados por AgentShelf y entornos admitidos gestionados por el cliente o externos. Son el punto de partida adecuado para una evaluación. Si necesitas una solución híbrida o completamente en instalaciones propias, confirma con AgentShelf qué está disponible para tus requisitos antes de planificar con esa opción.
Continúa con los fundamentos de infraestructura para LLM y espacios de trabajo y agentes externos para distinguir los componentes y sus vínculos.