모델 기능 탐색: 우리에게 필요한 누락된 API

커뮤니티 반응

대체로 긍정적이며, 많은 개발자가 프레임워크 유지보수의 어려움에 공감하며 표준화의 필요성을 지지하고 있다.

주요 논점

01찬성다수

API 수준에서 모델 기능을 명시하여 프레임워크의 수동 관리 부담을 제거해야 한다.

합의점 vs 논쟁점

합의점

현재 LLM API의 모델 정보 제공 수준이 매우 낮다.
프레임워크들이 모델 사양을 수동으로 관리하는 것은 비효율적이다.

논쟁점

모든 제공업체가 동일한 표준 필드를 채택할 것인가에 대한 실현 가능성

실용적 조언

현재는 LiteLLM의 model_cost_map이나 models.dev를 활용하여 모델 사양을 동적으로 관리하는 것이 최선이다.

섹션별 상세

현재 대다수 LLM 제공업체의 API는 모델의 구체적인 기능을 반환하지 않는 구조적 결함을 가지고 있다. /v1/models 엔드포인트는 단순히 모델 ID와 소유자 정보만 제공할 뿐, 해당 모델이 펑션 콜링을 지원하는지 또는 특정 컨텍스트 윈도우를 가졌는지에 대한 메타데이터를 포함하지 않는다. 이로 인해 클라이언트 사이드에서 모델의 역량을 사전에 파악하기 어렵다.

API의 정보 부재로 인해 주요 LLM 프레임워크들은 막대한 리소스를 들여 자체적인 모델 레지스트리를 구축하고 있다. LiteLLM은 2,600개 이상의 모델 비용과 사양을 담은 model_cost_map을 직접 유지보수하며, LangChain은 models.dev와 같은 제3자 데이터베이스에 의존하는 실정이다. 소규모 프로젝트들은 모델 리스트를 코드에 하드코딩함으로써 업데이트가 발생할 때마다 수동으로 수정해야 하는 비효율을 겪는다.

이 문제를 근본적으로 해결하기 위해 /v1/models 응답 객체에 capabilities 필드를 표준화하여 추가하자는 제안이 제기됐다. 각 모델이 지원하는 기능을 불리언(Boolean) 값으로 명시하면, 프레임워크는 런타임에 모델의 기능을 동적으로 감지하여 적절한 로직을 실행할 수 있다. 이는 OpenAI의 OpenAPI 사양 개선을 통해 생태계 전반의 상호운용성을 높이는 계기가 된다.

json

{
  "capabilities": {
    "function_calling": true,
    "json_mode": true
  }
}

제안된 /v1/models 응답의 capabilities 필드 예시

Client-Server communication diagram showing a proposed JSON response with a 'capabilities' field. — Diagram클라이언트가 서버에 모델 정보를 요청했을 때, 서버가 'capabilities' 필드를 포함한 JSON을 반환하여 모델의 기능을 명시하는 구조를 시각화했다. 이는 제안된 API 개선안의 핵심 작동 방식을 보여준다.

용어 해설

API 엔드포인트(API Endpoint): — 서버에서 특정 리소스에 접근할 수 있도록 제공하는 통신 지점이다. 클라이언트가 HTTP 요청을 보내면 서버는 해당 경로에 정의된 로직에 따라 데이터를 반환하거나 작업을 수행한다.
OpenAPI 사양(OpenAPI Specification): — RESTful API의 구조를 설명하기 위한 표준화된 인터페이스 기술 언어이다. 이를 통해 개발자와 도구가 서비스의 기능을 코드를 보지 않고도 이해하고 상호작용할 수 있게 돕는다.
펑션 콜링(Function Calling): — LLM이 사용자의 질문에 답하기 위해 외부 도구나 API 함수를 호출해야 할 필요가 있는지 판단하고 필요한 인자를 생성하는 기능이다. 모델이 단순 텍스트 생성을 넘어 외부 시스템과 연동되는 핵심 메커니즘이다.

언급된 도구

LiteLLM추천

LLM 추론 추상화 및 모델 사양 매핑 관리

LangChain중립

LLM 애플리케이션 개발 프레임워크

언급된 리소스

GitHubOpenAI OpenAPI GitHub Issue #537