NatusAIModell- und Tensor-Berechnung
Gekachelte und dünnbesetzte Tensor-Layouts, Algebra, Rechengraphen, Modellressourcen, ONNX, Training, Autodiff, GPU-/NPU-Ausführung und verteilte Berechnung bleiben späteren Ausbaustufen vorbehalten.
Cygnus · spätere Profile & VorschlägeRoadmapWas nach einem bewährten Kern kommt. Der Umfang folgt den Nachweisen.
Dies sind vorgeschlagene oder zurückgestellte Fähigkeitsfamilien – keine veröffentlichten Funktionen und kein terminierter Lieferplan. Die Erstversion muss ihre Aussagen für einen einzelnen Server erst belegen, bevor ein breiteres Profil angenommen wird.
Status: Der optionale eigene Marktplatz ist eine gewählte Richtung, deren öffentlicher Betrieb an Kriterien gebunden bleibt. Cluster-, Managed-Platform- und Governance-Profile brauchen eigene Nachweise und Entscheidungen. Ein Termin ist nicht festgelegt.
Späteres Cluster-Profil Roadmap
Erst einen Knoten belegen, dann das System verteilen.
Das spätere Cluster-Profil würde Shards, Replikation, Failover, Routing, Rebalancing, Shard-übergreifende Transaktionen, verteilte Traversierung, Upgrades mit gemischten Versionen und die Verlagerung von Mandanten ergänzen.
Ein Mehrknoten- oder Multi-PiB-Designziel gehört hierher, niemals zu Cygnus 1.0.
Die Abnahme einer horizontalen Skalierung würde Nachweise zu verteilter Korrektheit, Wiederherstellung und Fehlerdomänen auf repräsentativen Workloads erfordern. Reservierte Formatfelder allein belegen keinen Cluster.
1 Knoten
Produktivtopologie von Cygnus 1.0: Kapazität und Fehlerdomäne bleiben ein Server.
Multi-PiB
Ein Designziel nur für das spätere Cluster-Profil, keine Aussage zur Erstversion.
Spätere KI und Rechenleistung Roadmap
Breitere KI erfordert eine separat qualifizierte Ausführung.
Anbieternative Workflows
Agenten-Workflows, Subagenten, Skills, Plugins, Hooks, Zusammenarbeit und Hintergrundaufgaben, erweitertes Gedächtnis, generierte Kompaktierung und automatisches Fallback liegen außerhalb des ersten Chat-Profils.
Weitere Anbindungen
Native oder kompatible Schnittstellen für vLLM, Ollama-kompatible Dienste, Anthropic-Agenten und Codex erfordern eine eigene Qualifizierung. Managed CUDA bleibt an den exakt zertifizierten Rahmen gebunden.
Modelle, Anbieterartefakte und Ressourcenrahmen brauchen fest versionierte Nachweise zu Fähigkeiten und Sicherheit. Ein entfernter Anbieter liefert keine lokale Ressourcengarantie. Anbieter- und Produktnamen bezeichnen ausschließlich Schnittstellen.
Wiederverwendbares Ökosystem Roadmap
Eine verifizierte Lösung finden – oder einen privaten Kandidaten erstellen, wenn es keine gibt.
Ein optionaler eigener Marktplatz mit Bibliothekskreislauf ist eine gewählte spätere Produktrichtung; sein öffentlicher Betrieb bleibt an Kriterien gebunden.
Er soll exakt kompatible Releases finden oder ausdrücklich „kein Treffer“ melden und bei Bedarf einen modulselektiven privaten Kandidaten vorbereiten. Kompilierung, Sicherheits-, Ressourcen- und Kompatibilitätsprüfung sowie Agenten-Evaluierung gingen einer separaten Freigabe durch die Maintainer und einem signierten, unveränderlichen Release voraus.
Ein Bibliotheks-Release versioniert seine Module gemeinsam, während jede Anwendung nur die Module aktiviert, die sie braucht – ohne ungenutzten Nachbarcode, Abhängigkeiten, Anbieter, Berechtigungen oder Ressourcenprofile mitzuziehen.
Freigegebene Artefakte und veröffentlichbare Nachweise könnten anwendungsübergreifend wiederverwendet werden. Kundendaten, private Logik, Prompts und Anbieterschlüssel blieben innerhalb ihrer Zugriffsgrenze. Agenten könnten Kandidaten vorschlagen, sie aber nicht eigenständig installieren, autorisieren, signieren, freigeben oder veröffentlichen.
Eine breitere Referenzanwendung für eine Managed Platform ist ein separater, nicht beschlossener Vorschlag: Bereitstellung von Anwendungen, Flottensteuerung, kaufmännische Datensätze, Beitragskampagnen und gehostetes Self-Update. Preise, Gebühren, Vergütungen, Abrechnung und Finanzierung sind noch nicht entschieden.
Vorgeschlagene Datenwelten und Governance Vorgeschlagen · nicht ausgewählt
Forkbare Welten und unabhängige Verifikation brauchen neue Fehlermodelle.
Ein Vorschlag für die Zeit nach v1, hier so dargestellt, wie er im aktuellen Cygnus-Umfang erscheint. Nichts in diesem Abschnitt ist ausgewählt, terminiert oder Teil von Cygnus 1.0.
Datenwelten
Strukturell geteilte Datenwelten, deterministische Simulation, semantischer Drei-Wege-Merge, Bilanzierung aufbewahrter Historie und explizite Merge-/Drop-Lebenszyklen sind zurückgestellt.
Unabhängige Verifikation
Eine vorgeschlagene Föderation würde byzantinisch fehlertolerante Finalität über deterministische Anwendungsübergänge und ein layoutunabhängiges semantisches State-Commitment nutzen. Validatoren, vollständige Verifizierer, Archive und Light-Verifizierer haben getrennte Rollen; Nutzer könnten eine unabhängig gehaltene Kopie der vollständigen öffentlichen Historie behalten und verifizieren, ohne Validator zu werden.
Eine qualifizierende Governance-Workload
Eine vorgeschlagene Anwendung für Liquid Democracy bräuchte unabhängig nachspielbare Antragsversionen, Snapshots der Stimmberechtigung, Erteilung und Widerruf von Delegationen, Regeln für Zyklen und Übersteuerungen, Stimmabgaben und deren Ablösung, Abschlusssemantik und Auszählungszertifikate.
Dies ist ein Vorschlag für die Zeit nach v1. Weder Konsensalgorithmus noch Validator-Governance, Identitätssystem, Token, öffentliches Netzwerk, betriebener Dienst oder Verfahren für das Wahlgeheimnis sind ausgewählt. Geheime Abstimmungen erfordern separat geprüfte Kryptografie und dürfen niemals Stimmen im Klartext veröffentlichen; eine verifizierte Historie allein begründet weder die Legitimität der Abstimmenden noch Fairness oder die Integrität einer Wahl.
Weitere zurückgestellte Familien
Angrenzende Arbeit bleibt außerhalb des Versprechens der Erstversion.
| Familie | Spätere Arbeit |
|---|---|
| Interpretation von Dokumenten und Medien | Mitgelieferte allgemeine Parser, OCR, Mediendekodierung/-transkodierung, Vorschaubilder, Frame-/Kachelextraktion, native Raster-Reprojektion und Übersichten. |
| Optimierung | JIT/AOT-Spezialisierung, Operator-Fusion, NUMA-Platzierung und adaptive Layouts. |
| Entwickler- und Komponentenwerkzeuge | Debug Adapter Protocol, Client für eine offene Paket-Registry und ein abgeschotteter Komponenten-Host. |
| Mandantenmobilität | Portabler Mandantenexport/-import und clusterabhängige Verlagerung. |
| UI und Web-Laufzeit | Allgemeine deklarative UI über ausgewählte Explorer-Muster hinaus, allgemeines Server-Rendering und eine browserseitige Sprachlaufzeit. |
| Aufbewahrung und Zeit | Standardmäßige kryptografische Löschung pro betroffener Person und schaltsekundenbewusste wissenschaftliche Zeitskalen. |
Widerlegbare Richtung
Die Nachweise können den Umfang ändern.
Die folgenden Punkte sind vorgeschlagene Kriterien für eine Neubewertung – keine erreichten Messwerte und keine Service-Level für Kunden. Wird eines erfüllt, löst das eine Überprüfung des Umfangs aus, kein Versprechen, eine Ersatzarchitektur auszuliefern.
| Signal | Vorgeschlagener Anlass zur Neubewertung |
|---|---|
| Aufnahme | Unter 80.000 dauerhaft verarbeiteten Meldungen/s auf der vorgeschlagenen 32-vCPU-Klasse bei transaktionaler Indexkonsistenz. Das Release-Kriterium liegt separat bei 100.000 Meldungen/s. |
| Abfrage | p99 über 500 ms für 250.000 aktuelle Positionen in einem Polygon oder über 1.000 ms für eine 90-tägige Schiffsroute, bei einem Verhältnis von Datensatz zu RAM von 24×. |
| Kosten der Richtlinien | Autorisierung auf Elementebene über 3× des grobgranularen p99. Das vorgeschlagene Release-Kriterium ist mit 2× strenger. |
| Eignung für Geodaten | Mehr als 20 % der räumlichen Abfragen von Designpartnern erfordern eine externe Geodatensprache. |
| Agenten-Abschlussquote | Weniger als 70 % der deklarierten Evaluierungen leerer Projekte gelingen ohne menschliche Nachbesserung. |
| Ausweichen auf externe Speicher | Ein Partner benötigt innerhalb von 90 Tagen einen weiteren Such-, Zeitreihen- oder Messaging-Speicher für die Referenz-Workload. |
| Lieferrisiko | Die Meilensteine für Kern, Dienste und Daten überschreiten bei realistischer Personalausstattung einen vorgeschlagenen Zeitraum von 30 Monaten nach dem ersten Meilenstein; dies ist ein Kriterium für eine Neubewertung, kein Liefertermin. |
| Wiederherstellung | Ein Test der geprüften Wiederherstellung schlägt fehl oder ein bestätigter Commit geht im Crashtest verloren. |
Workload, Hardware, Konsistenz, Personalausstattung und Testmethoden müssten vereinbart sein, bevor die Kriterien eine Release-Entscheidung leiten könnten.
Offene Entscheidungen
Die Pläne bleiben an Bedingungen geknüpft.
Weder öffentlicher Liefertermin noch Preis, Lizenz, Paket, Finanzierungsmodell für Anbieter oder Marktplatzgebühr sind festgelegt. Format-, Anbieter-, Locale- und Kompatibilitätsmatrizen sind Entscheidungen der Erstversion; spätere Profile brauchen ihre eigenen Belege.
Der erste technische Prüfpunkt sind die vollständigen Abnahmenachweise für Cygnus 1.0, einschließlich verifizierter Wiederherstellung und der festgelegten Supportzusagen. Der Umfang nach v1 wird anhand der tatsächlichen Nutzung durch Designpartner neu bewertet, nicht durch diese Roadmap vorausgesetzt.
Weiter entdecken
Mit unserem Team sprechen
Der Umfang folgt den Nachweisen. Unsere Gespräche auch.
Sagen Sie uns, welches spätere Profil für Ihre Workload wichtig ist. Wir teilen unsere Pläne offen – auch das, was noch nicht entschieden ist.
Oder schreiben Sie an contact@natusai.com
