Publicado el — Deja un comentario

Amazon Cognito now supports self-service provisioned API rate limits

Amazon Cognito now allows you to increase or decrease your provisioned API rate limits on demand. Cognito has default rate limits for the maximum number of operations per second that you can perform in your user pools in each AWS Region, and you can purchase additional limits on adjustable API categories. With the new on-demand model, you can adjust your rate limits up or down more quickly to match your application’s traffic patterns.

Previously, to adjust your Cognito API rate limits, you would request an increase through Service Quotas, where requests are manually reviewed. This meant you had to plan rate limits in advance ahead of anticipated traffic spikes. Now, you have a new self-service experience to set your desired Cognito rate limit up to the account-level max limit using the Amazon Cognito console or the new limit provisioning API operations. Rate limit changes take effect immediately.

Self-service provisioned limits are available for adjustable API categories in all AWS Regions where Amazon Cognito is available. For pricing details of this add-on feature, see Amazon Cognito pricing page. To get started, see developer guide.

 

​Amazon Cognito now allows you to increase or decrease your provisioned API rate limits on demand. Cognito has default rate limits for the maximum number of operations per second that you can perform in your user pools in each AWS Region, and you can purchase additional limits on adjustable API categories. With the new on-demand model, you can adjust your rate limits up or down more quickly to match your application’s traffic patterns. Previously, to adjust your Cognito API rate limits, you would request an increase through Service Quotas, where requests are manually reviewed. This meant you had to plan rate limits in advance ahead of anticipated traffic spikes. Now, you have a new self-service experience to set your desired Cognito rate limit up to the account-level max limit using the Amazon Cognito console or the new limit provisioning API operations. Rate limit changes take effect immediately. Self-service provisioned limits are available for adjustable API categories in all AWS Regions where Amazon Cognito is available. For pricing details of this add-on feature, see Amazon Cognito pricing page. To get started, see developer guide.  

Publicado el — Deja un comentario

Amazon SageMaker Studio now integrates with Hugging Face for one-click model deployment and customization

Amazon SageMaker Studio now supports direct integration from Hugging Face, letting you go from discovering a model to working with it inside a fully configured Studio environment in a single click. Select any supported model on Hugging Face and choose «Customize on SageMaker AI» or «Deploy on SageMaker AI» to land directly on the corresponding workflow page with the model pre-loaded and ready to use.

Previously, getting from model discovery to a working environment required navigating the AWS Console to find SageMaker AI, configuring an environment, setting up IAM permissions for serverless model customization, and in many cases requesting GPU quota increases through Service Quotas before running a first job. Now, new customers complete a standard AWS sign-up and receive a SageMaker Studio environment created in seconds with pre-configured permissions for serverless model customization jobs including fine-tuning with custom reward functions for reinforcement learning, model evaluation, and deployment to SageMaker or Bedrock endpoints. Verified customers receive default GPU access to G5, G6, and G4dn instances across endpoint deployments, training jobs, and notebooks without requesting quota increases, and quota limit and utilization information is visible for each instance type directly inside the Studio environment. Returning customers signing in from Hugging Face or SageMaker product pages select their environment and land directly inside SageMaker Studio with the model ready to use.

This feature is available in all AWS Commercial Regions where Amazon SageMaker Studio is supported. To get started, visit any supported model on Hugging Face and select «Customize on SageMaker AI» or «Deploy on SageMaker AI,» or click Get Started from the SageMaker Studio page. To learn more, see Service quotas for Studio in the Amazon SageMaker documentation.

 

​Amazon SageMaker Studio now supports direct integration from Hugging Face, letting you go from discovering a model to working with it inside a fully configured Studio environment in a single click. Select any supported model on Hugging Face and choose «Customize on SageMaker AI» or «Deploy on SageMaker AI» to land directly on the corresponding workflow page with the model pre-loaded and ready to use.
Previously, getting from model discovery to a working environment required navigating the AWS Console to find SageMaker AI, configuring an environment, setting up IAM permissions for serverless model customization, and in many cases requesting GPU quota increases through Service Quotas before running a first job. Now, new customers complete a standard AWS sign-up and receive a SageMaker Studio environment created in seconds with pre-configured permissions for serverless model customization jobs including fine-tuning with custom reward functions for reinforcement learning, model evaluation, and deployment to SageMaker or Bedrock endpoints. Verified customers receive default GPU access to G5, G6, and G4dn instances across endpoint deployments, training jobs, and notebooks without requesting quota increases, and quota limit and utilization information is visible for each instance type directly inside the Studio environment. Returning customers signing in from Hugging Face or SageMaker product pages select their environment and land directly inside SageMaker Studio with the model ready to use.
This feature is available in all AWS Commercial Regions where Amazon SageMaker Studio is supported. To get started, visit any supported model on Hugging Face and select «Customize on SageMaker AI» or «Deploy on SageMaker AI,» or click Get Started from the SageMaker Studio page. To learn more, see Service quotas for Studio in the Amazon SageMaker documentation.  

Publicado el — Deja un comentario

Amazon SageMaker HyperPod now supports disaggregated prefill and decode

Amazon SageMaker HyperPod now supports Disaggregated Prefill and Decode (DPD), an inference optimization that separates the two phases of large language model (LLM) inference — prefill and decode — onto dedicated GPU pools and transfers the key-value (KV) cache between them over Elastic Fabric Adapter (EFA) using GPU-Direct RDMA. Customers running LLMs in production for chat assistants, agentic pipelines, retrieval-augmented generation, and long-document analysis need consistent per-token latency and predictable throughput under mixed traffic, but when prefill and decode share the same GPU, a single long-context request can stall token generation for every concurrent request and force customers to over-provision one phase to protect the other.

With DPD, customers run compute-bound prefill on one set of GPUs and memory-bandwidth-bound decode on another, so the two phases no longer contend for the same resources. This delivers more consistent per-token latency under sustained concurrency, higher goodput at strict latency SLOs, and the ability to scale prefill and decode capacity independently to match the input and output distribution of the workload. An intelligent router automatically directs long-context requests through the disaggregated path and sends shorter prompts directly to the decoder, so customers get the benefit on the traffic that needs it without paying transfer overhead on short prompts. Customers enable DPD by adding a `pdSpec` section to the same `InferenceEndpointConfig` custom resource they already use for inference endpoints on the HyperPod Inference Operator, and DPD is composable with the existing KV cache offloading and intelligent routing features on HyperPod.

DPD is available for SageMaker HyperPod clusters using the EKS orchestrator on EFA-capable instance types in all AWS Regions where Amazon SageMaker HyperPod is available. To learn more, see Disaggregated Prefill and Decode for HyperPod inference in the Amazon SageMaker AI Developer Guide.

 

​Amazon SageMaker HyperPod now supports Disaggregated Prefill and Decode (DPD), an inference optimization that separates the two phases of large language model (LLM) inference — prefill and decode — onto dedicated GPU pools and transfers the key-value (KV) cache between them over Elastic Fabric Adapter (EFA) using GPU-Direct RDMA. Customers running LLMs in production for chat assistants, agentic pipelines, retrieval-augmented generation, and long-document analysis need consistent per-token latency and predictable throughput under mixed traffic, but when prefill and decode share the same GPU, a single long-context request can stall token generation for every concurrent request and force customers to over-provision one phase to protect the other. With DPD, customers run compute-bound prefill on one set of GPUs and memory-bandwidth-bound decode on another, so the two phases no longer contend for the same resources. This delivers more consistent per-token latency under sustained concurrency, higher goodput at strict latency SLOs, and the ability to scale prefill and decode capacity independently to match the input and output distribution of the workload. An intelligent router automatically directs long-context requests through the disaggregated path and sends shorter prompts directly to the decoder, so customers get the benefit on the traffic that needs it without paying transfer overhead on short prompts. Customers enable DPD by adding a `pdSpec` section to the same `InferenceEndpointConfig` custom resource they already use for inference endpoints on the HyperPod Inference Operator, and DPD is composable with the existing KV cache offloading and intelligent routing features on HyperPod. DPD is available for SageMaker HyperPod clusters using the EKS orchestrator on EFA-capable instance types in all AWS Regions where Amazon SageMaker HyperPod is available. To learn more, see Disaggregated Prefill and Decode for HyperPod inference in the Amazon SageMaker AI Developer Guide.  

Publicado el — Deja un comentario

Amazon EVS VCF 9.0 and 9.1 support

Today, we are announcing that Amazon Elastic VMware Service (EVS) now supports VMware Cloud Foundation (VCF) 9.0 and 9.1.

Amazon EVS lets you run the latest VCF software directly within your Amazon Virtual Private Cloud (VPC) on EC2 bare-metal instances. With this latest announcement, you now have complete control of the installation, operations, and management of the VMware virtualization solution running the VCF 9.0 and recently released VCF 9.1 versions. You can continue to use the same tools, processes, and skills on Amazon EVS that you use in your data center today, managing your VCF environment yourself or with an experienced AWS partner. With this, we’re also launching the Solutions for EVS GitHub repository with examples, templates, and infrastructure as code artifacts to help you get started.

This release is available in all regions where Amazon EVS is offered.

For more details, visit the launch blog, the Amazon EVS product detail page and user guide. 

 

​Today, we are announcing that Amazon Elastic VMware Service (EVS) now supports VMware Cloud Foundation (VCF) 9.0 and 9.1.
Amazon EVS lets you run the latest VCF software directly within your Amazon Virtual Private Cloud (VPC) on EC2 bare-metal instances. With this latest announcement, you now have complete control of the installation, operations, and management of the VMware virtualization solution running the VCF 9.0 and recently released VCF 9.1 versions. You can continue to use the same tools, processes, and skills on Amazon EVS that you use in your data center today, managing your VCF environment yourself or with an experienced AWS partner. With this, we’re also launching the Solutions for EVS GitHub repository with examples, templates, and infrastructure as code artifacts to help you get started.
This release is available in all regions where Amazon EVS is offered.
For more details, visit the launch blog, the Amazon EVS product detail page and user guide.   

Publicado el — Deja un comentario

CloudWatch Application Signals now automatically captures errors, performance anomalies, and deployment events

Today, AWS announces Service Events for Amazon CloudWatch Application Signals, which automatically captures exception and latency event snapshots, function-level performance data, and deployment events from instrumented services without additional code changes. Customers can now quickly identify whether a deployment has introduced new exceptions by navigating to CloudWatch > Application Signals > [Service] > Errors in the CloudWatch console.

Service Events is available to any application with CloudWatch Application Signals enabled. Customers instrument their applications with the ADOT SDKs or the Amazon CloudWatch Observability EKS add-on. Once Application Signals is active, Service Events begins capturing exception and latency event snapshots and deployment events automatically. Optionally, customers can gain deeper performance visibility by turning on function-call metrics.

Service Events is available in all commercial AWS Regions. Supported languages are Java, Python, and JavaScript.

To get started, see Monitor service events in the Amazon CloudWatch User Guide. Service Events data is captured as logs. Function call metrics are captured as OpenTelemetry metrics. Standard CloudWatch pricing applies. For details, see CloudWatch pricing.

 

​Today, AWS announces Service Events for Amazon CloudWatch Application Signals, which automatically captures exception and latency event snapshots, function-level performance data, and deployment events from instrumented services without additional code changes. Customers can now quickly identify whether a deployment has introduced new exceptions by navigating to CloudWatch > Application Signals > [Service] > Errors in the CloudWatch console.
Service Events is available to any application with CloudWatch Application Signals enabled. Customers instrument their applications with the ADOT SDKs or the Amazon CloudWatch Observability EKS add-on. Once Application Signals is active, Service Events begins capturing exception and latency event snapshots and deployment events automatically. Optionally, customers can gain deeper performance visibility by turning on function-call metrics.
Service Events is available in all commercial AWS Regions. Supported languages are Java, Python, and JavaScript.
To get started, see Monitor service events in the Amazon CloudWatch User Guide. Service Events data is captured as logs. Function call metrics are captured as OpenTelemetry metrics. Standard CloudWatch pricing applies. For details, see CloudWatch pricing.  

Publicado el — Deja un comentario

AWS Secrets Manager adds managed external secrets support for Paddle and GitLab

AWS Secrets Manager now extends its managed external secrets capability to include Paddle API Keys and GitLab Access Tokens. Managed external secrets enable customers to automatically rotate third-party credentials directly from AWS Secrets Manager by offering first-class integration with supported third-party services.

With this launch, you can manage rotation for Paddle API keys using Paddle’s native rotation API, which provides a configurable grace period that allows applications to seamlessly transition to new keys without interruption. For GitLab, you can now rotate three types of access tokens — Personal Access Tokens, Group Access Tokens, and Project Access Tokens — using GitLab’s atomic rotation mechanism.

These new integrations join existing managed external secrets integrations with BigID, Confluent Cloud, Datadog, MongoDB Atlas, Salesforce, and Snowflake, enabling customers to manage third-party software vended secrets.
Paddle and GitLab managed external secrets are available in all AWS Regions where AWS Secrets Manager managed external secrets is supported. To learn more, visit the AWS Secrets Manager managed external secrets documentation.

 

​AWS Secrets Manager now extends its managed external secrets capability to include Paddle API Keys and GitLab Access Tokens. Managed external secrets enable customers to automatically rotate third-party credentials directly from AWS Secrets Manager by offering first-class integration with supported third-party services. With this launch, you can manage rotation for Paddle API keys using Paddle’s native rotation API, which provides a configurable grace period that allows applications to seamlessly transition to new keys without interruption. For GitLab, you can now rotate three types of access tokens — Personal Access Tokens, Group Access Tokens, and Project Access Tokens — using GitLab’s atomic rotation mechanism. These new integrations join existing managed external secrets integrations with BigID, Confluent Cloud, Datadog, MongoDB Atlas, Salesforce, and Snowflake, enabling customers to manage third-party software vended secrets. Paddle and GitLab managed external secrets are available in all AWS Regions where AWS Secrets Manager managed external secrets is supported. To learn more, visit the AWS Secrets Manager managed external secrets documentation.  

Publicado el — Deja un comentario

AWS Certificate Manager now supports the ACME protocol for public certificates

AWS Certificate Manager (ACM) now allows you to provision a fully managed ACME server endpoint that issues public TLS certificates with a 45 day validity from Amazon Trust Services using any ACMEv2-compatible client, including Certbot, cert-manager for Kubernetes, and acme.sh. With the CA/Browser Forum mandating 47-day certificate lifetimes by 2029, manual management of public certificates becomes untenable. ACME support in ACM gives developers a standards-based path to fully automate certificate issuance and renewal.

PKI administrators can create managed ACME endpoints with centralized governance controls: define domain scopes to restrict which certificates each client can issue, enforce policies on wildcard usage, and delegate certificate requests to application teams without distributing DNS credentials. Domain validation is performed once at the endpoint level, while application owners use standard ACME clients to request certificates. All activity is visible in the ACM console with AWS CloudTrail logging and Amazon CloudWatch metrics for auditability.

ACME support in ACM is available in all commercial AWS Regions. For pricing details, see the ACM pricing page. To get started, visit the AWS News blog post or read the documentation.

 

​AWS Certificate Manager (ACM) now allows you to provision a fully managed ACME server endpoint that issues public TLS certificates with a 45 day validity from Amazon Trust Services using any ACMEv2-compatible client, including Certbot, cert-manager for Kubernetes, and acme.sh. With the CA/Browser Forum mandating 47-day certificate lifetimes by 2029, manual management of public certificates becomes untenable. ACME support in ACM gives developers a standards-based path to fully automate certificate issuance and renewal. PKI administrators can create managed ACME endpoints with centralized governance controls: define domain scopes to restrict which certificates each client can issue, enforce policies on wildcard usage, and delegate certificate requests to application teams without distributing DNS credentials. Domain validation is performed once at the endpoint level, while application owners use standard ACME clients to request certificates. All activity is visible in the ACM console with AWS CloudTrail logging and Amazon CloudWatch metrics for auditability. ACME support in ACM is available in all commercial AWS Regions. For pricing details, see the ACM pricing page. To get started, visit the AWS News blog post or read the documentation.  

Publicado el — Deja un comentario

AWS CodePipeline now available in Asia Pacific (New Zealand) region

Starting today, AWS CodePipeline is now available in Asia Pacific (New Zealand) Region (ap-southeast-6). AWS CodePipeline is a continuous delivery service that enables you to model, visualize, and automate the steps required to release your software. With CodePipeline, you model the full release process for building your code, deploying to pre-production environments, testing your application and releasing it to production. CodePipeline then builds, tests, and deploys your application according to the defined workflow every time there is a code change. You can integrate partner tools and your own custom tools into any stage of the release process to form an end-to-end continuous delivery solution.

CodePipeline integrates natively with other AWS services (such as CodeBuild, CodeDeploy, and CloudFormation) and supports third-party integrations, such as GitHub or with your own custom plugin, offering a comprehensive solution for orchestrating end-to-end CI/CD pipelines. By integrating manual approval gates, IAM-based access controls, and encryption of artifacts at rest and in transit, CodePipeline helps teams enforce governance policies and maintain a robust security posture throughout the software delivery lifecycle. CodePipeline enables organizations to automate security scans and compliance checks directly within their CI/CD workflows, ensuring consistent and reliable validation against industry frameworks.

To get started, you can sign in to the AWS Management Console and create a pipeline to start using the service. If you want an introduction to CodePipeline, see Getting Started, which includes step-by-step tutorials.  With CodePipeline, you only pay for what you use. There are no upfront fees or long-term commitments. See the pricing page for additional details on CodePipeline.

 

​Starting today, AWS CodePipeline is now available in Asia Pacific (New Zealand) Region (ap-southeast-6). AWS CodePipeline is a continuous delivery service that enables you to model, visualize, and automate the steps required to release your software. With CodePipeline, you model the full release process for building your code, deploying to pre-production environments, testing your application and releasing it to production. CodePipeline then builds, tests, and deploys your application according to the defined workflow every time there is a code change. You can integrate partner tools and your own custom tools into any stage of the release process to form an end-to-end continuous delivery solution.
CodePipeline integrates natively with other AWS services (such as CodeBuild, CodeDeploy, and CloudFormation) and supports third-party integrations, such as GitHub or with your own custom plugin, offering a comprehensive solution for orchestrating end-to-end CI/CD pipelines. By integrating manual approval gates, IAM-based access controls, and encryption of artifacts at rest and in transit, CodePipeline helps teams enforce governance policies and maintain a robust security posture throughout the software delivery lifecycle. CodePipeline enables organizations to automate security scans and compliance checks directly within their CI/CD workflows, ensuring consistent and reliable validation against industry frameworks.
To get started, you can sign in to the AWS Management Console and create a pipeline to start using the service. If you want an introduction to CodePipeline, see Getting Started, which includes step-by-step tutorials.  With CodePipeline, you only pay for what you use. There are no upfront fees or long-term commitments. See the pricing page for additional details on CodePipeline.  

Publicado el — Deja un comentario

Construir una máquina para subir colinas: Lanzamos siete nuevos modelos MAI

Collage de personas en distintas actividades cotidianas como trabajar, estudiar, hacer ejercicio y socializar en un fondo blanco.

Construir una máquina para subir colinas: Lanzamos siete nuevos modelos MAI

Por: Mustafa Suleyman

De manera reciente, anunciamos una familia de siete nuevos modelos desarrollados a nivel interno en Microsoft AI. Más allá de estos modelos, construimos un laboratorio de superinteligencia: un sistema y un enfoque que creemos definirá la próxima fase de la IA.

Esta es una época extraordinaria en tecnología. El cálculo utilizado para entrenar modelos de frontera ha aumentado por un factor de un billón. Ahora esperamos otro aumento de mil veces en los próximos tres años, lo que a su vez significa capacidades más avanzadas y el despliegue continuo de una IA cada vez más eficaz.

Esta épica rampa de computación cambiará la naturaleza del trabajo, los negocios y la vida diaria. Todos tenemos que prepararnos para esta realidad. Nuestro trabajo en MAI es ayudarlos a hacer esto: a empujar la frontera y construir una máquina para subir colinas que los mantenga en la frontera.

Aquí están nuestros primeros pasos en el camino.

Nuestros modelos

Nuestros nuevos modelos en imagen, voz, transcripción, codificación y razonamiento, forman juntos la familia de modelos MAI: un ecosistema multimodal diseñado para trabajar en los tipos de tareas que importan en el mundo real.

  • MAI-Thinking-1, el modelo de razonamiento insignia de Microsoft AI. Es un modelo de tamaño medio que se sitúa entre los más fuertes de su categoría: iguala a los modelos líderes en benchmarks clave de ingeniería de software, demuestra capacidades avanzadas de razonamiento matemático y es preferido a Sonet 4.6 en nuestras evaluaciones ciegas humanas lado a lado. Lo entrenamos desde cero con datos limpios, sin destilación de modelos de terceros.
  • MAI-Code-1-Flash es un modelo de codificación agente eficiente en la inferencia. Este modelo está hecho a medida y está integrado a fondo en GitHub Copilot, VS Code y la pila de Microsoft, y, con 5.000 millones de parámetros activos, es comparable a Haiku pero más barato.
  • MAI-Image-2.5, incluida su variante ultraeficiente en Flash, soporta tanto texto a imagen como edición de imagen de clase mundial, donde supera la puntuación Arena de Nano Banana Pro.
  • MAI Transcribe-1.5 es el mejor modelo de transcripción del mundo, con precisión SOTA. Es cinco veces más rápido que los modelos competidores, con soporte integrado para terminología específica de dominio en 43 idiomas.
  • MAI-Voice-2 ofrece una generación de voz de alta calidad y sonido natural en 15 idiomas, con la capacidad de adaptarse a una voz a partir de una muestra corta, junto con fuertes salvaguardas contra el mal uso. MAI-Voice-2-Flash, disponible más adelante, lo hace en un paquete más económico y ultra eficiente.

Junto con la distribución en Foundry y la optimización para nuestros productos 1P, nuestros modelos también estarán disponibles de manera amplia para desarrolladores en OpenRouter, así como Fireworks y Baseten. Por primera vez, los desarrolladores podrán ajustar los pesos del modelo ellos mismos.

Todos estos modelos comparten la misma infraestructura y el mismo compromiso con una línea de datos limpia y de nivel empresarial. No destilamos de otros laboratorios ni dependemos de datos opacos. Nuestros conjuntos de datos son limpios, rastreables y de nivel empresarial. Están diseñados para trabajar juntos e integrarse directo en los productos que la gente usa cada día. Pero los modelos en sí son solo una parte de la historia.

El cambio más importante está en lo que ustedes pueden hacer con ellos.

Adaptada para ustedes

La IA ha entrado en una nueva fase. Con el aprendizaje por refuerzo en entornos reales, la IA puede adaptarse por completo por primera vez a las particularidades de un flujo de trabajo determinado. A esto lo llamamos Microsoft Frontier Tuning. Creemos que es el futuro de cómo se presenta la IA. Pueden obtener más información en la entrada del blog de Microsoft 365.

Creemos que es el futuro de cómo se presenta la IA.

En esta configuración, los datos más valiosos son suyos: la traza del trabajo real que realiza un agente, la secuencia de pasos, las decisiones, las acciones tomadas que definen cómo se realizan en realidad las tareas dentro de una organización.

Nuestros entornos de aprendizaje por refuerzo (RLE, por sus siglas en inglés) permiten que tus modelos MAI aprendan directo de sus flujos de trabajo. Piensen en ellos como gimnasios de entrenamiento para IA, accesibles solo para ustedes.

Con Frontier Tuning, ustedes construyen su propio modelo, entrenado con sus datos, dentro de su entorno, controlado por ustedes. Su conocimiento institucional pasa a formar parte del modelo, y sigue siendo suyo. Lo que es aún mejor es que esta adaptación impulsa la eficiencia y el rendimiento.

En Microsoft y con los clientes, Frontier Tuning demuestra que los modelos personalizados son tanto mejores como más eficientes: nuestro modelo ajustado para MAI para Excel iguala GPT 5.4 y es hasta un 10× más eficiente. Los primeros adoptantes ven avances similares en la frontera. Cuando se ajustó a los exigentes estándares empresariales de una organización líder en el mercado, MAI logró la mayor tasa de victorias de cualquier modelo probado, con un coste cerca de un 10× menor.

Los desarrolladores y las empresas han deseado por un tiempo una IA que cumpla con sus condiciones y bajo su opinión. Vemos esto como un paso importante para conseguir eso.

Inteligencia sanitaria en la frontera con la Clínica Mayo

Existen varios ámbitos de alta importancia y alta sensibilidad —como la salud— que requieren una colaboración aún más intensa. Por eso hoy también anunciamos que Microsoft y Mayo Clinic colaboran para co-crear un modelo de IA pionero para la sanidad que reúne la experiencia clínica líder mundial de Mayo Clinic, los datos clínicos desidentificados y las perspectivas longitudinales con las capacidades fundamentales de IA de Microsoft.

Este modelo estará diseñado para destacar en el ámbito más amplio del razonamiento clínico y los casos de uso en la salud, para alcanzar un nivel que los sistemas de propósito general actuales no pueden igualar.

El modelo se implementará primero en el propio entorno de la Clínica Mayo, el principal sistema hospitalario del mundo, donde esperamos que permita una amplia gama de capacidades, incluidos diagnósticos y planificación de tratamientos más tempranas y precisas. Una vez validado, el modelo estará disponible para otras organizaciones a través de Microsoft Foundry, para hacer que la experiencia de Mayo Clinic sea accesible para muchas más personas que la necesiten.

El modelo pionero de IA será propiedad de Mayo Clinic, lo que refuerza nuestro compromiso mutuo de larga data con la confianza del paciente, el rigor clínico, la seguridad y la gestión responsable de los datos clínicos de salud y la IA.

Nuestro laboratorio

En Microsoft AI, reconocemos que no hay atajos hacia la frontera. Entrenamos nuestros modelos de razonamiento desde cero. No destilamos de otros laboratorios ni dependemos de datos no licenciados u opacos. Nuestros conjuntos de datos son limpios y están licenciados de manera debida. Cada componente del sistema, desde la arquitectura hasta la cadena de entrenamiento y la post-formación, lo construimos nosotros mismos. Co-diseñamos con nuestro propio silicio Maia 200 y ya vemos un aumento de eficiencia de 1,4 veces gracias a estos esfuerzos. Todo esto trata sobre la autosuficiencia a largo plazo para Microsoft y nuestros socios. Se trata de modelos en los que puedas confiar.

El objetivo aquí es construir lo que consideramos una máquina de subir colinas: una organización que pueda mejorar de manera continua, ciclo tras ciclo, a medida que aplicamos más cálculo, mejores datos y evaluaciones más precisas.

Creemos que el rigor científico es fundamental para esto. Por eso, en todo lo que hacemos, ablacionamos, medimos, documentamos. Invertimos mucho en pipelines de datos. Trabajamos en equipos pequeños con objetivos falsificables en periodos cortos, para ajustar velocidad con calidad y enfoque y ambición. Y estamos comprometidos con la transparencia. Queremos acompañarlos en este camino. Por eso hemos publicado informes detallados sobre seguridad y técnicos.

Superinteligencia humanista

Esto es lo que construimos en MAI: una familia de modelos, con nuevas versiones disponibles ahora. Un laboratorio basado en principios básicos, centrado en la capacidad a largo plazo. Y un nuevo enfoque para la optimización y la propiedad que creemos definirá la próxima fase de la IA.

Nuestro objetivo final es lo que llamamos Superinteligencia Humanista. Eso significa sistemas avanzados de IA diseñados para servir a personas y organizaciones, no para reemplazarlas. Estos sistemas deben mantenerse herramientas, moldeadas por la intención humana, responsables ante la supervisión humana y, en última instancia, subordinadas a los objetivos humanos. Las personas – ustedes – siempre deben mantener el control.

Durante el próximo año, prepárense para una rápida ampliación de nuestro cálculo y capacidades mientras avanzamos para hacer realidad esta ambición. Es una nueva etapa para la IA, y para nosotros.

– El equipo de MAI

The post Construir una máquina para subir colinas: Lanzamos siete nuevos modelos MAI appeared first on Source LATAM.

 

​The post Construir una máquina para subir colinas: Lanzamos siete nuevos modelos MAI appeared first on Source LATAM.  

Publicado el — Deja un comentario

Amazon SageMaker HyperPod now supports AMI versioning and auto-patching

Amazon SageMaker HyperPod now gives you visibility into the Amazon Machine Image (AMI) versions running across your clusters and automatically applies security patches without disrupting your workloads. SageMaker HyperPod is purpose-built infrastructure for training and deploying foundation models at scale. Cluster administrators previously had limited insight into which AMI versions were running, making drift hard to detect and security patching a manual, reactive process that was difficult to run on long multi-day training jobs and that risked changing bundled software in the AMI such as NVIDIA drivers or CUDA. These new capabilities on HyperPod help you keep clusters secure and consistent while removing the operational burden of manual patching.

With AMI versioning, you can see the exact AMI version on every instance group and node in the semantic versioning (major.minor.patch) format, quickly detect version drift, and roll back to a previous version—including the prior NVIDIA driver, CUDA, and other software stack—using the UpdateClusterSoftware API. Auto-patching is an opt-in, per-instance-group capability that applies only backward-compatible security patches as nodes become idle, so your running workloads stay undisrupted and critical AI/ML packages such as NVIDIA driver, CUDA version, and operating system kernels are never upgraded to a different major or minor version; you can enable it through the CreateCluster or UpdateCluster API. A new AMI support policy also publishes support timelines for different AMI versions after which HyperPod stops publishing security patches.

Both AMI versioning and auto-patching are available for HyperPod clusters orchestrated by Amazon EKS, in all AWS Regions where SageMaker HyperPod is supported. To learn more, see the HyperPod AMI management documentation and the new HyperPod AMI support policy.

 

​Amazon SageMaker HyperPod now gives you visibility into the Amazon Machine Image (AMI) versions running across your clusters and automatically applies security patches without disrupting your workloads. SageMaker HyperPod is purpose-built infrastructure for training and deploying foundation models at scale. Cluster administrators previously had limited insight into which AMI versions were running, making drift hard to detect and security patching a manual, reactive process that was difficult to run on long multi-day training jobs and that risked changing bundled software in the AMI such as NVIDIA drivers or CUDA. These new capabilities on HyperPod help you keep clusters secure and consistent while removing the operational burden of manual patching.
With AMI versioning, you can see the exact AMI version on every instance group and node in the semantic versioning (major.minor.patch) format, quickly detect version drift, and roll back to a previous version—including the prior NVIDIA driver, CUDA, and other software stack—using the UpdateClusterSoftware API. Auto-patching is an opt-in, per-instance-group capability that applies only backward-compatible security patches as nodes become idle, so your running workloads stay undisrupted and critical AI/ML packages such as NVIDIA driver, CUDA version, and operating system kernels are never upgraded to a different major or minor version; you can enable it through the CreateCluster or UpdateCluster API. A new AMI support policy also publishes support timelines for different AMI versions after which HyperPod stops publishing security patches.
Both AMI versioning and auto-patching are available for HyperPod clusters orchestrated by Amazon EKS, in all AWS Regions where SageMaker HyperPod is supported. To learn more, see the HyperPod AMI management documentation and the new HyperPod AMI support policy.