Ollama 하나로 두 대의 DGX Spark(각 128GB, 200Gb/s 직결 케이블, RDMA)를 사용하게 해 주는 내 포크의 후속 소식이다. 지난주에는 llama.cpp RPC를 통한 텐서 병렬 기능이 추가되어 두 대의 머신이 한 대보다 빨라졌다. 그런데 두 번째 모델을 로드하니 두 번째 머신에는 도달하지 않았다. 오류도 없이 그저 첫 번째 머신으로만 갔다. 원인은 ggml-rpc-server가 한 번에 한 클라이언트만 처리하기 때문이다. Ollama에서 각 모델은 자체 llama-server로 동작하므로, 한 모델이 워커의 RPC 서버를 점유하는 순간 다른 모델 전부, 텐서 병렬 모델까지도, 로컬 GPU로 폴백했다.

포크가 이제 하는 일은 다음과 같다. 워커는 모델별로 하나의 RPC 서버, 이른바 슬롯을 실행하는데, 첫 번째 슬롯은 항상 띄우고 이후 슬롯은 요청 시 생성하며 기본 3개(최대 7개)까지다. 슬롯은 llama-server가 연결될 때까지(최대 30초) 해당 모델을 위해 예약되므로 두 모델이 동시에 로드돼도 같은 슬롯을 잡지 않는다. 해제된 추가 슬롯은 다음 모델을 위해 30분간 유지된 뒤 종료되는데, 유휴 RPC 서버마다 자체 GPU 컨텍스트를 점유하기 때문이다. 스케줄러는 여전히 워커 GPU를 하나의 장치로 보므로 그 위의 모든 모델 메모리가 합산해 계산된다. ollama cl ps는 '3개 슬롯 중 1개 사용'으로 표시하고 이후 슬롯의 모델은 worker#1로 보여준다.

발을 걸린 부분도 있었다. 이전 버전의 방화벽 규칙은 첫 RPC 포트만 커버했는데, 새 슬롯(50054, 50055)과 그 텐서 병렬 포트(+1000)도 규칙이 필요하므로 ollama cl upgrade는 이제 규칙을 교체하고 doctor는 오래된 규칙을 표시한다. 워커가 반환한 슬롯 주소는 그대로 llama-server 인자로 들어가므로, Ollama는 슬롯 포트가 붙은 워커 주소만 받아들인다.

아직 측정하지 못한 것은 워커에서 두 모델이 동시에 생성하는 경우다. 텐서 병렬로는 케이블과 메모리 대역폭을 공유하므로 공짜 성능은 기대하지 않는다. 이번 주 새 기능으로 ollama cl mv <model> <location>은 자주 쓰지 않는 모델의 가중치를 다른 디스크로 옮기고(복사 중 sha256 검증, Ollama 스토어에는 링크가 남는다), mv <model> store는 다시 가져온다.

코드와 문서는 GitHub의 ollama-cluster 저장소 클러스터 문서에서 확인할 수 있다.