Servidores GPU en la nube: qué proveedor elegir en 2026

Elige servidores GPU en la nube según el trabajo que necesites hacer: Runpod para realizar fine-tuning con control directo, Modal para inferencia serverless con código propio, Together AI para acceder a modelos mediante una API gestionada y Vast.ai para alquilar capacidad en un marketplace y ejecutar trabajos que puedas reanudar. La selección de 7 proveedores se completa con Lambda para máquinas virtuales con GPU, CoreWeave para capacidad de clúster planificada y Google Cloud cuando tu aplicación ya depende de su infraestructura. Para decidir, empieza por la memoria que necesita el modelo y el tiempo de ejecución que vas a pagar, no por la tarifa de GPU más baja del anuncio.

Precios y documentación de producto verificados el 30 de octubre de 2026. Los precios siguientes son importes en USD que cada proveedor mostraba en su página de precios ese día. Esta comparativa se basa en documentación; no es una prueba de rendimiento realizada con las plataformas. La disponibilidad, los impuestos y la configuración final del despliegue pueden modificar el importe que pagues.

Los mejores servidores GPU según el trabajo

Runpod es la primera opción que conviene evaluar si quieres hacer fine-tuning directamente; Modal y Together AI encabezan la selección para poner el modelo en producción sin mantener una máquina GPU encendida de forma permanente. La elección cambia cuando necesitas una región concreta, capacidad continua o un entorno por lotes que facilite la recuperación ante fallos.

Comparativa de precios de GPU en la nube: primero la unidad, después la cifra

Cada tarifa inicial corresponde a un producto y un hardware concretos. Son precios de entrada a servicios distintos, no ofertas de rendimiento equivalente. El precio de una GPU conectada a una máquina virtual no incluye esa máquina; un segundo de GPU serverless no incluye los recursos que se facturan por separado; y una tarifa de inferencia dedicada no es el precio de una API por tokens.

Una oferta del marketplace puede desaparecer, y el dispositivo más barato del catálogo quizá no tenga memoria suficiente para tu modelo. La columna de pruebas gratuitas refleja la oferta pública consultada, no todos los programas de créditos que se puedan negociar. Together AI exige acceso de prepago; Google especifica su restricción de GPU en las condiciones de Free Trial.

Inferencia serverless: ¿código propio o una API de modelos?

Antes de elegir una GPU, decide si necesitas controlar el entorno de ejecución del modelo. La inferencia consiste en usar un modelo entrenado para generar una respuesta. Una API gestionada te permite solicitar esa respuesta; el cómputo serverless con código propio te permite aportar el programa que la produce. Esa diferencia pesa más que el hecho de que ambos productos se presenten como «serverless».

1. Modal: para inferencia en Python con código propio y tráfico irregular

Modal es una plataforma de cómputo serverless para aplicaciones en contenedores que se despliegan mediante Python. Encaja cuando el código que ejecuta el modelo forma parte de tu producto. Por ejemplo, un servicio de procesamiento de documentos puede necesitar preprocesamiento propio, una llamada al modelo y posprocesamiento dentro del mismo despliegue. Modal permite escalar esa aplicación según la demanda, pero el tiempo facturado incluye la inicialización y la espera con recursos activos, además del cálculo útil del modelo. Elige Modal si quieres controlar el entorno de ejecución sin mantener una máquina virtual encendida permanentemente.

Ideal para: Equipos de Python que despliegan inferencia con código propio o trabajos de GPU en cola con demanda variable.
Lo más destacado: Despliegue a nivel de aplicación y escalado automático, con recursos de cómputo facturados por separado.
Precio: El cómputo con una GPU T4 parte de $0.000164/segundo, más CPU y memoria, verificado el 30 de octubre de 2026 en la página de precios de Modal.
Prueba gratuita: Starter incluye $30/mes en créditos de cómputo; los Shared Endpoints facturados por tokens quedan fuera de ese saldo.

La principal limitación práctica es la latencia tras un periodo sin actividad. Un arranque en frío es el trabajo necesario para preparar un contenedor nuevo antes de que pueda responder. Iniciar el contenedor, importar bibliotecas y cargar los pesos del modelo son etapas distintas. Que el contenedor arranque rápido no significa que el modelo esté listo de inmediato.

Modal ofrece controles para mantener contenedores preparados y capacidad de reserva. Pueden mejorar la rapidez de respuesta, pero también mantienen recursos asignados. En un asistente de cara al cliente, prueba tanto la primera solicitud después de un periodo de inactividad como las solicitudes de una sesión con tráfico. En una cola nocturna de extracción de datos, esperar a la inicialización puede ser aceptable. La guía de arranques en frío de Modal explica ese equilibrio.

Starter también impone un límite concreto al escalado: 3 usuarios por espacio de trabajo y 10 GPU simultáneas. Es suficiente para un piloto útil, pero una ráfaga de procesos independientes puede agotar la concurrencia antes de que el gasto mensual parezca elevado. Los volúmenes persistentes y la transferencia de datos salientes incluyen ciertas cuotas y se cobran aparte cuando se superan, así que incorpora el recorrido de los datos a la estimación.

La ubicación exige otra decisión de configuración. Modal distingue entre la región que ejecuta el contenedor y la que enruta sus solicitudes. Fijar una región también aplica un multiplicador al precio. Ejecutar el modelo cerca de la base de datos solo resulta útil si la ruta de las solicitudes cumple, a su vez, los requisitos de latencia y residencia de datos. La documentación de selección de región describe ambos controles.

2. Together AI: cuando lo que necesitas es un endpoint de modelos

Together AI es una plataforma gestionada de inferencia y entrenamiento. Encaja con equipos que quieren lanzar una función basada en modelos antes de asumir la gestión de infraestructura GPU. Su API serverless es el punto de partida natural si el modelo que necesitas está en el catálogo; la inferencia dedicada añade control sobre el hardware que lo sirve. El límite está en la personalización: una API con modelos compatibles es un producto distinto de un entorno de entrenamiento donde puedas ejecutar lo que quieras. Elige Together AI cuando el producto que necesitas sea el endpoint, y contrata capacidad dedicada solo cuando el tráfico o los requisitos de control lo justifiquen.

Ideal para: Equipos que sirven modelos compatibles o recurren al fine-tuning gestionado y a la inferencia dedicada.
Lo más destacado: Permite pasar de una API facturada por tokens a un despliegue de modelos dedicado.
Precio: La inferencia dedicada con NVIDIA HGX H100 parte de $5.49/GPU-hora; las tarifas de la API serverless dependen del modelo, verificado el 30 de octubre de 2026 en la página de precios de Together AI.
Prueba gratuita: No hay prueba gratuita; es necesario comprar créditos de prepago.

Separa los modelos de facturación. La inferencia de lenguaje serverless se cobra por tokens de entrada y salida, los fragmentos de texto que procesa el modelo. La inferencia dedicada se cobra por minuto y por cada réplica lista para atender solicitudes, es decir, cada copia en ejecución del servicio del modelo. Su documentación excluye el aprovisionamiento y el arranque en frío de la facturación de cómputo dedicado, pero una réplica lista sigue costando dinero aunque reciba pocas solicitudes. Escalar a cero detiene ese cargo de cómputo. La documentación de facturación de inferencia dedicada delimita qué se cobra.

Para una aplicación de soporte con conversaciones esporádicas, serverless evita comprar capacidad de modelos que queda sin uso. En una aplicación con mucho tráfico y un patrón de demanda conocido, vale la pena comparar réplicas dedicadas con los mismos prompts y longitudes de respuesta. No cambies solo porque la tarifa por GPU parezca menor: necesitas medir el rendimiento para convertirla en costo por respuesta completada.

El fine-tuning gestionado también requiere una estimación propia. Together ofrece LoRA basado en adaptadores y fine-tuning completo, con cargos por tokens que tienen en cuenta las pasadas de entrenamiento y la evaluación. Una época es una pasada completa por el conjunto de datos de entrenamiento. Repetir el conjunto aumenta los tokens procesados; el tamaño del archivo subido, por sí solo, no determina la factura.

El producto de clústeres GPU vuelve a ser un servicio distinto. Ofrece capacidad bajo demanda y reservada, con almacenamiento persistente facturado por separado. Las reservas de clústeres se pagan por adelantado y no son reembolsables; eliminar un clúster no hace que todos los volúmenes conservados dejen de costar dinero. La documentación de clústeres indica que la entrada y la salida de datos no se cobran. No hay que asumir que esas reglas se aplican a todos los productos de API. La documentación de facturación de clústeres recoge los detalles.

Para servir modelos, comprueba el modelo y la región conjuntamente. Algunos modelos serverless permiten limitar la inferencia a Estados Unidos; otros requisitos regionales llevan a los endpoints dedicados. Los tiempos de respuesta de la API compartida pueden variar según la demanda, y las aplicaciones siguen necesitando gestionar reintentos. La documentación de serverless explicita estos límites.

Pods y máquinas virtuales bajo demanda para fine-tuning

Alquila un entorno que controles mientras sigas modificando el script de entrenamiento, las dependencias o el modelo. El fine-tuning adapta un modelo existente con tus datos. Un Pod o una máquina virtual te permite investigar los fallos y repetir el trabajo; también te deja a cargo de detener el cómputo y conservar los resultados.

3. Runpod: por dónde empezar para hacer fine-tuning con control directo

Runpod ofrece Pods con GPU dedicada, además de productos Serverless y de clústeres. Por eso es una primera opción práctica para un equipo pequeño que esté desarrollando su propio flujo de trabajo con modelos. Puedes elegir una GPU y una plantilla de contenedor, realizar el fine-tuning y evaluar después un despliegue Serverless independiente para la inferencia. Sus límites son concretos: la fiabilidad de Community Cloud varía según el anfitrión, el almacenamiento persistente tiene su propio ciclo de vida y detener un Pod no garantiza que la misma GPU esté disponible al reanudarlo. Runpod destaca por el control y la flexibilidad de despliegue, sin prometer ser la opción más barata para cualquier carga de trabajo.

Ideal para: Desarrolladores que necesitan un contenedor con GPU para experimentar, hacer fine-tuning con adaptadores y desarrollar inferencia con código propio.
Lo más destacado: Productos Pod y Serverless separados para las etapas de desarrollo y puesta en producción.
Precio: La página muestra Pods con RTX A5000 y 24 GB de VRAM desde $0.27/hora, verificado el 30 de octubre de 2026 en la página de precios de Runpod.
Prueba gratuita: La página de precios consultada no anunciaba una prueba gratuita de GPU.

Empieza por la memoria, no por el nombre de chip que más impresione. Runpod ofrece tarjetas de 24 GB, opciones de 48 GB como A40 y RTX A6000, y variantes A100 y H100 de 80 GB. Así, un equipo pequeño puede evaluar varias capacidades de memoria sin diseñar un clúster desde el principio. Eso no establece una clasificación por rendimiento: el motor de inferencia, la precisión del modelo y la configuración de los lotes pueden cambiar qué tarjeta conviene contratar.

Secure Cloud y Community Cloud también exigen decisiones diferentes. Runpod describe Secure Cloud como infraestructura de centros de datos, y Community Cloud como oferta entre pares con fiabilidad variable. Un experimento que se puede repetir tolera un riesgo de fallo distinto al de un servicio que atiende solicitudes de clientes. Elige el entorno según los requisitos de recuperación y soporte del trabajo. La guía de selección de Pods de Runpod explica la diferencia.

El almacenamiento es el límite que más puede sorprender en un primer despliegue. El disco del contenedor es temporal. Un disco de volumen se conserva al detener el Pod, pero se pierde al eliminarlo. Un volumen de red persiste de forma independiente, aunque está disponible para Pods de Secure Cloud y condiciona la elección del hardware a su ubicación. Guardar los puntos de control solo en almacenamiento temporal anula la utilidad de conservarlos. La documentación de volúmenes de red explica esa restricción de ubicación.

Los Pods facturan el cómputo por segundo y, según las reglas de precios consultadas para ese producto, no cobran la entrada ni la salida de datos. El almacenamiento de un Pod detenido puede seguir generando cargos. Serverless tiene otro ciclo de vida: los workers se cobran durante la inicialización, la ejecución y la espera inactiva hasta que se detienen. Los workers Flex pueden escalar a cero; los Active permanecen en ejecución. Son decisiones sobre cuánto tiempo pagas por mantener recursos asignados, no simples etiquetas de una misma tarifa horaria. Consulta la facturación de Pods y la facturación de Serverless.

Para calcular todas las tarifas y el almacenamiento, consulta la guía de precios de Runpod de este sitio. Utiliza esa hoja de cálculo para estimar ejecuciones repetidas y un servicio que permanece activo.

1. 1

   Define el trabajo antes del despliegue

   Anota el punto de control exacto del modelo, el modo de inferencia o fine-tuning, la precisión, la longitud máxima de entrada y la concurrencia prevista. Elige una capacidad de memoria GPU que deje espacio para el entorno de ejecución, además del archivo del modelo.

2. 2

   Elige primero dónde guardar los datos

   Si el trabajo necesita un volumen de red, créalo o selecciónalo en el centro de datos previsto antes de elegir la GPU. Confirma que allí haya capacidad GPU adecuada. Mantén una copia aparte de los datos de entrenamiento y los puntos de control que no puedas reemplazar.

3. 3

   Despliega una plantilla compatible

   En Pods, selecciona la GPU, elige la plantilla del contenedor, indica la cantidad de GPU y despliega bajo demanda. Comprueba el filtro de compatibilidad CUDA del anfitrión con respecto a la plantilla. CUDA es la plataforma de software de la que dependen muchas aplicaciones para GPU NVIDIA.

4. 4

   Haz un ensayo pequeño y comprueba cómo terminarlo

   Prueba el mismo recorrido de carga, entrenamiento y escritura de puntos de control que usarás en el trabajo previsto. Registra el pico de memoria GPU y el tiempo transcurrido. Confirma que el punto de control está en almacenamiento persistente antes de detener o terminar el cómputo; después, revisa los cargos de almacenamiento que sigan activos.

Estos controles de despliegue se documentan en Gestión de Pods. Aprovecha el ensayo para probar la recuperación: la siguiente ejecución debería poder continuar sin depender de una máquina anterior concreta.

4. Lambda: para trabajar en una máquina virtual con GPU familiar

Lambda es una nube de GPU con máquinas virtuales Linux y clústeres reservados. Encaja con equipos que quieren una máquina convencional para una sesión prolongada de entrenamiento. Sus entornos incluyen herramientas NVIDIA, y el catálogo abarca desde instancias con una GPU hasta asignaciones mayores. El límite de compra está en esa asignación: la tarifa por GPU de un mismo modelo puede cambiar según cuántas alquiles. Elige Lambda para disponer de un entorno de entrenamiento bajo tu control, y revisa el selector de cantidad de GPU antes de tomar una tarifa como importe de tu factura.

Ideal para: Equipos de entrenamiento y fine-tuning que prefieren acceder por SSH a una máquina virtual con GPU.
Lo más destacado: Instancias con una GPU y una opción independiente de clústeres reservados.
Precio: Las instancias con una GPU parten de $0.69/GPU-hora para una Quadro RTX 6000 con 24 GB de VRAM, verificado el 30 de octubre de 2026 en la página de precios de Lambda.
Prueba gratuita: La página de precios consultada no anunciaba una prueba gratuita de GPU.

El catálogo incluye A6000 con 48 GB y variantes H100 PCIe y SXM con 80 GB. Los nombres importan. «RTX 6000», «A6000» y tarjetas más nuevas con nombres similares no son compras intercambiables. Anota el nombre completo de la GPU y su memoria en la documentación del despliegue para evitar que una ejecución futura utilice otro dispositivo sin que lo adviertas.

El cómputo bajo demanda de Lambda se anuncia por hora, pero se factura en intervalos de un minuto, desde que la instancia arranca correctamente hasta que se termina. Una máquina encendida que no hace trabajo sigue generando cargos. En un entrenamiento, organiza el cierre según el ciclo de terminación del proveedor: que acabe el proceso de Python no significa que termine el alquiler. La documentación de facturación de Lambda explica cómo se mide el uso.

Los sistemas de archivos persistentes añaden otro paso a la planificación: deben conectarse al crear la instancia y estar en la misma región. Se siguen cobrando mientras existan, incluso si están desmontados; la documentación de facturación indica que la entrada y salida de datos del sistema de archivos no se cobran. Confirma que la GPU y el sistema de archivos pueden coexistir en la ubicación elegida antes de preparar un conjunto de datos grande. La documentación de instancias de Lambda recoge las reglas regionales y de almacenamiento.

La opción de clústeres reservados supone otra escala de contratación. La tabla pública de 1-Click Cluster parte de 16 GPU y un plazo de dos semanas. Puede encajar en una campaña de entrenamiento concentrada, pero es un mal punto de partida si todavía estás averiguando si adaptar un modelo en un solo dispositivo resolverá el problema. Empieza por el experimento viable más pequeño y amplía solo cuando hayas establecido el rendimiento necesario.

Marketplaces de GPU y capacidad interrumpible

Asume el riesgo de interrupción solo después de comprobar que el trabajo puede recuperarse. Un marketplace reúne ofertas de distintos anfitriones. Una instancia interrumpible puede pausarse o ser recuperada por el proveedor. Ambos conceptos se solapan, pero alquilar bajo demanda en un marketplace no implica automáticamente contratar capacidad interrumpible.

5. Vast.ai: para trabajos que se pueden reanudar y admiten distintas ubicaciones

Vast.ai es un marketplace de GPU donde los anfitriones fijan los precios. Resulta útil si puedes examinar cada oferta y tolerar que cambie la disponibilidad de máquinas. Un trabajo por lotes para generar embeddings o un experimento de fine-tuning repetible pueden encajar si los datos de entrada y los puntos de control sobreviven a la instancia. El límite está en los costos de cada anfitrión: el cómputo, el almacenamiento y la transferencia de datos en ambas direcciones pueden tener cargos separados. Elige Vast.ai si puedes adaptar la solución a la oferta, en lugar de necesitar que todas las ofertas se comporten igual.

Ideal para: Experimentos con presupuesto ajustado, trabajos por lotes y entrenamientos que pueden reanudarse desde puntos de control.
Lo más destacado: Elección de anfitrión con alquileres bajo demanda, reservados e interrumpibles.
Precio: Tarifas de GPU fijadas por el anfitrión y facturadas por segundo, más almacenamiento y transferencias; consulta la oferta inicial para tu configuración en la página de precios en vivo de Vast.ai, revisada el 30 de octubre de 2026.
Prueba gratuita: La página de precios consultada no anunciaba una prueba gratuita de GPU.

La oferta más barata solo sirve si su hardware es adecuado para el trabajo. El catálogo de Vast.ai muestra tarjetas RTX 3090 y RTX 4090 de 24 GB, L40S de 48 GB y H100 SXM de 80 GB. Primero filtra por la memoria y el software que necesitas. Después compara la CPU, la memoria del sistema, el almacenamiento, las condiciones de transferencia y la ubicación del anfitrión concreto.

El cómputo se mide por segundo mientras está en ejecución. El almacenamiento se sigue cobrando mientras exista la instancia, incluso si está detenida. Los cargos de subida y descarga varían según el anfitrión. Por eso, una GPU barata que descarga repetidamente un modelo o un conjunto de datos grande puede salir cara para un trabajo corto. Compara todo el recorrido de los datos, además de la tarjeta gráfica. La documentación de precios de Vast.ai explica estos componentes.

En un entrenamiento interrumpible, guardar el archivo del modelo puede no bastar para reanudarlo correctamente. Conserva el estado que necesita tu framework de entrenamiento y comprueba el procedimiento de reinicio antes de depender de él. En una cola de trabajos por lotes, asigna identificadores estables para que los reintentos no dupliquen resultados visibles para el cliente. Estos son criterios que debes cumplir para elegir capacidad interrumpible, no afirmaciones de que el proveedor se encargue de la recuperación.

Vast.ai también ofrece infraestructura serverless. Eso no elimina las cuestiones sobre el anfitrión y el costo de los datos: la documentación consultada describe una facturación serverless basada en el cómputo, el almacenamiento y el ancho de banda de la instancia. Esta selección se centra en los alquileres del marketplace porque es donde mejor encaja un equipo pequeño dispuesto a gestionar esas condiciones.

Clústeres reservados e infraestructura de nube existente

Reserva capacidad después de medir la demanda estable; mantén el trabajo cerca de la infraestructura existente si moverlo supondría más esfuerzo del que ahorras. Son motivos distintos para elegir una plataforma de mayor escala. Un equipo pequeño puede tener cualquiera de ellos sin convertirse en un comprador de capacidad masiva.

6. CoreWeave: cuando ya sabes qué clúster necesitas

CoreWeave es una nube de infraestructura para IA con Kubernetes gestionado sobre nodos físicos dedicados con GPU. Encaja con un equipo que ya pasó del experimento a una necesidad de cómputo planificada. Kubernetes coordina contenedores entre máquinas; resulta útil cuando el despliegue necesita esa orquestación y hay alguien a cargo. Para un equipo pequeño, los límites están en la capacidad contratada y la operación: comprar por nodo y usar un clúster gestionado sigue exigiendo una carga de trabajo definida, un plan de almacenamiento y un responsable operativo. Incluye CoreWeave en la evaluación cuando planificar capacidad sea una necesidad real, no como punto de partida para descubrir qué necesita tu modelo.

Ideal para: Equipos con una demanda de clúster conocida y capacidad para operar cargas de trabajo en Kubernetes.
Lo más destacado: Kubernetes gestionado sobre nodos físicos dedicados, con redes de clúster y aislamiento.
Precio: La tabla de Norteamérica muestra una instancia GH200 con una GPU a $6.50/hora; la capacidad reservada requiere cotización, verificado el 30 de octubre de 2026 en la página de precios de CoreWeave.
Prueba gratuita: La página de precios consultada no anunciaba una prueba gratuita de GPU.

Lee con atención las columnas de CoreWeave. Varias instancias publicadas incluyen 8 GPU, entre ellas las filas de H100, H200, A100, L40 y L40S. La página muestra por separado precios de inferencia con una GPU, y una nota al pie restringe esas tarifas a los clientes de la plataforma de inferencia. Dividir el precio de un nodo entre su cantidad de GPU sirve para calcular costos, pero no demuestra que puedas alquilar una fracción de ese nodo para un trabajo de clúster convencional.

La página de precios separa Norteamérica y Europa e incluye opciones bajo demanda, spot y reservadas. Para una reserva, pide la configuración exacta del nodo, la ubicación del despliegue, el plazo del compromiso y las condiciones de capacidad. Confirma también el intervalo de facturación en la cotización: que la tarifa pública se exprese por hora no significa que el consumo se mida por segundo.

CoreWeave anuncia como gratuitas las transferencias internas y por internet, mientras que el almacenamiento y los servicios de IP pública tienen cargos propios. Esto justifica estudiar la plataforma para trabajos que mueven muchos datos, pero el compromiso de cómputo debe seguir siendo útil. Ahorrar en transferencias no compensa un clúster que pasa inactivo la mayor parte del periodo reservado.

La documentación de CoreWeave Kubernetes Service describe el plano de control gestionado, los nodos físicos dedicados, las redes privadas y las redes para GPU. Para un equipo pequeño de IA, lo decisivo es quién se hace cargo: ¿quién empaquetará los trabajos, vigilará los fallos, gestionará los secretos y restablecerá el servicio? Si es la misma persona que todavía está validando la aplicación, un Pod o una API más sencillos pueden permitirle lanzar antes una función que realmente opere.

7. Google Cloud: cuando conviene ejecutar el modelo junto a tu aplicación

Google Cloud ofrece máquinas virtuales de Compute Engine con GPU. Es una opción lógica para evaluar si tu aplicación y tus datos ya están allí. Mantener la ejecución del modelo cerca del resto del sistema puede simplificar el despliegue, aunque una nube especializada ofrezca una tarifa de GPU atractiva. Su límite es el acceso: deben coincidir el tipo de máquina, la región, la cuota y la disponibilidad física. Elige Google Cloud cuando la ubicación y la configuración operativa existente beneficien al trabajo; no tomes su precio inicial de GPU como el de un servidor completo.

Ideal para: Desarrolladores que incorporan tareas con GPU a una aplicación que ya operan en Google Cloud.
Lo más destacado: Familias de máquinas con GPU y controles explícitos de disponibilidad regional y cuotas.
Precio: Conectar una T4 en Iowa parte de $0.35/hora solo por la GPU, más la máquina virtual, verificado el 30 de octubre de 2026 en la página de precios de aceleradores de Google.
Prueba gratuita: No se pueden añadir GPU durante Free Trial; es necesario pasar a una cuenta de pago.

Precios de GPU en Google Cloud: también pagas la máquina virtual

Una GPU conectada es un recurso adicional, no una máquina completa. La T4 de la tarifa citada tiene 16 GB de memoria GPU. Si una aplicación necesita más memoria u otro acelerador, debe elegir una configuración diferente en vez de construir su presupuesto alrededor de ese precio de entrada.

Google también ofrece familias de máquinas con GPU integradas, entre ellas G2 con L4, A2 con variantes A100 y variantes A3 que usan H100 o H200. El precio de una máquina integrada y el de una GPU conectada cubren recursos distintos. Incluye en la estimación el tipo de máquina elegido, además del almacenamiento y los cargos de red.

Compute Engine factura por segundo después de un mínimo de un minuto. Una máquina virtual encendida sin trabajo sigue generando cargos. Las reservas también pueden facturarse aunque los recursos no se hayan iniciado, por lo que reservar disponibilidad y lanzar un trabajo son decisiones diferentes. Las reglas de facturación de Compute Engine explican estos límites.

Disponibilidad de GPU en Google Cloud: la cuota es solo un requisito

Que un tipo de GPU figure en el catálogo no garantiza que tu cuenta pueda iniciarlo hoy en la zona que prefieres. Google documenta la compatibilidad de GPU por zona, y los controles de cuota funcionan por separado de la capacidad física. Comprueba la máquina que quieres en la lista de regiones y zonas con GPU y confirma después las cuotas de GPU necesarias.

Por ejemplo, un equipo que atiende a clientes cerca de su base de datos existente debería identificar ubicaciones cercanas aceptables antes de solicitar una configuración GPU. Si la zona deseada no tiene capacidad, alejar únicamente el servidor del modelo puede cambiar tanto el tiempo de respuesta como el recorrido de las transferencias de datos. Trata esa alternativa como un cambio en la aplicación que debe probarse.

Free Trial impone otra restricción: no permite añadir GPU ni solicitar aumentos de cuota. El nivel gratuito permanente Free Tier de Google también excluye las GPU. Por tanto, un anuncio de créditos de bienvenida no demuestra que una cuenta nueva pueda iniciar de inmediato un experimento con GPU. Las condiciones de Google son la referencia que hay que seguir.

Cómo elegir GPU en la nube para IA

Descarta primero el hardware que no puede ejecutar la carga de trabajo; después compara los proveedores que ofrecen el adecuado. La memoria de la GPU, a menudo llamada VRAM, almacena el modelo y el estado necesario para ejecutarlo. Un modelo que apenas logra cargarse puede fallar cuando llega un prompt más largo u otra solicitud simultánea.

Empieza con una estimación que contemple solo los pesos. A 16 bits, cada parámetro ocupa 2 bytes; a 4 bits, el peso sin otros componentes ocupa medio byte. Por tanto, un modelo de 8 mil millones de parámetros tiene unos 16 GB de pesos a 16 bits o 4 GB de pesos a 4 bits. Uno de 32 mil millones da 64 GB o 16 GB; uno de 70 mil millones, 140 GB o 35 GB. Son nuestros cálculos en GB decimales, no requisitos medidos para servir los modelos. La guía de dimensionamiento de Runpod explica la regla de memoria que usamos como base.

El espacio que falta también cuenta. El entorno de inferencia necesita memoria de trabajo, y la caché KV almacena el estado de atención a medida que avanza la generación. La longitud del contexto y las solicitudes simultáneas modifican ese estado. Un «modelo de 35 GB» no significa que baste un presupuesto de memoria de 35 GB para desplegarlo. La documentación de caché de Hugging Face explica por qué hay que considerar la caché por separado.

Usa las tarjetas de 24 GB, 48 GB y 80 GB como grupos de evaluación, no como garantías. Un modelo pequeño cuantizado puede dejar un margen útil en un dispositivo de 24 GB. Un modelo mayor, un contexto más largo o más solicitudes simultáneas pueden exigir otra capacidad. Deja un margen explícito sobre el máximo consumo de memoria observado, en lugar de dimensionar a partir de la solicitud más pequeña que funcionó.

El fine-tuning cambia el problema. El entrenamiento completo añade gradientes, estado del optimizador y activaciones guardadas. Los métodos basados en adaptadores actualizan un subconjunto menor de parámetros, lo que puede reducir los requisitos, pero no elimina todos los costos de memoria. Que una ejecución de inferencia funcione no demuestra que el fine-tuning completo quepa en la misma tarjeta. Consulta el desglose de memoria de entrenamiento y la introducción al fine-tuning eficiente en parámetros.

Después revisa la variante de GPU y la compatibilidad del software. Que un proveedor anuncie H100 no significa que todas sus ofertas H100 tengan el mismo formato físico, configuración de memoria, asignación de CPU o interconexión. Usar varias GPU también requiere un framework capaz de repartir bien el trabajo; comprar más tarjetas no resuelve automáticamente una carga demasiado lenta o grande.

Termina revisando todo el ciclo que se factura. Para cada finalista, distingue el arranque del cómputo, el trabajo útil, la espera con recursos activos, la terminación y el almacenamiento conservado. Estima un mes con el calendario previsto, incluidos los periodos inactivos y los reintentos. Una máquina asignada de forma continua y un lote diario corto necesitan presupuestos distintos, aunque la tarifa horaria anunciada sea idéntica.

Qué proveedor conviene en cada caso

Lo que cambia la elección es, primero, si necesitas controlar el entorno de ejecución y, después, si conviene mantenerlo preparado. Si una API compatible resuelve la función, empieza por evaluar Together AI. Si tu código de inferencia es imprescindible y el tráfico es irregular, compara Modal con Runpod Serverless. Si necesitas un entorno interactivo o una sesión sostenida de fine-tuning, empieza por los Pods de Runpod y las instancias de Lambda.

Si el trabajo por lotes se puede reanudar y admite distintas ubicaciones, añade Vast.ai. Si ya conoces la carga del clúster y hay alguien a cargo de operarlo, añade CoreWeave. Si la aplicación ya depende de una ubicación y una configuración operativa concretas de Google Cloud, evalúa su capacidad GPU antes de asumir el costo de migrar a otro proveedor.

Reservar capacidad tiene sentido cuando sabes que el hardware seguirá siendo útil durante el plazo contratado y que asegurar su disponibilidad importa. No reserves para descubrir cuánto lo vas a usar. Ejecuta primero el trabajo, identifica la demanda que se mantiene durante los periodos tranquilos y reserva solo la capacidad que justifique esa base.

Un servicio sensible a la latencia también puede necesitar capacidad dedicada o preparada aunque reciba relativamente pocas solicitudes. Hacer esperar al cliente después de cada periodo sin actividad puede salir más caro que mantener un worker inactivo. Mide la primera respuesta tras la inactividad y las respuestas más lentas durante las ráfagas; la latencia media puede ocultar ambos problemas.

Si todavía estás decidiendo si necesitas controlar un entorno GPU, la guía sobre chips de inferencia frente a GPU explica la decisión más amplia sobre el control del hardware.

Cómo seleccionamos los proveedores

Los criterios son la adecuación al trabajo, una unidad de contratación verificable, la memoria disponible, los costos de datos, el comportamiento al arrancar y el acceso regional. Los siete proveedores cubren API de modelos gestionadas, aplicaciones serverless con código propio, alquiler directo de GPU, marketplaces y clústeres planificados. Cada recomendación responde a un trabajo concreto; no es una clasificación universal de velocidad.

Las afirmaciones sobre precios y capacidades se contrastaron con las páginas de los proveedores el 30 de octubre de 2026. Para esta comparativa no se alquilaron GPU ni se realizaron pruebas de rendimiento o disponibilidad. Las estimaciones de pesos son cálculos explícitos; las recomendaciones de plataformas se basan en analizar el comportamiento documentado.

La selección se centra en desarrolladores y equipos pequeños de IA. Añadir directorios generales de nube, intermediarios de contratación y otros grandes proveedores sumaría nombres sin resolver la primera decisión: si necesitas un endpoint de modelos, una máquina o un clúster. Un proveedor solo debe llegar a la evaluación final si puede ofrecer la configuración necesaria en una ubicación donde puedas utilizarla.

Qué opciones conviene evitar

Evita un modelo de contratación que no encaje con tu trabajo, aunque el proveedor sea adecuado en otros casos.

• Capacidad interrumpible de Vast.ai para un trabajo que no puede reanudarse ni repetirse de forma segura. Comprueba la recuperación antes de asumir el riesgo de interrupción.
• Runpod Community Cloud si tu plan depende de conectar un volumen de red de Runpod. Esa opción de almacenamiento corresponde a los Pods de Secure Cloud.
• Modal escalado a cero si cada primera respuesta debe cumplir un objetivo de latencia estricto y no has medido la inicialización. Presupuesta capacidad preparada o cambia el despliegue.
• Lambda 1-Click Clusters o una reserva de CoreWeave mientras la cantidad útil de GPU y la duración del trabajo sigan siendo suposiciones. Determina primero la demanda con un alquiler menor.
• Together AI serverless si el punto de control o el comportamiento del entorno que necesitas quedan fuera de lo que admite su API. Evalúa sus productos dedicados o un entorno GPU programable.
• Free Trial de Google Cloud sin pasar a una cuenta de pago como plan para acceder de inmediato a GPU. Sus restricciones de GPU son explícitas.

Preguntas frecuentes sobre GPU en la nube

¿Qué proveedores de GPU en la nube conviene comparar?

Los siete proveedores de esta comparativa son Runpod, Lambda, CoreWeave, Vast.ai, Modal, Together AI y Google Cloud. Empieza por la categoría de producto que necesitas: una API de modelos gestionada, cómputo serverless con código propio, una máquina bajo demanda, un alquiler en un marketplace o capacidad de clúster reservada. Las secciones de cada proveedor explican dónde se solapan esas categorías.

¿Se puede usar una GPU en la nube gratis?

El plan Starter de Modal incluye créditos mensuales limitados de cómputo, no acceso ilimitado a GPU, y los cargos por tokens de Shared Endpoints van aparte. Free Trial de Google bloquea la conexión de GPU hasta pasar a una cuenta de pago, mientras que Free Tier también las excluye. Together AI exige explícitamente acceso de prepago. Usa los créditos para evaluar una carga de trabajo, no como plan de capacidad para producción.

¿Cómo comparar servicios de GPU en la nube?

Compara el mismo punto de control, precisión, longitudes de entrada y concurrencia en la variante exacta de GPU y con la misma cantidad de recursos asignados. Incluye el arranque y la espera facturados, el almacenamiento, las transferencias y el trabajo fallido. El resultado útil es el costo del trabajo completado que cumple tus requisitos de latencia y recuperación, no la cifra más pequeña junto a «GPU-hora».

La próxima semana, prueba dos finalistas con la misma carga pequeña y los mismos criterios de aceptación. Registra el pico de memoria, el tiempo hasta el primer resultado útil, el rendimiento en trabajos completados, el tiempo de recursos facturado y el costo que queda después de detenerlos. Para entrenamiento, ensaya la recuperación desde un punto de control guardado; para inferencia, prueba una solicitud tras un periodo de inactividad y una ráfaga. Amplía el despliegue solo cuando esos resultados lo justifiquen.

Obtén la lista de verificación para auditar flujos de trabajo empresariales con IA y el boletín para quienes los gestionan.