Tag:

Azure

Mundo

Microsoft destituye a su gerente en Israel por escándalo de espionaje en Palestina

by Editor de Mundo
written by Editor de Mundo

Microsoft destituye a directivo en Israel tras denuncias por vigilancia

La compañía tecnológica Microsoft ha tomado medidas drásticas en sus operaciones en Israel, confirmando la destitución de su gerente general, Alon Haimovich. Esta decisión se produce en el marco de un escándalo relacionado con la supuesta utilización de servicios en la nube de la empresa para actividades de vigilancia contra la población palestina.

Además de la salida de Haimovich, los reportes indican que la multinacional ha procedido con el despido de otros miembros del personal directivo y empleados de alto rango en la región. Las medidas disciplinarias están directamente vinculadas con las investigaciones en curso sobre el papel de la tecnología de la empresa en el contexto de la guerra en Gaza.

Hasta el momento, la compañía no ha ofrecido detalles adicionales sobre el alcance total de la investigación interna, pero la cúpula directiva ha confirmado el cese de las funciones de Haimovich, quien lideraba las operaciones de Microsoft en el territorio. La situación ha generado una notable atención mediática, centrando el debate en la responsabilidad ética de las grandes corporaciones tecnológicas frente al uso de sus herramientas de computación en la nube en zonas de conflicto.

Generative AI “is not a trend” for employees, says Microsoft Israel | Alon Haimovich | CTech
0 comments
0 FacebookTwitterPinterestLinkedinEmail
Negocio

Dudas de los inversores sobre la rentabilidad de la IA

by Editora de Negocio
written by Editora de Negocio

Los inversores muestran una creciente preocupación respecto a si las masivas cantidades de dinero que se están destinando a la infraestructura de inteligencia artificial (IA) generarán los retornos esperados.

En este contexto de alta inversión, Meta ha anunciado que invertirá 21,000 millones de dólares adicionales en la infraestructura de IA de CoreWeave.

Asimismo, Alphabet se encuentra desarrollando discretamente su próximo gran negocio, el cual podría alcanzar una escala considerable.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

AKS: Asignación Dinámica de GPU con vGPU de NVIDIA

by Editor de Tecnologia
written by Editor de Tecnologia

El equipo de Azure Kubernetes Service (AKS) ha publicado una guía detallada sobre cómo utilizar la Asignación Dinámica de Recursos (DRA) con la tecnología NVIDIA vGPU en AKS. Esta actualización mejora el control y la eficiencia para el uso compartido de GPU en tareas de IA y medios.

La Asignación Dinámica de Recursos (DRA) es ahora el estándar para el uso de recursos de GPU en Kubernetes. En lugar de recursos estáticos como nvidia.com/gpu, las GPU se asignan dinámicamente utilizando DeviceClasses y ResourceClaims. Este cambio mejora la programación e integra mejor las tecnologías de virtualización como NVIDIA vGPU.

La razón para combinar estas tecnologías es clara: los aceleradores virtuales como NVIDIA vGPU a menudo manejan tareas más pequeñas. Permiten que una GPU física se divida entre muchos usuarios o aplicaciones. Esta configuración es útil para el desarrollo empresarial de IA/ML, el ajuste fino y el procesamiento de audio y video. VGPU ofrece un rendimiento predecible al tiempo que proporciona capacidades CUDA a las cargas de trabajo en contenedores.

En el lado de la infraestructura, esta función se basa en la serie de máquinas virtuales NVadsA10_v5 de Azure. En lugar de asignar toda la GPU a una sola VM, la tecnología vGPU la divide en múltiples segmentos de tamaño fijo en la capa del hipervisor. Desde la perspectiva de Kubernetes, cada VM muestra un dispositivo GPU claro. El hipervisor establece los límites de capacidad y memoria, no el software.

La configuración requiere Kubernetes 1.34 o superior. En este momento, los primitivos DRA como deviceclasses y resourceslices están disponibles. Los equipos aprovisionan un grupo de nodos con instancias NVadsA10_v5 y aplican una etiqueta (nvidia.com/gpu.present=true) para el plugin kubelet NVIDIA DRA como su selector de nodos. Luego, implementan el controlador NVIDIA DRA a través de Helm. La publicación destaca tres banderas importantes de Helm para escenarios vGPU. La bandera gpuResourcesEnabledOverride=true omite una verificación que impide que el controlador NVIDIA DRA se instale con el plugin de dispositivo heredado debido a diferentes nombres de GPU. FeatureGates.IMEXDaemonsWithDNSNames=false deshabilita una función IMEX que requiere una versión del controlador GRID más reciente que la compatible en la serie A10 en Azure.

Una vez que el controlador está activo, escanea cada nodo, detecta el único dispositivo vGPU de la VM de Azure y lo registra en el plano de control de Kubernetes como un dispositivo administrado por DRA. Cada nodo registra un dispositivo asignable porque eso es lo que presenta la VM. Los operadores pueden verificar la configuración buscando la gpu.nvidia.com DeviceClass y ResourceSlices. De esta manera, pueden confirmar que el plano de control ha encontrado el hardware disponible.

Además del segmento base de un sexto (Standard_NV6ads_A10_v5), la serie ofrece un perfil de un tercio con 8 GB de memoria aceleradora y un perfil de la mitad con 12 GB. Los límites se aplican en la capa del hipervisor, por lo que AKS ve un único dispositivo GPU con una capacidad predecible. Esto brinda a los equipos de plataforma la flexibilidad de dimensionar la asignación de GPU según las necesidades de la carga de trabajo sin sobreaprovisionar los nodos.

El equipo de AKS enmarca la importancia general como direccional. A medida que las GPU se convierten en recursos de primera clase en Kubernetes, combinar la GPU virtualizada con DRA ofrece una forma práctica de ejecutar cargas de trabajo compartidas y de nivel de producción. Para las implementaciones de AKS a gran escala, especialmente en industrias reguladas o sensibles a los costos, la ubicación y utilización óptimas de la GPU impactan directamente en el rendimiento del trabajo y la eficiencia de la infraestructura. El uso de DRA con vGPU ayuda a las organizaciones a pasar de la asignación a nivel de nodo gruesa a un uso de GPU controlado y basado en la carga de trabajo a escala.

Google Cloud está siguiendo un camino similar en GKE, centrándose en DRA como un primitivo de programación tanto para GPU como para TPU. El soporte de DRA de GKE permite a las cargas de trabajo utilizar expresiones CEL para filtrar dispositivos con atributos específicos. Esto permite que un único manifiesto se implemente en diferentes clústeres con varios tipos de GPU sin cambios. Específicamente para vGPU, Google recientemente presentó de forma preliminar VM G4 fraccionadas que utilizan la tecnología NVIDIA vGPU basada en la GPU RTX PRO 6000 Blackwell, administrada a través de GKE y combinada con el empaquetamiento de contenedores para una mayor utilización. Cuando se programa a través del Programador de Carga de Trabajo Dinámica de Google, las prioridades de respaldo pueden mejorar el acceso a los recursos.

Amazon EKS adopta un enfoque diferente, utilizando DRA principalmente para simplificar la complejidad de su hardware GPU de alta gama en lugar de compartirlo fraccionadamente. Amazon EKS hizo que DRA estuviera disponible de forma general a partir de la versión de Kubernetes 1.33. Esta tecnología es esencial para las instancias P6e-GB200 UltraServer, donde la programación estática tradicional de GPU no puede modelar la interconexión NVLink e IMEX necesaria para las cargas de trabajo de varios nodos. Para los equipos que ejecutan cargas de trabajo más pequeñas que desean compartir GPU en EKS, DRA ahora admite solicitudes basadas en atributos estructuradas. Esto permite a los programadores responder a solicitudes como «una partición MIG de 10 GB con al menos 1/7 de capacidad de cómputo» en lugar de tratar las GPU como simples recuentos. En todos los tres proveedores de la nube, el cambio de los plugins de dispositivos estáticos a DRA se está acelerando, impulsado por la necesidad de una programación de GPU más expresiva y consciente de la topología a medida que la infraestructura de IA crece en complejidad y costo.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

Ray en AKS: Escala IA/ML con Azure, Anyscale y GPUs

by Editor de Tecnologia
written by Editor de Tecnologia

El equipo de Azure Kubernetes Service (AKS) de Microsoft ha compartido recomendaciones para ejecutar el servicio gestionado Ray de Anyscale a escala. Se centran en tres problemas clave: los límites de capacidad de las GPU, el almacenamiento de ML disperso y los problemas con la caducidad de las credenciales.

Esta publicación amplía una visión general anterior de KubeRay en AKS de código abierto. Ahora, destaca el runtime mejorado de Anyscale, anteriormente conocido como RayTurbo. Este runtime ofrece escalado automático inteligente, monitorización mejorada y funciones de entrenamiento tolerante a fallos, todo ello basado en el framework Ray de código abierto.

Ray es un framework de computación distribuida nativo de Python diseñado para escalar cargas de trabajo de IA y ML desde un único portátil hasta clústeres que abarcan miles de nodos. La plataforma gestionada de Anyscale mejora Ray con funciones para su uso en producción. La nueva guía muestra una colaboración entre Microsoft y Anyscale para mejorar la integración con Azure.

La escasez de GPU es uno de los mayores desafíos operativos en el ML a gran escala. Los aceleradores de alta demanda, como las GPU NVIDIA, a menudo tienen problemas de cuota y disponibilidad en las regiones de Azure, lo que puede retrasar la configuración del clúster y la programación de trabajos.

La solución propuesta por Microsoft utiliza una configuración multi-clúster y multi-región. Distribuir los clústeres Ray en diferentes instancias de AKS en varias regiones de Azure permite a los equipos: agregar cuota de GPU más allá de los límites regionales, redirigir automáticamente las cargas de trabajo durante las interrupciones o los problemas de capacidad y extender el grupo de computación a sistemas locales u otros proveedores de la nube utilizando Azure Arc con AKS.

La consola de Anyscale muestra estos clústeres registrados en una sola vista. Anyscale Workspaces gestiona la programación de cargas de trabajo utilizando la capacidad disponible, ya sea manualmente o automáticamente. Puede agregar nuevas regiones creando un manifiesto cloud_resource.yaml y luego aplicándolo mediante la CLI de Anyscale. Este enfoque basado en la configuración facilita la gestión de la expansión multi-región.

Un problema común en las operaciones de ML es la transferencia de datos de entrenamiento, puntos de control y artefactos entre las etapas de la canalización, incluyendo su movimiento desde el pre-entrenamiento hasta el ajuste fino y luego a la inferencia. La guía aborda esto con Azure BlobFuse2, que monta Azure Blob Storage en los pods de trabajador de Ray como un sistema de archivos compatible con POSIX.

Desde la perspectiva de Ray, el punto de montaje es simplemente un directorio local. Las tareas y los actores leen conjuntos de datos y escriben puntos de control utilizando la E/S de archivos estándar. BlobFuse2 luego guarda los datos en Azure Blob Storage, lo que los hace disponibles en todos los pods y grupos de nodos. El almacenamiento en caché local evita los bloqueos de la GPU durante las ejecuciones de entrenamiento a gran escala y, dado que los datos están desacoplados de la computación, los clústeres Ray pueden escalar hacia arriba y hacia abajo sin pérdida de datos.

Para configurar, habilite el controlador CSI de blob al crear el clúster. Luego, defina una StorageClass que utilice la identidad de carga de trabajo para la autenticación. Finalmente, cree una PersistentVolumeClaim con acceso ReadWriteMany. Esto permite que varios trabajadores de Ray en diferentes nodos accedan a los datos compartidos al mismo tiempo. Este enfoque hace que el código de Ray sea portátil y agrega la durabilidad y la escalabilidad del almacenamiento nativo de Azure a la capa de infraestructura.

Otro tema importante es la fiabilidad de la autenticación. Anteriormente, Anyscale y Azure se integraban con tokens de CLI o claves de API que caducaban cada 30 días. Esto significaba que era necesaria una rotación manual, lo que corría el riesgo de interrumpir el servicio.

El nuevo método utiliza Microsoft Entra service principals y AKS workload identity. Emite tokens de corta duración automáticamente. El pod del operador de Kubernetes de Anyscale utiliza una identidad administrada asignada por el usuario. Esta identidad solicita un token de acceso para el principal de servicio de Anyscale desde Entra ID. Azure gestiona la actualización de los tokens de forma transparente, lo que significa que no se almacenan credenciales de larga duración en el clúster y no se requiere una rotación manual.

Los autores señalan que esto es especialmente importante en entornos multi-clúster. Aquí, la gestión manual de las credenciales en muchos clústeres aumenta la carga operativa. El modelo de identidad de carga de trabajo proporciona RBAC granular para el acceso a los recursos de Azure y produce pistas de auditoría completas a través de los registros de actividad de Azure como subproducto.

La integración de Anyscale en AKS está actualmente en vista previa privada. Los equipos que deseen acceder deben comunicarse con su equipo de cuenta de Microsoft. También pueden presentar una solicitud en el repositorio de GitHub de AKS. Incluya detalles sobre las cargas de trabajo de Ray y las regiones objetivo. Puede consultar configuraciones de ejemplo y cargas de trabajo para el ajuste fino con DeepSpeed y LLaMA-Factory en el repositorio Azure-Samples/aks-anyscale en GitHub. Esto también incluye puntos finales de inferencia LLM.

Microsoft no es la única entidad que apuesta por esto. AWS anunció su asociación con Anyscale en Ray Summit 2024. Esto conecta los clústeres de EKS con el runtime RayTurbo. Destaca la flexibilidad del hardware al combinar las GPU NVIDIA con los aceleradores Trainium e Inferentia de AWS. Además, SageMaker HyperPod es ahora un destino de implementación para trabajos de entrenamiento de larga duración que necesitan resistencia a nivel de nodo. Google Cloud lidera las contribuciones de código abierto.

El equipo de GKE trabajó con ingenieros de Anyscale para integrar la programación basada en etiquetas en Ray v2.49. También crearon una capa ray.util.tpu para reducir la fragmentación de recursos en configuraciones de TPU multi-chip. Además, agregaron la asignación dinámica de recursos para las nuevas instancias respaldadas por GB200.

Los tres hiperescaladores han elegido el mismo operador gestionado de Ray y cada uno ha agregado su infraestructura. Esto demuestra que la industria prefiere Kubernetes más Ray para las cargas de trabajo de IA. Ahora, la competencia es menos sobre el runtime y más sobre qué nube puede optimizar mejor la infraestructura circundante.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

Soberanía Digital: Europa Reduce Dependencia de EEUU

by Editor de Tecnologia
written by Editor de Tecnologia

Las empresas y administraciones europeas están reevaluando su dependencia digital.

Lo que durante mucho tiempo se consideró una decisión pragmática en materia de TI –el uso de Microsoft 365, Azure o los servicios de Google– se está convirtiendo cada vez más en una cuestión de riesgo, cumplimiento y competitividad. Esto convierte a la soberanía digital en un tema clave para la ubicación de las empresas.

El poder del mercado se enfrenta al riesgo legal

Un estudio del Parlamento Europeo describe claramente la situación: los proveedores estadounidenses dominan las capas centrales de la creación de valor digital, desde la infraestructura en la nube hasta el software empresarial. AWS, Microsoft Azure y Google Cloud concentran alrededor del 70 por ciento del mercado europeo de la nube. Los formatos propietarios, los ecosistemas integrados y los contratos a largo plazo intensifican la dependencia.

A esto se suman las incertidumbres jurídicas. La sentencia Schrems II del Tribunal de Justicia Europeo (2020) anuló el entonces vigente acuerdo de transferencia de datos entre la UE y Estados Unidos y endureció los requisitos para las transferencias de datos a Estados Unidos. Las empresas deben evaluar cuidadosamente desde entonces cómo se pueden procesar los datos personales con proveedores estadounidenses. La Ley US CLOUD también se considera un riesgo potencial de acceso. Para los consejos de administración, esto significa que la arquitectura de TI ya no es solo una cuestión de costes o eficiencia, sino parte de la gestión estratégica del riesgo.

Francia apuesta por el control estatal

Francia está impulsando políticamente la soberanía digital. El gobierno planea reemplazar gradualmente Microsoft Teams y Zoom con una plataforma nacional de videoconferencia („Visio“) para 2027. La base es la estrategia „Cloud-au-centre“, que vincula el uso de la nube a requisitos claros en cuanto a la soberanía de los datos, la cualificación de los proveedores y el espacio jurídico.

Ya en 2022, el Ministerio de Educación recomendó no utilizar las versiones gratuitas de Microsoft 365 y Google Workspace en las escuelas, citando la protección de datos y Schrems II. El enfoque de Francia: utilizar la demanda pública como instrumento de política industrial para promover alternativas europeas y reducir las dependencias.

Austria elige un camino intermedio

Mientras que Francia apuesta por la sustitución, Austria sigue un enfoque de regulación. La estrategia nacional de la nube sigue el principio „Cloud first“, pero bajo reglas claras para la protección de datos, la seguridad de la información y la evaluación de riesgos. La protección y el cumplimiento son decisivos.

El Bundesrechenzentrum (BRZ), que opera gran parte de la TI federal, desempeña un papel central. Actúa como integrador, conectando soluciones de software internacionales con una estructura nacional de operación y control. Este modelo no implica un abandono abrupto de Microsoft, sino un mayor control estatal sobre el almacenamiento de datos y la arquitectura de seguridad.

Además, Austria participa en GAIA-X, la iniciativa europea para espacios de datos interoperables y soberanos. El objetivo es definir estándares técnicos comunes, independientemente de la ubicación de los proveedores individuales. Austria apuesta así por una dependencia controlada en lugar de una desconexión total.

Las empresas de Tirol entre eficiencia y autonomía

En Tirol, las demandas de autonomía digital son cada vez más fuertes. Muchas empresas locales –desde la industria y el turismo hasta los proveedores de energía y las instituciones públicas– están examinando actualmente cómo pueden operar las soluciones en la nube de forma segura, conforme a la ley y económicamente.

Precisamente en una región impulsada por la innovación como Tirol, donde muchas empresas dependen de soluciones de software internacionales, surge la pregunta clave: ¿Cómo se puede conciliar la competitividad con la soberanía de los datos?

Los proveedores de servicios de TI regionales y las iniciativas ya están trabajando para conectar los estándares de la nube europeos con los requisitos locales, un modelo que puede hacer de Tirol una ubicación económica más independiente y resiliente.

Reacción de los proveedores estadounidenses

Microsoft y otras empresas estadounidenses están reaccionando: con iniciativas como „EU Data Boundary“, los datos de los clientes se procesarán en el futuro exclusivamente en la UE. El concepto de „Sovereign Cloud“ en cooperación con socios europeos también se presenta como un compromiso. Sin embargo, la pregunta clave sigue abierta: ¿Es suficiente la localización de datos bajo la estructura de una empresa estadounidense, o necesita Europa una verdadera autonomía tecnológica?

Realidad económica en lugar de la idea de la autarquía

La autonomía tecnológica completa se considera poco realista. Las cadenas de suministro globales, los ecosistemas de software y los ciclos de innovación están estrechamente entrelazados. Por lo tanto, incluso los grandes proveedores de servicios de TI europeos abogan por una soberanía escalonada, dependiendo de las necesidades de protección y del modelo de negocio, en lugar de un aislamiento generalizado.

Esto implica una clara tarea de revisión para las empresas:

  • Definir la criticidad: ¿Qué datos y procesos son estratégicamente sensibles?
  • Analizar el bloqueo: ¿Cuáles son los costes de cambio y las dependencias?
  • Evaluar el marco legal: ¿Qué riesgos existen en la transferencia y el acceso a los datos?
  • Desarrollar estrategias de salida: ¿Existen alternativas interoperables y rutas de migración?

Conclusión

El paso alejarse de Microsoft & Co. no es un reflejo ideológico, sino una expresión de nuevas condiciones: tensiones geopolíticas, requisitos de protección de datos más estrictos y el reconocimiento de que la infraestructura digital es un factor de producción estratégico. Francia apuesta por la sustitución, Austria por la regulación. Ambos caminos demuestran:

La soberanía digital se ha convertido en una cuestión de ubicación económica y debe estar en la agenda de cada consejo de administración.

0 comments
0 FacebookTwitterPinterestLinkedinEmail

Para contacto, publicidad, derechos de autor o incidencias, escriba a: office@notiulti.com