¿Qué exigen realmente los modelos aislados?

Los modelos aislados exigen mucho más que un servidor con GPU y el cable de red desconectado. Una definición útil describe un sistema cuyos datos de inferencia, artefactos del modelo, vía de administración, registros y proceso de actualización solo pueden cruzar el límite de seguridad mediante un procedimiento explícito e inspeccionado. Si un ingeniero puede restaurar Internet para instalar un paquete, o si un controlador de gestión todavía llama a la nube de un proveedor, el diseño tiene una brecha en el sentido habitual. No tiene una separación física en el sentido de seguridad.

Esa distinción cambia la compra. La organización asume la capacidad del hardware, la custodia del modelo, las dependencias de software, la identidad, la observación, la recuperación y cada actualización futura. También acepta que algunas capacidades alojadas no pueden entrar a ningún precio porque el proveedor no distribuye sus pesos. Puede ser la respuesta correcta para código fuente, registros de producción, material sujeto a control de exportaciones o cargas reguladas, pero solo si el modelo operativo se diseña antes de que lleguen los servidores.

Un aislamiento físico es un límite gobernado de datos

Una máquina solo está aislada cuando cada vía que cruza su límite está ausente o se controla como un evento de transferencia. Los equipos suelen revisar la red de aplicaciones y olvidan el controlador de administración de placa, el plano del hipervisor, la replicación de almacenamiento, el DNS, la sincronización horaria, los exportadores de telemetría, las comprobaciones de licencias, los informes de fallos y el portátil que un administrador usa a ambos lados. Cualquiera puede convertir un entorno supuestamente cerrado en uno parcialmente conectado.

Empiece con cuatro flujos: datos de entrada, datos de salida, suministro de software y administración. Dibuje cada origen y destino. Marque el protocolo, la identidad, quién aprueba el paso y las pruebas que se conservan. Un diagrama que diga «clúster sin conexión» casi no informa a un auditor. Un inventario que diga «el paquete firmado entra por la estación T1 tras la aprobación de dos personas» describe un control que se puede construir y probar.

Hay varios niveles de aislamiento defendibles. Llamarlos a todos aislamiento físico genera malas decisiones. Una subred privada con el tráfico saliente bloqueado aún depende de routers conectados, planos de control en la nube y servicios de identidad. Un entorno desconectado puede admitir importaciones programadas por una pasarela vigilada. Un aislamiento físico no tiene ninguna ruta de red activa y mueve los artefactos aprobados mediante soportes controlados o un mecanismo unidireccional específico. Elija el nivel según el modelo de amenazas y use el nombre preciso en contratos y revisiones.

NIST SP 800-53 trata la protección y el transporte de soportes, la protección de límites, la gestión de configuración y la auditoría como familias distintas. Esa separación resulta útil. Quitar una ruta no responde quién puede llevar una actualización, cómo se analiza el soporte, si el receptor lo verifica ni cómo se demuestra el cambio. Un entorno aislado necesita que todos esos controles trabajen juntos.

Pruebe la afirmación en vez de confiar en el diagrama. Inventaríe interfaces de red y radios, siga los puertos de los conmutadores, inspeccione los controladores de gestión, intente consultas DNS y conexiones salientes desde cada espacio de carga, y revise dónde acaban los registros. Repita las pruebas después del mantenimiento, porque un acceso temporal de diagnóstico suele convertirse en infraestructura permanente.

El modelo de amenazas decide qué debe quedarse dentro

El límite debe contener los activos y las operaciones cuya divulgación o dependencia externa no pueda aceptar. Sin embargo, muchas implantaciones ejecutan la inferencia dentro mientras preparan los prompts en un servicio conectado, copian los resultados a un sistema de incidencias alojado o envían trazas con código fuente a una plataforma de observación. La GPU trabajó localmente, pero la carga completa no.

Separe tres planos. El plano de datos transporta prompts, documentos recuperados, respuestas, representaciones vectoriales y resultados de herramientas. El plano de control gestiona identidad, programación, políticas, secretos, registros y administración. El plano de suministro trae pesos, contenedores, paquetes del sistema, controladores, firmware y avisos de vulnerabilidades. Cerrar solo el plano de datos deja dos vías amplias de ataque o fuga.

Escriba un modelo de amenazas con adversarios y fallos concretos. Un equipo de registros regulados puede preocuparse sobre todo por la divulgación accidental y la custodia demostrable. Un programa de defensa también puede asumir un atacante capaz en la cadena de suministro. Una fábrica puede priorizar el funcionamiento cuando fallen los enlaces externos. Estas necesidades producen reglas de transferencia, redundancia y profundidad de revisión diferentes. «Lo exige la seguridad» es demasiado vago para elegir hardware o aprobar una excepción.

Decida qué salidas pueden abandonar el entorno. Un árbol de código transformado puede contener comentarios, credenciales, nombres de clientes y lógica presentes en la entrada. Una respuesta del modelo no está saneada solo por ser nueva. Si los resultados cruzan el límite, trátelos como una exportación con revisión de contenido, aprobador, destino y registro. Lo mismo vale para los paquetes de soporte: las trazas y capturas de prompts suelen contener el material que el aislamiento debía proteger.

La pregunta incómoda es si las personas derrotan el diseño. Si los operadores fotografían errores con sus teléfonos, copian órdenes desde un chat conectado o mueven cualquier dispositivo USB entre zonas, el límite de red solo cambia la vía de fuga. Proporcione una copia interna de la documentación, manuales buscables, soportes aprobados y un procedimiento de soporte que funcione bajo presión. Los controles que impiden recuperarse se eluden en la primera avería seria.

El hardware se dimensiona por la carga, no por la ficha del modelo

Dimensione el clúster de inferencia aislado con solicitudes, concurrencia, longitud de contexto, latencia y disponibilidad medidas, y después elija el modelo y la precisión. Tener memoria de GPU suficiente para cargar los pesos solo demuestra que un proceso puede arrancar. Producción también necesita memoria para la caché de claves y valores, activaciones, áreas de trabajo, contextos simultáneos y la capa de servicio.

Una primera estimación del tamaño de los pesos es sencilla:

weight_bytes ~= parameter_count * bits_per_weight / 8
required_vram = weights + kv_cache + activations + runtime_workspace + safety_margin

La primera línea es un límite inferior, no un presupuesto. Los formatos cuantizados incluyen escalas y metadatos. Algunas arquitecturas activan solo parte de los parámetros por token, pero pueden necesitar todos los expertos residentes. La documentación de TensorRT de NVIDIA explica que un motor serializado aproxima la memoria de pesos, mientras que los contextos añaden memoria persistente y de ejecución. También recomienda medir la memoria libre y fijar límites de trabajo. Es mejor que multiplicar los parámetros y comprar la siguiente GPU.

Mida la versión real del servidor en el hardware exacto. Use longitudes de entrada y salida representativas, incluidas las solicitudes largas que dominan la caché. Mida tiempo hasta el primer token, tokens por segundo, espera, pico de memoria del dispositivo, RAM, lecturas de almacenamiento al arrancar y recuperación tras el fallo de un proceso. Envíe suficientes solicitudes simultáneas para mostrar cómo programa el sistema. Un único prompt interactivo oculta el problema de capacidad.

La RAM y el almacenamiento también importan. Puede necesitar espacio para los pesos actuales y anteriores, una copia desempaquetada, capas de contenedores, cachés de motores, conjuntos de evaluación y registros de auditoría. Si volver atrás exige borrar el único modelo conocido como bueno, faltaba almacenamiento. El almacenamiento local rápido acorta reinicios; uno compartido y lento puede hacer que todos los nodos regresen a la vez y esperen el mismo cuello de botella.

La ejecución con varias GPU resuelve un problema de tamaño o latencia, pero añade comunicación y otro dominio de fallo. NVIDIA documenta que repartir la ejecución reduce la presión de memoria por dispositivo a cambio de comunicación entre GPU. Valide la topología, la ruta directa y las bibliotecas colectivas con las versiones de controlador y firmware previstas. Dos GPU en una lista de materiales no garantizan un paralelismo útil.

La disponibilidad multiplica la necesidad. Si el mantenimiento o un fallo no pueden detener la inferencia, reserve capacidad para soportar la mayor avería permitida sin incumplir la latencia. Puede necesitar un nodo de repuesto, margen repartido entre nodos, registros internos redundantes y piezas en las instalaciones. Un proveedor alojado esconde buena parte de esa reserva en su precio. Dentro del perímetro, es responsabilidad suya.

Las pruebas de capacidad deben cubrir energía y temperatura, no solo rendimiento del software. Un nodo denso puede superar una prueba corta y reducir su velocidad bajo carga sostenida porque el rack no elimina el calor o una línea eléctrica no soporta todos los dispositivos. Registre frecuencias, temperatura, errores corregidos y consumo durante una prueba prolongada. Pregunte qué sucede al fallar una alimentación o la refrigeración y repita el cálculo en ese estado.

Cualifique una base completa: firmware del servidor, del controlador y de la GPU, controlador, entorno de ejecución, núcleo, imagen de contenedor y motor de inferencia. Un motor optimizado puede estar compilado para una generación de GPU o combinación de software. Importar uno precompilado sin reproducir su destino puede fallar al arrancar dentro de la zona. Mantenga el proceso de compilación dentro o promocione un motor solo después de ejecutarlo en la clase de hardware de producción.

No suponga que la inferencia por CPU ofrece un modo de emergencia útil. Puede mantener un modelo pequeño, pero la latencia y el ancho de banda pueden impedir todos los objetivos de la carga principal. Mídalo y etiquételo con precisión: servicio degradado, recuperación solo por lotes o ningún respaldo. Sea igual de claro con una flota mixta. Dispositivos diferentes pueden requerir motores diferentes y complicar la programación y la reserva más de lo que sugiere el descuento.

Reserve también una vía de cualificación. Si todas las GPU atienden producción, cada cambio de controlador, entorno o peso debe probarse en hardware distinto o en el grupo activo. Un nodo pequeño y representativo puede validar importaciones, reconstruir motores, ejecutar evaluaciones y detectar incompatibilidades antes de la promoción. Cuesta capacidad, pero descubrir tras un parche urgente que a la única imagen interna de compilación le falta una dependencia también cuesta.

Los pesos necesitan custodia, licencia e identidad reproducible

Los pesos del modelo son entradas ejecutables con condiciones legales, consecuencias de seguridad e identidad exacta. Tratarlos como un archivo grande copiado desde una estación elimina la información necesaria para reproducir o investigar una implantación. El registro de versión debe vincular pesos, configuración, tokenizador, entorno de inferencia, adaptadores, imágenes, licencias y resultado de evaluación.

Use resúmenes inmutables, no nombres cambiantes como latest o una etiqueta simple. La Open Container Initiative Image Specification exige que los descriptores incluyan resumen de contenido y tamaño, y recomienda verificar los bytes antes de usarlos. Ese principio también sirve si los pesos viajan como archivos normales. Un manifiesto firmado debe listar cada artefacto con SHA-256, número de bytes, origen, licencia revisada y expediente de aprobación.

Un paquete mínimo se comprueba con herramientas presentes en casi cualquier entorno controlado:

$ sha256sum -c SHA256SUMS
weights/model-00001-of-00004.safetensors: OK
weights/model-00002-of-00004.safetensors: OK
weights/model-00003-of-00004.safetensors: OK
weights/model-00004-of-00004.safetensors: OK
config/tokenizer.json: OK
images/inference-server.oci.tar: OK

$ sha256sum SHA256SUMS
4b7f...a921  SHA256SUMS

El resumen abreviado muestra la forma de la salida, no un valor que deba copiarse. En producción, registre la suma completa, compruebe la firma del manifiesto con una clave pública ya confiable dentro y vuelva a calcular cada archivo tras el traslado. Una suma solo protege la integridad si la esperada llega por una vía confiable y autenticada. Poner un archivo malicioso y su suma correspondiente en la misma unidad sin revisar no demuestra nada.

Conserve el paquete original después de promocionarlo. Si cambia una salida, debe saber si la causa fue una revisión de pesos, tokenizador, entorno, controlador, muestreo o código de aplicación. Versione toda la unidad de inferencia y haga del retroceso una operación normal. Nunca reconstruya una versión antigua desde dependencias móviles durante un incidente.

Las licencias pueden impedir una implantación aunque los archivos se descarguen. Revise los derechos para ejecutar, modificar, redistribuir internamente, crear derivados y usar los resultados para el objetivo previsto. Registre las condiciones de uso que afecten a la carga. Un modelo descrito informalmente como abierto puede usar una licencia que no cumpla la definición de código abierto de su organización, por lo que la aprobación de seguridad no sustituye la revisión legal.

La ruta de actualización forma parte de producción

Un entorno aislado necesita una vía de importación diseñada porque los modelos dependen de una pila cambiante. Controladores, firmware, entornos, imágenes base, paquetes de Python o del sistema, pesos, tokenizadores, avisos de seguridad y datos de revocación envejecen. Congelarlos evita hoy el traslado, pero acumula defectos y hace más difícil probar el salto posterior.

Use dos zonas de preparación. Una zona conectada adquiere artefactos fijados y registra su procedencia. Una estación de transferencia analiza, verifica, inventaría y empaqueta la versión sin guardar secretos de producción. La zona receptora vuelve a verificar el manifiesto, importa en repositorios internos, ejecuta pruebas de aceptación y promociona por resumen inmutable. Producción no debe descargar directamente del dispositivo de transferencia.

La documentación de Red Hat para entornos OpenShift desconectados trata los espejos y las actualizaciones como operaciones continuas, no como trucos de instalación. Ese enfoque sirve también fuera de OpenShift. Duplique los repositorios consumidos, conserve metadatos y practique actualizaciones y retrocesos sin infraestructura pública. Si un gestor de paquetes intenta llegar a un índice externo durante una reconstrucción, el paquete está incompleto.

Defina ritmos distintos para cambios normales y urgentes. Las versiones rutinarias pueden agrupar modelo, entorno y sistema después de evaluarlos. Una vulnerabilidad explotada en un controlador o biblioteca puede exigir un paquete de emergencia reducido. Defina quién declara esa vía, qué pruebas se acortan, cómo se acepta el riesgo y cuándo se completa la batería. De otro modo, cada parche urgente se convierte en un debate improvisado.

Para reescrituras reguladas de sistemas antiguos, CodeHero suministra los modelos y puede ejecutarlos aislados dentro del perímetro del cliente, en hardware del cliente o alquilado por CodeHero al cliente. Aun así, cliente y equipo deben acordar la autoridad de traslado, el acceso físico, los registros, la revisión de exportaciones y el destino final de pesos y hardware.

Planifique la retirada con el mismo cuidado. Pesos caducados, discos averiados, soportes, archivos de registro y hardware alquilado pueden contener datos protegidos o activos del modelo. Defina las pruebas de borrado y destrucción antes de retirar nada. Un perímetro cerrado sin salida documentada solo aplaza la custodia.

Las operaciones sin conexión necesitan dependencias propias

El clúster debe seguir funcionando cuando no haya ninguna comodidad pública. Eso incluye identidad, hora, nombres, certificados, repositorios, seguimiento, alertas, documentación, copias de seguridad y soporte. Un servidor que funciona mientras los usuarios no pueden autenticarse no es un servicio disponible.

La identidad suele ser la primera dependencia oculta. Si la organización usa un proveedor de identidad en la nube, decida si la zona tendrá directorio independiente, una parte replicada por un mecanismo controlado o cuentas locales. Planifique altas, bajas y revisiones. La duración de una caché no es una arquitectura de identidad, sobre todo si un administrador despedido conserva acceso hasta que caduque un token sin conexión.

La hora y los certificados fallan de forma más silenciosa. Ejecute una fuente horaria interna y documente su sincronización y sus controles de deriva. Opere una autoridad de certificación interna o importe certificados mediante un proceso que empiece mucho antes de caducar. Pruebe qué hacen la pasarela, el registro, la monitorización y la automatización ante un certificado vencido. Cambiar el reloj de urgencia puede invalidar registros y firmas, así que no debe ser la reparación habitual.

La observación se queda dentro salvo que exista una exportación aprobada. Recoja identificadores, latencia, cola, tokens, presión de memoria, errores de hardware, versión, decisiones de políticas y acciones de operadores. Evite registrar prompts y salidas completos por defecto. Si necesita capturar contenido para depurar o probar paridad, limítelo por función, retención y caso, pues el almacén de registros puede concentrar una copia de la carga protegida.

Cree una fuente interna fiable para procedimientos y problemas conocidos. El soporte del proveedor puede pedir diagnósticos que no pueden salir. Acuerde antes si el personal puede entrar, si un paquete saneado puede salir y qué órdenes ejecutará el cliente. Ensaye un fallo de GPU, paquete corrupto, caída del registro, certificado caducado y retroceso. El aislamiento gana confianza durante la recuperación, no durante la presentación.

Las copias necesitan pruebas de restauración independientes. Guarde configuración, manifiestos, metadatos de repositorios, políticas y datos persistentes. No suponga que los pesos deben copiarse en el mismo sistema si los paquetes firmados ya son una fuente recuperable. Restaure en un segmento limpio y demuestre que no necesita descargas externas.

Los modelos cerrados imponen un techo de capacidad

No puede alojar un modelo cuyo proveedor no publique los pesos con una licencia utilizable. Es la renuncia más clara frente a la inferencia alojada, y compras no puede negociar archivos inexistentes. Un modelo distribuible menor puede bastar para clasificación, extracción, transformación de código o tareas con recuperación documental, pero no equivale siempre al mejor alojado en razonamiento amplio o idiomas poco comunes.

Los servicios alojados también concentran trabajo que la instalación cerrada debe reproducir: núcleos optimizados, agrupación de solicitudes, escalado, enrutamiento, controles de abuso, herramientas, preparación multimodal, salida estructurada y renovaciones frecuentes. Algunas funciones se reconstruyen dentro. Otras dependen de modelos propietarios o sistemas del proveedor y desaparecen. Enumere cada capacidad necesaria y pruébela; no acepte la afirmación general de que un modelo local es «igual».

La longitud de contexto anunciada no demuestra buen rendimiento a esa longitud. Los contextos largos consumen caché, reducen concurrencia y pueden empeorar el resultado aunque la solicitud quepa. Pruebe documentos reales y la forma del repositorio. Para un millón de líneas, la pregunta práctica no es si caben en un prompt. El sistema necesita analizar todo el árbol, conservar relaciones y verificar cambios contra el comportamiento observado.

Las actualizaciones llegan más despacio por diseño. Un punto alojado puede cambiar detrás de una API estable, para bien o mal. Dentro, cada peso o entorno pasa por adquisición, revisión, traslado, evaluación y promoción. El retraso aporta control y repetibilidad, pero las funciones nuevas y las correcciones no llegan de inmediato. Decida qué demora acepta para mejoras y qué fallos activan la emergencia.

Las herramientas externas son otra frontera. Búsqueda web, repositorios alojados, incidencias SaaS, metadatos públicos y recuperación administrada no están disponibles si no se replican o pasan por una pasarela autorizada. Un flujo basado en llamadas en vivo pierde funciones al entrar. Sustituya cada dependencia por datos y API internos o declare que la función no existirá.

La calidad debe evaluarse por tarea. Mantenga dentro un conjunto versionado de entradas representativas, invariantes, divulgaciones prohibidas, límites de latencia y guías de puntuación humana. Compare candidatos con el modelo vigente antes de promocionarlos. Las pruebas públicas ayudan a preseleccionar, pero no indican si una reescritura conserva el cierre mensual o una extracción maneja sus formularios más difíciles.

Los costes alojados y aislados se comportan de forma distinta

La inferencia alojada convierte gran parte de la plataforma en gasto variable; el despliegue aislado concentra el coste en capacidad reservada y operaciones. Comparar el precio por token con la compra de una GPU omite casi todo en ambos lados. Modele un servicio que cumpla los mismos requisitos de disponibilidad, latencia, contexto, seguridad y soporte.

Para el lado cerrado, incluya nodos GPU, CPU, RAM, almacenamiento rápido, red interna, rack, energía, refrigeración, reserva, repuestos, equipos de transferencia, registros, monitorización, copia y tiempo del personal. Añada el plazo de compra y el coste de capacidad ociosa para picos o averías. Si necesita zonas separadas de desarrollo, prueba y producción, cuente todas. El hardware alquilado para el proyecto sigue siendo capacidad dedicada, no facturación por tokens.

Para el lado alojado, incluya uso de entrada y salida, caché, rendimiento reservado, retención, conectividad privada, pasarelas, registros, tráfico de evaluación, reintentos y trabajo para gestionar cambios. Añada saneamiento o minimización si los datos brutos no pueden salir. Un punto barato que legal o seguridad no aprueban no tiene una economía útil.

Una comparación sencilla expone los supuestos:

closed_annual_cost = annualized_hardware + facilities + licenses + operations + transfer_and_assurance
hosted_annual_cost = request_volume * blended_request_cost + connectivity + operations + assurance
cost_per_success = total_cost / accepted_task_outputs

La última línea es la más importante. Tokens por segundo y coste por token pueden premiar un sistema rápido cuyo trabajo se rechaza. Defina un resultado aceptado, como una transformación que supera pruebas de paridad o una extracción que alcanza el umbral, y mida reintentos y corrección humana. Use rangos para utilización, crecimiento, vida del hardware y personal en vez de fingir una previsión exacta.

El aislamiento suele tener sentido económico con carga constante, hardware ocupado, un modelo distribuible adecuado y una restricción que ya exige operación local. El alojamiento suele ganar con demanda variable, cuando una capacidad propietaria cambia el resultado, importa la escala mundial o no se quieren operar aceleradores. Un modelo híbrido puede enviar fuera trabajo aprobado de baja sensibilidad, pero exige clasificación fiable y debe bloquearse ante dudas.

La aprobación debe depender de pruebas, no de la etiqueta

Apruebe la implantación cuando el equipo pueda demostrar el límite, reproducir la unidad de inferencia, operar todas las dependencias sin conexión, actualizar y volver atrás por una vía probada, y demostrar que el modelo cumple la tarea. Rechace propuestas que solo ofrecen una GPU desconectada y la promesa de resolver las actualizaciones después. Eso es un experimento, no producción.

Pida pruebas inspeccionables: inventario de flujos, modelo de amenazas, medición de hardware, cálculo de capacidad, manifiesto firmado, licencia, evaluación, procedimiento de recuperación, registro de transferencias, proceso de vulnerabilidades y plan de retirada. Observe después una importación y un retroceso. Los controles en papel suelen fallar en la entrega entre el equipo conectado y los operadores internos.

Revise los fallos antes de comprar. ¿Qué ocurre si muere una GPU, un administrador pierde acceso, se corrompe el registro, caduca un certificado, el modelo empeora seriamente o se anuncia una vulnerabilidad grave? Nombre el tiempo de recuperación tolerable y las personas autorizadas. Si la respuesta exige volver a conectar el clúster, presupueste y apruebe ahora esa excepción o cambie la dependencia.

No exija aislamiento como símbolo de estatus. Si la inferencia privada alojada con controles contractuales satisface las amenazas, puede ofrecer mejores modelos con menos riesgo operativo. Si código, registros o políticas no pueden cruzar, acepte el coste de capacidad y personal en vez de ocultarlo. CodeHero completa cada reescritura de sistemas antiguos en menos de 30 días, así que el perímetro, el hardware y los traslados deben decidirse pronto.

La prueba decisiva es operativa: corte toda vía externa, introduzca una actualización firmada, ejecute la carga representativa, exporte un resultado aprobado, vuelva atrás y recupere un nodo perdido. Si el equipo puede completar la secuencia desde sus repositorios y dejar una pista de auditoría completa, el aislamiento puede sostener producción.