Arquitectura de Kvasir

Un solo mapa de todo el sistema: las wallets, el gateway que cobra, el bridge que da la cara por el motor, y la red p4 que ejecuta el modelo.

Kvasir son cuatro capas con una costura cada una. Las wallets guardan las claves. El gateway cobra el pago y lleva el libro contable. El bridge le pone cara HTTP al motor de inferencia. La red p4 es la que realmente ejecuta el modelo. Todo lo que sigue es consecuencia de dónde caen esas costuras — y el diagrama marca qué corre hoy frente a lo que todavía es un diseño.

iOS (Swift), Android (Kotlin) y escritorio (React + Electron) son builds distintas de la misma wallet, y la build de escritorio es además lo que el gateway sirve en / como wallet de navegador — una wallet completa, con firma dentro de la página, no una consola de solo lectura. Las recompensas se pagan a la dirección Solana propia de cada dueño; el gateway nunca guarda una clave de usuario.

solana/staking-service es a la vez el gateway de API (un /v1/chat/completions compatible con OpenAI, más el flujo de pago por petición /api/pay/quote → /api/inference) y el gateway de liquidación (staking, el registro de nodos, las cuentas de crédito, el crédito por contribución). Son un solo proceso porque comparten un solo libro contable: una petición solo se sirve después de verificar su transferencia de KVR on-chain, y ese mismo libro acredita a los nodos que la sirvieron.

El bridge (p4bridge) es un OUTER en términos de p4: instala una sesión a través de los stages, envía al stage de cabeza y recoge el stream de tokens. Para el gateway es un contrato pequeño y fijo — qué modelos están cargados, quién contribuyó cuánto, y completions.

Dos trabajos que p4 deja deliberadamente al bridge: la plantilla de chat (p4 le entrega al stage server un prompt opaco y no aplica ninguna, así que un modelo instruct continuaría tu texto en vez de responderlo) y el bloque de razonamiento (devuelto como reasoning_content, separado de content, para que una pasada de pensamiento no pueda comerse en silencio el presupuesto de tokens y cobrarle al pagador una respuesta en blanco).

Un agente posee los nodos de un host; un stage server es un proceso que guarda una rebanada de las capas del modelo. Un stage entrega su resultado al siguiente pidiéndole a su propio agente que marque al agente de ese stage en la dirección que ese agente anuncia — así que la dirección anunciada tiene que ser alcanzable desde los demás hosts, y debería ser la red más rápida que compartan. En el rack MI250 eso es el enlace InfiniBand, no la LAN de la oficina y nunca loopback.

• `p4-agent` y `p4_staged_server` son una sola release. Un agente compilado desde un árbol más nuevo falla en READY por una capacidad de HELLO ausente — después de cargar el modelo entero.
• La colocación es un artefacto del operador. Qué capas van en qué GPU, y bajo qué load generation, sale de un plan de colocación; el bridge responde 409 a quien le pida servir, y el watchdog del gateway lo dice una vez y deja de preguntar.
• Un pipeline necesita al menos dos stages. El comando de sesión rechaza un pipeline de un solo stage.

Los nodos de borde — una app de escritorio, un teléfono — no tienen ninguna dirección que se pueda marcar. El relay les da una: el nodo se conecta hacia fuera, demuestra el par de claves de la wallet con un desafío ed25519, y a partir de ahí es alcanzable a través del relay. El relay es la frontera de autenticación y nunca parsea cargas útiles. El instalador de escritorio trae el agente p4 junto a la app, así que unirse no es una segunda instalación.

Cada stage reporta las filas de tokens que ejecutó. El bridge las acumula por nodo, y el gateway sondea /api/contributions cada 30 segundos y acredita la wallet que el bridge nombra, como rows / 1000 unidades escaladas por el nivel de rendimiento del nodo. En un pipeline todos los stages ven las mismas filas, así que un anillo de cuatro stages paga igual a sus cuatro stages sin importar cuántas capas guarde cada uno — el crédito sigue a la participación, no a la cuota de peso. El sharding de expertos, donde los nodos guardan fracciones distintas de una capa, es el caso que obligará a revisar esto.

P4 Studio es la consola de operador propia de p4. El feed de observabilidad por petición que quiere de los agentes es una propuesta upstream, no algo que corra aquí — por eso el diagrama lo dibuja discontinuo, junto a los shards de expertos servidos desde nodos de borde, que están diseñados y todavía no en marcha.