Groq 이중 AI 통합: 두 번째 AI를 추가한 이유와 실제로 고쳤던 것

이미 하나가 있는 애플리케이션에 두 번째 AI 제공자를 추가하는 것은 명백한 결정이 아닙니다. 복잡성을 추가합니다: 2개의 API 키를 관리하고, 2개의 속도 제한 시스템을 추적하고, 2개의 API 특정 특이점을 해결합니다. 우리는 어쨌든 그렇게 했습니다. Gemini는 요약 및 Q&A에 탁월하지만, 실시간 음성 교정에 맞지 않는 특성 있는 지연시간 프로필을 가지기 때문입니다. 여기는 Groq 통합의 전체 이야기이며, 첫날 그것을 깨뜨린 400 오류와 우리가 그것에 대해 한 것을 포함합니다.

모든 것에 Gemini를 사용하는 문제

429 속도 제한 문제를 해결한 후 (우선순위 큐에 대한 우리의 전용 포스트 참조), VORA의 Gemini 통합은 안정적이었습니다. 하지만 안정성은 새로운 문제를 드러냈습니다: 지연시간 비대칭성. 다양한 작업 유형은 하나의 모델이 최적으로 제공할 수 없는 다양한 지연시간 요구사항을 가집니다:

CORRECTION: 실시간처럼 느껴지려면 1-2초 내에 완료되어야 합니다. Gemini Flash는 대략 70%를 달성하지만, 때로는 부하 시 3-5초가 걸립니다. 실시간 교정의 경우, 간헐적 5초 지연이 매우 눈에 띕니다.
QA: 사용자는 질문 답변을 위해 2-3초를 견딜 수 있습니다. 문제 없음.
SUMMARY: 백그라운드 작업, 사용자에게 지연시간이 중요하지 않습니다.

교정 사용 사례는 특히 깊이보다 속도를 위해 최적화된 모델을 필요로 합니다. Gemini Flash는 훌륭한 일반주의자입니다. 하지만 Groq의 Llama 3.3 70B, Groq의 사용자 정의 LPU (Language Processing Unit) 하드웨어에서 실행, 짧은 프롬프트에 대해 일관되게 더 빠른 추론을 제공합니다 — 교정 작업의 응답 시간은 Groq의 하드웨어 수준 최적화 덕분에 일관되게 1초 미만입니다.

아키텍처 결정: 선택사항 두 번째 모델

우리는 2개의 API 키를 관리해야 하는 마찰이 원하지 않으면 사용자를 강요하고 싶지 않았습니다. 통합은 선택 사항으로 설계되었습니다: 활성화되면 CORRECTION 작업을 Groq으로 라우트하고 QA와 SUMMARY를 Gemini에 그대로 두는 "빠른 교정 모드" 토글을 설정합니다. Groq이 실패하거나 구성되지 않으면, 모든 것은 투명하게 Gemini로 폴백합니다.

TextCorrector 모듈은 이미 추상화 계층을 가지고 있었습니다 — aiCorrect() 메서드가 useGrokForCorrection플래그에 따라 _grokCorrect() 또는 _geminiCorrectOriginal()을 호출했습니다. 두 번째 모델을 추가하는 것은 대부분 Gemini이 기대하는 인터페이스와 일치하는 깨끗한 GrokAPI 클래스를 작성하고 UI 토글을 연결하는 문제였습니다.

1일차: 400 오류

우리는 Groq 통합을 배포했습니다. 첫 실제 테스트 세션 몇 분 내: api.groq.com/openai/v1/chat/completions에서 HTTP 400. 일관되게, 모든 요청에서. API 오류 메시지는 도움이 되지 않았습니다: 단지 "나쁜 요청."

GrokAPI 클래스는 모델 ID llama-3.3-70b를 사용했습니다. 여기가 우리가 중대한 가정 오류를 만들었습니다: 우리는 Groq의 문서 요약에서 모델 이름을 추론했고 API 모델 식별자가 변형 접미사 없는 간단한 버전 번호일 것이라고 가정했습니다.

그렇게 작동하지 않습니다. Groq API는 배포 변형을 포함한 전체 모델 식별자를 필요로 합니다 — 일반 용도 128K 컨텍스트 배포의 llama-3.3-70b-versatile. -versatile을 생략하면 모델 이름이 유효한 엔드포인트로 해석되지 않기 때문에 400이 발생합니다. 실제 Groq 모델 목록을 console.groq.com에서 확인 (배포 전에 했어야 함)은 올바른 식별자를 확인합니다.

// 버그:
this.model = 'llama-3.3-70b';           // Groq 모델 ID로 존재하지 않음

// 수정:
this.model = 'llama-3.3-70b-versatile'; // 올바른 Groq 모델 식별자 (128K ctx)

디버깅 중 2차 발견이 있었습니다: Groq의 API는 OpenAI 호환 형식을 따르며, temperature, max_tokens, 표준 메시지 역할이 모두 정확히 문서화된 대로 작동한다는 것입니다. 일부 다른 LLM API가 특정 모델 유형에 대한 매개변수를 제한하지 않는 다른 것과는 다르게, Groq의 Llama 엔드포인트는 전체 표준 매개변수 세트를 수락하며, 통합을 상당히 단순화했습니다.

이것을 배포하기에 안전하게 만든 폴백 패턴

모델 이름 문제를 수정한 후에도, 우리는 우려가 있었습니다: 사용자가 Groq을 구성했지만 Groq API가 문제가 있을 때 (속도 제한, 서비스 중단, 네트워크 문제)? 교정 파이프라인이 폴백이 견고하지 않으면 조용히 깨집니다.

TextCorrector._grokCorrect()의 구현에 명시적 폴백 처리가 있습니다:

async _grokCorrect(text) {
    try {
        const result = await this.grokAPI.correctText(text, prompt);
        if (result) { /* process and return */ }
        return { text: text, isQuestion: false }; // 빈 결과 폴백
    } catch (error) {
        console.warn('[Groq] 교정 실패, Gemini로 폴백:', error.message);
        // Groq 실패 시 Gemini로 폴백
        if (this.geminiAPI && this.geminiAPI.isConfigured) {
            return this._geminiCorrectOriginal(text);
        }
        return { text: text, isQuestion: false }; // 최악의 경우: 교정 없음
    }
}

폴백 체인은: Groq → Gemini (구성된 경우) → 원본 텍스트 (교정 없음). 사용자는 Groq이 다운되면 약간 더 적은 교정을 볼 수 있지만, 그들은 절대 깨진 상태를 보지 않습니다. 관리 모니터링 대시보드는 Groq 통계 (총 요청, 오류, 평균 지연시간)를 보여주어 폴백이 자주 활성화되고 있음을 감지할 수 있습니다.

이중 AI 실제로 잠금 해제되는 것

Groq이 교정을 처리하고 Gemini가 깊이 작업을 처리하면, GeminiAPI의 우선순위 큐는 훨씬 덜 혼잡합니다. CORRECTION 작업 (큐 항목의 다수)은 이제 Groq의 자신의 요청 큐로 라우트됩니다. Gemini의 큐는 대부분 QA와 SUMMARY 작업을 봅니다. 실제 효과: 질문 답변이 더 빠르게 도착합니다. CORRECTION 작업이 더 이상 앞에서 줄을 서 있지 않기 때문입니다.

실제 Groq 교정 지연시간: 중앙값 ~650ms, 95 백분위수 ~1.2s. Gemini 교정 지연시간: 중앙값 ~900ms, 95 백분위수 ~2.8s. 지속적인 음성 실시간 교정의 경우, Groq 경로는 사용자에게 의미 있게 더 반응하는 경험을 제공합니다.

관리 대시보드: 프로덕션에서 이중 AI 모니터링

이중 AI 아키텍처에서 나온 더 흥미로운 기능 중 하나는 확장된 관리 대시보드였습니다. 원래 관리 페이지는 Gemini 큐 상태를 모니터링했습니다. Groq이 추가되면서, 우리는 하트비트 시스템 (앱 탭에서 BroadcastChannel로 방송)을 확장했습니다. Groq 통계를 포함하려면: grokEnabled, grokStats.totalRequests, grokStats.totalErrors, grokStats.avgLatency.

관리 페이지는 브라우저 탭에서 별도로 열 수 있고, 두 AI 시스템의 라이브 상태를 볼 수 있습니다. 긴 회의 세션에서, Groq 교정 카운트가 올라가고, Gemini QA 카운트가 올라가고, 오류율이 수용 가능한지 볼 수 있습니다. 이것은 내부 모니터링을 위해 구축되었지만 사용자 보고 문제를 디버깅하는 데 정말 유용하다는 것을 밝혔습니다.

이중 AI 접근이 부족한 곳

정직한 평가: 자유 Gemini API 키를 가진 대부분의 사용자의 경우, Groq으로 빠른 교정 모드는 아마도 두 번째 API 키를 얻고 구성하는 마찰을 정당화하지 않습니다. 교정 지연시간의 개선은 실제이지만 미묘합니다 — 대부분의 사용자는 900ms와 650ms 교정 시간의 차이를 인식하지 않을 것입니다. 기능은 장시간 다중 시간 회의를 하는 파워 사용자에게 가장 가치 있습니다. 성능 차이가 복합됩니다.

Groq API도 자유 계층에 자신의 속도 제한이 있습니다 (~분당 30개 요청), 우리는 여전히 긴 세션에 대해 프로파일링 중입니다. 현재 구현은 Groq과 Gemini 사이의 속도 제한을 조정하지 않습니다 — Groq이 속도 제한되면, 그것은 Gemini로 폴백합니다. 그것은 Gemini의 CORRECTION 할당이 갑자기 사용될 것을 의미합니다. 더 정교한 구현은 결합된 교정 속도를 추적하고 어느 것이 더 많은 여유가 있는 기반 모델 사이를 선택할 것입니다. 그것은 미래 개선입니다.

이중 AI 접근의 더 넓은 교훈: 2개 모델 아키텍처의 복잡성은 오직 2개 모델이 당신의 애플리케이션의 다양한 작업에 진정으로 다른 강점을 가질 때만 정당화됩니다. 하드웨어 가속 짧은 프롬프트 속도 (Groq/Llama) 대 깊은 추론이 긴 컨텍스트 (Gemini)는 의미 있는 차별화입니다. 만약 당신이 단지 2개 모델을 서로 핫 스탠바이로 사용한다면, 복잡성은 가치가 없습니다 — 좋은 재시도 논리가 있는 단일 모델을 사용하세요.