Kvasir-architectuur

Eén kaart van het hele systeem: wallets, de gateway die de betaling aanneemt, de bridge die de engine afschermt, en het p4-netwerk dat het model draait.

Kvasir bestaat uit vier lagen met elk één naad. Wallets houden de sleutels. De gateway neemt de betaling aan en houdt het grootboek bij. De bridge zet een HTTP-gezicht op de inferentie-engine. Het p4-netwerk draait het model daadwerkelijk. Alles hieronder volgt uit waar die naden liggen — en het diagram markeert wat vandaag draait tegenover wat nog ontwerp is.

iOS (Swift), Android (Kotlin) en desktop (React + Electron) zijn aparte builds van dezelfde wallet, en de desktop-build is ook wat de gateway op / serveert als browser-wallet — een volwaardige wallet die in de pagina ondertekent, geen alleen-lezen console. Beloningen gaan naar het eigen Solana-adres van elke eigenaar; de gateway houdt nooit een gebruikerssleutel vast.

solana/staking-service is tegelijk de API-gateway (een OpenAI-compatibele /v1/chat/completions, plus de betaal-per-verzoek-flow /api/pay/quote → /api/inference) en de verrekengateway (staking, het node-register, creditrekeningen, bijdragekrediet). Ze zijn één proces omdat ze één grootboek delen: een verzoek wordt pas bediend nadat de KVR-overdracht on-chain is geverifieerd, en hetzelfde grootboek schrijft de nodes bij die het bedienden.

De bridge (p4bridge) is in p4-termen een OUTER: hij installeert een sessie over de stages, dient in bij de kopstage en verzamelt de tokenstroom. Voor de gateway is hij een klein, vast contract — welke modellen geladen zijn, wie hoeveel bijdroeg, en completions.

Twee taken die p4 bewust aan de bridge overlaat: het chat-template (p4 geeft de stage-server een ondoorzichtige prompt en past er geen enkele toe, dus een instruct-model zou je tekst voortzetten in plaats van hem te beantwoorden) en het redeneerblok (teruggegeven als reasoning_content, los van content, zodat een denkfase het tokenbudget niet stilletjes kan opeten en de betaler een leeg antwoord in rekening kan brengen).

Een agent bezit de nodes van een host; een stage-server is één proces dat een plak van de lagen van het model vasthoudt. Een stage geeft zijn resultaat door aan de volgende door zijn eigen agent te vragen de agent van die stage te bellen op het adres dat die agent adverteert — het geadverteerde adres moet dus bereikbaar zijn vanaf de andere hosts, en hoort het snelste netwerk te zijn dat ze delen. Op het MI250-rack is dat de InfiniBand-link, niet het kantoor-LAN en nooit loopback.

• `p4-agent` en `p4_staged_server` zijn één release. Een agent die uit een nieuwere tree is gebouwd faalt bij READY op een ontbrekende HELLO-capaciteit — nadat het hele model is geladen.
• Plaatsing is een operator-artefact. Welke lagen op welke GPU zitten, onder welke load generation, komt uit een placement plan; de bridge antwoordt 409 aan wie hem vraagt te serveren, en de watchdog van de gateway zegt dat één keer en stopt met vragen.
• Een pipeline heeft minstens twee stages nodig. Het sessiecommando weigert een pipeline met één stage.

Edge-nodes — een desktop-app, een telefoon — hebben geen adres dat iemand kan bellen. De relay geeft ze er een: de node belt naar buiten, bewijst het wallet-sleutelpaar met een ed25519-challenge, en is daarna via de relay bereikbaar. De relay is de authenticatiegrens en parseert nooit payloads. De desktop-installer levert de p4-agent samen met de app, dus meedoen is geen tweede installatie.

Elke stage rapporteert de tokenrijen die hij heeft gedraaid. De bridge telt ze per node op, en de gateway pollt elke 30 seconden /api/contributions en schrijft bij op de wallet die de bridge noemt, als rows / 1000 eenheden geschaald naar het prestatieniveau van de node. In een pipeline ziet elke stage dezelfde rijen, dus een ring met vier stages betaalt zijn vier stages gelijk, ongeacht hoeveel lagen elk vasthoudt — krediet volgt deelname, niet gewichtsaandeel. Expert-sharding, waarbij nodes verschillende fracties van een laag vasthouden, is het geval dat dit opnieuw ter discussie zal stellen.

P4 Studio is de eigen operatorconsole van p4. De observability-feed per verzoek die hij van de agents wil hebben, is een voorstel upstream en draait hier niet — daarom tekent het diagram hem gestippeld, naast expert-shards die vanaf edge-nodes worden geserveerd, wat ontworpen is maar nog niet draait.