Stack di calcolo AI per training e inferenza | Dweve Core

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Assistenza per agenti di codifica e operatori. Le metriche demo sono illustrative.

Terminale, ricerca, lint, test, git e altro.

Ricorda il tuo codebase e il contesto del team.

Agenti specializzati collaborano su diversi ambiti.

Ogni passaggio è registrato con timestamp.

Politiche, controlli e test vengono sempre eseguiti.

Rivedi le diff, richiedi modifiche, approvazione finale.

Riproduci qualsiasi sessione bit per bit quando qualcosa richiede revisione.

Leggi retry.ts, individuato bug di timeout

Agenti autonomi che scrivono codice e tengono traccia

per gestire timeout di rete, risposte 5xx e condizioni idempotent-safe. Helper puro, completamente testato.

Capacità e determinismo dichiarati per cella

Operazione diretta su infrastruttura controllata dal cliente

Un modello, più percorsi detenuti dal fornitore

la compressione vive in un altro strumento

la definizione e l'esecuzione gradualmente divergono

Runs on ordinary computers, where supported

cella di esecuzione e contratto di replay registrati

da binario a virgola mobile convenzionale

Il formato di archiviazione non è del tipo accumulatore

Dweve Core è uno stack di calcolo AI completo per training e inferenza. La maggior parte delle piattaforme AI copre solo una parte e affida il resto ad altri fornitori. Core mantiene authoring del modello, training, inferenza, kernel, dispatch e distribuzione in un unico sistema coerente. Su carichi di lavoro binari supportati, Core consuma il 96% in meno di energia rispetto a uno stack GPU.

25 famiglie di formati numerici registrati

I sistemi parziali creano dipendenza permanente

La definizione e l'esecuzione gradualmente divergono.

La compressione vive nello strumento di qualcun altro.

Nuovo hardware, nuovo sistema di servizio, nuovo comportamento.

La roadmap del fornitore diventa la tua roadmap.

Nessun singolo sistema può spiegare il risultato.

La dipendenza persiste perché lo spazio computazionale sottostante è solo parzialmente coperto.

Core mantiene le modifiche in larghezza numerica, packing, hardware e distribuzione all'interno di un unico sistema di implementazione. Un algoritmo non diventa un prodotto diverso perché passa da un server x86 ad ARM, una GPU, un browser o un target specializzato. L'operazione rimane nominata, ispezionabile e di proprietà durante tutto il trasferimento, e ogni percorso è registrato anziché dedotto da un'etichetta di formato.

Il registro delle implementazioni copre più di 2.900 operazioni, 76 categorie di operazioni e 25 famiglie di formati numerici registrati. Ogni percorso è determinato su nove dimensioni: algoritmo, tipo di dato, larghezza, packing, accumulatore, backend, set di istruzioni, politica di dispatch e modalità di determinismo. Il contratto di rappresentazione mantiene queste scelte numeriche e fisiche legate all'operazione. La visualizzazione qui sotto fissa la maggior parte di queste dimensioni così che una piccola fetta rappresentativa rimanga leggibile. Il conteggio descrive un registro di celle e contratti concreti, non un'affermazione che un'etichetta di formato o un badge di capacità generico spieghi da solo un percorso di esecuzione.

ciò che determina realmente un'esecuzione

Come viene memorizzato, come viene sommato.

Dove viene eseguito, su quale percorso reale.

Quale percorso viene scelto, sotto quale contratto.

Il campione è piccolo perché il registro delle implementazioni non lo è.

Arriva una nuova larghezza, packing, host o contratto.

L'operazione mantiene il suo significato.

La macchina sceglie il percorso per la nuova cella.

Quale codice è stato eseguito, su quale macchina, dichiarato.

Stesso asset, stesso proprietario, nuova condizione.

La prima assunzione ereditata che Core rimuove è che un singolo tipo di dato debba dominare tutto.

nessun piolo è una funzionalità di ricerca

Il processore dovrebbe essere sostituibile quanto il tipo di dato.

Core non tratta un ecosistema di acceleratori come la definizione di IA e tutto il resto come una versione minore. Le sue operazioni hanno implementazioni di riferimento scalari e percorsi specifici per target su backend CPU, GPU, FPGA, browser e deployment supportati. Il runtime seleziona un'implementazione in base alla macchina disponibile e alla policy associata al lavoro.

Un processore x86 moderno può usare le sue istruzioni vettoriali. ARM e Apple silicon possono usare i loro percorsi nativi. Le GPU NVIDIA, AMD e Apple possono usare i rispettivi backend. L'esecuzione nel browser può usare WebAssembly o WebGPU dove appropriato. I programmi di deployment possono puntare a hardware specializzato. Il processore è una destinazione per l'operazione. Non è il proprietario del modello.

Vettori x86, percorsi nativi ARM e Apple silicon.

GPU NVIDIA, AMD e Apple sui loro backend.

Hardware specializzato per programmi di deployment.

Le etichette di target generiche sono facili. Possedere il percorso reale è più difficile.

Il tipo di dato non era supportato, l'hardware target è cambiato e il quantizzatore richiedeva un altro runtime.

Lo stack di serving non poteva riprodurre il risultato. Procurement ha aperto un'altra revisione del fornitore.

Il quantizzatore richiedeva un altro runtime

Il risultato non poteva essere riprodotto

Procurement ha aperto un'altra revisione

Non hai aggiunto una funzionalità. Hai esposto un altro buco nella macchina.

Ottimizzato a mano significa che qualcuno possiede il risultato

Un'API ampia è facile da pubblicizzare. Il possesso a livello di macchina è molto più difficile. Core non conta un'operazione come coperta solo perché un'implementazione generica compila su un altro target. I percorsi supportati sono implementati e ottimizzati per la loro combinazione effettiva di operazione, rappresentazione, packing, backend e set di istruzioni.

La moltiplicazione di matrici binarie su AVX-512 non è trattata come moltiplicazione di matrici in virgola mobile con valori più piccoli. Le operazioni a bit impacchettati usano le istruzioni bit disponibili sulla macchina. Le operazioni intere e a virgola fissa usano l'accumulatore e il comportamento di overflow corretti. I percorsi GPU usano la struttura di esecuzione del target. Le implementazioni scalari restano presenti come riferimento e floor universale. Questo crea una risposta responsabile a una domanda semplice: quale codice ha effettivamente eseguito questa operazione su questa macchina? Core può nominare il percorso.

Scritta per ciò che viene effettivamente calcolato.

Istruzioni bit per i bit, non float scalati.

Comportamento di overflow corretto, by design.

Kernel NEON scritti per l'architettura vettoriale di ARM.

Questo possesso deve continuare oltre il kernel e lungo l'intero ciclo di vita del modello.

Una macchina dalla definizione all'inferenza

le stazioni che il modello non lascia mai

Addestrato per la rappresentazione che utilizzerà.

Eseguito dal sistema che lo ha addestrato.

Instradato al percorso ottimizzato per l'host.

Testato e riprodotto nella stessa macchina.

Una volta che il ciclo di vita è coerente, la variazione può diventare un contratto piuttosto che un incidente.

Core dichiara il contratto del percorso che è effettivamente eseguito. I percorsi binari, ternari, interi con e senza segno, a virgola fissa, adattivi ed esatti di Core Native sono puramente deterministici dove coperti, senza seed. I percorsi floating, bfloat, block-scaled e microscaled di Core Native utilizzano replay con seed. Core opzionale su Kera rende puramente deterministici anche i percorsi supportati in quelle famiglie floating.

Un flusso di lavoro regolamentato a bassa bitness, in formato Q o adattivo può richiedere un replay Core Native bit-identico. Un flusso di lavoro in famiglia floating può utilizzare un seed fissato e una registrazione completa sotto Core Native. Il campionamento creativo rimane una scelta di generazione separata. Una distribuzione che richiede esecuzione floating puramente deterministica bfloat, block-scaled, microscaled o convenzionale può utilizzare Core su Kera e rimuovere il seed. Questi sono contratti dichiarati diversi per la cella selezionata, non nomi di marketing intercambiabili per ogni risposta ripetuta.

il percorso selezionato indica quale si applica

Percorsi binari, interi, Q, adattivi ed esatti. Nessun seed.

Replay floating, bfloat, block-scaled e microscaled.

Percorsi supportati in famiglia floating, nessun seed richiesto.

Quando il comportamento cambia, un solo sistema dovrebbe ancora possedere la spiegazione.

Quando un risultato di produzione cambia in uno stack frammentato, la responsabilità è distribuita. Il framework incolpa l'exporter. L'exporter incolpa il runtime. Il runtime incolpa il kernel. Il kernel incolpa il driver. Il driver incolpa l'hardware. Core porta queste responsabilità all'interno di un unico sistema.

La definizione del modello, le scelte numeriche, il backend selezionato, il percorso di dispatch, la modalità di determinismo e il record di esecuzione risultante possono essere esaminati insieme. Ciò non significa che ogni dipendenza esterna scompaia. Le fonti di dati, le applicazioni, i sistemi operativi e l'hardware esistono ancora. Significa che la macchina AI stessa ha un unico confine responsabile. Una revisione può chiedere quale implementazione è stata eseguita, su quale target supportato e sotto quale contratto di replay, senza dover ricostruire la risposta dai sistemi interni di più fornitori.