요약
- 스트리밍 응답은 불완전한 청크와 마지막 토큰 사용량 데이터를 처리하기 위해 견고한 SSE 파싱이 필요합니다.
- JSON 모드 실패는 모델이 엄격한 JSON 스키마 외부에 후행 텍스트를 생성할 때 발생합니다.
- 100k 컨텍스트 윈도우는 프롬프트와 완성 사이에 공유되므로 긴 출력은 사용 가능한 입력 공간을 줄입니다.
- 비용 추계 시 출력 토큰의 높은 단가를 고려해야 합니다.
스트리밍 응답이 멈추는 이유
클라이언트가 토큰 사용량 데이터를 포함하는 마지막 서버 전송 이벤트(SSE) 청크를 읽지 않으면 스트리밍 응답이 멈춥니다. 당사 API는 생성되는 대로 토큰을 스트리밍하지만, 마지막 청크가 도착할 때까지 연결이 완전히 종료되지 않습니다. 클라이언트 코드가 조기에 연결을 끊거나 마지막 청크를 무시하면 청구 검증에 필요한 정확한 토큰 수를 잃게 됩니다.
스트림이 끝날 때까지 모든 청크를 읽으세요. 마지막 청크에 최종 토큰만 포함된다고 가정하지 마세요. 저희의 SSE 스트림에서 마지막 청크에는 다음이 포함됩니다. usage 입력 및 출력 토큰 합계가 표시되는 필드입니다. 이 데이터를 삭제하면 선불 크레딧 소비량을 정확하게 추적할 수 없습니다.
공통 함정
- 마지막 SSE 이벤트 무시.
- 긴 완성 텍스트에 대해 타임아웃이 너무 낮게 설정된 경우.
- 스트리밍 모드에서 부분 JSON 처리 안됨.
서버가 클라이언트가 전체 응답을 받았음을 알리기 위해 스트림을 모두 소비하세요. 이는 당사 측의 리소스 누수를 방지하고 자체 로그에 필요한 데이터를 확보합니다.
프로덕션 환경의 JSON 모드 오류 처리
JSON 모드 오류는 모델이 닫는 중괄호 뒤에 텍스트를 생성하여 엄격한 JSON 구문 분석 규칙을 위반하기 때문에 발생합니다. 설정 response_format 수신하여 {"type": "json_object", 모델은 유효한 JSON을 출력하려고 시도하지만, 닫는 괄호 뒤에 'Here is the data:'와 같은 대화형 여백 텍스트를 추가하는 경우가 많습니다. 그러면 파서가 추가 텍스트에서 충돌합니다.
마지막 유효한 닫는 중괄호 뒤에 오는 텍스트를 잘라냅니다. 모델이 JSON 구조의 끝에 정확히 멈춘다고 가정하지 마세요. 마지막 '}' 또는 ']'를 찾아 그 이후의 모든 내용을 버리는 후처리 단계를 구현해야 합니다. 이는 배열이나 중첩된 객체를 구문 분석할 때 매우 중요합니다.
모범 사례
- 마지막 유효한 JSON 블록을 추출하려면 정규식(regex)을 사용하세요.
- 추출된 문자열을 JSON 파서로 검증합니다.
- 출력이 혼란스러울 경우 더 낮은 temperature로 재시도하세요.
이 방식은 모델이 장문으로 답변하려는 경우에도 생산 파이프라인이 안정적으로 유지되도록 보장합니다. Uncensored 모델은 제약이 적으므로 포맷팅 측면에서 더 '창의적'일 수 있습니다.
컨텍스트 윈도우 제한 이해하기
컨텍스트 윈도우 제한은 프롬프트와 응답을 합쳐 100,000 토큰입니다. 즉, 입력이 50,000 토큰인 경우 제한에 도달하기 전에 최대 50,000 토큰까지만 생성할 수 있습니다. 제한은 입력에만 적용되는 것이 아니라 전체 요청에 대한 공유 예산입니다.
입력 토큰 수를 100,000에서 빼서 사용 가능한 출력 공간을 계산하세요. 긴 시스템 프롬프트나 긴 메시지 기록을 보내면 사용 가능한 출력 공간이 줄어듭니다. 긴 대화 기록을 유지하는 애플리케이션에 이것이 중요합니다.
계산 예시
- 전체 윈도우: 100,000 토큰.
- 입력 토큰: 20,000개.
- 최대 출력: 80,000 토큰.
이 제한을 초과하면 API가 오류를 반환합니다. 모델 응답의 예상치 못한 잘림을 피하기 위해 토큰 사용량을 주의 깊게 모니터링하세요. 모델은 자동으로 잘리지 않으며, 총량이 윈도우를 초과하면 단순히 요청을 거부합니다.
토큰 세기 및 비용 추정
비용 추계 시 입력 토큰과 출력 토큰의 가격 차이를 고려해야 합니다. 입력 토큰은 1M당 $0.15, 출력 토큰은 1M당 $0.50입니다. 출력 토큰이 훨씬 비싸므로 긴 응답을 생성하면 긴 프롬프트를 전송하는 것보다 비용이 더 빠르게 증가합니다.
예상 토큰 수에 해당 가격을 곱하여 비용을 추정하세요. 예를 들어, 10,000개의 입력 토큰과 5,000개의 출력 토큰은 다음과 같은 비용이 듭니다: (10,000/1,000,000 * $0.15) + (5,000/1,000,000 * $0.50). 이는 요청당 $0.0015 + $0.0025 = $0.004입니다.
가격표
| 토큰 유형 | 1M 토큰당 가격 |
|---|---|
| 입력 | $0.15 |
| 출력 | $0.50 |
최종 SSE 청크 또는 API 응답을 통해 사용량을 추적하세요. 이는 대용량 애플리케이션의 예산을 정확하게 책정할 수 있도록 보장합니다. 선불 크레딧은 만료되지 않으므로 월별 요금 없이 시간이 지남에 따라 지출을 계획할 수 있습니다.
속도 제한: 분당 300회(RPM) 설명
속도 제한은 API 키당 분당 300회 요청으로 제한합니다. 이 제한은 페이로드 크기나 토큰 수에 관계없이 모든 요청에 적용됩니다. 이 제한을 초과하면 API는 429 오류를 반환합니다. 이러한 오류를 우아하게 처리하기 위해 지수 백오프를 구현해야 합니다.
요청 속도를 모니터링하고 동시성을 적절히 조정하세요. 여러 스레드나 프로세스를 사용하는 경우 동일한 API 키를 공유하며 분당 300회(RPM) 제한을 collectively 초과하지 않도록 하세요. 이 한도를 초과하면 속도 제한이 초기화될 때까지 일시적인 오류가 발생합니다.
429 오류 처리
- 지수 백오프를 구현하세요.
- 분석을 위해 실패한 요청 로깅.
- 제한이 빈번하게 발생하면 동시성을 줄이세요.
저희 API는 대용량 사용에 적합하지만, 속도 제한을 통해 모든 클라이언트에게 공정한 사용량을 보장합니다. 더 높은 제한이 필요하면 새 API 키를 생성할 수 있지만, 각 계정당 동시에 활성화된 키는 하나만 허용된다는 점을 유의하세요.
함수 호출 실패トラブルシュー팅
함수 호출 실패는 모델의 도구 정의가 예상 스키마와 일치하지 않거나 모델이 도구 인수에 대한 유효한 JSON을 출력하지 못할 때 발생합니다. 도구 정의가 정확하고 모든 필수 매개변수가 포함되어 있는지 확인하세요. 모호한 스키마는 잘못된 도구 호출을 초래합니다.
함수를 실행하기 전에 도구 인수를 검증합니다. 모델은 필수 필드가 누락되었거나 잘못된 유형을 포함하는 인수를 생성할 수 있습니다. 클라이언트 코드는 더 명확한 프롬프트로 다시 시도하거나 도구 정의를 조정하여 이러한 오류를 처리해야 합니다.
디버깅 단계
- 도구 정의 구문 확인
- 인수 유형과 값을 검증합니다.
- 누락된 필드가 있는지 모델 출력을 검토합니다.
함수 호출은 강력한 기능이지만 신중한 스키마 설계가 필요합니다. Uncensored 모델은 필터링된 모델보다 도구 정의에서 일관성이 낮을 수 있으므로 엄격한 검증이 필수적입니다.
'uncensored'가 완전히 무제한이 아닌 이유
'무차별' 라벨은 모델이 합법적인 성인, 허구적 또는 논쟁적인 주제를 거부하지 않음을 의미하지만, 미성년자를 포함한 성적인 콘텐츠에는 여전히 엄격한 한계가 있습니다. 이것이 항상 적용되는 유일한 콘텐츠 제한입니다. 해당 콘텐츠가 포함된 요청은 프롬프트의 나머지 부분이 완벽하게 타당하더라도 거부됩니다.
기술적 오류나 속도 제한으로 인해 기타 거부가 여전히 발생할 수 있습니다. 모델은 마법이 아니며 입력이 너무 복잡하거나 컨텍스트 윈도우를 초과하는 경우 응답을 생성하지 못할 수 있습니다. 'uncensored'는 기술적 신뢰성이 아닌 콘텐츠 정책을 의미한다는 점을 이해하세요.
콘텐츠 제한
- 미성년자가 포함된 성인 콘텐츠는 허용되지 않음.
- 합법적인 성인 콘텐츠는 허용됩니다.
- 기술적 오류가 발생해도 거부가 여전히 발생할 수 있습니다.
이 구별은 광범위한 주제를 처리해야 하는 애플리케이션에 중요합니다. 특정 한계를 알면 필터링 로직을 올바르게 설계할 수 있습니다.
400 및 429 오류 디버깅
400 오류는 유효하지 않은 JSON, 필수 필드 누락 또는 8 MB 요청 본문 한도 초과와 같은 요청 자체의 문제를 나타냅니다. 429 오류는 1분당 300개의 요청 제한을 초과했음을 나타냅니다. 이러한 오류를 구분하면 올바른 문제를 빠르게 수정할 수 있습니다.
For 400 errors, check your request payload and schema. For 429 errors, implement backoff and reduce concurrency. If you receive a 400 error with a message about the request body size, ensure you are not sending too much data in a single request. The 8 MB limit is strict.
오류 코드
| 오류 코드 | 의미 |
|---|---|
| 400 | 잘못된 요청 |
| 429 | 속도 제한 초과 |
이러한 오류를 컨텍스트(페이로드, 타임스탬프)와 함께 기록하면 디버깅이 훨씬 쉬워집니다. 이 데이터를 사용하여 통합을 최적화하고 반복적인 실패를 방지하세요.
Heretic LLM 최적화를 위한 다음 단계
Optimization begins with monitoring your token usage and error rates. Use the token data from the final SSE chunk to track your actual consumption. Compare this against your estimated costs to ensure accuracy. Adjust your concurrency and rate limiting strategies based on your observed usage patterns.
더 일관된 JSON 출력이나 함수 호출을 위해 더 낮은 온도를 사용하세요. 더 창의적인 응답이 필요하면 온도를 높이지만 더 많은 파싱 오류가 발생할 수 있음을 준비하세요. 사용 사례에 맞는 적절한 균형을 찾기 위해 다양한 매개변수를 실험하세요.
Optimization Tips
- 토큰 사용량을 주의 깊게 모니터링합니다.
- 일관성 대 창의성을 위해 온도를 조정합니다.
- 견고한 오류 처리를 구현하세요.
통합 테스트를 위해 무료 체험으로 시작하세요. 클라이언트 코드가 스트리밍, JSON 모드 및 속도 제한을 올바르게 처리하는지 확인하기 위해 선불 크레딧을 구매하기 전에 저위험 방식으로 검증할 수 있습니다.
