로컬 AI 박스와 API 구독, 비용 부담은 언제 갈리나?
비용 부담이 갈리는 지점은 구독료와 기계 값을 표로 맞대는 순간이 아닙니다. API는 호출이 늘면 미터와 한도가 일을 멈추는 쪽이고, 로컬 박스는 그 호출이 건물을 나가면 안 되거나 같은 한도에 반복해서 막힐 때 후보가 됩니다. 이 글은 그 시점만 다룹니다. 가격, 전기요금, 총소유비용 숫자는 넣지 않습니다.
채팅 제품의 좌석과 API 미터는 다른 청구입니다. 플랜 이름과 좌석 비교, 특정 박스의 메모리 용량 비교는 여기서 다루지 않습니다. Spark급은 “책상이나 랩에 두고 모델을 로컬에서 돌리는 박스”라는 형태 예입니다.
API 구독만으로 충분한 반복·팀 패턴은?
한 줄 답: 각자 호출이 사람 속도이고, 그 데이터가 외부 API로 나가도 되며, 응답을 대화 속도로 기다려도 되고, 한도에 닿으면 미루거나 더 작은 모델로 바꿔도 일이 멈추지 않으면 API 구독으로 충분합니다.
반복이라는 말만으로 박스가 필요해지지는 않습니다. 초안, 리뷰 코멘트, 회의 정리, 검색 뒤 고치기처럼 다음 단계가 사람인 반복은 호출 간격이 사람의 읽기 속도에 묶입니다. 그 패턴은 구독 미터 안에서 끝나는 경우가 많습니다.
팀으로 볼 때는 좌석 수보다 동시에 도는 자동 호출이 기준입니다. OpenAI 레이트 리밋 문서는 한도가 사용자 개인이 아니라 조직과 프로젝트에 걸린다고 설명합니다. 여러 사람이 가볍게 겹쳐 쓰고 미터에 여유가 있으면 구독을 유지합니다. 좌석마다 방치된 에이전트가 동시에 긴 작업을 돌리면, 그것은 아래의 한도 신호입니다.
구독으로 남을 조건은 네 가지입니다.
- 데이터 분류가 API 전송을 허용합니다. 나가면 안 되는 문서를 싸게 처리하려고 구독을 깨는 선택이 아닙니다. 약관과 사내 정책은 그 시점의 문서로 확인하고, 이 글은 약관을 요약하지 않습니다.
- 지연은 대화 속도면 됩니다. 채팅, 비동기 리뷰, 밤에 끝나는 배치는 왕복을 견딥니다.
- 한도는 대기나 강등으로 넘깁니다. 더 작은 모델, 다음 시간, 잠시 멈춤으로 업무가 이어집니다. 같은 문서의 지출 알림은 트래픽을 끊지 않고 알려 주고, 하드 지출 한도는 해당 요청을
429로 거절합니다. 알림만으로 일이 이어지면 아직 구독 쪽입니다. - 모델 교체와 장애는 공급자 쪽에 둡니다. 팀이 호스팅된 큰 모델을 가끔 나눠 쓰는 긴 꼬리는 박스 한 대가 대신하지 않습니다.
로컬 박스(예: Spark급)가 맞는 데이터·지연·한도 신호는?
한 줄 답: 프롬프트가 건물 밖에 나가면 안 되거나, 왕복 지연이 작업 루프를 깨거나, 줄인 뒤에도 같은 대량 호출이 한도와 지출 상한에 반복해서 막힐 때 로컬 박스가 후보입니다.
Spark급은 그 후보의 형태입니다. 용량이 다른 두 구성을 견주는 글이 아닙니다.
신호는 셋으로 나눕니다.
| 신호 | 구독이 일을 막는 방식 | 박스가 맡는 조각 |
|---|---|---|
| 데이터 | 정책상 그 텍스트·코드를 API에 넣을 수 없음 | 그 조각만 기기 안에 둠. 나머지 허용 업무는 API에 남김 |
| 지연 | 한 단계의 답이 다음 단계를 막고, 그 대기가 원격 왕복에 걸림 | 같은 자리의 루프, 또는 망이 전제이면 안 되는 응답 |
| 한도 | 같은 반복 작업이 429나 하드 지출 한도로 거듭 멈춤 | 이미 호출을 줄인 뒤에도 남는 대량 조각 |
한도 쪽은 숫자를 새로 만들지 않습니다. 문서의 한도는 요청 수, 토큰 수처럼 먼저 닿는 지표로 걸리고, 모델마다 다르며, 계정 화면에 나옵니다. 신호는 “우리 작업 리듬에서 같은 일이 한 번 이상 팀 전체를 세운다”이지, 분당 몇 토큰부터 박스를 사라는 문장이 아닙니다.
박스가 바꾸지 않는 것도 같이 말합니다.
- 호스팅 모델의 업데이트와, 그 기계에 올라가지 않는 더 큰 모델은 API에 남습니다.
- 전력, 자리, 스택을 돌보는 시간은 생깁니다. 이 글은 그 항목을 금액으로 바꾸지 않습니다. 부담의 종류가 미터에서 운영으로 옮겨 간다는 뜻만 둡니다.
- 다섯 팀이 가끔 큰 모델을 쓰는 패턴은 박스의 신호가 아닙니다. 막히는 조각과 가끔 쓰는 꼬리를 한 기계로 합치지 않습니다.
올리기 전 줄일 클라우드 사용은?
한 줄 답: 상위 한도나 하드웨어로 올리기 전에, 같은 결과를 더 짧은 컨텍스트·더 적은 재시도·더 작은 모델·배치로 만들 수 있는 호출을 먼저 걷어 냅니다.
줄일 순서는 사용 기록에서 나옵니다.
- 반복 전송. 에이전트 루프가 매 단계 전체 대화를 다시 보내고, 사람마다 같은 저장소 요약을 다시 돌리고, 평가 작업이 항상 가장 큰 모델을 쓰면 그 호출이 미터를 채웁니다. 같은 입력은 저장해 둔 결과를 씁니다.
- 재시도. 문서는 실패한 요청도 분당 한도에 들어가고, SDK 재시도와 애플리케이션 재시도를 겹치면 호출이 곱해진다고 적습니다.
Retry-After가 있으면 그 시간 전에 다시 보내지 않습니다. 할당량·결제 오류는 재시도로 풀리지 않습니다. - 출력 길이. 필요한 답보다 훨씬 큰 최대 출력은 한도 계산을 불필요하게 키울 수 있습니다. 기대하는 답 길이에 맞춥니다.
- 당장 답이 필요 없는 묶음. 문서의 Batch API는 동기 요청의 레이트 리밋과 따로 큰 묶음을 넣는 경로입니다. 사람이 화면 앞에서 기다리지 않는 작업은 그쪽으로 보냅니다.
- 모델 크기. 분류와 추출은 더 작은 모델로 두고, 큰 모델은 거기서 남은 건만 봅니다.
- 상한의 종류. 먼저 지출 알림으로 곡선만 보고, 하드 한도는 정말로 그 달을 끊어도 될 때 겁니다. 알림이 울리자마자 기계를 보는 순서는 아닙니다.
이 여섯을 적용한 뒤에 남는 조각이 여전히 데이터 정책, 지연, 같은 한도에 막히면 그 조각만 로컬 박스 후보입니다. 줄어든 꼬리는 API에 둡니다.
닫는 문장은 이렇게 두면 됩니다. “사람 속도의 팀 호출이고 데이터가 나가도 되면 API 구독을 유지합니다. 나가면 안 되는 데이터이거나, 줄인 뒤에도 같은 작업이 한도에 반복해서 서면 그 조각만 Spark급 같은 로컬 박스로 옮기겠습니다. 금액 표는 만들지 않겠습니다.”
출처
- OpenAI API rate limits — 조직·프로젝트 단위 한도,
429, 지출 알림과 하드 한도, 재시도와 Batch API