브리지

추론 엔진의 HTTP 얼굴: 무엇이 로드돼 있고, 누가 얼마나 기여했고, completion — 그 외에는 아무것도.

브리지는 정산 게이트웨이가 추론을 위해 말을 거는 유일한 대상입니다. p4 용어로는 OUTER입니다: 모델의 스테이지들에 걸쳐 세션을 설치하고, head 스테이지에 요청을 제출하고, 토큰 스트림을 모으고, 각 노드가 무엇을 기여했는지 보고합니다. 배치도, 스케줄링도, 무엇이 로드돼 있는지에 대한 카탈로그 외의 상태도 소유하지 않습니다 — 의도적으로 작게 만든 것인데, 브리지가 결정하지 않는 것은 어긋날 수도 없기 때문입니다.

계약

네 개의 라우트, 하나의 토큰

라우트무엇에 답하는가
/api/controllers어떤 모델이 로드돼 있는지, 그리고 모든 스테이지의 상태
/api/runtime운영자 지갑과 그 뒤의 머신들
/api/contributions노드별 행 수, units, 요청 수, 처리량
/c/<model>/v1/chat/completions추론

/api/health를 제외한 모든 라우트는 X-Kvasir-Service-Token 헤더로 보내는 공유 서비스 토큰을 요구합니다. 그 토큰이 열린 인터넷과 링의 무상 사용 사이를 막는 유일한 장치이고, 그래서 브리지는 루프백에 바인딩된 채 공개되지 않고 터널을 통해 접근됩니다.

p4가 넘기는 것

엔진이 하지 않는 두 가지 일

  • 채팅 템플릿. p4는 스테이지 서버에 불투명한 프롬프트를 건넬 뿐 자기 턴 포맷을 적용하지 않습니다. 모델의 포맷은 브리지가 렌더합니다 — GGUF에서 읽어 카탈로그에 prompt_format으로 표기됩니다. 이를 건너뛰면 instruct 모델은 질문에 답하는 대신 텍스트를 이어 쓰고, end-of-turn 토큰을 끝내 내보내지 않으며, 매번 토큰 한도까지 갑니다.
  • 추론(reasoning) 블록. 추론 모델은 생각으로 답을 시작합니다. 브리지는 그것을 content와 분리해 reasoning_content로 반환하고, enable_thinking: false는 프롬프트 안에서 블록을 닫아 주는 방식으로 지킵니다 — 그러지 않으면 긴 thinking 패스가 예산을 통째로 먹고 호출자에게 이미 지불한 빈 답을 건넬 수 있습니다.
배치는 브리지의 일이 아니다

왜 409로 답하는가

브리지에 모델을 서빙하라고 요청하면 409가 돌아옵니다. 어떤 레이어가 어떤 GPU에, 어떤 load generation으로 앉는지는 운영자가 작성해 로드한 placement plan에서 나오며, 원격으로 재로드할 것이 없습니다. 게이트웨이의 링 워치독은 이것을 한 번 배우고, 될 수 없는 일을 재시도하는 대신 묻기를 멈춥니다.

기여 카운터는 메모리에 있습니다. 브리지를 재시작하면 게이트웨이가 아직 폴링하지 않은 만큼이 사라지고 — 폴링 주기는 30초입니다 — 카운터가 뒤로 돌아가면 게이트웨이는 이중 계산 대신 기준선을 다시 잡습니다. 브리지가 소유자를 모르는 노드는 조용히 건너뛰므로, 운영자 지갑이 설정돼 있지 않으면 "이 머신들은 아무것도 벌지 않았다"로 읽힙니다.