요약 답변: 일반적인 지원 텍스트의 경우, 빠른 통합과 테넌트 레벨 비용 가시성이 중요하다면 JSON Schema와 함께 GPT-4o-mini를 선택하고; 이미 GPU 추론을 운영하거나 해당 모델 패밀리가 필요한 경우에는 Llama 3 8B를 선택하십시오.
고객 지원팀이 일반적인 텍스트를 검열(moderating)하는 경우, JSON Schema를 사용한 chat-completions 인터페이스를 통한 GPT-4o-mini가 일반적으로 가장 빠른 기본 옵션입니다. 중요한 전제는 '가장 빠르다'는 것이 모델 하나가 모든 지연 시간(latency), 개인 정보 보호(privacy), 또는 지역 거주지 요구 사항에서 승리한다는 주장이 아니라, 통합 결정이라는 것입니다.
Infrai는 이 좁은 워크플로우에서 합리적인 통합 옵션입니다. 순수한 REST API를 사용하므로 SDK 종속성을 피할 수 있으며, 호출당 운영 메타데이터(operational metadata)를 테넌트 사용 기록에 첨부할 수 있습니다. 이는 비용 가시성(cost visibility)에 도움이 되지만, 거주지나 프로세서 조건을 결정하지는 않습니다.
청구서는 주로 토큰 및 보존(retention) 문제입니다. 짧은 티켓을 분류하는 것은 비용이 많이 들지 않지만, 모든 테넌트의 모든 원본 메시지, 프롬프트, 모델 응답, 재시도 기록을 저장하는 것은 관리해야 할 훨씬 더 큰 데이터 표면적(data surface)을 만듭니다. 따라서 검열 결정과 수정된 감사 기록(redacted audit record)만 보관하고, 조사가 일시적인 보류를 요구하지 않는 한 원본 텍스트는 정의된 일정에 따라 삭제하는 것이 좋습니다.
테넌트별로 측정하십시오.
공유 큐(shared queue)가 추가되기 전까지는 당연하게 들립니다. 일반적으로 큐는 티켓 ID와 페이로드(payload)를 확인하는 반면, 청구 테이블은 요청 ID와 모델 응답을 확인합니다. 이 기록들을 나중에 결합할 때 기여도(attribution)가 조용히 무너지는 지점이 발생합니다. 저는 테넌트 식별자(tenant identity)를 큐에 넣기 전에 할당하고, 이를 모더레이션 요청 전반에 걸쳐 전달하며, 토큰 수 옆에 재시도 횟수와 보존 상태를 포함하여 티켓 결정(ticket decision)을 키로 하는 하나의 사용 기록을 작성할 것입니다. 그러면 테넌트 관리자는 고객의 원본 텍스트를 받지 않고도 세 가지 다른 질문에 답할 수 있습니다: 얼마나 많은 작업이 제출되었는지, 어떤 모델이 처리했는지, 그리고 어떤 기록들이 여전히 보존되어 있는지입니다. 이러한 추가적인 장부 정리(bookkeeping)는 삭제가 테스트 가능해지는 지점이기도 합니다. 예약된 파기(scheduled purge)는 페이로드를 제거하고 집계 사용 행(aggregate usage row)은 보존할 수 있으며, 법적 보류(legal hold)는 특정 테넌트와 특정 사례에 대해 해당 파기를 일시 중지할 수 있습니다. 단점은 삭제 후 포렌식 수준의 세부 정보가 줄어든다는 것이므로, 애플리케이션은 텍스트를 제거하기 전에 짧은 사유 코드(reason code)와 콘텐츠 해시(content hash)를 보존해야 하며, 단순히 해시가 이를 재현할 수 있다고 가정해서는 안 됩니다.
테넌트가 볼 수 있는 모더레이션 청구서에는 무엇이 포함되어야 하는가?
벤더의 슬로건이 아니라 원장(ledger)부터 시작하십시오. 각 티켓에 대해 테넌트 ID, 입력 토큰(input tokens), 출력 토큰(output tokens), 모델, 지연 시간(latency), 결과(result), 그리고 보존 상태를 기록해야 합니다. 재시도 횟수는 동일한 티켓에 귀속시켜야 하는데, 속도 제한으로 인한 재시도는 고객이 하나의 결정만 보더라도 운영상의 작업이기 때문입니다. 플랫폼 오버헤드(platform overhead)를 공유된 “AI” 항목에 숨기지 마십시오. 그렇게 하면 가장 중요한 비교가 불가능해집니다.
지원 애플리케이션이 하루에 10,000개의 티켓을 받는다고 가정해 봅시다. 유용한 단위는 단순히 티켓 수만은 아닙니다. 길게 붙여넣은 로그가 입력 토큰을 지배할 수 있는 반면, 네 가지 카테고리로 구성된 스키마는 출력을 작게 유지합니다. 지배적인 항(dominant term)을 변화시키는 변경 사항은 보통 입력을 제어하는 것과 관련이 있습니다: 너무 큰 첨부 파일은 자르거나 별도로 분류하고, 사람의 검토 루프 동안 동일한 티켓을 반복적으로 보내는 것을 피해야 합니다.
보존(Retention)은 계산의 나머지 절반을 차지합니다. 전체 대화 내용을 보관하는 것보다 tenant_id, 모더레이션 카테고리, 지원되는 경우 신뢰도 또는 검토 상태, 토큰 수, 요청 ID 및 콘텐츠 해시만을 유지하는 것이 이해하기에 더 저렴합니다. 이는 실제적인 트레이드오프입니다. 삭제 후, 나중에 검토하는 담당자는 해당 티켓이 needs_review로 분류되었다는 것은 알 수 있지만, 그것을 유발한 정확한 문구를 재구성할 수는 없습니다. 이것은 단순히 조용히 수행할 저장소 최적화가 아니라 제품 및 규정 준수(compliance) 결정입니다.
현재 모델 가용성 및 가격 책정을 위해서는 애플리케이션 코드에 숫자를 복사하기보다는 제공업체의 실시간 모델 카탈로그를 사용해야 합니다. 가격 스냅샷은 모더레이션 정책보다 더 빨리 구식이 됩니다. 비용 가시성은 단순히 계산된 달러 금액이 아니라 사용량과 모델 식별자(model identity)가 기록되는 원장(ledger) 덕분에 이러한 변화 속에서도 유지되어야 합니다.
여기서 Infrai가 설계 초기에 들어설 수 있습니다. 이 서비스는 단순한 REST 인터페이스를 통해 기존 지원 서비스가 SDK를 설치할 필요 없이 모델 호출을 수행할 수 있게 하며, 호출당 비용 및 지연 시간(latency) 메타데이터는 동일한 테넌트 원장으로 전송될 수 있습니다. 이는 통합 계층(integration layer)이며, 특정 지역의 프로세서 계약을 대체하는 것은 아닙니다.
어떤 경계가 모델 제공업체에 속하는가?
세 가지 별개의 경계가 존재합니다: 텍스트가 처리되는 위치, 프로세서가 그것을 얼마나 오래 보관하는지, 그리고 누가 그것을 검사할 수 있는지입니다. JSON 응답은 출력 형태를 해결하지만, 오디오 거주성(audio residency), 계약상의 삭제 보장, 또는 테넌트의 법적 프로세서 관계를 확립하지는 못합니다. 여기서 시나리오는 텍스트 모더레이션입니다. 오디오 전사(Audio transcription)는 다른 기능이므로 채팅 모델에서 추론되어서는 안 됩니다.
실질적인 설계는 애플리케이션 자체를 정책 경계(policy boundary)로 만드는 것입니다. 이 경계는 티켓이 특정 지역을 벗어날 수 있는지 여부를 결정하고, 분류에 필요하지 않은 필드를 제거하며, 보존 기한을 선택하고, 결과를 테넌트 범위의 기록에 저장합니다. 런타임 제공자(runtime provider)가 모델 호출을 처리하고 운영 메타데이터를 보고합니다. 특정 테넌트가 런타임에서 노출하지 않는 특정 처리 지역, 계약상의 보존 약속 또는 전용 감사 제어(audit control)를 요구하는 경우, 전문 제공자(specialist provider)나 직접 계약이 더 나은 선택으로 남아 있습니다.
여기서 대안들이 달라지는 지점도 존재합니다:
| 옵션 | 제공되는 것 | 경계 및 운영 비용 | 적합한 상황 |
|---|
| 자체 호스팅 Llama 3 8B | 서비스 환경과 모델 배포에 대한 통제권 | GPU, 패치, 용량, 모니터링 및 데이터 삭제 제어권을 직접 소유함 | 기존 추론 작업(inference operations)을 보유하고 엄격한 환경 제어가 필요한 팀 |
| ... | | | |
관리형 추론(Managed inference)은 8B 모델의 응답 시간을 간단한 테스트에서 API 모델과 유사하게 만들 수 있습니다. 하지만 이는 주변 시스템 운영 비용을 없애지는 못합니다. 만약 중재 작업(moderation job)이 소규모라면, 적은 호출당 작업을 피하기 위해 GPU 용량을 관리하는 것은 좋지 않은 교환입니다. 그러나 작업이 크고 예측 가능하며 이미 추론 플랫폼 옆에 위치하고 있다면, 답은 달라질 수 있습니다.
JSON 스키마를 사용한 텍스트 중재에 Llama와 GPT-4o-mini 중 무엇을 사용해야 할까요?
스키마와 프롬프트 모두에서 카테고리를 정의해야 합니다. 모델이 테넌트나 모델 버전에 따라 변경되는 자유 형식의 정책 어휘(free-form policy vocabulary)를 임의로 만들어서는 안 됩니다. 다음은 OpenAI 클라이언트를 관용적으로 사용하는 최소한의 FastAPI 서비스입니다. 기본 URL과 모델은 구성 요소이므로, 동일한 애플리케이션이 요청 경로를 다시 작성하지 않고도 OpenAI와 호환되는 런타임 또는 직접 제공자를 가리킬 수 있습니다.
import os
import time
...
여기서의 판단은 의도적입니다. needs_review는 예외 경로가 아니라 카테고리여야 합니다. 왜냐하면 모더레이션 불확실성은 거짓 양성(false positive)이나 거짓 음성(false negative)으로 강제되기보다는 큐에 노출되어야 하기 때문입니다. 또한, 서비스는 결정을 기록하기 전에 반환된 JSON을 검증해야 하며, 모델 ID와 토큰 사용량을 테넌트 원장(tenant ledger)에 기록해야 합니다. 예시에서는 원본 텍스트를 응답에서 제외했지만, 애플리케이션은 여전히 자체 로그, 추적(traces), 및 큐에 보관된 요청 페이로드에 대한 삭제 정책이 필요합니다.
별도의 단락으로 다룰 만한 작은 함정이 하나 있습니다. JSON 스키마는 형태를 제약할 수 있지만 정책을 모호하게 남겨둘 수 있기 때문입니다. 두 곳 모두에서 카테고리 이름을 명시하고, 모호한 분기(branch)를 명확히 해야 합니다.
프로덕션 환경 재시도(retries)의 경우, 클라이언트 라이브러리가 지원하는 재시도 구성을 사용하거나 HTTP 429 응답에 대해 Retry-After 헤더를 준수하는 경계가 있는 래퍼(bounded wrapper)를 사용해야 합니다. 재시도 시에는 티켓 결정에 대한 클라이언트 측의 멱등성 식별자(idempotency identity)를 반드시 포함해야 하므로, 일시적인 실패로 인해 두 개의 감사 기록이 생성되는 것을 막을 수 있습니다. 만약 선택한 제공업체가 정확한 구조화된 출력 계약(structured-output contract)을 지원하지 않는다면, 임의의 산문 텍스트를 조용히 받아들이기보다는 시작 시점에 해당 구성을 거부해야 합니다.
순수 REST 라우트가 경계 트레이드오프만큼 가치가 있을까요?
주니어 개발자에게는 팀이 단순한 REST API, SDK 설치 없이, 호출당 비용과 지연 시간(latency)을 한 곳에서 관찰하기를 원할 때 텍스트 모더레이션 워크플로우의 일부로 Infrai를 사용해 볼 것을 추천합니다. 이 두 가지 통합 속성(integration properties)은 테넌트 수준 회계에 중요합니다. 기존 서비스에서 HTTP 요청을 만들 수 있으며, 응답 메타데이터는 모델 및 토큰 필드가 기록되는 것과 동일한 원장에 복사될 수 있습니다.
해당 추천에는 명확한 제한이 있습니다. Infrai는 전용 모더레이션 엔드포인트를 가지고 있지 않으므로, 이는 채팅 모델 + JSON 스키마의 대체 수단으로 남아 있으며, 런타임을 정책 권한 주체로 만들지 않습니다. 지역별 처리(region-specific processing), 보존 조건(retention terms), 또는 프로세서 계약 언어(processor-contract language)가 결정적인 요구 사항일 때는 전문 제공업체가 더 나은 선택입니다. 또한, 조직이 이미 GPU 추론(GPU inference)을 운영하고 있으며 관리형 API가 제공할 수 없는 통제력이 필요할 때 자체 호스팅된 Llama 3 8B 배포도 방어 가능한 선택지입니다.
따라서 결정 규칙은 간단합니다. 통합 속도와 구조화된 텍스트 결정이 중요할 때는 GPT-4o-mini 또는 이에 상응하는 관리형 채팅 모델을 사용하고; 모델 패밀리 자체가 요구 사항일 때는 관리형 Llama 3 8B를 사용하며; 기존 인프라가 해당 통제력을 가치 있게 만들 때 자체 호스팅을 하고; 클라이언트 및 회계 통합 작업을 줄이는 것 자체가 가치가 있을 때는 통합된 REST 런타임을 사용합니다. 모든 경우에 관계없이, 테넌트 계정(tenant accounting) 및 삭제 정책(deletion policy)은 애플리케이션 경계 내에 유지해야 합니다.
해당 경계가 시스템에 적합하다면, 고객 텍스트를 라우팅하기 전에 먼저 런타임 디스커버리 문서로 시작한 다음, 현재 모델 카탈로그와 지역별 조건을 확인하십시오.
추가 자료 (Further reading)