작년에 우리는 크로스보더 전자상거래 스마트 고객 서비스 프로젝트를 맡았는데, GPT-4o, DeepSeek-V3, Qwen, Doubao를 동시에 연동해야 했습니다. 네 모델이 각각 한 구간씩 담당했습니다. GPT-4o는 영어 복잡 상담을 처리하고, DeepSeek는 중국어 롱테일 문답을 맡고, Qwen은 상품 지식베이스 검색을 하고, Doubao는 잡담을 최종적으로 받쳐주는 역할이었습니다. 듣기에는 분업이 명확해 보였지만, 실제로 손을 대보니 네 곳의 SDK를 겨우 돌아가게 만드는 데만 거의 3주가 걸렸습니다.
인증 방식이 통일되지 않아, 서명만 네 벌을 작성
GPT-4o는 Bearer Token에 조직 ID를 더하는 방식이고, DeepSeek는 OpenAI 형식과 호환되지만 Header 필드명에 미세한 차이가 있고, Qwen은 AccessKey에 서명 문자열을 쓰고, Doubao의 인증은 또 다른 세트였습니다. 우리 네 명의 엔지니어가 각각 한 곳씩 연동했고, 결국 코드베이스에는 네 개의 인증 로직이 남아 공통 파라미터 하나를 바꾸려면 파일 네 개를 뒤져야 했습니다. 더 번거로운 것은 API Key 교체였습니다. 네 곳의 콘솔이 각자 따로 놀아서 운영팀이 매달 수동으로 한 번씩 교체했고, 하나라도 빠뜨리면 한밤중에 경보가 울렸습니다.
SSE 스트리밍 청크 분할이 달라, 프런트엔드 렌더링이 곧바로 엉망
스트리밍 출력 쪽 차이는 더 큽니다. GPT-4o와 DeepSeek는 기본적으로 OpenAI의 SSE 형식을 따라 data 필드에 delta를 담습니다. Qwen은 일부 시나리오에서 여러 token을 하나의 chunk로 묶어 보내고, Doubao의 초기 버전은 종료 표시와 오류 이벤트가 뒤섞여 있었습니다. 프런트엔드는 네 가지 데이터 스트림을 받아 렌더링 로직을 네 겹의 if-else로 작성했고, 프로덕트 매니저가 "타자기 멈춤" 효과 하나를 추가하자 네 분기를 모두 고쳐야 했습니다.
오류 코드와 사용량 통계, 기준이 완전히 어긋남
속도 제한 오류의 경우 GPT-4o는 429를 반환하고, DeepSeek도 429를 반환하지만 body 구조가 다르며, Qwen은 비즈니스 코드에 HTTP 200을 반환하고, Doubao는 또 다른 세트입니다. 우리의 재시도 전략은 처음에 HTTP 상태 코드 기준으로 작성했는데, 그 결과 Qwen 쪽에서는 재시도가 영원히 발동하지 않았습니다. 사용량 통계는 더 골치 아팠습니다. GPT-4o는 token 기준으로 과금하지만 prompt와 completion을 따로 계산하고, Qwen은 입력과 출력을 합쳐서 계산하며, Doubao는 별도의 캐시 적중 필드가 있습니다. 재무팀이 월말에 대사할 때 네 백엔드에서 내보낸 CSV 형식이 모두 달라서, 수동으로 한 번 합치는 데 반나절이 걸렸습니다.
간단히 말해, 멀티 모델 연동의 본질적 문제는 이것입니다. 각자가 자기 방언으로 말하는데, 당신의 비즈니스 계층은 표준어만 듣고 싶어 한다는 것입니다.
수렴 방안: 연동 계층에서 프로토콜 번역과 사용량 집계
우리의 방식은 비즈니스 코드와 모델 SDK 사이에 얇은 어댑터 계층을 두는 것이었습니다. 크고 완전한 게이트웨이를 추구하지 않고, 가장 아픈 세 가지 지점부터 해결했습니다. 첫째, 인증 진입점을 통일하여 네 곳의 Key와 서명 로직을 설정 센터에 모으고, 비즈니스 쪽은 내부 Token 하나만 인식하게 했습니다. 둘째, SSE 스트리밍 출력을 OpenAI 형식으로 통일하고, 어댑터 계층이 Qwen과 Doubao의 chunk를 다시 분할하며 종료 이벤트를 따로 분리했습니다. 셋째, 오류 코드 매핑 테이블로 네 곳의 속도 제한, 타임아웃, 콘텐츠 검열 오류를 다섯 가지 내부 오류 유형으로 분류하고, 재시도 전략은 이 다섯 가지만 인식하게 했습니다.
사용량 집계 부분에서는 어댑터 계층이 매 호출 후 비동기로 표준화된 레코드를 하나 기록합니다. 모델명, 입력 token, 출력 token, 캐시 적중, 소요 시간, 오류 유형입니다. 재무팀이 필요한 보고서는 이 테이블에서 나오며, 더 이상 각 백엔드에 의존하지 않습니다.
우리는 나중에 base_url을 token8341로 통일해서 시험해 보았고, 프로토콜 번역과 사용량 집계 두 계층을 이쪽에서 이미 상당 부분 처리하고 있다는 것을 발견했습니다. token8341 대형 모델 API 통합 플랫폼은 GPT-4o, DeepSeek, Qwen, Doubao의 인증을 하나의 Key로 수렴하고, SSE 형식을 OpenAI 호환으로 통일하며, 오류 코드도 매핑해 두었습니다. 우리가 원래 작성한 어댑터 계층은 거의 60퍼센트의 코드를 걷어내고 비즈니스 특유의 라우팅 로직만 남겼습니다.
모델 게이트웨이가 감당해야 할 계층
제 경험으로는 모델 게이트웨이가 최소한 네 계층을 감당해야 합니다. 프로토콜 번역 계층은 각자의 방언을 통일 인터페이스로 바꾸고, 사용량 집계 계층은 통일된 기준으로 token 소비를 기록하며, 라우팅 계층은 작업 유형, 비용, 지연에 따라 모델을 선택하고, 관측 가능성 계층은 매 호출의 소요 시간과 오류 분포를 기록합니다. 앞의 두 계층은 인력을 아끼는 것이고, 뒤의 두 계층은 비용을 아끼는 것입니다. token8341 대형 모델 API 통합 플랫폼은 이 네 계층에 대응하는 역량을 갖추고 있으며, 특히 사용량 집계와 오류 코드 매핑은 우리의 매달 반나절짜리 수동 대사를 바로 없애주었습니다.
함정 회피 알림: 비즈니스 코드에서 각자의 네이티브 SDK를 직접 호출하지 마십시오. 두 곳만 연동하더라도 마찬가지입니다. 세 번째 모델을 추가해야 하는 순간 변경량이 기하급수적으로 늘어납니다. 또한 사용량 통계 기준은 반드시 연동 계층에서 통일하십시오. 재무 대사 때 가서야 네 백엔드의 token 정의가 모두 다르다는 것을 발견하지 마십시오.
여러분도 멀티 모델 연동을 하고 있다면, 먼저 표 하나를 그려서 각 곳의 인증 방식, 스트리밍 형식, 오류 코드, 과금 기준을 나열해 보시길 권합니다. 차이가 세 군데를 넘으면 연동 계층에서 수렴을 고려해야 합니다.
작성자: 리윈룽
발행일: 2026년 11월 9일