Modell- och tensorberäkning
Rutindelade och glesa tensorlayouter, algebra, beräkningsgrafer, modellresurser, ONNX, träning, automatisk derivering, GPU/NPU-exekvering och distribuerad beräkning är fortfarande senare arbete.
Det här är föreslagna eller uppskjutna förmågefamiljer, inte släppta funktioner eller en daterad leveransplan. Den första versionen måste förtjäna sina anspråk för en enda server innan en bredare profil godtas.
Status: den valfria marknadsplatsen i egen regi är en vald riktning, men offentlig drift är fortfarande villkorad. Profilerna för kluster, förvaltad plattform och styrning kräver separata belägg och beslut. Inget datum är valt.

Den senare klusterprofilen skulle lägga till shards, replikering, failover, dirigering, ombalansering, transaktioner över flera shards, distribuerad traversering, uppgraderingar med blandade versioner och flytt av kunders data.
Ett designmål för flera noder eller flera PiB hör hemma här, aldrig i Cygnus 1.0.
För att godta utskalning krävs belägg för distribuerad korrekthet, återställning och feldomäner på representativa arbetslaster. Reserverade formatfält bevisar inte i sig ett kluster.
1 nod
Produktionstopologi för Cygnus 1.0: kapacitet och feldomän är en server.
flera PiB
Ett designmål enbart för den senare klusterprofilen, inte ett anspråk för den första versionen.
Rutindelade och glesa tensorlayouter, algebra, beräkningsgrafer, modellresurser, ONNX, träning, automatisk derivering, GPU/NPU-exekvering och distribuerad beräkning är fortfarande senare arbete.
Agentarbetsflöden, underagenter, skills, plugins, hooks, samarbete och bakgrundsuppgifter, avancerat minne, genererad komprimering och automatisk reservlösning ligger utanför den första chattprofilen.
Inbyggda eller kompatibla gränssnitt för vLLM, Ollama-kompatibla gränssnitt samt Anthropics agent- och Codex-gränssnitt kräver egen kvalificering. Förvaltad CUDA förutsätter fortfarande exakt den certifierade ramen.
Modeller, leverantörsartefakter och resursramar kräver fastställda belägg för förmåga och säkerhet. En extern leverantör ger ingen lokal resursgaranti. Leverantörs- och produktnamn anger endast gränssnitt.
En valfri marknadsplats och bibliotekscykel i egen regi är en vald senare produktriktning, men offentlig drift är fortfarande villkorad.
Den är utformad för att hitta exakt kompatibla releaser eller uttryckligen svara att ingen match finns, och sedan vid behov förbereda en privat kandidat med utvalda moduler. Kompilering, säkerhet, resurser, kompatibilitet och agentutvärdering skulle komma före ett separat godkännande av en ansvarig förvaltare och en signerad, oföränderlig release.
En biblioteksrelease versionerar sina moduler tillsammans, medan varje applikation bara aktiverar de moduler den behöver, utan att dra med sig oanvänd kod från andra moduler, beroenden, leverantörer, behörigheter eller resursprofiler.
Godkända artefakter och publicerbara belägg skulle kunna återanvändas mellan applikationer. Kunddata, privat logik, promptar och leverantörsnycklar skulle stanna inom sin åtkomstgräns. Agenter skulle kunna föreslå kandidater men inte på egen hand installera, auktorisera, signera, godkänna eller publicera dem.
En bredare referensapplikation för en förvaltad plattform är ett separat, ej fastställt förslag som omfattar provisionering av applikationer, flottstyrning, kommersiella poster, bidragskampanjer och självuppdatering i molndrift. Priser, avgifter, belöningar, fakturering och finansiering är ännu inte bestämda.
Ett förslag för tiden efter v1, återgivet så som det står i den nuvarande omfattningen för Cygnus. Inget i det här avsnittet är valt, schemalagt eller en del av Cygnus 1.0.
Strukturellt delade datavärldar, deterministisk simulering, semantisk trevägssammanslagning, redovisning av bevarad historik och uttryckliga livscykler för sammanslagning och kassering är uppskjutna.
En föreslagen federation skulle använda bysantinskt feltolerant slutgiltighet för deterministiska applikationsövergångar och ett layoutoberoende semantiskt tillståndsåtagande. Validerare, fullständiga verifierare, arkiv och lätta verifierare har separata roller; en användare skulle kunna behålla och verifiera en oberoende ägd kopia av hela den offentliga historiken utan att bli validerare.
En föreslagen applikation för flytande demokrati skulle kräva oberoende uppspelningsbara förslagsversioner, ögonblicksbilder av röstberättigande, beviljade och återkallade delegeringar, regler för cykler och åsidosättanden, avgivna och ersatta röster, regler för avslut samt intyg om rösträkning.
Det här är ett förslag för tiden efter v1. Ingen konsensusalgoritm, styrning av validerare, identitetssystem för personer, token, offentligt nätverk, driven tjänst eller metod för valhemlighet har valts. Hemliga omröstningar kräver separat granskad kryptografi och får aldrig publicera röster i klartext; verifierad historik visar inte i sig att väljarna är legitima, att valet är rättvist eller att valets integritet är säkrad.
| Familj | Senare arbete |
|---|---|
| Tolkning av dokument och media | Medföljande generella parsrar, OCR, avkodning och omkodning av media, miniatyrbilder, extrahering av bildrutor och rutor, inbyggd omprojicering av rasterdata och översiktsnivåer. |
| Optimering | JIT/AOT-specialisering, operatorfusion, NUMA-placering och adaptiva layouter. |
| Utvecklar- och komponentverktyg | Debug Adapter Protocol, klient för öppna paketregister och sandlådad komponentvärd. |
| Flytt av kunddata | Portabel export och import per kund samt klusterberoende flytt. |
| UI och webbkörmiljö | Generellt deklarativt UI utöver utvalda Explorer-mönster, generell serverrendering och en språkkörmiljö i webbläsaren. |
| Lagringstid och tid | Kryptografisk radering per registrerad som standard och vetenskapliga tidsskalor som hanterar skottsekunder. |
Följande är föreslagna kriterier för omprövning, inte uppnådda mätvärden eller servicenivåer för kunder. Om ett kriterium uppfylls utlöser det en översyn av omfattningen, inte ett löfte om att leverera en ersättande arkitektur.
| Signal | Föreslaget skäl till omprövning |
|---|---|
| Inläsning | Under 80 000 rapporter/s uthålligt på den föreslagna klassen med 32 vCPU och transaktionell indexkonsistens. Releasekravet är separat 100 000 rapporter/s. |
| Frågor | p99 över 500 ms för 250 000 aktuella positioner i en polygon, eller över 1 000 ms för ett fartygsspår på 90 dagar, vid en datamängd på 24× RAM. |
| Kostnad för policy | Behörighet på elementnivå över 3× p99 för grovkornig policy. Det föreslagna releasekravet är strängare, 2×. |
| Geografisk passform | Mer än 20 % av designpartnernas rumsliga frågor kräver ett externt rumsligt frågespråk. |
| Slutförande av agenter | Färre än 70 % av de deklarerade utvärderingarna från tomt projekt lyckas utan mänsklig reparation. |
| Behov av externa lager | En partner behöver ett annat lager för sökning, tidsserier eller meddelanden inom 90 dagar för referensarbetslasten. |
| Leveransrisk | Milstolparna för kärna, tjänster och data överskrider ett föreslaget intervall på 30 månader efter den första milstolpen med realistisk bemanning; det är ett kriterium för omprövning, inte ett leveransdatum. |
| Återställning | Något test av verifierad återställning misslyckas eller en bekräftad commit går förlorad vid kraschtester. |
Arbetslast, hårdvara, konsistens, bemanning och testmetoder måste avtalas innan kriterierna kan vägleda ett releasebeslut.
Inget offentligt leveransdatum, pris, licens, paket, finansieringsmodell för leverantörer eller avgift för marknadsplatsen har valts. Matriser för format, leverantörer, språkinställningar och kompatibilitet är beslut för den första versionen; senare profiler kräver egna bevis.
Den första tekniska kontrollpunkten är de fullständiga acceptansbeläggen för Cygnus 1.0, inklusive verifierad återställning och supportkontrakt. Omfattningen efter v1 omprövas utifrån designpartnernas faktiska användning, inte utifrån antaganden i den här färdplanen.
Berätta vilken senare profil som är viktig för din arbetslast. Vi delar planerna ärligt, inklusive det som inte är bestämt.
Eller skriv till contact@natusai.com
