Kvasir 架构

整个系统的一张图：钱包、收款的网关、为引擎装上门面的 bridge，以及真正运行模型的 p4 网络。

Kvasir 是四个层次，每两层之间只有一道接缝。钱包持有密钥。网关收取付款并保管账本。bridge 为推理引擎装上 HTTP 门面。p4 网络真正运行模型。下面的一切都是这些接缝落在何处的结果——示意图也标出了哪些今天已在运行、哪些仍只是设计。

iOS（Swift）、Android（Kotlin）和桌面（React + Electron）是同一个钱包的三种构建，而桌面构建同时也是网关在 / 上提供的浏览器钱包——一个支持页内签名的完整钱包，不是只读控制台。奖励支付到每位所有者自己的 Solana 地址；网关从不持有用户的密钥。

solana/staking-service 既是 API 网关（OpenAI 兼容的 /v1/chat/completions，以及 /api/pay/quote → /api/inference 的按次付费流程），也是结算网关（质押、节点注册表、额度账户、贡献记账）。它们是同一个进程，因为共享同一本账：一个请求只有在其 KVR 转账在链上被验证之后才会被服务，而同一本账随后又为服务了它的节点记账。

bridge（p4bridge）在 p4 的术语里是一个 OUTER：它在各 stage 上装配会话、向头部提交请求、汇集 token 流。对网关而言，它只是一份小而固定的契约——哪些模型已加载、谁贡献了多少、以及补全。

p4 刻意留给 bridge 的两件事：对话模板（p4 把不透明的提示词原样交给 stage server，自己不套用任何格式，因此 instruct 模型会续写你的文本而不是回答它）和思考块（作为 reasoning_content 返回，与 content 分开，这样一次思考过程就不会悄悄吃光 token 预算、让付款方为一份空白回复买单）。

agent 拥有一台主机上的节点；stage server 是持有模型一段层切片的单个进程。一个 stage 把结果交给下一个的方式，是请自己的 agent 去拨通那个 stage 的 agent——按那个 agent 所公示的地址。因此公示地址必须能被其他主机访问，并且应当是它们共享的最快的那张网。在 MI250 机架上那是 InfiniBand 链路，而不是办公室 LAN，更绝不是 loopback。

• `p4-agent` 与 `p4_staged_server` 是同一个发行版。用更新的代码树构建的 agent 会在 READY 阶段因缺少 HELLO 能力而失败——而且是在整个模型加载完之后。
• 放置是运营者的产物。哪些层落在哪张 GPU 上、在哪个 load generation 下，来自一份放置方案（placement plan）；谁要求 bridge 去服务，它就回 409，而网关的看门狗说一次之后就不再问了。
• 一条流水线至少要两个 stage。会话命令会拒绝单 stage 的流水线。

边缘节点——桌面应用、手机——没有任何人能拨通的地址。中继给了它们一个：节点向外连接，用 ed25519 挑战证明自己的钱包密钥对，此后即可经由中继被访问。中继就是认证边界，且从不解析载荷。桌面安装包把 p4 agent 与应用一起装上，因此加入网络不需要第二次安装。

每个 stage 汇报自己跑过的 token 行数。bridge 按节点累计，网关每 30 秒轮询一次 /api/contributions，并以 rows / 1000 个单位、按节点的性能等级缩放后，记入 bridge 指名的那个钱包。在一条流水线里每个 stage 看到的行数相同，因此一个四 stage 的环会平均付给它的四个 stage，无论各自持有多少层——记账跟随参与，而不是权重份额。专家分片让节点各持一层的不同部分，那正是需要重新审视这一点的场景。

P4 Studio 是 p4 自己的运营者控制台。它想从 agent 那里获取的逐请求可观测性数据流，在上游还只是一份提案，并不是此处正在运行的东西——示意图为此把它画成虚线，与它并列的还有从边缘节点提供的专家分片：已完成设计，尚未运行。