더 작은 오픈 소스 모델로 독점 LLM을 이기는 방법

오픈소스 중국 APP, 시작하세요! 이것은 이전에 본 적이 없는 완전히 새로운 버전입니다.”

오픈 소스 모델을 기반으로 AI 애플리케이션을 구축하면 더 좋고, 더 저렴하고, 더 빠르게 만들 수 있습니다.

Aidan Cooper의 저자인 How to Beat Proprietary LLMs With Smaller Open Source Models를 번역했습니다 .

소개

텍스트 생성 모델을 사용하는 시스템을 설계할 때 많은 사람들은 먼저 OpenAI의 GPT-4 또는 Google의 Gemini와 같은 독점 서비스로 전환합니다. 결국, 이것들은 세상에서 가장 크고 최고의 모델인데 왜 다른 것에 신경을 쓰겠습니까? 결국 애플리케이션은 이러한 API가 지원하지 않는 규모에 도달하거나 비용이 많이 들거나 응답 시간이 너무 느려집니다. 오픈 소스 모델은 이러한 모든 문제를 해결할 수 있지만 독점 LLM을 사용하는 것과 동일한 방식으로 사용하려고 하면 충분한 성능을 얻을 수 없습니다.

이 기사에서는 오픈 소스 LLM의 고유한 장점과 이를 활용하여 독점 LLM보다 저렴하고 빠를 뿐만 아니라 더 나은 AI 애플리케이션을 개발할 수 있는 방법을 살펴보겠습니다.

독점 LLM과 오픈 소스 LLM

표 1은 독점 LLM과 오픈 소스 LLM의 주요 특성을 비교합니다. 오픈 소스 LLM은 온프레미스든 클라우드든 사용자 관리 인프라에서 실행되는 것으로 생각됩니다. 요약: 독점 LLM은 관리형 서비스이며 가장 강력한 폐쇄 소스 모델과 가장 큰 컨텍스트 창을 제공하지만 오픈 소스 LLM은 다른 모든 중요한 측면에서 우수합니다.

다음은 표의 중국어 버전입니다(markdown 형식).

	독점 대형 언어 모델	오픈 소스 대규모 언어 모델
예	GPT-4 (OpenAI), Gemini (구글), Claude (Anthropic)	젬마 2B (구글), 미스트랄 7B (미스트랄 AI), 라마 3 70B (메타)
소프트웨어 접근성	비공개 소스	오픈 소스
매개변수 수	조 수준	일반적인 규모: 2B, 7B, 70B
컨텍스트 창	더 길고, 100k-1M+토큰	더 짧고 일반적인 8k-32k 토큰
능력	모든 순위표 및 벤치마크에서 최고의 성과를 냈습니다.	역사적으로 독점적인 대규모 언어 모델보다 뒤떨어져 있음
하부 구조	공급자가 관리하는 PaaS(Platform as a Service)입니다. 구성할 수 없습니다. API 속도 제한.	일반적으로 클라우드 인프라(IaaS)에서 자체 관리됩니다. 완전히 구성 가능합니다.
추론 비용	더 높은	낮추다
속도	같은 가격대에서는 더 느립니다. 조정할 수 없습니다.	인프라, 기술 및 최적화에 따라 다르지만 더 빠릅니다. 고도로 구성 가능합니다.
처리량	일반적으로 API 비율 제한이 적용됩니다.	무제한: 인프라에 따라 확장됩니다.
지연	더 높은. 여러 라운드의 대화로 인해 상당한 네트워크 대기 시간이 누적될 수 있습니다.	모델을 로컬로 실행하면 네트워크 대기 시간이 없습니다.
기능	일반적으로 API를 통해 제한된 기능 세트를 노출합니다.	모델에 직접 액세스하면 여러 가지 강력한 기술을 사용할 수 있습니다.
은닉처	서버측에 접근할 수 없습니다	처리량을 늘리고 비용을 줄이기 위해 구성 가능한 서버 측 정책.
미세 조정	제한된 미세 조정 서비스(예: OpenAI)	미세 조정을 완벽하게 제어할 수 있습니다.
프롬프트/플로우 프로젝트	높은 비용이나 요율 제한 또는 지연으로 인해 불가능한 경우가 많습니다.	제한 없이 세심하게 설계된 제어 프로세스는 부정적인 영향을 최소화합니다.

**표 1.** 독점 LLM과 오픈 소스 LLM 기능 비교

이 기사의 초점은 오픈 소스 모델의 장점을 활용하여 독점 LLM보다 더 나은 작업을 수행하는 동시에 더 나은 처리량과 비용 프로필을 달성하는 AI 애플리케이션을 구축할 수 있다는 것입니다.

우리는 독점 LLM으로는 불가능하거나 덜 효과적인 오픈 소스 모델에 대한 전략에 중점을 둘 것입니다. 즉, Few-Shot 힌트나 RAG(Retrieval-Augmented Generation)와 같이 두 가지 모두에 도움이 되는 기술은 논의하지 않을 것입니다.

효과적인 LLM 시스템 요구 사항

LLM을 중심으로 효과적인 시스템을 설계하는 방법을 고려할 때 명심해야 할 몇 가지 중요한 원칙이 있습니다.

작업 성능, 처리량 및 비용 간에는 직접적인 균형이 있습니다. 둘 중 하나를 개선하는 것은 쉽지만 일반적으로 다른 두 가지를 희생해야 합니다. 무제한의 예산이 없다면 시스템이 생존하려면 세 가지 영역 모두에서 최소 기준을 충족해야 합니다. 독점 LLM을 사용하면 삼각형의 꼭지점에 갇혀 허용 가능한 비용으로 충분한 처리량을 달성할 수 없는 경우가 많습니다.

각 문제를 해결하는 데 도움이 될 수 있는 전략을 탐색하기 전에 이러한 비기능적 요구 사항 각각의 특성을 간략하게 설명하겠습니다.

처리량

많은 LLM 시스템은 단순히 LLM이 느리기 때문에 적절한 처리량을 달성하는 데 어려움을 겪습니다.

LLM을 사용할 때 전체 시스템 처리량은 거의 전적으로 텍스트 출력을 생성하는 데 필요한 시간에 따라 결정됩니다.

데이터 처리가 특별히 무겁지 않는 한 텍스트 생성 이외의 요소는 상대적으로 중요하지 않습니다. LLM은 텍스트를 생성하는 것보다 훨씬 빠르게 텍스트를 "읽을" 수 있습니다. 이는 입력 토큰이 병렬로 계산되는 반면 출력 토큰은 순차적으로 생성되기 때문입니다.

품질 저하나 과도한 비용 발생 없이 텍스트 생성 속도를 극대화해야 합니다.

이는 처리량을 늘리는 것이 목표일 때 활용할 수 있는 두 가지 레버를 제공합니다.

생성해야 하는 토큰 수를 줄입니다.
개별 토큰 생성 속도 향상

아래 전략 중 다수는 이러한 영역 중 하나 또는 둘 다를 개선하도록 설계되었습니다.

비용

독점 LLM의 경우 입력 및 출력 토큰별로 요금이 청구됩니다. 각 토큰의 가격은 사용하는 모델의 품질(예: 크기)과 관련됩니다. 이로 인해 비용을 절감할 수 있는 옵션이 제한됩니다. 입력/출력 토큰 수를 줄이거나 더 저렴한 모델을 사용해야 합니다(선택할 항목이 너무 많지 않음).

자체 호스팅 LLM을 사용하면 비용은 인프라에 따라 결정됩니다. 호스팅을 위해 클라우드 서비스를 사용하는 경우 가상 머신을 "대여"하는 시간 단위별로 요금이 청구됩니다.

더 큰 모델에는 더 크고 더 비싼 가상 머신이 필요합니다. 하드웨어를 변경하지 않고 처리량을 늘리면 고정된 양의 데이터를 처리하는 데 필요한 컴퓨팅 시간이 줄어들기 때문에 비용이 절감됩니다. 마찬가지로 하드웨어를 수직 또는 수평으로 확장하여 처리량을 늘릴 수 있지만 이로 인해 비용이 증가합니다.

비용을 최소화하기 위한 전략은 작업에 더 작은 모델을 사용하는 데 중점을 둡니다. 이러한 모델은 처리량이 가장 높고 실행 비용이 가장 저렴하기 때문입니다.

작업 수행

임무 수행은 세 가지 요구 사항 중 가장 모호하지만 최적화 및 개선 범위가 가장 넓은 요구 사항이기도 합니다. 적절한 작업 성과를 달성하는 데 있어 주요 과제 중 하나는 이를 측정하는 것입니다. LLM 결과에 대해 신뢰할 수 있고 정량적인 평가를 올바르게 얻는 것은 어렵습니다.

우리는 오픈 소스 LLM에 고유한 이점을 제공하는 기술에 중점을 두고 있기 때문에 우리의 전략은 더 적은 리소스로 더 많은 작업을 수행하고 모델에 직접 액세스해야만 가능한 방법을 활용하는 데 중점을 둡니다.

독점 LLM을 물리치기 위한 오픈 소스 LLM 전략

다음 전략은 모두 독립적으로 효과적이지만 보완적이기도 합니다. 시스템의 비기능적 요구 사항 간의 올바른 균형을 유지하고 전체 성능을 최대화하기 위해 다양한 수준으로 적용할 수 있습니다.

다중 회전 대화 및 제어 흐름

작업 성능 향상
처리량 감소
입력당 비용 추가

광범위한 다중 턴 대화 전략을 독점 LLM과 함께 사용할 수 있지만 이러한 전략은 다음과 같은 이유로 실현 가능하지 않은 경우가 많습니다.

토큰으로 청구할 경우 비용이 많이 들 수 있음
입력당 여러 API 호출이 필요하므로 API 속도 제한이 소진될 수 있습니다.
주고받는 교환에 많은 토큰이 생성되거나 많은 네트워크 대기 시간이 누적되는 경우 너무 느릴 수 있습니다.

독점 LLM이 더 빠르고, 확장 가능하며, 저렴해짐에 따라 이러한 상황은 시간이 지남에 따라 개선될 가능성이 높습니다. 그러나 현재 독점 LLM은 실제 사용 사례에 대규모로 적용할 수 있는 단일, 단일 프롬프트 전략으로 제한되는 경우가 많습니다. 이는 독점 LLM이 제공하는 더 큰 컨텍스트 창과 일치합니다. 선호되는 전략은 종종 많은 정보와 지침을 단일 프롬프트에 밀어넣는 것입니다(그런데 비용과 속도에 부정적인 영향을 미칩니다).

자체 호스팅 모델을 사용하면 다중 라운드 대화의 이러한 단점이 덜 우려됩니다. 토큰당 비용이 덜 관련되고, API 속도 제한이 없으며 네트워크 대기 시간이 최소화될 수 있습니다. 오픈 소스 모델의 더 작은 컨텍스트 창과 약한 추론 기능으로 인해 단일 힌트를 사용할 수도 없습니다. 이는 독점 LLM을 물리치기 위한 핵심 전략을 제시합니다.

독점 LLM을 극복하는 열쇠는 더 작은 오픈 소스 모델을 사용하여 일련의 세분화된 하위 작업에서 더 많은 작업을 수행하는 것입니다.

조심스럽게 공식화된 다단계 프롬프트 전략은 지역 모델에 적합합니다. CoT( 생각의 사슬 ), ToT( 생각의 나무 ) 및 ReAct 와 같은 기술을 사용하면 성능이 떨어지는 모델이 대형 모델과 동등한 성능을 발휘할 수 있습니다.

또 다른 수준의 복잡성은 제어 흐름 및 분기를 사용하여 모델을 올바른 추론 경로에 따라 동적으로 안내하고 일부 처리 작업을 외부 기능에 오프로드하는 것입니다. 이는 기본 프롬프트 흐름 외부 분기의 하위 작업을 분기한 다음 해당 분기의 집계된 결과를 다시 결합하여 컨텍스트 창 토큰 예산을 보존하는 메커니즘으로도 사용할 수 있습니다.

지나치게 복잡한 작업으로 작은 오픈 소스 모델에 부담을 주기보다는 문제를 실행 가능한 하위 작업의 논리적 흐름으로 나누세요.

제한된 디코딩

처리량 향상
비용을 절감하다
작업 성능 향상

구조화된 출력(예: JSON 개체) 생성과 관련된 애플리케이션의 경우 제한된 디코딩은 다음을 수행할 수 있는 강력한 기술입니다.

요구되는 구조에 맞는 출력 보장
토큰 생성을 가속화하고 생성해야 하는 토큰 수를 줄여 처리량을 획기적으로 향상시킵니다.
모델을 안내하여 작업 성능 향상

나는 이 주제를 자세히 설명하는 별도의 기사를 작성했습니다. 제한된 디코딩을 사용한 구조적 생성 가이드 언어 모델 출력 생성의 방법, 이유, 기능 및 함정

결정적으로 제약 조건 디코딩은 완전한 다음 토큰 확률 분포에 대한 직접 액세스를 제공하는 텍스트 생성 모델에서만 작동하며, 이 글을 쓰는 시점에는 주요 독점 LLM 제공업체에서는 사용할 수 없습니다.

OpenAI는 JSON 스키마를 제공 하지만 이렇게 엄격하게 제한된 디코딩은 JSON 출력의 구조적 또는 처리량 이점을 보장하지 않습니다.

제약 조건 디코딩은 제어 흐름 전략과 밀접하게 연관되어 있습니다. 이를 통해 다양한 분기 옵션에 대한 응답을 제한하여 대규모 언어 모델을 미리 지정된 경로로 안정적으로 지정할 수 있습니다. 일련의 길고 여러 차례 대화 질문에 대해 짧고 제한된 답변을 생성하도록 모델에 요청하는 것은 매우 빠르고 저렴합니다. 처리 속도는 생성된 토큰 수에 따라 결정됩니다.

제약 조건 디코딩에는 주목할만한 단점이 없으므로 작업에 구조화된 출력이 필요한 경우 이를 사용해야 합니다.

캐싱, 모델 양자화 및 기타 백엔드 최적화

처리량 향상
비용을 절감하다
작업 성능에 영향을 미치지 않습니다

캐싱은 계산의 입력:출력 쌍을 저장하고 동일한 입력이 다시 발생하는 경우 결과를 재사용하여 데이터 검색 작업 속도를 높이는 기술입니다.

LLM이 아닌 시스템에서는 일반적으로 이전에 본 요청과 정확히 일치하는 요청에 캐싱이 적용됩니다. 일부 LLM 시스템은 이러한 엄격한 형태의 캐싱으로 이점을 얻을 수도 있지만 일반적으로 LLM을 사용하여 구축할 때 정확히 동일한 입력이 너무 자주 발생하는 것을 원하지 않습니다.

다행스럽게도 훨씬 더 유연한 LLM 전용의 정교한 키-값 캐싱 기술이 있습니다 . 이러한 기술은 이전에 확인된 입력과 부분적으로 일치하지만 정확히 일치하지 않는 요청에 대한 텍스트 생성 속도를 크게 높일 수 있습니다. 이는 생성해야 하는 토큰의 양을 줄여서(또는 특정 캐싱 기술 및 시나리오에 따라 최소한 속도를 높여서) 시스템 처리량을 향상시킵니다.

독점 LLM을 사용하면 요청에 대해 캐싱이 수행되거나 수행되지 않는 방식을 제어할 수 없습니다. 그러나 오픈 소스 LLM의 경우 추론 처리량을 크게 향상시키고 시스템의 맞춤형 요구 사항에 따라 구성할 수 있는 LLM 서비스용 다양한 백엔드 프레임워크가 있습니다.

캐싱 외에도 모델 양자화 와 같은 추론 처리량을 향상시키는 데 사용할 수 있는 다른 LLM 최적화가 있습니다 . 모델 가중치에 사용되는 정밀도를 줄임으로써 출력 품질을 크게 저하시키지 않고 모델 크기(따라서 메모리 요구 사항)를 줄일 수 있습니다. 인기 모델에는 오픈 소스 커뮤니티에서 제공하는 Hugging Face에서 사용할 수 있는 다수의 양자화된 변형이 있는 경우가 많으므로 양자화 프로세스를 직접 수행할 필요가 없습니다.

SGLang의 놀라운 처리량 발표(SGLang 릴리스 블로그 게시물 참조)

vLLM은 아마도 다양한 캐싱 메커니즘, 병렬화, 커널 최적화 및 모델 양자화 방법을 갖춘 가장 성숙한 서비스 프레임워크일 것입니다. SGLang은 vLLM과 유사한 기능은 물론 특히 인상적인 성능을 주장하는 혁신적인 RadixAttention 캐싱 방법을 갖춘 최신 플레이어입니다.

모델을 자체 호스팅하는 경우 처리량을 최소한 10배 이상 향상시킬 수 있다고 합리적으로 기대할 수 있으므로 이러한 프레임워크와 최적화 기술을 사용하는 것이 좋습니다.

모델 미세 조정 및 지식 증류

작업 실행 효율성 향상
추론 비용에 영향을 미치지 않습니다.
처리량에 영향을 미치지 않습니다.

미세 조정에는 특정 작업에서 더 나은 성능을 발휘하도록 기존 모델을 조정하는 다양한 기술이 포함됩니다. 주제에 대한 입문서로서 미세 조정 방법에 대한 Sebastian Raschka의 블로그 게시물을 확인하는 것이 좋습니다 . 지식 증류는 관심 있는 작업에 대해 더 큰 "교사" 모델의 출력을 시뮬레이션하기 위해 더 작은 "학생" 모델을 훈련시키는 관련 개념입니다.

OpenAI를 포함한 일부 독점 LLM 제공업체는 최소한의 미세 조정 기능을 제공합니다. 그러나 오픈 소스 모델만이 미세 조정 프로세스에 대한 완전한 제어와 포괄적인 미세 조정 기술에 대한 액세스를 제공합니다.

모델을 미세 조정하면 추론 비용이나 처리량에 영향을 주지 않고 작업 성능을 크게 향상시킬 수 있습니다. 그러나 미세 조정을 구현하려면 시간, 기술, 좋은 데이터가 필요하며 훈련 프로세스에는 비용이 듭니다. LoRA 와 같은 PEFT( Parameter Efficient Fine-Tuning ) 기술은 필요한 리소스 양에 비해 가장 높은 성능 수익을 제공하기 때문에 특히 매력적입니다.

미세 조정 및 지식 증류는 모델 성능을 최대화하는 가장 강력한 기술 중 하나입니다. 올바르게 구현되는 한, 실행에 필요한 초기 초기 투자를 제외하고는 단점이 없습니다. 그러나 큐 흐름 및 제한된 디코딩 출력 구조와 같은 시스템의 다른 측면과 일치하는 방식으로 미세 조정이 수행되도록 주의해야 합니다. 이러한 기술 간에 차이가 있는 경우 예기치 않은 동작이 발생할 수 있습니다.

모델 크기 최적화

소형 모델:

처리량 향상
비용을 절감하다
작업 실행 성능 저하

이것은 정반대의 장점과 단점을 지닌 "더 큰 모델"이라고 동일하게 말할 수 있습니다. 핵심 사항은 다음과 같습니다.

모델을 가능한 한 작게 만들되 작업을 안정적으로 이해하고 완료할 수 있는 충분한 용량을 유지하세요.

대부분의 독점 LLM 제공업체는 일부 모델 크기/능력 계층을 제공합니다. 그리고 오픈 소스의 경우 최대 100B개 이상의 매개변수까지 원하는 모든 크기의 어지러운 모델 옵션이 있습니다.

다중 턴 대화 섹션에서 언급했듯이 복잡한 작업을 보다 관리하기 쉬운 일련의 하위 작업으로 나누어 단순화할 수 있습니다. 그러나 더 이상 세분화할 수 없거나 그렇게 하면 더 완전하게 해결해야 하는 임무 측면이 손상될 수 있는 문제가 항상 존재합니다. 이는 사용 사례에 따라 크게 다르지만 가장 작은 모델 크기에서 적절한 작업 성능을 달성하는 것으로 표시된 것처럼 작업 세분성과 복잡성은 모델의 올바른 크기를 결정하는 가장 좋은 지점을 갖습니다.

일부 작업의 경우 이는 찾을 수 있는 가장 크고 가장 유능한 모델을 사용하는 것을 의미하며, 다른 작업의 경우 매우 작은 모델(LLM이 아닌 경우에도)을 사용할 수 있습니다.

어떤 경우든 주어진 매개변수 크기에서 동급 최고의 모델을 사용하도록 선택하십시오. 이는 해당 분야의 빠른 개발 속도에 따라 정기적으로 변경되는 공개 벤치마크 및 순위를 참조하여 확인할 수 있습니다 . 일부 벤치마크는 다른 벤치마크보다 사용 사례에 더 적합하므로 어떤 벤치마크가 가장 적합한지 알아내는 것이 좋습니다.

하지만 단순히 새로운 최고 모델을 교체하고 즉각적인 성능 향상을 달성할 수 있다고 생각하지 마십시오. 모델마다 고장 모드와 특성이 다르기 때문에 한 모델에 최적화된 시스템이 다른 모델에도 반드시 작동하는 것은 아닙니다.

기술 로드맵

앞서 언급했듯이 이러한 모든 전략은 상호 보완적이며 함께 결합되면 강력하고 포괄적인 시스템을 생성합니다. 그러나 이러한 기술 간에는 종속성이 있으므로 기능 장애를 방지하려면 일관성을 유지하는 것이 중요합니다.

다음 그림은 이러한 기술을 구현하기 위한 논리적 순서를 보여주는 종속성 다이어그램입니다. 이는 사용 사례에 구조화된 출력 생성이 필요하다고 가정합니다.

이러한 단계는 다음과 같이 이해될 수 있습니다.

대상 데이터 모델은 생성하려는 최종 출력입니다. 이는 사용 사례와 텍스트 처리 생성을 넘어 전체 시스템의 광범위한 요구 사항에 따라 결정됩니다.
제한된 디코딩 출력 구조는 대상 데이터 모델과 동일할 수도 있고 제한된 디코딩 중에 최적의 성능을 위해 약간 수정될 수도 있습니다. 왜 이런 일이 발생하는지 이해하려면 제한된 디코딩 기사를 참조하세요 . 다를 경우 최종 대상 데이터 모델로 변환하기 위한 후처리 단계가 필요합니다.
귀하의 사용 사례에 맞는 올바른 프롬프트 전략에 대해 초기에 최선의 추측을 해야 합니다. 문제가 단순하거나 직관적으로 분류할 수 없는 경우 단일 프롬프트 전략을 선택합니다. 세부적인 하위 구성 요소가 많아 문제가 매우 복잡한 경우 다중 프롬프트 전략을 선택합니다.
초기 모델 선택은 주로 크기를 최적화하고 모델 속성이 문제의 기능적 요구 사항을 충족하는지 확인하는 문제입니다. 최적의 모델 크기는 위에서 논의되었습니다. 필요한 컨텍스트 창 길이와 같은 모델 속성은 예상되는 출력 구조((1) 및 (2))와 프롬프트 전략(3)을 기반으로 계산할 수 있습니다.
모델 미세 조정에 사용되는 훈련 데이터는 출력 구조(2)와 일치해야 합니다. 단계별로 출력을 구축하는 다중 큐 전략을 사용하는 경우 훈련 데이터는 이 프로세스의 각 단계도 반영해야 합니다.
모델 미세 조정/추출은 당연히 모델 선택, 교육 데이터 선별 및 신속한 흐름에 따라 달라집니다.
미세 조정된 모델의 양자화는 선택 사항입니다. 정량화 옵션은 선택한 기본 모델에 따라 달라집니다.
LLM 추론 서버는 특정 모델 아키텍처와 양자화 방법만 지원하므로 이전 선택 사항이 원하는 백엔드 구성과 호환되는지 확인하세요.
엔드투엔드 시스템이 구축되면 지속적인 개선을 위한 피드백 루프를 생성할 수 있습니다. 시스템이 허용 가능한 출력을 생성하지 못하는 예를 설명하기 위해 프롬프트와 몇 장의 예(사용하는 경우)를 정기적으로 조정해야 합니다. 합리적인 실패 사례 샘플을 축적한 후에는 이러한 샘플을 사용하여 추가 모델 미세 조정을 수행하는 것도 고려해야 합니다.

실제로 개발 프로세스는 완전히 선형적이지 않으며 사용 사례에 따라 이러한 구성 요소 중 일부를 다른 구성 요소보다 최적화하는 데 우선 순위를 두어야 할 수도 있습니다. 그러나 이는 특정 요구 사항에 따라 로드맵을 설계하는 합리적인 기반입니다.

결론적으로

오픈 소스 모델은 독점 LLM보다 빠르고 저렴하며 우수할 수 있습니다. 이는 오픈 소스 모델의 고유한 장점을 활용하고 처리량, 비용 및 임무 성능 간에 적절한 균형을 이루는 보다 복잡한 시스템을 설계함으로써 달성할 수 있습니다.

이 디자인 선택은 전체 성능을 위해 시스템 복잡성을 교환합니다. 유효한 대안은 독점 LLM으로 구동되는 더 간단하고 동일하게 강력한 시스템을 보유하는 것입니다. 하지만 비용은 더 높고 처리량은 더 낮습니다. 올바른 결정은 애플리케이션, 예산, 엔지니어링 리소스 가용성에 따라 달라집니다.

하지만 오픈 소스 모델을 수용할 수 있도록 기술 전략을 조정하지 않고 너무 빨리 포기하지 마십시오. 이러한 모델의 기능에 놀랄 수도 있습니다.

이 기사는 Yunyunzhongsheng ( https://yylives.cc/ ) 에 처음 게재되었습니다 . 누구나 방문하실 수 있습니다.