{"id":631,"date":"2026-09-18T13:39:47","date_gmt":"2026-09-18T12:39:47","guid":{"rendered":"https:\/\/www.darifer.net\/?p=631"},"modified":"2026-09-18T15:12:10","modified_gmt":"2026-09-18T14:12:10","slug":"del-laboratorio-a-una-plataforma-de-organizacion","status":"publish","type":"post","link":"https:\/\/www.darifer.net\/index.php\/2026\/09\/18\/del-laboratorio-a-una-plataforma-de-organizacion\/","title":{"rendered":"Del Laboratorio a una plataforma de organizacion"},"content":{"rendered":"\n

Hola a tod@s,<\/p>\n\n\n\n

En el art\u00edculo anterior vimos c\u00f3mo desplegar y servir un LLM con vLLM en un Dell Pro Max GB10. La idea era sencilla y muy \u00fatil para laboratorio o para un entorno peque\u00f1o: Linux, GPU NVIDIA, Docker, un modelo descargado desde Hugging Face y una API compatible con OpenAI.<\/p>\n\n\n\n

Pero al llevar esta misma necesidad a una organizaci\u00f3n aparecen nuevas preguntas. \u00bfC\u00f3mo damos servicio a varios equipos? \u00bfC\u00f3mo evitamos que el modelo dependa de un \u00fanico equipo? \u00bfC\u00f3mo controlamos actualizaciones, identidades, red, secretos, capacidad y observabilidad? Aqu\u00ed es donde Azure Local puede convertirse en la base de una plataforma de IA ejecutada dentro de nuestro propio centro de datos.<\/p>\n\n\n\n

Azure Local<\/strong> no sustituye al motor de inferencia. vLLM seguir\u00e1 siendo quien cargue el modelo y responda a las peticiones. Lo que aporta Azure Local es la capa de infraestructura h\u00edbrida: c\u00f3mputo, almacenamiento, redes, virtualizaci\u00f3n, integraci\u00f3n con Azure Arc<\/strong> y una ruta hacia Kubernetes para operar el servicio con criterios empresariales.<\/p>\n\n\n\n

\n

QU\u00c9 VAMOS A CONSEGUIR<\/strong> Dise\u00f1aremos dos caminos: una m\u00e1quina virtual Linux con GPU para empezar de forma controlada y una plataforma con AKS habilitado por Azure Arc<\/strong> para escalar. El laboratorio principal se centrar\u00e1 en Kubernetes porque permite separar infraestructura, runtime y aplicaci\u00f3n.<\/p>\n<\/blockquote>\n\n\n\n

Me viene a la cabeza una pregunta que me hizo un amigo de la comunidad tecnol\u00f3gica.<\/p>\n\n\n\n

\u00bfPor qu\u00e9 ejecutar modelos de IA en local?<\/h1>\n\n\n\n
    \n
  • Mantener prompts, documentos, c\u00f3digo y respuestas dentro del per\u00edmetro definido por la organizaci\u00f3n.<\/li>\n\n\n\n
  • Reducir latencia cuando las aplicaciones y los datos ya est\u00e1n en el datacenter o en el Edge.<\/li>\n\n\n\n
  • Operar en ubicaciones con conectividad limitada o con requisitos estrictos de soberan\u00eda.<\/li>\n\n\n\n
  • Controlar el ciclo de vida del runtime, del modelo y de la infraestructura.<\/li>\n\n\n\n
  • Crear una API interna reutilizable por asistentes, automatizaciones, RAG y herramientas de desarrollo.<\/li>\n\n\n\n
  • Predecir el coste cuando la demanda es estable y el hardware se aprovecha de forma sostenida.<\/li>\n<\/ul>\n\n\n\n

    Tener el modelo en local no elimina los riesgos. Al contrario, nos convierte en responsables del parcheado, la protecci\u00f3n del endpoint, las licencias del modelo, la gesti\u00f3n de secretos, el filtrado de datos y la capacidad. La soberan\u00eda no consiste solo en guardar los pesos en nuestro CPD; tambi\u00e9n implica gobernar todo el servicio.<\/p>\n\n\n\n

    Azure Local como base para IA privada<\/h1>\n\n\n\n

    Podemos ver la soluci\u00f3n en cuatro capas:<\/p>\n\n\n\n

    Capa<\/strong><\/td>Componentes<\/strong><\/td>Responsabilidad<\/strong><\/td><\/tr>
    Infraestructura<\/td>Nodos Azure Local, red, almacenamiento, GPU<\/td>Disponibilidad, rendimiento y ciclo de vida del hardware.<\/td><\/tr>
    Plataforma<\/td>VM Linux o AKS habilitado por Azure Arc<\/td>Aislamiento, scheduling, actualizaciones y pol\u00edticas.<\/td><\/tr>
    Serving (publicar un modelo de IA como servicio para que se puedan utilizar)<\/td>vLLM, imagen de contenedor, cach\u00e9 de modelos<\/td>Carga de pesos, KV cache, batching y API.<\/td><\/tr>
    Consumo (Quien va a utilizar el modelo y como lo va a utilizar)<\/td>Aplicaciones, RAG, agentes, portales internos<\/td>Autenticaci\u00f3n, experiencia, datos y casos de uso.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Dos caminos de despliegue<\/h1>\n\n\n\n
    Opci\u00f3n<\/strong><\/td>Cuando elegirla<\/strong><\/td>Ventajas<\/strong><\/td>L\u00edmites<\/strong><\/td><\/tr>
    VM Linux + GPU<\/td>Piloto, un modelo, pocos consumidores<\/td>Sencilla, cercana al art\u00edculo anterior, troubleshooting directo.<\/td>Escalado y alta disponibilidad m\u00e1s manuales.<\/td><\/tr>
    AKS + GPU<\/td>Varios modelos o equipos, GitOps, necesidad de estandarizaci\u00f3n<\/td>Despliegues declarativos, servicios, rolling updates y pol\u00edticas.<\/td>M\u00e1s componentes, curva operativa y soporte GPU dependiente de versi\u00f3n.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Mi recomendaci\u00f3n es comenzar con una VM si todav\u00eda estamos validando el modelo y el patr\u00f3n de consumo. Cuando la API pase a ser un servicio compartido, tengamos varios consumidores o necesitemos una operaci\u00f3n repetible, Kubernetes empieza a aportarnos valor.<\/p>\n\n\n\n

    Arquitectura de referencia<\/h1>\n\n\n\n

    La siguiente arquitectura nos muestra c\u00f3mo podemos transformar un laboratorio basado en una \u00fanica GPU en una plataforma empresarial gobernada desde Azure.<\/strong> Los usuarios consumen una API interna protegida por un gateway, mientras que vLLM ejecuta los modelos sobre nodos con GPU dentro de Kubernetes. Azure Arc<\/strong> proporciona gobierno, pol\u00edticas y operaciones, mientras que Azure Local <\/strong>aporta la infraestructura de ejecuci\u00f3n.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    El endpoint de vLLM no deber\u00eda publicarse directamente en Internet. En producci\u00f3n lo normal es situarlo detr\u00e1s de una capa que termine TLS, autentique al cliente, aplique cuotas, limite el tama\u00f1o de las peticiones y genere trazabilidad.<\/p>\n\n\n\n

    Requisitos previos<\/h1>\n\n\n\n
      \n
    • Una instancia de Azure Local<\/strong> instalada, registrada y saludable.<\/li>\n\n\n\n
    • Hardware validado para la versi\u00f3n desplegada, incluida la opci\u00f3n de GPU cuando corresponda.<\/li>\n\n\n\n
    • AKS habilitado por Azure Arc<\/strong> operativo, o una VM Linux si elegimos el camino inicial.<\/li>\n\n\n\n
    • Driver y device plug-in compatibles con la GPU y con la versi\u00f3n de Kubernetes.<\/li>\n\n\n\n
    • Registro de contenedores autorizado y repositorio para manifiestos.<\/li>\n\n\n\n
    • Almacenamiento suficiente para imagen, pesos, cach\u00e9 y posibles variantes del modelo.<\/li>\n\n\n\n
    • Conectividad controlada hacia el registro y el repositorio del modelo, o un proceso offline de importaci\u00f3n.<\/li>\n\n\n\n
    • Licencia del modelo revisado y, si es necesario, credenciales de Hugging Face con permisos m\u00ednimos.<\/li>\n\n\n\n
    • DNS, certificados y una red privada para consumidores internos.<\/li>\n\n\n\n
    • Una estimaci\u00f3n de memoria GPU que incluya pesos, KV cache, contexto y concurrencia.<\/li>\n<\/ul>\n\n\n\n
      \n

      DECISI\u00d3N CR\u00cdTICA<\/strong> No seleccion\u00e9is un modelo solo por su n\u00famero de par\u00e1metros. La cuantizaci\u00f3n, la longitud de contexto, la la concurrencia y el runtime modifican de forma importante el consumo real de memoria.<\/p>\n<\/blockquote>\n\n\n\n

      Paso 1. Validar el cl\u00faster y localizar la GPU<\/h1>\n\n\n\n

      Antes de desplegar vLLM comprobaremos que Kubernetes ve el recurso acelerador. Los nombres exactos de los nodos y del recurso pueden variar seg\u00fan el plug-in utilizado.<\/p>\n\n\n\n

      kubectl get nodes -o wide

      kubectl describe nodes | grep -i -E \u00abnvidia.com\/gpu|gpu\u00bb

      kubectl get pods -A | grep -i nvidia<\/p>\n\n\n\n

      El resultado esperado es que al menos un nodo publique capacidad GPU y que los componentes del device plug-in est\u00e9n en estado Running. Si Kubernetes no anuncia la GPU, no merece la pena continuar con el modelo: primero debemos resolver driver, firmware, asignaci\u00f3n y compatibilidad.<\/p>\n\n\n\n

      Paso 2. Preparar namespace, secretos y almacenamiento<\/h1>\n\n\n\n

      Separaremos la carga en un namespace y as\u00ed evitaremos incluir tokens directamente en el manifiesto.<\/p>\n\n\n\n

      kubectl create namespace ai-inference

      kubectl -n ai-inference create secret generic hf-token \\
        –from-literal=token=\u00bbhf_REEMPLAZAR\u00bb<\/p>\n\n\n\n

      Para la cach\u00e9 del modelo necesitamos una StorageClass disponible en el cl\u00faster. El siguiente ejemplo solicitamos 200 GiB; ajustamos el tama\u00f1o del modelo y a vuestra pol\u00edtica de almacenamiento.<\/p>\n\n\n\n

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: hf-cache
        namespace: ai-inference
      spec:
        accessModes:
          – ReadWriteOnce
        resources:
          requests:
            storage: 200Gi
        storageClassName: REEMPLAZAR_STORAGECLASS<\/p>\n\n\n\n

      Paso 3. Desplegar vLLM con GPU<\/h1>\n\n\n\n

      Este manifiesto es una base de laboratorio. Fijaremos una imagen versionada en lugar de latest, solicitaremos una GPU y montaremos la cach\u00e9. Debemos sustituir el modelo, la etiqueta de imagen y los valores de capacidad por versiones validadas en nuestro entorno.<\/p>\n\n\n\n

      apiVersion: apps\/v1
      kind: Deployment
      metadata:
        name: vllm
        namespace: ai-inference
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: vllm
        template:
          metadata:
            labels:
              app: vllm
          spec:
            containers:
              – name: vllm
                image: vllm\/vllm-openai:REEMPLAZAR_VERSION
                args:
                  – –model
                  – REEMPLAZAR_MODELO
                  – –max-model-len
                  – \u00ab8192\u00bb
                  – –gpu-memory-utilization
                  – \u00ab0.80\u00bb
                env:
                  – name: HF_TOKEN
                    valueFrom:
                      secretKeyRef:
                        name: hf-token
                        key: token
                ports:
                  – name: http
                    containerPort: 8000
                resources:
                  requests:
                    cpu: \u00ab4\u00bb
                    memory: 24Gi
                    nvidia.com\/gpu: \u00ab1\u00bb
                  limits:
                    cpu: \u00ab8\u00bb
                    memory: 48Gi
                    nvidia.com\/gpu: \u00ab1\u00bb
                readinessProbe:
                  httpGet:
                    path: \/health
                    port: http
                  initialDelaySeconds: 30
                  periodSeconds: 10
                  failureThreshold: 60
                volumeMounts:
                  – name: hf-cache
                    mountPath: \/root\/.cache\/huggingface
            volumes:
              – name: hf-cache
                persistentVolumeClaim:
                  claimName: hf-cache<\/p>\n\n\n\n

      En un cl\u00faster con nodos heterog\u00e9neos a\u00f1adiremos labels, nodeSelector o affinity para que el pod solo se programe donde exista la GPU adecuada. Tambi\u00e9n es habitual aplicar taints a los nodos acelerados para reservarlos a las cargas de IA.<\/p>\n\n\n\n

      Paso 4. Exponer el servicio dentro de la red<\/h1>\n\n\n\n

      apiVersion: v1
      kind: Service
      metadata:
        name: vllm
        namespace: ai-inference
      spec:
        selector:
          app: vllm
        ports:
          – name: http
            port: 8000
            targetPort: http
        type: ClusterIP<\/p>\n\n\n\n

      ClusterIP mantiene el servicio accesible \u00fanicamente dentro de Kubernetes. Para consumidores externos al cl\u00faster utilizaremos un ingress controller, un reverse proxy o un balanceador interno con TLS y autenticaci\u00f3n. No cambiaremos a LoadBalancer sin haber definido antes red, exposici\u00f3n y controles de acceso.<\/p>\n\n\n\n

      Paso 5. Aplicar y validar<\/h1>\n\n\n\n

      kubectl apply -f pvc.yaml
      kubectl apply -f deployment.yaml
      kubectl apply -f service.yaml

      kubectl -n ai-inference rollout status deployment\/vllm
      kubectl -n ai-inference get pods -o wide
      kubectl -n ai-inference logs -f deployment\/vllm<\/p>\n\n\n\n

      La primera carga ser\u00e1 m\u00e1s lenta porque se debe descargar o leer los pesos. Esperaremos a que la readiness probe est\u00e9 correcta y despu\u00e9s haremos una prueba temporal mediante port-forward.<\/p>\n\n\n\n

      kubectl -n ai-inference port-forward service\/vllm 8000:8000

      curl http:\/\/127.0.0.1:8000\/health<\/p>\n\n\n\n

      Paso 6. Probar la API compatible con OpenAI<\/h1>\n\n\n\n

      curl http:\/\/127.0.0.1:8000\/v1\/chat\/completions \\
        -H \u00abContent-Type: application\/json\u00bb \\
        -d ‘{
          \u00abmodel\u00bb: \u00abREEMPLAZAR_MODELO\u00bb,
          \u00abmessages\u00bb: [
            {\u00abrole\u00bb: \u00absystem\u00bb, \u00abcontent\u00bb: \u00abResponde en espa\u00f1ol y de forma concisa.\u00bb},
            {\u00abrole\u00bb: \u00abuser\u00bb, \u00abcontent\u00bb: \u00abExplica qu\u00e9 aporta Azure Local a una plataforma de IA privada.\u00bb}
          ],
          \u00abmax_tokens\u00bb: 300,
          \u00abtemperature\u00bb: 0.2
        }’<\/p>\n\n\n\n

      Si obtenemos un array choices y contenido en message.content, el flujo b\u00e1sico funciona. Esto solo valida funcionalidad, no capacidad ni seguridad.<\/p>\n\n\n\n

      Paso 7. Consumirlo desde Python<\/h1>\n\n\n\n

      from openai import OpenAI

      client = OpenAI(
          base_url=\u00bbhttps:\/\/ia.interna.ejemplo\/v1″,
          api_key=\u00bbtoken-obtenido-del-gateway\u00bb
      )

      respuesta = client.chat.completions.create(
          model=\u00bbREEMPLAZAR_MODELO\u00bb,
          messages=[
              {\u00abrole\u00bb: \u00abuser\u00bb, \u00abcontent\u00bb: \u00abResume las ventajas de Azure Local.\u00bb}
          ],
          max_tokens=300,
          temperature=0.2
      )

      print(respuesta.choices[0].message.content)<\/p>\n\n\n\n

      La compatibilidad con el formato OpenAI simplifica la integraci\u00f3n, pero no significa que todas las extensiones o comportamientos sean id\u00e9nticos. Debemos probar el cliente, el modelo y el endpoint concretos.<\/p>\n\n\n\n

      Seguridad: lo m\u00ednimo para producci\u00f3n<\/h1>\n\n\n\n
      Control<\/strong><\/td>Aplicaci\u00f3n pr\u00e1ctica<\/strong><\/td><\/tr>
      Red<\/td>Endpoint privado, segmentaci\u00f3n, firewall y acceso solo desde redes autorizadas.<\/td><\/tr>
      Identidad<\/td>Autenticaci\u00f3n en gateway; evitar confiar en una clave de laboratorio colocada en el cliente.<\/td><\/tr>
      TLS<\/td>Certificados internos o p\u00fablicos seg\u00fan el escenario; rotaci\u00f3n automatizada.<\/td><\/tr>
      Secretos<\/td>Secretos fuera de YAML y repositorios; rotaci\u00f3n y privilegio m\u00ednimo.<\/td><\/tr>
      Im\u00e1genes<\/td>Versiones fijadas, an\u00e1lisis de vulnerabilidades y registro autorizado.<\/td><\/tr>
      Modelos<\/td>Licencia, procedencia, hash, versionado y proceso de aprobaci\u00f3n.<\/td><\/tr>
      Datos<\/td>Clasificaci\u00f3n, DLP, retenci\u00f3n y prevenci\u00f3n de prompts con informaci\u00f3n innecesaria.<\/td><\/tr>
      Abuso<\/td>Cuotas, l\u00edmites de tokens, tama\u00f1o m\u00e1ximo de prompt, timeout y l\u00edmites por consumidor.<\/td><\/tr>
      Auditor\u00eda<\/td>Registrar identidad, modelo, latencia, tokens y resultado t\u00e9cnico sin almacenar datos sensibles por defecto.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      \n

      NO OLVIDEMOS<\/strong> Un modelo local puede inventar informaci\u00f3n, revelar contenido presente en su contexto o producir una respuesta insegura. La ubicaci\u00f3n del modelo no sustituye la validaci\u00f3n de salida, el dise\u00f1o responsable ni los controles de aplicaci\u00f3n.<\/p>\n<\/blockquote>\n\n\n\n

      Alta disponibilidad y escalado<\/h1>\n\n\n\n

      Aumentar r\u00e9plicas de un Deployment no siempre es suficiente. Cada r\u00e9plica puede requerir una GPU completa y su propia carga de pesos. La estrategia depender\u00e1 del modelo, la memoria y el runtime.<\/p>\n\n\n\n

        \n
      • Una r\u00e9plica por GPU y balanceo entre r\u00e9plicas cuando cada modelo cabe en una GPU.<\/li>\n\n\n\n
      • Tensor parallel o pipeline parallel cuando un modelo necesita varias GPU, validando topolog\u00eda y rendimiento.<\/li>\n\n\n\n
      • Replicas separadas por modelo para evitar que modelos con perfiles distintos compitan por memoria.<\/li>\n\n\n\n
      • Escalado basado en cola o concurrencia, no solo en CPU.<\/li>\n\n\n\n
      • PodDisruptionBudget, anti-affinity y pruebas reales de reinicio y mantenimiento.<\/li>\n\n\n\n
      • Cach\u00e9 precargada o repositorio local para reducir el tiempo de recuperaci\u00f3n.<\/li>\n<\/ul>\n\n\n\n

        Observabilidad y pruebas de capacidad<\/h1>\n\n\n\n
        M\u00e9trica<\/strong><\/td>Qu\u00e9 nos dice<\/strong><\/td>Se\u00f1al de alerta<\/strong><\/td><\/tr>
        TTFT<\/td>Tiempo hasta el primer token<\/td>Cola, prompt largo o modelo saturado.<\/td><\/tr>
        Tokens\/s<\/td>Velocidad de generaci\u00f3n<\/td>Ca\u00eddas al aumentar concurrencia.<\/td><\/tr>
        Concurrencia<\/td>Sesiones atendidas<\/td>Errores, timeouts o esperas largas.<\/td><\/tr>
        Memoria GPU<\/td>Margen para pesos y KV cache<\/td>OOM, evictions o reinicios.<\/td><\/tr>
        Utilizaci\u00f3n GPU<\/td>Aprovechamiento del acelerador<\/td>Muy baja con cola, o sostenida al 100 %.<\/td><\/tr>
        Latencia total<\/td>Experiencia extremo a extremo<\/td>Gateway, red, retrieval o inferencia.<\/td><\/tr>
        Errores HTTP<\/td>Salud del servicio<\/td>429, 5xx y timeouts crecientes.<\/td><\/tr>
        Tama\u00f1o de prompt<\/td>Presi\u00f3n de contexto<\/td>Usuarios enviando documentos completos sin control.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

        Las pruebas se deben utilizar prompts y contextos representativos. Una pregunta corta desde curl no predice c\u00f3mo funcionar\u00e1 un asistente RAG con documentos extensos y varios usuarios simult\u00e1neos.<\/p>\n\n\n\n

        Operaci\u00f3n desconectada y soberan\u00eda<\/h1>\n\n\n\n

        Si el entorno debe operar con conectividad limitada, prepararemos un flujo de suministro controlado: im\u00e1genes copiadas a un registro local, pesos descargados y validados previamente, dependencias congeladas, certificados disponibles y documentaci\u00f3n para renovar o importar artefactos. Tambi\u00e9n debemos distinguir entre ejecutar la carga sin Internet y administrar toda la plataforma de forma completamente desconectada; no son el mismo requisito y pueden implicar capacidades, licencias y procedimientos diferentes.<\/p>\n\n\n\n

        Errores comunes y troubleshooting<\/h1>\n\n\n\n
        S\u00edntoma<\/strong><\/td>Causa probable<\/strong><\/td>Comprobaci\u00f3n<\/strong><\/td><\/tr>
        Pod Pending<\/td>No hay GPU disponible o selector incorrecto<\/td>kubectl describe pod y capacidad del nodo.<\/td><\/tr>
        CrashLoopBackOff<\/td>Modelo incompatible, argumentos err\u00f3neos u OOM<\/td>Logs del contenedor y eventos del pod.<\/td><\/tr>
        CUDA no disponible<\/td>Driver o device plug-in no operativo<\/td>DaemonSet, runtime y recurso nvidia.com\/gpu.<\/td><\/tr>
        Descarga interminable<\/td>Token, licencia, DNS o salida bloqueada<\/td>Secret, acceso al repositorio y proxy.<\/td><\/tr>
        Readiness no pasa<\/td>Carga lenta o ruta de salud incorrecta<\/td>Logs, \/health e initialDelay\/failureThreshold.<\/td><\/tr>
        OOM con pocas peticiones<\/td>Contexto o KV cache sobredimensionados<\/td>Reducir max-model-len y medir concurrencia.<\/td><\/tr>
        Respuesta lenta<\/td>Modelo grande, almacenamiento lento o cola<\/td>TTFT, tokens\/s, GPU y latencia de cach\u00e9.<\/td><\/tr>
        Servicio inaccesible<\/td>DNS, ingress, firewall o Service mal definido<\/td>Endpoints, NetworkPolicy y ruta completa.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

        \u00bfCu\u00e1ndo no elegir esta arquitectura?<\/h1>\n\n\n\n
          \n
        • Si nuestra demanda es muy variable y no justifica mantener GPU propia.<\/li>\n\n\n\n
        • Si necesitamos modelos propietarios disponibles \u00fanicamente como servicio cloud.<\/li>\n\n\n\n
        • Si el equipo no puede operar Kubernetes, GPU, seguridad y observabilidad de forma sostenida.<\/li>\n\n\n\n
        • Si el objetivo es una prueba r\u00e1pida y una VM aislada cubre el caso.<\/li>\n\n\n\n
        • Si no existe un requisito real de latencia, soberan\u00eda o integraci\u00f3n local que compense la complejidad.<\/li>\n<\/ul>\n\n\n\n

          La decisi\u00f3n no es local contra cloud como si fueran opciones excluyentes. Muchas organizaciones terminar\u00e1n con un enfoque h\u00edbrido: modelos locales para informaci\u00f3n sensible o baja latencia y servicios cloud para capacidades espec\u00edficas, picos de demanda o modelos que no pueden alojar por s\u00ed mismas.<\/p>\n\n\n\n

          Conclusi\u00f3n<\/h1>\n\n\n\n

          En el art\u00edculo anterior demostramos que un Dell Pro Max GB10 se puede convertir en un laboratorio de inferencia muy capaz con vLLM. Con Azure Local <\/strong>damos el siguiente paso: transformamos ese patr\u00f3n t\u00e9cnico en una plataforma que puede integrarse con la infraestructura, la red, el almacenamiento y el gobierno de una organizaci\u00f3n.<\/p>\n\n\n\n

          La pieza clave es separar responsabilidades. Azure Local <\/strong>aporta la base h\u00edbrida; AKS habilitado por Azure Arc<\/strong> organiza la ejecuci\u00f3n; la GPU acelera la inferencia; vLLM sirve el modelo; y la capa de acceso protege y gobierna el consumo. Cuando cada capa tiene l\u00edmites y propietarios claros, la IA local deja de ser un experimento conectado a una GPU y empieza a comportarse como un servicio de plataforma.<\/p>\n\n\n\n

          Mi recomendaci\u00f3n es avanzar por etapas: primero un modelo y un caso de uso medible, despu\u00e9s seguridad y observabilidad, y finalmente alta disponibilidad y automatizaci\u00f3n. Y, como siempre, probadlo primero en laboratorio antes de llevarlo a producci\u00f3n.<\/p>\n\n\n\n

          Saludos, nos vemos en el pr\u00f3ximo art\u00edculo.<\/p>\n","protected":false},"excerpt":{"rendered":"

          Hola a tod@s, En el art\u00edculo anterior vimos c\u00f3mo desplegar y servir un LLM con vLLM en un Dell Pro Max GB10. La idea era sencilla y muy \u00fatil para laboratorio o para un entorno peque\u00f1o: Linux, GPU NVIDIA, Docker, un modelo descargado desde Hugging Face y una API compatible con OpenAI. Pero al llevar […]<\/p>\n","protected":false},"author":1,"featured_media":368,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,6,12,36,35],"tags":[8,13,10,37],"class_list":["post-631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-azure-arc","category-azure-local","category-ia","category-linux","tag-azure","tag-azure-local","tag-hci","tag-ia-linux"],"_links":{"self":[{"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts\/631","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/comments?post=631"}],"version-history":[{"count":13,"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts\/631\/revisions"}],"predecessor-version":[{"id":646,"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/posts\/631\/revisions\/646"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/media\/368"}],"wp:attachment":[{"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/media?parent=631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/categories?post=631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.darifer.net\/index.php\/wp-json\/wp\/v2\/tags?post=631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}