Architecture de Kvasir
Une seule carte de tout le système : les wallets, le gateway qui encaisse, le bridge qui donne un visage au moteur, et le réseau p4 qui exécute le modèle.
Kvasir, ce sont quatre couches et une couture chacune. Les wallets détiennent les clés. Le gateway encaisse le paiement et tient le registre. Le bridge donne un visage HTTP au moteur d'inférence. Le réseau p4 exécute réellement le modèle. Tout ce qui suit découle de l'endroit où tombent ces coutures — et le schéma distingue ce qui tourne aujourd'hui de ce qui n'est encore qu'une conception.
Les clés ne quittent jamais l'appareil
iOS (Swift), Android (Kotlin) et desktop (React + Electron) sont des builds distincts du même wallet, et c'est le build desktop que le gateway sert aussi sur / comme wallet de navigateur — un wallet complet, avec signature dans la page, pas une console en lecture seule. Les récompenses sont versées sur l'adresse Solana propre à chaque propriétaire ; le gateway ne détient jamais une clé d'utilisateur.
Un seul processus, deux surfaces
solana/staking-service est à la fois le gateway d'API (un /v1/chat/completions compatible OpenAI, plus le flux de paiement à la requête /api/pay/quote → /api/inference) et le gateway de règlement (staking, registre des nœuds, comptes de crédit, crédit de contribution). Les deux ne font qu'un seul processus parce qu'ils partagent un seul registre : une requête n'est servie qu'une fois son transfert de KVR vérifié on-chain, et c'est ce même registre qui crédite les nœuds qui l'ont servie.
Le paiement se règle avant que l'inférence ne s'exécute. Si le bridge échoue ensuite, le gateway rembourse le payeur depuis la trésorerie et renvoie un 502 plutôt que de facturer du vide. Il n'y a derrière ni modèle factice ni catalogue de remplissage : un modèle que l'app propose est un modèle qu'un bridge sert réellement, sinon la liste est vide.
Le visage HTTP du moteur
Le bridge (p4bridge) est un OUTER au sens de p4 : il installe une session à travers les stages, soumet au stage de tête et recueille le flux de tokens. Pour le gateway, c'est un contrat petit et figé — quels modèles sont chargés, qui a contribué combien, et les complétions.
| Route | Ce qu'elle répond |
|---|---|
/api/controllers | quels modèles sont chargés, et l'état de chaque stage |
/api/runtime | le wallet de l'opérateur et les machines derrière lui |
/api/contributions | les lignes par nœud, unités, requêtes, débit |
/c/<model>/v1/chat/completions | l'inférence |
Deux tâches que p4 laisse délibérément au bridge : le template de conversation (p4 transmet au stage server un prompt opaque et n'en applique aucun, si bien qu'un modèle instruct poursuivrait votre texte au lieu d'y répondre) et le bloc de raisonnement (renvoyé comme reasoning_content, séparé de content, pour qu'une passe de réflexion ne puisse pas dévorer silencieusement le budget de tokens et facturer au payeur une réponse vide).
Le bridge n'est jamais publié. Sa seule authentification est un service token partagé, et tout ce qui l'atteint peut faire tourner l'anneau. Il écoute sur la loopback ; le tunnel est la porte.
Les agents possèdent les nœuds, les stage servers détiennent les couches
Un agent possède les nœuds d'un hôte ; un stage server est un processus détenant une tranche des couches du modèle. Un stage passe son résultat au suivant en demandant à son propre agent de composer vers l'agent de ce stage à l'adresse que cet agent annonce — l'adresse annoncée doit donc être joignable depuis les autres hôtes, et devrait désigner le réseau le plus rapide qu'ils partagent. Sur le rack MI250, c'est le lien InfiniBand, pas le LAN du bureau, et jamais la loopback.
- `p4-agent` et `p4_staged_server` forment une seule release. Un agent compilé depuis un arbre plus récent échoue au READY sur une capacité absente du HELLO — après avoir chargé le modèle entier.
- Le placement est un artefact d'opérateur. Quelles couches se posent sur quel GPU, sous quelle load generation, vient d'un plan de placement ; le bridge répond
409à qui lui demande de servir, et le watchdog du gateway le signale une fois puis cesse de demander. - Un pipeline exige au moins deux stages. La commande de session refuse un pipeline à un seul stage.
Une adresse composable pour un portable
Les nœuds de bordure — une app desktop, un téléphone — n'ont aucune adresse que l'on puisse composer. Le relais leur en donne une : le nœud se connecte vers l'extérieur, prouve la paire de clés de son wallet sur un challenge ed25519, et devient dès lors joignable à travers le relais. Le relais est la frontière d'authentification et n'analyse jamais les payloads. L'installeur desktop embarque l'agent p4 avec l'app : rejoindre le réseau n'est pas une seconde installation.
Le crédit suit la participation
Chaque stage rapporte les lignes de tokens qu'il a exécutées. Le bridge les accumule par nœud, et le gateway interroge /api/contributions toutes les 30 secondes et crédite le wallet que le bridge désigne, à raison de rows / 1000 unités mises à l'échelle par le niveau de performance du nœud. Dans un pipeline, tous les stages voient les mêmes lignes : un anneau à quatre stages paie donc ses quatre stages à égalité, quel que soit le nombre de couches détenues par chacun — le crédit suit la participation, pas la part de poids. Le sharding d'experts, où les nœuds détiennent des fractions différentes d'une même couche, est le cas qui obligera à revoir cela.
Ce que le schéma marque comme proposé
P4 Studio est la console d'opérateur propre à p4. Le flux d'observabilité par requête qu'elle attend des agents est une proposition en amont, pas quelque chose qui tourne ici — c'est pour cela que le schéma le dessine en pointillés, aux côtés des shards d'experts servis depuis des nœuds de bordure, conçus mais pas encore en service.