프로덕션 모범 사례

통합 시스템이 실제 트래픽을 처리하기 전에 올바르게 준비해야 할 사항.

안정성

• 적절한 코드에 대해 재시도하세요. 429, 500, 502, 503, 529 지수 백오프와 지터를 적용하세요. 무작정 재시도하지 마세요 400, 401, 402 또는 403.
• 타임아웃을 설정하세요. 긴 생성 작업은 정상적으로도 몇 분이 걸릴 수 있습니다. 하지만 소켓이 멈췄다고 워커까지 멈춰서는 안 됩니다. 비스트리밍 호출에는 120초가 합리적인 상한입니다.
• 동시 실행 수를 제한하세요 모든 요청을 한꺼번에 보내고 거부된 요청을 재시도하는 대신 세마포어를 사용하세요.
• 대체 모델을 준비하세요. 주 모델에 과부하가 걸리면 오류를 반환하는 것보다 더 작은 모델로 전환하는 편이 낫습니다.

비용

• 설정할 항목: max_tokens 모든 호출에 적용하세요. 이는 권고가 아니라 지출 한도입니다.
• 작업별로 라우팅하세요 — 참고: 비용 관리.
• 활성화하세요 프롬프트 캐싱 안정적인 접두사에 관한 내용입니다.
• 기록하세요 usage 나중에 지출을 작업별로 파악할 수 있도록 각 요청에 작업 라벨을 붙여 기록하세요.

보안

• 키는 환경 변수나 시크릿 관리자에 보관하세요. 저장소나 클라이언트 번들에는 절대 넣지 마세요.
• 서비스마다 별도의 키를 사용하면 필요한 키만 정확히 폐기할 수 있습니다.
• 신뢰할 수 없는 사용자 입력을 지침과 문자열로 이어 붙여 프롬프트를 만들지 마세요. 사용자 콘텐츠는 다음 위치에 두세요: user 메시지에 두고, 지침은 다음 위치에 두세요: system.
• 모델 출력을 신뢰할 수 없는 데이터로 취급하세요. 다음 작업을 하지 마세요: eval 실행하지 말고, 생성된 SQL을 쓰기 권한이 있는 역할로 실행하지 마세요.

관측 가능성

• 모델, 지연 시간, 다음 항목을 기록하세요: usage, stop_reason 그리고 모든 호출에 대해 자체 작업 유형도 기록하세요.
• 다음 항목에 대한 알림을 설정하세요: stop_reason: max_tokens 비율이 높아지면 답변이 잘리고 있다는 뜻입니다.
• 총비용뿐 아니라 작업 유형별 비용을 추적하세요. 총액만 보면 어떤 워크로드의 비용 효율이 나빠졌는지 알 수 없습니다.