p4

Kvasir を動かすエンジン：エージェントがノードを所有し、ステージサーバーがレイヤーを保持し、配置はネットワークが推測するものではなくオペレーターが宣言するものである、イベントアドレス型のプロトコル。

p4 は、モデルをステージ — レイヤーの連続した一部 — に切り分け、各ステージに専用のプロセスを与えることで、1 つのモデルを複数のマシンにまたがって走らせます。エージェントはホスト上のノードを所有します：ステージサーバーを起動し、ステージ間のイベントをルーティングし、そのライフサイクルに責任を持ちます。どこに何を置くかを決めるスケジューラは存在しません。オペレーターが配置プランを書いてロードし、ネットワークはそのとおりに提供するだけです。

browser / SDK
  → gateway :8791              # payment, settlement, the wallet app
  → bridge :19000              # OUTER: session, submit, gather
  → p4 agent                   # owns this host's nodes
  → stage servers              # one process per layer slice

あるステージが自分のレイヤーを終えると、自分のエージェントに対し、次のステージのエージェントへ、そのエージェントが広告しているアドレスで接続を開くよう依頼して結果を手渡します。したがって広告アドレスは飾りではありません：リング内の他のすべてのホストから到達可能でなければならず、しかも共有する最速のネットワークを指すべきです。ループバックを広告すれば、2 ホストのリングは静かに自分自身へダイヤルします。

• load generation はロードする者が選び、セッション・推論・精算・アンロードのたびに完全一致で比較されます。マシン上のどこにも記録されないため、ロード側は最初のコマンドを送る*前に*それをディスクへ書き出します — これがないとロード済みモデルは撤去することすらできません。
• ノードの generation と load generation は同じ数字です。アダプタはリリースレシートの source generation を、それが属するロードと突き合わせ、異なればノードを停止します。つまり 2 つの異なる数字でロードされたリングは、1 リクエストだけ提供したあとで先頭を失います。
• 運用ジャーナルがなければモデルはそもそもロードされません：これはデバッグ用の補助ではなく、ロードをリプレイ安全にする受理記録です。

p4 はチャットテンプレートを適用しません — 不透明なプロンプトを転送し、モデルのターン形式は呼び出し元がレンダリング済みであると期待します。配置の判断もしません。そして誰が支払われるべきかという概念も持ちません：ステージは処理したトークン行数を報告し、精算は他者の契約です。これらはいずれも Kvasir が [bridge](/wiki/bridge) で埋める継ぎ目であり、おかげでエンジンは上流を追える程度に狭いままでいられます。