Producto y uso ilimitado
La suscripción da acceso al modelo seleccionado durante 3, 7 o 30 días sin cuota total de tokens de entrada o salida. Cada suscripción incluye cuatro solicitudes simultáneas. Las claves de la cuenta usan un conjunto compartido de espacios para el modelo correspondiente. El espacio se libera cuando termina la operación.
Rate Cloud gestiona la ubicación de los pesos, los motores de ejecución, los perfiles de precisión y la distribución de solicitudes. El equipo se alquila a propietarios empresariales. La capacidad disponible de sus clústeres complementa la reserva estable. El uso ilimitado se refiere a los tokens durante el período: el contexto, el tiempo de cada operación, la concurrencia y los límites de protección siguen siendo finitos.
Servidores y cómputo
La arquitectura usa plataformas Huawei Atlas y aceleradores Ascend: Atlas 800I A2 y A3 para modelos grandes, y Atlas 900 A2 PoD y A3 SuperPoD para grupos distribuidos. Atlas 500 y 500 A2 se destinan a tareas de servicio pequeñas; Atlas 800 con Atlas 300I Duo pertenece a una clase de compatibilidad aparte.
Atlas 800I A2 contiene 8 NPU de 64 GB cada una. Atlas 800I A3 contiene 8 NPU físicas de 128 GB, representadas como 16 dispositivos lógicos. Son dos representaciones de la misma memoria y no deben sumarse. La compatibilidad se comprueba por separado para cada modelo. Entre sitios se trasladan solicitudes completas; los cálculos estrechamente acoplados de una réplica usan una red local compatible.
Modelos y cuantización
El mismo modelo se prepara en varias variantes de cuantización. Por ejemplo, GLM 5.3 puede atender distintas solicitudes con un perfil de calidad, equilibrado o económico. El sistema inteligente evalúa la tarea y elige una variante adecuada de ese mismo modelo. El usuario solo tiene que elegir el modelo; no necesita cambiar manualmente la cantidad de bits.
El perfil de calidad usa el formato original verificado, W8A8 u otra configuración aprobada. El perfil equilibrado combina la precisión de sus componentes, por ejemplo 4 y 8 bits con un promedio efectivo cercano a 6 bits. No promete INT6 universal. El perfil económico usa W4A16, W4A8 o MXFP4 verificados del mismo modelo. La disponibilidad depende del equipo y de la validación de calidad.
Imagina los números del modelo como valores escritos con distinta precisión. Una representación compacta ocupa menos memoria, pero puede afectar el resultado. Por eso, una búsqueda sencilla puede usar una variante compacta verificada, mientras que el código complejo, las matemáticas y el uso de herramientas pueden usar un perfil de calidad. Si hay dudas, el sistema elige calidad. Flash y Pro siguen siendo modelos separados y no se sustituyen entre sí.
| Modelo | Versión original | Variantes de un mismo modelo: el sistema elige para cada solicitud |
|---|---|---|
| GLM 5.3 | zai-org/GLM-5.3 / GLM-5.3-BF16 | Formato original; W8A8C8 o MXFP4 verificados en hardware compatible. |
| GLM 5.3 Flash | zai-org/GLM-5.3-Flash / BF16 | W8A8; A3 y 950DT usan variantes de hardware distintas, incluida MXFP8. |
| DeepSeek V4 Pro | deepseek-ai/DeepSeek-V4-Pro-0813 | MXFP8 y MXFP4 nativos; W4A8 preparado cuando se confirma la compatibilidad. |
| DeepSeek V4.1 Flash | deepseek-ai/DeepSeek-V4.1-Flash-1017 | MXFP4, FP8 nativos y componentes de mayor precisión; adaptación W8A8 para A2/A3 con ubicación independiente de Engram. |
| Qwen 3.8 Max | Qwen/Qwen3.8-2.4T-A95B | Perfiles verificados de calidad y ahorro del mismo modelo. Esta edición de arquitectura no establece un formato fijo único. |
Validación de calidad
Cada perfil se comprueba frente a la versión original exacta con tareas públicas, sintéticas y preparadas específicamente: código, matemáticas, contexto largo, herramientas y JSON estricto. Las conversaciones de usuarios no se usan para entrenamiento ni calibración.
La validación abarca la calidad del resultado, la memoria, la velocidad y el funcionamiento correcto de la API. Solo se permite una baja cantidad de bits para tareas adecuadas. Aumentar los bits de pesos de pocos bits ya publicados no recupera la información perdida. Cambiar reasoning_effort es un ajuste independiente y no se atribuye a la cuantización.
Ruta de la solicitud
Conexión segura → comprobar clave, suscripción y espacio libre → determinar requisitos → elegir el perfil del modelo seleccionado → asignar una réplica lista → transmitir la respuesta → liberar el espacio y borrar el contenido temporal.
Una operación lógica tiene un request_id; cada intento de cómputo tiene un attempt_id. Antes de empezar la salida, se permite reintentar en una réplica compatible dentro del plazo total. Una vez iniciado el flujo, el comienzo de una respuesta no se une a la continuación de una nueva generación. El cliente debe considerar incompleto un flujo interrumpido.
Distribución inteligente
El enrutador considera el contexto, las imágenes, las herramientas, el formato de respuesta, la complejidad de la tarea, la memoria disponible, la cola, el estado de la réplica y el plazo de asignación de recursos. El código, las matemáticas, los esquemas estrictos, las herramientas y las tareas inciertas tienen prioridad de calidad. Una pregunta breve no siempre es sencilla.
El coste solo se considera entre rutas adecuadas. Durante la operación se fijan la versión de los pesos y las funciones permitidas. Los servidores incompatibles se descartan antes de asignar. Si no hay capacidad adecuada, puede haber espera dentro del presupuesto interno o un error explícito de indisponibilidad temporal; nunca se sustituye silenciosamente por otro modelo.
Resiliencia y recuperación
Los grupos estables mantienen la operación principal y la recuperación. Los grupos interrumpibles adicionales aumentan la capacidad. Ante un aviso de revocación, el servidor deja de aceptar operaciones nuevas y las tareas pendientes continúan dentro del plazo original. La pérdida de un acelerador crítico excluye toda la réplica que depende de él.
Una réplica preparada pasa por la carga de pesos, el calentamiento y las comprobaciones de disponibilidad. Los grupos de fallo independientes reducen el impacto de una avería. Repetir cálculos puede aumentar la latencia. La arquitectura de recuperación no garantiza la disponibilidad 24/7 de cada modelo.
Seguridad de la infraestructura
Las transferencias externas están protegidas por TLS. Las conexiones entre servicios usan verificación de identidad y mTLS. Los permisos se conceden según las necesidades del trabajo. Las claves, cuentas, proyectos y áreas de caché están aislados. Los secretos de API y los cuerpos de solicitudes no deben aparecer en registros ni copias de seguridad.
La seguridad de la conexión no es lo mismo que la protección de los datos durante el cómputo. El equipo alquilado tiene su propio límite de confianza: no se puede prometer ejecución protegida por hardware en todos los aceleradores. Si se pierde el control, se excluye el nodo y se revoca su autoridad; para volver se exige revisión y limpieza.
Eliminación de solicitudes y caché temporal
Rate Cloud no crea un historial permanente del texto de solicitudes y respuestas ni entrena modelos con datos de usuarios. El contenido se procesa en memoria temporal. El objetivo de limpieza de los búferes de aplicación gestionados y disponibles es de hasta 5 segundos después de una entrega correcta y hasta 30 segundos tras un error definitivo, una cancelación o una desconexión.
La caché KV de cómputo aislada tiene un plazo propio: hasta 5 minutos sin reutilización y hasta 15 minutos de antigüedad absoluta. Al vencer el plazo, el bloque no se usa en nuevas coincidencias; una operación que ya lo esté usando puede terminar dentro de su plazo. La memoria se borra al liberar la última referencia. La caché no se escribe en disco persistente ni se incluye en instantáneas.
La clave de compatibilidad incluye cuenta, modelo, revisión de pesos, cuantización, tokenizador, plantilla de conversación e instrucciones del sistema. El índice está protegido con HMAC. El usuario no puede seleccionar el área de caché de otra persona. La política de tratamiento del proyecto define el perfil sin caché entre solicitudes. El historial de una aplicación cliente lo controla esa aplicación.
Los metadatos técnicos incluyen identificadores, modelo, perfil, hora, duración, usage, estado de los espacios y códigos de error. Los registros detallados se eliminan después de 30 días. No incluyen prompts, respuestas, argumentos de herramientas, archivos ni tokens de autorización. Los datos de cuenta, pago y solicitudes voluntarias de soporte tienen fines y plazos de conservación distintos.
Disponibilidad y compensación
No se garantiza la disponibilidad de los modelos las 24 horas del día, los 7 días de la semana. Si todo el sistema queda completamente inaccesible durante más de 4 horas seguidas y las solicitudes devuelven HTTP 503, se amplían las suscripciones pagadas: un período de 3 días recibe 12 horas, uno de 7 días recibe 1 día y uno de 30 días recibe 3 días.
Esta regla se aplica únicamente a una interrupción total del sistema con HTTP 503. Los errores de un modelo concreto, una respuesta lenta, los límites de concurrencia y otros códigos de error no cumplen el requisito. Para revisar el incidente, contacta con soporte e indica la hora y los identificadores de operación, sin enviar secretos de API ni contenido de solicitudes. Se mantienen los derechos obligatorios del usuario.
Versiones y criterios de implementación
La aceptación comprueba que se conserva el modelo seleccionado, se da prioridad a la calidad, la recuperación respeta el plazo original, la caché está aislada, el contenido se elimina, las conexiones están protegidas y los textos no aparecen en los análisis. Los cambios en los contratos de API, caché y perfiles deben concordar entre la documentación, el panel y las condiciones.