모델 선택은 쉬운 부분입니다

AI 요약

프런티어 API에서 오픈 웨이트 모델 자체 운영으로 코딩 에이전트를 옮기려면 무엇이 필요한지 살펴보기 위해, 글쓴이는 실제 소프트웨어 엔지니어링 작업을 정해진 세트로 구성하고 여러 오픈 웨이트 모델과 이를 제대로 구동할 하드웨어를 조합했습니다. 에이전트 하네스도 바꾸며 해결한 작업 수, 소요 시간, 동시에 처리한 사용자 수를 측정했습니다.

모델 가격은 메모리 구간에 따라 달라집니다

모델 성능이 좋아질수록 실행 비용도 비례해 오른다는 예상은 실험 결과와 맞지 않았습니다. 오픈 웨이트 모델 사이의 품질 차이는 점진적으로 커졌지만, 하드웨어 비용은 모델 가중치가 기존 장비 메모리에 들어가는지를 기준으로 계단식으로 뛰었습니다. 메모리 한계를 넘으면 파라미터가 조금 늘어나는 데 그치지 않고 다음 등급의 장비가 필요합니다.

따라서 리더보드 순위가 비용 대비 성능을 설명하지는 못합니다. 실험에 포함된 중간 크기 모델 하나는 작은 모델보다 서빙 비용이 네 배 들었지만 애플리케이션 성능은 2%만 나아졌습니다. 훨씬 큰 모델은 바로 아래 등급보다 비용이 조금 더 들면서 더 많은 작업을 해결했습니다. 글쓴이는 토큰당 가격보다 하드웨어 등급 안에 들어오는 모델을 찾고, 해결한 작업 하나당 비용을 비교해야 한다고 설명합니다.

자체 운영에서는 동시성이 제약이 됩니다

API를 쓰면 동시 요청 처리를 제공자가 맡지만, 자체 스택에서는 각 사용자의 컨텍스트가 메모리를 차지합니다. 하드웨어가 계속 작동하더라도 지연 시간이 길어지면 사용자에게 받아들일 만한 수준을 벗어날 수 있습니다. 실험한 구성별로 장비 한 대가 감당하는 개발자 수는 크게 달랐으며, 가장 크고 성능 좋은 구성에서 동시 처리 인원이 가장 적었습니다.

자체 운영의 손익분기점도 가동률에 좌우됩니다. 실험에서 성능이 약한 구성은 손익분기점에 필요한 가동률이 기업의 실제 가동률보다 훨씬 높았습니다. 실제 배포 환경의 보고된 가동률은 낮고, 운영을 잘하는 조직도 크게 다르지 않다고 글쓴이는 설명합니다. 비용 계산이 장비를 거의 계속 포화 상태로 써야만 성립한다면 그 사업성은 유지되기 어렵습니다.

하네스는 해결률보다 실행 비용을 바꿨습니다

글쓴이는 같은 하드웨어와 추론 설정에서 널리 쓰이는 코딩 하네스 세 가지를 비교했습니다. 작업 해결률은 하네스에 따라 몇 건 정도 차이가 나는 수준이었습니다. 반면 같은 모델과 하드웨어로 같은 수의 작업을 해결해도 하네스 조합에 따라 실제 실행 시간은 두 배까지 달랐습니다. GPU를 대여한다면 벽시계 기준 실행 시간이 비용을 좌우합니다.

하네스를 고른 뒤에도 평가를 이어가야 합니다. 실험 초반에는 한 하네스가 가장 나은 결과를 냈지만 소프트웨어를 다음 버전으로 올린 뒤 성능이 급락했습니다. 접두부 캐싱(prefix caching)을 처리하는 작은 변경으로 캐시가 완전히 깨졌고 GPU 대여 비용은 다섯 배로 뛰었습니다. 글쓴이는 개발자가 선호하는 하네스를 선택하되 이를 계측해야 한다고 말합니다. 모델 교체보다 하네스의 소규모 업데이트가 비용을 더 크게 바꿀 수 있습니다.

비용 외에 자체 운영을 정당화하는 조건

자체 운영이 더 저렴한지를 묻는 질문에는 작업 부하, 사용량 피크, 에이전트 속도에 대한 허용 범위가 빠져 있어 답하기 어렵습니다. 글쓴이는 실제 가동률과 외부 API에 맡길 수 없는 요구를 따져야 한다고 제안합니다. 건물 밖으로 데이터를 보낼 수 없는 경우, 요청량 제한을 적용하기 어려운 스택, 분기 중 가격 변동을 피해야 하는 상황은 비용표만으로 대체하기 어려운 자체 운영 이유로 제시됩니다.

dev.to 반응

• @deanlee — 개발자 활동의 피크와 저점까지 비용에 넣으면 동시성 계산은 더 불리해집니다. 사내 엔지니어링 클러스터는 하루 중 시간대별 수요 차이가 큽니다. 핵심 인력이 겹치는 네 시간 동안 대기열을 막으려면 지역별 피크에 맞춰 인프라를 마련해야 하고, 저녁과 주말 이용률은 한 자릿수까지 떨어집니다. 프런티어 API는 여러 시간대의 기업 수요를 함께 묶어 그 편차를 공유 부하에 흡수합니다. 사내 클러스터는 사용하지 않는 VRAM의 자본 감가상각 비용을 하루 24시간 부담합니다. 두 번째 숨은 비용은 컨텍스트 유지입니다. 장기 실행 코딩 에이전트는 계속해서 큰 컨텍스트를 쌓습니다. 개발자가 diff를 읽거나 생각하는 동안에도 할당된 KV 캐시는 적극적으로 다른 곳에 내보내지 않으면 고대역폭 메모리를 차지합니다. 실제 이용률 20%와 유휴 세션의 메모리 예약을 함께 계산하면, 해결한 작업 하나에 배분되는 비용이 캐시를 쓰지 않는 프런티어 API 요금보다 쉽게 커집니다.
• @alexshev — 동시성에 따라 처리 용량이 달라지므로 '해결한 작업당 비용'이 적절한 단위입니다. 포화 곡선도 공개하면 좋겠습니다. 동시 에이전트 수를 늘리며 해결 작업 수, p95 지연 시간, 실패율을 함께 보여주면 대기열이 비어 있을 때만 저렴해 보이는 모델인지 알 수 있습니다.
• @jabinpou — 접두부 캐시 회귀는 모델 변경뿐 아니라 하네스 업그레이드도 벤치마크해야 하는 이유를 잘 보여줍니다. 배포 전 고정된 다중 사용자 작업 부하를 넣고 해결 작업당 비용과 꼬리 지연 시간을 비교하겠습니다. 평균 실행 시간만 보면 긴 대기열 뒤에 선 개발자를 놓칠 수 있습니다.

원문: dev.to / 번역·요약: Trawling