Smart Balancer로 여러 기기에 요청 분산하기

무엇을 하는 기능인가

문서에 Pro, Enterprise 표시가 붙은 기능입니다.

Smart Balancer는 흩어져 있는 추론 자원을 주소 하나로 묶습니다. 호환되는 모델과 기기들 사이에 요청을 나눠 보내고, 바쁘거나, 비우는 중(draining)이거나, 쓸 수 없는 대상은 피해 갑니다.

앱은 기기가 몇 대이고 어떻게 연결되어 있는지 알 필요가 없습니다. 풀 주소 하나만 부릅니다.

@pool/<slug>

업무 예를 들면(설명을 위한 예입니다), 같은 로컬 모델을 깔아 둔 Mac 세 대를 풀 하나로 묶으면, 직원 열 명이 동시에 질문해도 한 대에 몰리지 않습니다. 한 대를 점검하느라 꺼도 앱 설정은 그대로입니다.

앱 쪽에서 달라지는 점

balancer가 없으면 앱마다 특정 모델 엔드포인트에 묶이고, 실패도 앱이 스스로 처리해야 합니다. Smart Balancer를 쓰면 이렇게 바뀝니다.

• 자원이 늘거나 줄어도 앱은 같은 모델 이름을 씁니다.
• 상태가 좋은 대상들이 동시 작업을 나눠 맡습니다.
• 바쁘거나 쓸 수 없는 대상에는 새 요청이 배정되지 않습니다.
• 운영자는 진행 중인 요청을 갑자기 끊지 않고 점검을 위해 대상을 비울 수 있습니다.
• 요청 기록이 일이 어디로 갔고 왜 그랬는지를 설명해 줍니다.

Cluster와의 차이

Smart Balancer는 이미 가진 자원의 안정성을 높이는 기능이고, 모델 가중치를 합치지 않습니다. 풀에 들어가는 대상은 저마다 호환되는 모델을 혼자서 돌릴 수 있어야 합니다. Mac 여러 대가 힘을 합쳐 모델 하나를 돌려야 한다면 Cluster를 씁니다.

화면 구성

영역	내용
Pools	여러 호환 대상이 뒤를 받치는 고정된 모델 주소
Nodes	자원을 내놓는 Nexus 기기 또는 인증된 호환 엔드포인트
Deployments	관리 대상 Nexus 기기들에 모델이 준비되어 있는 상태
Live	진행 중인 일, 기다리는 일, 처리량, 대상의 상태
History	대상 선택과 대체 처리에 대한, 범위가 정해진 결정 기록

용어 네 가지

• pool: 앱이 쓰는 고정된 @pool/<slug> 모델 이름
• target: 풀 안의 모델 대상 하나
• node: 자기 모델을 controller가 쓸 수 있게 내놓는 다른 Nexus 기기
• controller: 앱의 요청을 받고, 대기열을 관리하고, target을 고르는 Nexus 기기

풀 하나에 로컬 런타임, 다른 Nexus 기기의 모델, 호환 제공업체 엔드포인트를 함께 넣을 수 있습니다. target마다 모델, 용량, 상태, 자격 증명을 따로 갖습니다.

준비물

풀을 만들기 전에 갖춰야 할 것입니다.

• 닿을 수 있는 Nexus 기기 또는 호환 추론 엔드포인트가 하나 이상
• 넣으려는 모든 대상에 준비된 호환 모델
• 그 연결에 필요한 범위로만 제한한 클라이언트 토큰 또는 node 자격 증명

Nexus 기기 여러 대는 먼저 Fleet으로 연결합니다. 문서는 믿을 수 있는 LAN이나 사설 VPN을 권하고, 자원으로 추가하기 전에 표시된 주소를 하나하나 확인하라고 합니다.

풀 만들기

1. Smart Balancer를 엽니다.
2. 자원을 내놓을 node를 추가하거나 고릅니다.
3. 풀에 알아보기 쉬운 이름과 바뀌지 않을 slug를 붙입니다.
4. 호환 모드를 고릅니다.
5. 모델 대상마다 target을 하나씩 추가합니다.
6. 분산 전략을 고릅니다.
7. target의 우선순위와 용량 가중치를 검토합니다.
8. 풀을 검증하고 dry run을 실행합니다.
9. 풀을 만들고 @pool/<slug> 값을 앱의 모델 이름으로 씁니다.

앱이 풀을 직접 부를 수도 있고, Smart Route가 풀을 대상으로 고를 수도 있습니다.

호환 모드

호환 모드는 요청을 target 사이에서 옮길 때 풀이 무엇을 보장하는지를 정합니다.

모드	언제 쓰는가	주의
Exact replicas	모든 target이 같은 모델을 제공할 때. 한 로컬 모델의 복사본들에 부하를 나누는 가장 안전한 선택	같은 정체를 보고하지만 실제 빌드가 같은지 증명되지 않는 모델은 Nexus가 확인을 요청할 수 있습니다. 복사본을 직접 관리하고 서로 바꿔 써도 된다고 알 때만 확인합니다
Equivalent generation	target들이 서로 다른 모델이지만, 같은 생성 업무에 써도 된다고 판단할 때	답변, 지연 시간, 토큰 사용량, 컨텍스트 동작, 안전 특성이 달라질 수 있습니다. 앱이 보낼 요청 종류를 모든 target이 지원하는지 확인합니다

Equivalent generation은 일의 종류에 따라 일부러 다른 모델을 쓰려는 경우를 대신하지 못합니다. 그런 경우에는 Smart Routes를 씁니다.

분산 전략

권장 기본값은 Smart입니다.

전략	target을 고르는 방식	어울리는 경우
Smart	우선순위, 용량 가중치, 현재 부하, 최근 지연 시간, 안정성, 모델이 데워져 있는지, 대화 연속성을 함께 봅니다	응답성과 가용성을 Nexus에 맡기고 싶을 때
Priority	번호가 가장 낮은 정상 우선순위 단계를 쓰고, 그 안에서 가장 덜 바쁜 target을 고릅니다	주 자원과 예비 자원이 분명할 때
Capacity	설정한 용량에 따라 일을 나누되 현재 사용률을 반영합니다	target마다 처리량 차이가 커서 비례해서 나눠야 할 때
Least busy	알려진 동시 처리 수에 비해 진행 중·대기 중인 일이 가장 적은 target을 고릅니다	target이 비슷해서 현재 부하만 보면 될 때
Round robin	설정한 순서대로 돌아가며 고릅니다	예측할 수 있는 분배가 필요하고 부하를 따질 필요가 없을 때

어떤 전략이든 쓸 수 없거나, 호환되지 않거나, 비우는 중이거나, 상태가 나쁜 target은 건너뜁니다.

우선순위와 용량

우선순위 단계

• Priority 1이 주 단계입니다.
• 같은 우선순위의 target끼리 트래픽을 나눕니다.
• 번호가 높은 단계는, 낮은 단계의 target이 대상이 못 되거나 자리가 없을 때 대신 받습니다.

모두 함께 일하게 하려면 우선순위를 같게 둡니다. 대기용 기기나 더 비싼 제공업체 엔드포인트에는 높은 번호를 붙여, 주 자원이 감당하지 못할 때만 닿게 합니다.

용량 가중치(capacity weight)

용량 가중치는 두 가지를 함께 정합니다. target이 동시에 처리할 요청 수, 그리고 같은 우선순위 단계 안에서의 상대적인 몫입니다. 가중치 4인 target은 비슷한 가중치 2 target보다 대략 두 배의 기회를 받습니다.

실제 동시 처리 능력에 맞추는 방법입니다.

• 감지된 값이 런타임을 정확히 반영하면 그대로 둡니다.
• 다른 일도 하는 업무용 컴퓨터, 긴 컨텍스트 작업, Cluster에도 참여하는 기기는 낮춥니다.
• 호스팅 엔드포인트는 내 계정에 주어진 제공업체 용량에 맞춥니다.
• 로컬 런타임의 동시 처리 수보다 높게 잡지 않습니다. 넘치는 일이 풀이 아니라 그 런타임에서 기다리게 되어, Nexus가 다른 target으로 돌릴 판단을 할 수 없게 됩니다.

용량은 일정 배분의 한도이지, 그만큼의 빠른 응답을 계속 낸다는 보장이 아닙니다. 실제 처리량을 보고 조정합니다.

대기열, 연속성, 재시도

대기열: 쓸 수 있는 target이 모두 차면, 크기가 정해진 풀 대기열에 요청을 잡아 둘 수 있습니다. 기다리는 일은 클라이언트 토큰별로 공평하게 받아들여, 바쁜 앱 하나가 다른 앱의 대기 몫까지 다 쓰지 못하게 합니다. 화면의 대기 수는 운영 참고용이고 대기 순번을 보장하지 않습니다.

연속성: 대화의 이어지는 턴을 같은 target에 두어, 모델이 데워진 상태와 재사용할 수 있는 프롬프트 상태를 살릴 수 있습니다. 앱이 줄 수 있다면 X-Msty-Nexus-Session-Id, prompt_cache_key, 또는 지원되는 user 값을 일정하게 보냅니다. 이전 target이 눈에 띄게 더 바쁘거나 쓸 수 없으면 연속성은 양보됩니다.

재시도: 보수적으로 합니다. 기본적으로 시도는 두 번을 넘지 않고, 출력이 시작되기 전에만 다른 target을 고를 수 있습니다. 결과가 불분명한 시간 초과를 되풀이하지 않고, 내용이 이미 앱에 닿은 응답을 처음부터 다시 만들지도 않습니다.

실시간 화면과 요청 기록

Live status는 진행 중·대기 중인 일, 준비된 대상과 상태가 나빠진 대상, 초당 토큰 수, 풀 상태, 경로 결정을 일어나는 대로 보여 줍니다.

Request history는 요청마다 다음을 설명합니다.

• 어느 target이 선택되었는가
• 왜 그 target의 순위가 가장 높았는가
• 어느 target이 왜 건너뛰어졌는가
• 대기 시간과 첫 출력까지 걸린 시간
• 다른 target을 시도했는가
• 최종 완료 또는 실패 이유

기록에는 경로 정보만 있고 프롬프트나 응답 내용은 없습니다.

여러 node에 모델 배포하기

여러 node가 풀에 들어가기 전에 같은 모델을 갖춰야 하면 Deployments를 씁니다.

1. 대상 node를 고릅니다.
2. 런타임과 모델 출처를 고릅니다.
3. 필요하면 Nexus가 런타임을 설치하게 둡니다.
4. 배포를 시작하고 node별 진행 상황을 따라갑니다.
5. 실패한 node만 다시 시도합니다.
6. 풀에 넣기 전에 node의 모델 목록에 그 모델이 나타나는지 확인합니다.

배포는 자원을 준비할 뿐입니다. 준비된 모델이 기존 풀에 자동으로 들어가지는 않습니다.

점검과 유지 보수

점검 전에는 풀이나 대상을 비웁니다(drain). 비우기는 새 배정을 막고 진행 중인 요청은 끝나게 둡니다. Runtime을 다시 시작하거나, 모델을 바꾸거나, 기기를 끄기 전에 비우기가 끝나기를 기다리고, 상태가 돌아온 뒤에만 다시 받게 합니다.

풀에 기대기 전에 쓸 수 있는 확인 도구는 네 가지입니다.

도구	하는 일
Validate	target 가용성, 모델 호환성, 설정 경고 확인
Dry run	설정한 전략이 지금 target들을 어떤 순위로 매길지 확인. 풀의 트래픽 경로는 바꾸지 않습니다
Try traffic	대표적인 요청을 풀로 보내 실시간 분산을 지켜봅니다
Failure drill	target 하나를 비우기 전, 비우는 동안, 그 뒤의 트래픽을 재고, 풀이 그 target을 피해 갔다가 회복했는지 보고합니다

Try traffic과 Failure drill은 실제 추론 작업을 만듭니다. 모델 사용, 데이터 처리, 제공업체 비용이 허용되는 곳에서만 실행합니다.

자격 증명은 각 대상에 둔다

Smart Balancer는 제공업체 키를 호출하는 쪽이나 다른 기기에 나눠 주지 않습니다. 대상마다 자기 자격 증명을 갖고, 앱은 Nexus 클라이언트 토큰으로 controller에 인증합니다.

대상을 추가하기 전에 기기의 정체, 전송 구간, 표시된 주소, 토큰 범위를 확인합니다. 네트워크 공개에 관한 기준은 Nexus 보안 모델에 있습니다.

참고한 문서

• Nexus 문서: Smart Balancer
• Nexus 문서: Cluster