Cygnus · perfiles posteriores y propuestasHoja de rutaSe trata de familias de capacidades propuestas o aplazadas, no de funciones publicadas ni de un calendario de entregas con fechas. La primera versión debe demostrar lo que afirma para un solo servidor antes de que se acepte un perfil más amplio.
Estado: el marketplace propio opcional es una dirección seleccionada cuya puesta en marcha pública sigue sujeta a criterios de aceptación. Los perfiles de clúster, de plataforma gestionada y de gobernanza necesitan evidencias y decisiones propias. No se ha fijado ninguna fecha.
El perfil de clúster posterior añadiría shards, replicación, conmutación por error, enrutamiento, reequilibrio, transacciones entre shards, recorrido distribuido, actualizaciones con versiones mixtas y reubicación de clientes (tenants).
Un objetivo de diseño multinodo o de varios PiB corresponde a este perfil, nunca a Cygnus 1.0.
La aceptación del escalado horizontal exigiría evidencia de corrección distribuida, de recuperación y de dominios de fallo con cargas de trabajo representativas. Los campos de formato reservados no bastan por sí solos para demostrar un clúster.
1 nodo
Topología de producción de Cygnus 1.0: la capacidad y el dominio de fallo siguen siendo un servidor.
varios PiB
Un objetivo de diseño exclusivo del perfil de clúster posterior, no algo que se afirme para la primera versión.
Las disposiciones de tensores en mosaico y dispersas, el álgebra, los grafos de cálculo, los recursos de modelos, ONNX, el entrenamiento, la diferenciación automática, la ejecución en GPU/NPU y el cálculo distribuido siguen siendo trabajo posterior.
Los flujos de trabajo de agentes, los subagentes, las skills, los plugins, los hooks, las tareas colaborativas o en segundo plano, la memoria avanzada, la compactación generada y el respaldo automático quedan fuera del primer perfil de chat.
Las interfaces de vLLM (nativas o compatibles), las compatibles con Ollama, las de agentes de Anthropic y las de Codex requieren su propia cualificación. CUDA gestionado sigue condicionado a la envolvente certificada exacta.
Los modelos, los artefactos de proveedores y las envolventes de recursos necesitan evidencia fijada de capacidades y de seguridad. Un proveedor remoto no aporta una garantía de recursos locales. Los nombres de proveedores y productos solo identifican interfaces.
Un marketplace propio opcional y un ciclo de bibliotecas son una dirección de producto posterior ya seleccionada, cuya puesta en marcha pública sigue sujeta a criterios de aceptación.
Está diseñado para descubrir versiones compatibles exactas o devolver explícitamente que no hay coincidencia, y después preparar, cuando haga falta, un candidato privado con selección de módulos. La compilación, la seguridad, los recursos, la compatibilidad y la evaluación por agentes precederían a una aprobación independiente de quien mantiene la biblioteca y a una versión inmutable firmada.
Una versión de biblioteca versiona sus módulos en conjunto, mientras que cada aplicación activa solo los módulos que necesita, sin arrastrar código, dependencias, proveedores, permisos ni perfiles de recursos de módulos hermanos que no utiliza.
Los artefactos aprobados y la evidencia publicable podrían reutilizarse entre aplicaciones. Los datos de los clientes, la lógica privada, los prompts y las claves de los proveedores permanecerían dentro de su perímetro de acceso. Los agentes podrían proponer candidatos, pero no podrían instalarlos, autorizarlos, firmarlos, aprobarlos ni publicarlos por su cuenta.
Una aplicación de referencia más amplia de plataforma gestionada es una propuesta independiente, no ratificada, que abarca el aprovisionamiento de aplicaciones, el control de flotas, los registros comerciales, las campañas de contribución y la autoactualización alojada. Los precios, las comisiones, las recompensas, la facturación y la financiación siguen sin decidirse.
Una propuesta posterior a la v1, que se muestra tal como figura en el alcance actual de Cygnus. Nada de lo que contiene esta sección está seleccionado, programado ni forma parte de Cygnus 1.0.
Los mundos de datos con estructura compartida, la simulación determinista, la fusión semántica a tres bandas, la contabilidad del historial conservado y los ciclos de vida explícitos de fusión y descarte quedan aplazados.
Una federación propuesta utilizaría una finalidad tolerante a fallos bizantinos sobre transiciones deterministas de la aplicación y un compromiso de estado semántico independiente de la disposición física. Validadores, verificadores completos, archivos y verificadores ligeros tienen funciones separadas; un usuario podría conservar y verificar una copia propia e independiente de todo el historial público sin convertirse en validador.
Una aplicación propuesta de democracia líquida necesitaría versiones de propuestas reproducibles de forma independiente, instantáneas de elegibilidad, concesiones y revocaciones de delegaciones, reglas de ciclos y de anulación, emisiones de votos y sustituciones, semántica de cierre y certificados de recuento.
Es una propuesta posterior a la v1. No se ha seleccionado ningún algoritmo de consenso, gobernanza de validadores, sistema de identidad personal, token, red pública, servicio operado ni esquema de secreto del voto. El voto secreto requiere una criptografía revisada por separado y nunca debe publicar votos en claro; un historial verificado no basta por sí solo para acreditar la legitimidad de los votantes, la equidad ni la integridad de una elección.
| Familia | Trabajo posterior |
|---|---|
| Interpretación de documentos y multimedia | Analizadores generales integrados, OCR, decodificación y transcodificación multimedia, miniaturas, extracción de fotogramas o mosaicos, reproyección ráster nativa y vistas generales. |
| Optimización | Especialización JIT/AOT, fusión de operadores, ubicación NUMA y disposiciones adaptativas. |
| Herramientas para desarrolladores y componentes | Debug Adapter Protocol, cliente de registro abierto de paquetes y host de componentes aislado (sandbox). |
| Movilidad de clientes (tenants) | Exportación/importación portable de los datos de un cliente y reubicación dependiente del clúster. |
| UI y entorno de ejecución web | UI declarativa general más allá de los patrones seleccionados del Explorer, renderizado general en el servidor y un entorno de ejecución del lenguaje en el navegador. |
| Conservación y tiempo | Borrado criptográfico predeterminado por titular de los datos y escalas de tiempo científicas que tienen en cuenta los segundos intercalares. |
Lo que sigue son criterios de revisión propuestos, no mediciones alcanzadas ni niveles de servicio para clientes. Cumplir uno de ellos desencadenaría una revisión del alcance, no la promesa de entregar una arquitectura de sustitución.
| Señal | Motivo propuesto para revisar |
|---|---|
| Ingesta | Por debajo de 80 000 informes/s sostenidos en la clase propuesta de 32 vCPU con coherencia transaccional de índices. El criterio de versión es, por separado, de 100 000 informes/s. |
| Consulta | p99 superior a 500 ms para 250 000 posiciones actuales en un polígono, o superior a 1000 ms para la trayectoria de un buque durante 90 días, con una relación entre conjunto de datos y RAM de 24×. |
| Coste de las políticas | Autorización por elemento superior a 3× el p99 de grano grueso. El criterio de versión propuesto es más estricto: 2×. |
| Encaje geoespacial | Más del 20 % de las consultas espaciales de los socios de diseño requieren un lenguaje espacial externo. |
| Finalización por agentes | Menos del 70 % de las evaluaciones declaradas en proyecto vacío tienen éxito sin reparación humana. |
| Recurso a almacenes externos | Un socio necesita, en un plazo de 90 días, otro almacén de búsqueda, de series temporales o de mensajería para la carga de trabajo de referencia. |
| Exposición en la entrega | Los hitos del núcleo, los servicios y los datos superan un intervalo propuesto de 30 meses tras el hito inicial con una dotación de personal alcanzable; es un criterio de revisión, no una fecha de entrega. |
| Recuperación | Falla cualquier prueba de restauración verificada o se pierde un commit confirmado en las pruebas de fallo. |
La carga de trabajo, el hardware, la coherencia, la dotación de personal y los métodos de prueba tendrían que acordarse antes de que los criterios pudieran orientar una decisión de versión.
No se ha fijado ninguna fecha pública de entrega, precio, licencia, paquete, modelo de financiación de proveedores ni comisión del marketplace. Las matrices de formatos, proveedores, configuraciones regionales y compatibilidad son decisiones de la primera versión; los perfiles posteriores necesitan su propia prueba.
El primer hito técnico es la evidencia de aceptación completa de Cygnus 1.0, incluidos la recuperación verificada y los contratos de soporte. El alcance posterior a la v1 se revisará a partir del uso real por parte de los socios de diseño, en lugar de darlo por supuesto en esta hoja de ruta.
Díganos qué perfil posterior es importante para su carga de trabajo. Compartimos los planes con honestidad, incluido lo que no está decidido.
O escríbanos a contact@natusai.com
NatusAI