p4
Kvasir를 움직이는 엔진: 에이전트가 노드를 소유하고, 스테이지 서버가 레이어를 들고, 배치는 네트워크가 추측하는 것이 아니라 운영자가 명시하는 것인 이벤트 주소 기반 프로토콜.
p4는 하나의 모델을 스테이지 — 레이어의 연속된 슬라이스 — 로 잘라 각 스테이지에 자기 프로세스를 주는 방식으로 여러 머신에 걸쳐 실행합니다. 에이전트는 한 호스트의 노드들을 소유합니다: 스테이지 서버를 띄우고, 그들 사이에서 이벤트를 라우팅하고, 라이프사이클을 책임집니다. 무엇을 어디에 둘지 정하는 스케줄러는 없습니다. 운영자가 placement plan을 작성해 로드하면, 네트워크는 정확히 그대로 서빙합니다.
p4 배포를 통과하는 요청 경로.
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
스테이지는 다음 스테이지의 에이전트를 dial한다
스테이지가 자기 레이어를 마치면, 자기 에이전트에게 다음 스테이지의 에이전트에게, 그 에이전트가 광고하는 주소로 연결을 열어 달라고 요청해 결과를 넘깁니다. 그래서 광고된 주소는 장식이 아닙니다: 링의 다른 모든 호스트에서 닿을 수 있어야 하고, 그들이 공유하는 가장 빠른 네트워크를 가리켜야 합니다. 루프백을 광고하면 두-호스트 링이 조용히 자기 자신을 dial합니다.
하나의 숫자가 로드를 묶는다
- load generation은 로드하는 쪽이 정하고, 모든 세션·추론·정산·언로드에서 정확히 같은지 비교됩니다. 머신 어디에도 기록되지 않으므로, 로드하는 쪽이 첫 명령이 떠나기 *전에* 디스크에 적어 두어야 합니다 — 이 값이 없으면 로드된 모델을 내릴 수조차 없습니다.
- 노드의 generation과 load generation은 같은 숫자입니다. 어댑터는 release receipt의 source generation을 그것이 속한 로드와 대조하고 다르면 노드를 멈추므로, 서로 다른 두 숫자로 로드된 링은 요청 하나를 서빙하고는 head를 잃습니다.
- 운영 저널이 있어야 모델이 아예 로드됩니다: 디버깅 보조 도구가 아니라, 로드를 재생(replay) 안전하게 만드는 승인 기록입니다.
의도적인 생략
p4는 채팅 템플릿을 적용하지 않습니다 — 불투명한 프롬프트를 그대로 전달하고, 모델의 턴 포맷은 호출자가 렌더했으리라 기대합니다. 배치 결정도 하지 않습니다. 그리고 누구에게 지불해야 하는지에 대한 개념도 없습니다: 스테이지는 자기가 실행한 토큰 행 수를 보고할 뿐이고, 정산은 다른 누군가의 계약입니다. 이 하나하나가 Kvasir가 [브리지](/wiki/bridge)에서 메우는 이음매이며, 그 덕에 엔진은 업스트림을 따라갈 만큼 좁게 유지됩니다.
에이전트와 네이티브 스테이지 서버는 하나의 릴리스입니다. 더 새 트리에서 빌드한 에이전트는 — 모델을 전부 로드한 뒤에 — 스테이지 서버의 HELLO에 능력이 빠졌다며 READY에서 실패합니다. 둘 다 같은 체크아웃에서 빌드하세요.