오케스트레이터 모델조합 노하우 — sol·luna·omon·TPS

이날 방에서는 sol·luna·terra·omon 네 모델을 오케스트레이터로 어떻게 조합할지가 오후 내내 화두였다. 오후 3시 10분, 한 참여자가 자신이 쓰는 조합을 짧게 공유하며 대화를 열었다.

"전 sol med 씁니다 오케스트레이터"

한 시간 남짓 지나 다른 참여자는 직접 돌려본 비교 결과를 좀 더 구체적으로 풀어놓았다. PR 11개를 같은 기준으로 테스트해본 후기였다.

"관점이 명확한 리뷰로 테스트를 pr 11개 돌려봤는데 루나 xhigh가 요구사항 만족, 회귀, 컨벤션 충족 면에서 커버력도 정확도도 더 좋았어요. 다만 버그 및 동시성 문제 등은 sol med가 더 잘 찾아줬습니다"

한 모델이 모든 면에서 앞서는 게 아니라, 요구사항 충족과 회귀 검증에는 루나가, 버그·동시성 탐지에는 sol이 강점을 보인다는 정리였다. 여러 모델을 역할별로 나눠 오케스트레이터를 짜는 방식이 이 방에서 통용되는 실전 조합법으로 보인다. 어느 한 모델을 정답으로 못박기보다, 작업 성격에 따라 담당을 나누는 쪽이 실제로 더 나은 결과를 냈다는 뜻으로 읽힌다.

대화는 이어서 TPS(초당 토큰 수)가 모델에 고정된 값인지를 두고 논쟁으로 번졌다. 한 참여자는 TPS를 계산 속도의 문제로 짧게 설명했다.

"본질적으로 통계치 계산이잖아요? 그럼 이 계산을 빠르게하면 tps 가 빨라집니다"

다른 참여자는 여기에 좀 더 구조적인 설명을 얹었다. TPS를 끌어올리는 요소가 모델 자체가 아니라 그 모델을 서빙하는 환경 전반에 걸쳐 있다는 설명이었다.

"모델이 TPS가 정해진건 아니긴 합니다. 실제 GPU, 배치 크기, 컨텍스트 길이, 정밀도, 서빙 엔진, 커널 등 많은 최적화 가능한 요소가 있고 이런 부분을 최적화해서 시간 내에 처리되는 양을 늘리면 TPS가 올라가는거죠. "

이 설명대로면 TPS는 모델 선택만으로 결정되는 수치가 아니라 GPU·배치 크기·컨텍스트 길이·서빙 엔진 조합까지 함께 따져야 하는 문제인 셈이다. 결국 오케스트레이터를 잘 짜는 일과 TPS를 끌어올리는 일은 같은 축 위에 있는 것으로 보인다. 어떤 모델에게 어떤 역할을 맡길지 정하는 조합 설계와, 그 모델을 어떤 하드웨어·엔진으로 서빙할지 정하는 실행 설계가 함께 맞물려야 실제 체감 속도가 나온다는 뜻이다.

오케스트레이터로 무엇을 쓸지 고르는 실전 후기와 TPS를 좌우하는 구조 설명이 같은 오후 시간대에 겹쳐 나온 점은, 이 방 참여자들이 모델 하나를 정답으로 고정하기보다 역할과 환경에 맞춰 조합을 계속 조정해 나가고 있다는 걸 보여준다. PR 단위로 성능을 재보고 서빙 구조까지 따지는 태도가, 이 커뮤니티에서 실험을 대하는 기본기로 자리 잡아가는 모습이다.