저는 50개 이상의 모델을 하나의 통합 인터페이스 뒤에 배치한 OpenAI 호환 채팅 엔드포인트를 출시했습니다. 마케팅 계산은 쉬웠습니다. 클라이언트 한 곳, 어떤 제공업체든 상관없이 코드를 다시 작성할 필요 없이 교체가 가능했죠. 하지만 엔지니어링 계산은 더 어려웠습니다.
첫 번째 비용은 모델 레지스트리였습니다. 모든 제공업체가 약간씩 다른 /models 페이로드를 전송합니다. 어떤 것은 컨텍스트 윈도우를 포함하고, 어떤 것은 그렇지 않습니다. 어떤 것은 max_tokens를 사용하고, 어떤 것은 max_completion_tokens를 사용합니다. 심지어 몇몇은 특정 모델이 어느 지역에서 실제로 사용 가능한지에 대해 거짓말을 합니다. 결국 저는 '이 모델이 존재한다'는 다섯 가지 다른 어휘 간의 번역 테이블인 정규화 계층(normalization layer)을 유지해야 했습니다.
두 번째 비용은 라우팅이었습니다. 에이전트들이 제공업체의 이름을 알지 못해도 가격-품질 트레이드오프를 선택할 수 있도록 auto/eco/premium 티어를 추가했습니다. 이는 모델별 지연 시간(latency)과 비용 데이터를 최신 상태로 유지해야 함을 의미하며, 그렇지 않으면 라우터가 확신에 찬 잘못된 결정을 내립니다. 오래된 가격표는 모든 'eco' 요청을 지난 화요일보다 더 비싸진 모델로 보냅니다.
세 번째 비용—저를 놀라게 한 것—은 사용 중단(deprecation)이었습니다. 제공업체들은 때로는 30일, 때로는 그보다 적은 통보 기간으로 모델을 폐기합니다. 제 레지스트리에는 '이 모델이 사라지고 있다'는 개념 자체가 없었습니다. 에이전트들은 워크플로우에 모델 이름을 하드코딩했고, 어느 날 갑자기 404 오류를 마주했습니다. 저는 이제 모델 ID를 정체성(identity)이 아닌 임대 기간(lease)으로 취급하며, API가 폐기 예정임을 알 때 폐기 헤더(deprecation header)를 반환합니다.
배운 교훈은 이렇습니다: 통합된 모델 카탈로그는 편리한 래퍼(wrapper)가 아니라 제품 표면(product surface)입니다. 이는 스키마 유효성 검사, 최신 상태 보장, 그리고 사용 중단 정책이 필요하며—이는 여러분이 구축할 다른 모든 API와 같습니다. 이 API를 사용하는 에이전트들은 괜찮았습니다. 문제가 된 것은 저 자신이었죠.
모델 목록 엔드포인트를 건드려 정규화의 흔적을 보고 싶다면 https://x402.freeq.one/tools/llm_chat.html에서 실행 중입니다.