Kvasir のアーキテクチャ

システム全体をひとつの地図に:鍵を持つウォレット、支払いを受けるゲートウェイ、エンジンの前に立つ bridge、そして実際にモデルを走らせる p4 ネットワーク。

Kvasir は 4 つの層からなり、層のあいだにはそれぞれひとつの継ぎ目があります。ウォレットが鍵を持ちます。ゲートウェイが支払いを受け取り台帳を管理します。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 が失敗した場合、ゲートウェイは何もしていない対価を請求する代わりに、トレジャリーから支払者へ返金して 502 を返します。背後にモックモデルもプレースホルダのカタログもありません:アプリが提示するモデルは bridge が実際に提供しているモデルであり、そうでなければリストは空になります。

bridge

エンジンの HTTP の顔

bridge(p4bridge)は p4 の用語でいう OUTER です:各ステージにまたがるセッションを設置し、先頭ステージへ投入し、トークンストリームを回収します。ゲートウェイから見れば、小さく固定された契約 — どのモデルがロードされているか、誰がどれだけ貢献したか、そして補完 — でしかありません。

ルート何を返すか
/api/controllersどのモデルがロードされているか、各ステージの状態
/api/runtimeオペレーターウォレットと、その背後のマシン群
/api/contributionsノードごとの行数・ユニット・リクエスト数・スループット
/c/<model>/v1/chat/completions推論

p4 が意図的に bridge へ委ねる 2 つの仕事:チャットテンプレート(p4 はステージサーバーに不透明なプロンプトを渡すだけで何も適用しないため、instruct モデルは質問に答える代わりにテキストの続きを書いてしまいます)と、推論(thinking)ブロック(content とは別の reasoning_content として返されるため、思考パスが黙ってトークン予算を食い尽くして空の返答を支払者に請求することがありません)。

bridge は決して公開しません。認証は共有サービストークンひとつだけであり、そこに到達できるものは何でもリングを動かせます。bridge はループバックにバインドし、扉はトンネルです。

p4 ネットワーク

エージェントがノードを所有し、ステージサーバーがレイヤーを持つ

エージェントはホスト上のノードを所有し、ステージサーバーはモデルのレイヤーの一部を保持する 1 プロセスです。あるステージは結果を次のステージへ渡すために、自分のエージェントに対し、次のステージのエージェントへそのエージェントが広告しているアドレスで接続するよう依頼します — つまり広告アドレスは他のホストから到達可能でなければならず、しかも共有する最速のネットワークであるべきです。MI250 ラックではそれは InfiniBand リンクであって、オフィス LAN ではなく、ましてループバックではありません。

  • `p4-agent` と `p4_staged_server` はひとつのリリースです。新しいツリーからビルドしたエージェントは、モデル全体をロードし終えたあとで、HELLO の capability 不足により READY で失敗します。
  • 配置はオペレーターの成果物です。どのレイヤーがどの GPU に載り、どの load generation で動くかは配置プランから来ます。提供を依頼してきた相手に bridge は 409 を返し、ゲートウェイのウォッチドッグは一度そう言ってから問い合わせをやめます。
  • パイプラインには最低 2 ステージ必要です。セッションコマンドは 1 ステージのパイプラインを拒否します。
リレー

ラップトップにダイヤル可能なアドレスを

エッジノード — デスクトップアプリやスマートフォン — には誰もダイヤルできるアドレスがありません。リレーがそれを与えます:ノードが外向きに接続し、ed25519 チャレンジでウォレットのキーペアを証明すると、以後はリレー経由で到達可能になります。リレーは認証の境界であり、ペイロードを決してパースしません。デスクトップインストーラーはアプリと一緒に p4 エージェントを同梱するため、参加は 2 度目のインストールになりません。

精算

記帳は参加に従う

各ステージは自分が処理したトークン行数を報告します。bridge はそれをノードごとに積み上げ、ゲートウェイは 30 秒ごとに /api/contributions をポーリングして、bridge が名指しするウォレットへ rows / 1000 ユニットをノードの性能ティアで倍率をかけて記帳します。パイプラインではすべてのステージが同じ行数を見るため、4 ステージのリングは各ステージが何レイヤー持っていようと 4 者へ等しく支払います — 記帳は重みの持ち分ではなく参加に従うのです。ノードがレイヤーの一部ずつを持つエキスパートシャーディングは、この点を見直す必要が出てくるケースです。

P4 Studio

図が「提案」と記しているもの

P4 Studio は p4 自身のオペレーターコンソールです。それがエージェントに求めているリクエスト単位の可観測性フィードは上流への提案であって、ここで動いているものではありません — 図が破線で描いているのはそのためで、エッジノードから提供されるエキスパートシャードも同じく、設計済みでまだ稼働していません。