LLMBoost

Services → LLMBoost 페이지는 LLMBoost 모델 서빙 클러스터의 읽기 전용 서빙 대시보드입니다. MAC은 클러스터의 OpenAI 호환 API와 서빙 엔진의 Prometheus /metrics를 직접 읽으며, SGLang / vLLM / 레거시 llmboost: 접두사 엔진을 모두 지원합니다. 사이드바 링크는 항상 표시되고, 도달 가능한 클러스터가 없으면 연결 카드가 나타납니다.

연결

MAC은 서빙 API를 다음 세 가지 방법으로 찾습니다 (우선순위 순).

1. 런타임 오버라이드 — admin이 페이지 상단의 연결 카드에 API 엔드포인트를 직접 입력 (메모리에만 저장되며 마스터 재기동 시 초기화).
2. 환경 변수 — 마스터에 설정한 LLMBOOST_API_ENDPOINT.
3. 자동 탐색 — api-server가 등록된 모든 에이전트의 IP를 30080 포트로 탐색하여, 관리 API (:30080/api, 관리 UI는 :30080/manage/)를 노출하는 LLMBoost 클러스터를 찾습니다.

자동 탐색은 이 관리 레이아웃을 갖춘 클러스터만 찾습니다. OpenAI API를 루트에서 서빙하는 독립 실행형 엔진 (:30080/v1/models, /manage/ 없음)은 떠 있어도 자동 탐색되지 않습니다 — 런타임 오버라이드나 LLMBOOST_API_ENDPOINT로 지정하세요. 서빙 클러스터가 어떤 에이전트도 도달할 수 없는 서브넷에 있을 때도 마찬가지로 오버라이드나 환경 변수를 사용하세요. 오버라이드를 지우면 자동 탐색이 다시 활성화됩니다.

페이지 구성

대시보드는 vLLM/SGLang 서빙 뷰처럼 위에서 아래로 읽히며, 각 정보는 정확히 한 번만 나타납니다.

Serving Hero

"지금 살아 있는가"에 한눈에 답하는 배너입니다: 상태 비컨 (Serving / Idle / Awaiting traffic / Unreachable), 헤드라인으로 표시되는 서빙 중인 모델 id (또는 N models serving), 실제로 조치가 필요할 때만 나타나는 압박 배지 (큐 적체, KV 캐시 ≥ 90 %, 실행 슬롯 가득 참), 그리고 예전 Engine Info 섹션을 흡수한 엔진 정체성 칩 — 컨텍스트 길이, 엔진 버전, 병렬화 (TP/DP/EP), 스펙큘레이티브 디코딩 알고리즘, KV 캐시 dtype, 모델 아키텍처, 추가 모달리티. 인트로스펙션이 없는 엔진 (예: vLLM)은 칩이 더 적게 표시될 뿐입니다. 클러스터가 도달 불가가 되면 api-server가 마지막으로 알려진 스냅샷을 계속 제공하므로, hero에 오래된 데이터 안내가 함께 표시됩니다.

KPI 타일

핵심 서빙 지표 네 가지를 스캔하기 쉬운 현재값으로 보여줍니다 — Gen throughput, Time to First Token, Inter-Token Latency, E2E Latency — 각각 단기 추세 **변화량(델타)**과 p50 / p95 / p99 꼬리 백분위 서브라인을 함께 표시합니다. 백분위는 최근 트래픽 윈도우 (보통 최근 ~60초; 실제 기준은 타일 툴팁에 표시되며, 엔진이 유휴일 때는 누적값으로 폴백) 기준으로 계산됩니다. 여기에는 스파크라인이 없습니다 — 각 지표의 롤링 곡선은 아래 Trends 그리드에 있습니다.

Trends

같은 크기로 읽기 좋게 정렬된 롤링 차트 그리드입니다: Gen throughput, Time to First Token, Inter-Token Latency, E2E Latency, KV Utilization, 그리고 Concurrency 카드 (엔진의 max_running_requests 상한 대비 실행 수, 실행 슬롯 포화 바, 스케줄러 큐 대기 시간, retracted/aborted 신뢰성 카운터를 함께 표시). 헤더의 컴팩트한 시간 윈도우 선택기 — 1m / 5m / 15m / 1d (기본 15m) — 가 모든 차트의 범위를 한 번에 조정합니다. 모든 윈도우는 지속화된 mac_llmboost_* Prometheus 시리즈에서 제공되므로 (지속화 참고), 페이지를 새로 고쳐도 차트가 처음부터 다시 쌓이지 않고 실제 이력을 즉시 보여줍니다. 헤더 값은 최신 라이브 판독값을 유지합니다.

Workload

위의 지연 시간을 해석하는 데 도움이 되는 요청 형태 분포 — 프롬프트 크기, 출력 크기, 프리픽스 재계산 비율. 엔진이 트래픽을 서빙하고 토큰 히스토그램을 내보낼 때만 렌더링되며, 없으면 스스로 숨습니다.

KV 캐시 & 메모리

계층형 KV 캐시 구조: L1 GPU 풀을 활성 / 회수가능 / 여유로 나눈 실시간 스택 바, 엔진이 내보내면 실시간 점유율을 (없으면 용량만) 보여주는 L2 호스트 RAM, 그리고 설정된 스토리지 백엔드이거나 "not configured"인 L3 디스크, 여기에 프리픽스 캐시 적중 지표를 더합니다. 호스트·디스크 계층은 엔진이 계층형 캐시 (--enable-hierarchical-cache)로 동작할 때 나타납니다. 데스크톱에서는 이 패널이 누적 Totals 스트립과 나란히 2열로 배치됩니다.

Totals

조용한 누적 / 비율 행입니다: 완료된 요청 수, 파생된 요청/분, 토큰 총합, 요청당 평균 생성 토큰, 캐시 적중률, 그리고 스펙큘레이티브 디코딩이 있을 때의 수락률. 엔진이 내보내지 않는 항목은 빈칸으로 두지 않고 생략합니다.

Models

카탈로그 메타데이터와 모델별 실시간 부하 (Inter-Token Latency 포함)를 합친 단일 표로, Prometheus의 model_name 레이블을 기준으로 합니다. 모델이 둘 이상 서빙될 때만 렌더링됩니다 — 단일 모델 배포는 이미 hero와 KPI 타일로 완전히 표현되므로, 한 줄짜리 표로 반복하는 것은 순전히 중복이기 때문입니다.

지속화

api-server는 파싱된 지표 및 파생 지표 (윈도우 백분위, 프리픽스 캐시 적중 비율, 계층별 KV 토큰 분할 — 원시 엔진 시리즈가 단일 게이지로 노출하지 않는 값들)를 자체 Prometheus /metrics에 mac_llmboost_* 게이지로 다시 발행합니다 (집계 세트와 model 레이블이 붙은 모델별 세트, 그리고 mac_llmboost_up). MAC의 Prometheus는 이미 api-server를 스크랩하므로, 이 이력이 TSDB에 저장되어 재시작 후에도 별도 데이터베이스 없이 유지됩니다 — 이 덕분에 Trends 차트 (특히 1d 윈도우)가 매번 새로 쌓이지 않고 실제 이력을 보여줍니다. 유휴이거나 도달 불가인 동안에는 서빙 비율 게이지가 NaN으로 발행되어, 차트가 유지된 평평한 선 대신 빈 구간(gap)을 보여줍니다.

이 페이지에 없는 것

모델 서빙 API는 의도적으로 시스템/노드 정보와 관리 기능을 노출하지 않습니다. 따라서 MAC도 K8s 노드, 디플로이먼트, 파드 배치를 보여주지 않으며, 스케일/일시정지/재개 같은 제어 기능도 제공하지 않습니다. 요청별 호출 이력도 없습니다 — 서빙 API가 제공하지 않기 때문입니다. 서빙 노드가 MAC 에이전트로 등록되어 있다면, 하드웨어 수준의 GPU 모니터링은 일반 노드별 페이지에서 확인할 수 있습니다.

문제 해결

클러스터가 떠 있는데도 페이지가 계속 Disconnected라면 LLMBoost 문제 해결 페이지를 참고하세요.