ReliAPI

ReliAPI는 두 개의 프록시 경로를 노출한다. /v1/proxy/http는 일반 HTTP 대상용이고 /v1/proxy/llm은 설정된 언어 모델 공급자용이다. 대상을 config.yaml 파일에서 정의하면, 프록시는 호출을 전달하기 전에 캐싱이나 회로 제한 같은 규칙을 적용한다. 모든 나가는 요청의 동작을 바꾸는 곳이 하나다. 그게 장점이다.

TTL 캐시는 HTTP GET과 HEAD 요청에 더해 비스트리밍 LLM 응답을 덮는다. 대상별로 캐시 창을 설정하고, 그 창 안의 반복 호출은 공급자를 다시 때리지 않고 저장된 결과를 돌려준다. 같은 방식으로 하루에 수백 번 호출하는 API라면, 그것만으로 지연과 비용을 줄이며 시간이 지날수록 쌓인다.

LLM 경로는 멱등 키를 받고, Redis가 이를 추적해 같은 논리 요청이 두 번 실행되지 않게 한다. 프로젝트는 여기서 신중하다. 이는 비스트리밍 호출만 덮고, 업스트림의 정확히 한 번 실행이나 공급자 청구와의 일치를 약속하지 않으니 의존하기 전에 문서를 읽어라. 우발적 중복에 대한 보호로 읽고, 청구 보증으로 읽지 말라.

각 대상은 무른 비용 상한과 단단한 비용 상한을 가질 수 있다. 요청이 나가기 전에 ReliAPI가 비용을 추정하고, 무른 상한은 경고하고 단단한 상한은 호출을 막을 수 있다. 주의점은 이것이 요청 전 추정치라 공급자가 실제로 청구하는 1센트까지 잡지는 못한다는 것이다. 가드레일에는 충분하다. 회계에는 아니다.

내장 요청 제한으로 설정한 등급별로 트래픽을 제한할 수 있고, 대상은 코드에 박히는 대신 순수 YAML로 정의된다. 공급자를 추가하거나 base URL을 바꾸는 건 설정 편집이다. 재배포는 없다. 그게 여러 공급자 구성 관리를 가능하게 유지한다. 여러 공급자에 걸쳐 API 신뢰성을 좇는 팀에게, 이 설정 우선 설계가 시간을 가장 많이 아껴 주는 부분이다.

npm(reliapi-sdk)과 PyPI(reliapi-sdk)의 공식 SDK가 두 언어를 위해 프록시 경로를 감싼다. 요청을 손으로 짜는 대신 몇 줄의 코드로 proxy_http나 proxy_llm을 호출할 수 있고, CI 워크플로를 위한 GitHub Action도 있다.

/metrics 엔드포인트가 기존 모니터링 스택을 위해 Prometheus 데이터를 노출한다. 프록시 트래픽은 거기서 추적한다. 지출이나 오류율이 움직일 때 청구서에서 발견하는 대신 알림을 받고 싶다면 이게 중요하다.