Kvasir 아키텍처
시스템 전체의 지도 한 장: 지갑, 결제를 받는 게이트웨이, 엔진 앞에 서는 브리지, 그리고 모델을 실제로 굴리는 p4 네트워크.
Kvasir는 네 개의 계층이고, 계층마다 이음매가 하나씩 있습니다. 지갑이 키를 쥡니다. 게이트웨이가 결제를 받고 원장을 관리합니다. 브리지가 추론 엔진에 HTTP 얼굴을 씌웁니다. p4 네트워크가 실제로 모델을 굴립니다. 아래의 모든 것은 그 이음매들이 어디에 놓였는지의 결과이며 — 다이어그램은 오늘 돌아가는 것과 아직 설계인 것을 구분해 표시합니다.
키는 기기를 떠나지 않는다
iOS(Swift), Android(Kotlin), 데스크톱(React + Electron)은 같은 지갑의 서로 다른 빌드이고, 데스크톱 빌드는 게이트웨이가 /에 서빙하는 브라우저 지갑이기도 합니다 — 읽기 전용 콘솔이 아니라 페이지 안에서 서명하는 온전한 지갑입니다. 보상은 각 소유자 자신의 Solana 주소로 지급되며, 게이트웨이는 사용자 키를 결코 보관하지 않습니다.
하나의 프로세스, 두 개의 면
solana/staking-service는 API 게이트웨이(OpenAI 호환 /v1/chat/completions와, /api/pay/quote → /api/inference의 요청당 지불 흐름)이자 정산 게이트웨이(스테이킹, 노드 레지스트리, 크레딧 계정, 기여 크레딧)입니다. 둘이 한 프로세스인 이유는 하나의 원장을 공유하기 때문입니다: 요청은 KVR 전송이 온체인에서 검증된 뒤에야 서빙되고, 그 요청을 서빙한 노드들에게 같은 원장이 크레딧을 줍니다.
결제는 추론이 실행되기 전에 정산됩니다. 그 뒤 브리지가 실패하면, 게이트웨이는 아무것도 아닌 것에 과금하는 대신 트레저리에서 지불자에게 환불하고 502를 반환합니다. 그 뒤에 목업 모델이나 자리 표시용 카탈로그는 없습니다: 앱이 제시하는 모델은 어떤 브리지가 실제로 서빙 중인 모델이거나, 아니면 목록이 비어 있습니다.
엔진의 HTTP 얼굴
브리지(p4bridge)는 p4 용어로 OUTER입니다: 스테이지들에 걸쳐 세션을 설치하고, head에 제출하고, 토큰 스트림을 모읍니다. 게이트웨이 입장에서는 작고 고정된 계약입니다 — 어떤 모델이 로드돼 있는지, 누가 얼마나 기여했는지, 그리고 completion.
| 라우트 | 무엇에 답하는가 |
|---|---|
/api/controllers | 어떤 모델이 로드돼 있는지, 그리고 모든 스테이지의 상태 |
/api/runtime | 운영자 지갑과 그 뒤의 머신들 |
/api/contributions | 노드별 행 수, units, 요청 수, 처리량 |
/c/<model>/v1/chat/completions | 추론 |
p4가 의도적으로 브리지에 남겨 두는 두 가지 일: 채팅 템플릿(p4는 스테이지 서버에 불투명한 프롬프트를 건네고 아무 포맷도 적용하지 않으므로, 그대로 두면 instruct 모델이 질문에 답하는 대신 텍스트를 이어 씁니다)과 추론 블록(content와 분리해 reasoning_content로 반환하므로, thinking 패스가 토큰 예산을 조용히 먹어 치우고 지불자에게 빈 답을 청구하는 일이 없습니다).
브리지는 절대 공개되지 않습니다. 인증 수단은 공유 서비스 토큰 하나뿐이라, 거기 닿는 것은 무엇이든 링을 굴릴 수 있습니다. 브리지는 루프백에 바인딩하고, 문은 터널입니다.
에이전트가 노드를, 스테이지 서버가 레이어를 소유한다
에이전트는 한 호스트의 노드들을 소유하고, 스테이지 서버는 모델 레이어의 슬라이스 하나를 들고 있는 프로세스 하나입니다. 스테이지는 자기 에이전트에게 다음 스테이지의 에이전트를 그 에이전트가 광고하는 주소로 dial해 달라고 요청해 결과를 넘깁니다 — 그래서 광고된 주소는 다른 호스트들에서 닿을 수 있어야 하고, 그들이 공유하는 가장 빠른 네트워크여야 합니다. MI250 랙에서 그것은 사무실 LAN도, 더더욱 루프백도 아닌 InfiniBand 링크입니다.
- `p4-agent`와 `p4_staged_server`는 하나의 릴리스입니다. 더 새 트리에서 빌드한 에이전트는 — 모델을 전부 로드한 뒤에 — HELLO 능력이 빠졌다며 READY에서 실패합니다.
- 배치는 운영자의 산출물입니다. 어떤 레이어가 어떤 GPU에, 어떤 load generation으로 앉는지는 placement plan에서 나옵니다. 브리지는 서빙해 달라는 요청에
409로 답하고, 게이트웨이의 워치독은 한 번 그렇다고 말한 뒤 묻기를 멈춥니다. - 파이프라인에는 최소 두 개의 스테이지가 필요합니다. 세션 명령은 1-스테이지 파이프라인을 거부합니다.
노트북에 dial 가능한 주소를
엣지 노드 — 데스크톱 앱, 폰 — 에는 누가 dial할 수 있는 주소가 없습니다. 릴레이가 그것을 줍니다: 노드가 바깥으로 접속해 ed25519 challenge로 지갑 키페어를 증명하면, 그때부터 릴레이를 통해 닿을 수 있습니다. 릴레이는 인증 경계이며 페이로드를 파싱하지 않습니다. 데스크톱 설치 프로그램이 p4 에이전트를 앱과 함께 싣기 때문에, 합류는 두 번째 설치가 아닙니다.
크레딧은 참여를 따른다
각 스테이지는 자기가 실행한 토큰 행 수를 보고합니다. 브리지가 그것을 노드별로 누적하고, 게이트웨이는 30초마다 /api/contributions를 폴링해 브리지가 지목한 지갑에 rows / 1000 units를 노드의 성능 등급으로 스케일해 크레딧합니다. 파이프라인에서는 모든 스테이지가 같은 행들을 봅니다. 그래서 4-스테이지 링은 각 스테이지가 몇 개의 레이어를 들고 있든 네 스테이지에 똑같이 지불합니다 — 크레딧은 가중치 지분이 아니라 참여를 따릅니다. 노드마다 한 레이어의 서로 다른 몫을 갖는 전문가 샤딩이, 이 부분을 다시 들여다봐야 할 경우입니다.
다이어그램이 제안으로 표시한 것
P4 Studio는 p4 자체의 운영자 콘솔입니다. 그것이 에이전트로부터 원하는 요청별 관측성 피드는 업스트림의 제안이지 여기서 돌고 있는 것이 아닙니다 — 다이어그램이 그것을 점선으로 그린 이유이며, 설계는 됐지만 아직 돌지 않는 엣지 노드 전문가 샤드 역시 마찬가지입니다.