LLM 프로젝트에 진행함에 있어서 가장 중요한 부분이라고 할 수 있는 "적절한 LLM모델 선택하기" 에 대해 이야기해보려고 한다.
1. 라이센스
모델의 사용범위나 제약조건을 명확히 평가해야한다. 이를 통해 프젝트의 목표와 정합성을 평가해야한다.
예를들어 특정 라이센서의 경우 상업적 용도를 제한하거나 모델 수정을 금지하고있다.
때문에 라이선스 조건을 검토애서 프로젝트 요구사항에 맞는 모델을 선택해야한다.
일반적으로 모델의 라이센스를 확인하는방법은 다음과 같다
(1) 모델 카드 확인 - 허깅페이스, 깃허브, 모델 레지스트리 등에서 라이센스 항목을 확인할 수 있다.
다음은 비교적 많이 사용되는 라이센스를 정리한 표의 내용이다.
| 라이선스 | 제약조건 | 주요 필수사항 | 주요 허용사항 |
| Apache License | 하 | • 라이선스 및 저작권 명시 • 변경사항 안내 |
• 상업적 이용 가능 • 2차 라이선스 |
| GPL v2.0/v3.0 | 상 | • 소스코드 GPL로 공개 • 라이선스 및 저작권 명시 |
• 상업적 이용 가능 • 수정 가능 |
| GNU AGPL v3.0 | 최상 | • 소스코드 AGPL로 공개 • 네트워크상 사용자에게 소스코드 공개 |
• 상업적 이용 가능 • 수정 가능 |
| GNU LGPL v2.1/v3.0 | 중 | • 수정한 소스코드 LGPL로 공개 • 라이선스 및 저작권 명시 |
• 상업적 이용 가능 • 2차 라이선스 |
| MIT License | 하 | • 라이선스 및 저작권 명시 | • 상업적 이용 가능 • 2차 라이선스 |
| Artistic License | 하 | • 라이선스 및 저작권 명시 • 변경사항 안내 |
• 상업적 이용 가능 • 2차 라이선스 |
| Eclipse License | 중 | • 수정한 소스코드 Eclipse로 공개 • 라이선스 및 저작권 명시 |
• 상업적 이용 가능 • 2차 라이선스 |
| BSD License | 하 | • 라이선스 및 저작권 명시 | • 상업적 이용 가능 • 2차 라이선스 |
| MPL v2.0 | 중 | • 수정한 소스코드 MPL로 공개 • 라이선스 및 저작권 명시 |
• 상업적 이용 가능 • 2차 라이선스 |
(출처 : https://okky.kr/articles/450248)
2. 기술수준
기술 역량과 LLM활용 경험을 고려해서 모델을 선택해야한다. 기술수준이 낮은경우네는 사용성이 편하고 직권적인 인터페이스를 제공하는 모델을 우선적으로 고려해야한다. 반대로 LLM에 대한 높은 이해도를 가지고 고급 기능을 활용하고자 하는 경우 다양한 커스터마이징 옵션을 제공하는 모델을 선택한다. 이때 반드시 "모델"이라고 생각할 필요는 없다. 초급수준에서는 "모델"보다는 적합한 "솔루션"을 선택하는것이 도움이 될 수 있다.
| 기술수준 | 고려사항 | 추천 | 주요특징 | 활용사례 |
| 초급 | 사용 편의성, 직관적 인터페이스 | 노코드/로우코드 솔루션 | • 단순한 UI/UX • 템플릿 기반 활용 • 최소한의 설정 옵션 • 가이드 문서 충실 |
• 간단한 챗봇 • 기본 콘텐츠 생성 • 데이터 요약 |
| 중급 | 기본 커스터마이징, 확장성 | API 기반 서비스 | • 기본 프롬프트 엔지니어링 • 일부 파라미터 조정 가능 • 통합 가이드 제공 • 중간 수준의 기술 지원 |
• 맞춤형 콘텐츠 생성 • 데이터 분석 보조 • 간단한 업무 자동화 |
| 고급 | 다양한 커스터마이징, 고급 기능 | 오픈소스/자체 호스팅 가능 모델 | • 상세한 파라미터 조정 • 모델 파인튜닝 가능 • 고급 프롬프트 엔지니어링 • API 완전 통합 • 자체 인프라 운영 |
• 복잡한 워크플로우 통합 • 맞춤형 AI 솔루션 개발 • 대규모 데이터 처리 |
(1) 초급 단계에서 활용할만한 노코드/로우코드 솔루션은 "Flowise"를 추천한다. (https://flowiseai.com/)
다음과 같이 블록기반의 워크플로우 구성을 간단하게 진행할 수 있다.'
(2) 중급 단계에서 추천할만한 서비스는
1. OpenAI의 GPT시리즈 API와 (https://openai.com/index/openai-api/)
2. Anthropic의 Claude모델 API 그리고 (https://www.anthropic.com/api)
3. Google CloudPlatform의 Gemini 정도가 있다. (https://ai.google.dev/gemini-api)
(3) 고급단계에서 추천할 만한 서비스는
기본적으로 Open모델을 사용한다. (2)와의 차이점은 직접 모델을 호스팅한다는 정도이며 프레임워크만 간단히 소개하고 추후 서술하겠다.
1. 워크플로우 구축 부분
- LangChain과 LangGraph를 활용하여 워크플로우를 비교적 쉽게 구축할 수 있다. 인터페이스가 이미 다 준비되어있기때문에 라이브러리만 활용하여 비교적 쉽게 구축이 가능하다.
- 비슷한 서비스로 LlamaIndex가 있다. LangChain & Graph가 애플리케이션 파이프라인, 즉 워크플로우에 집중되어있다면 LlamaIndex는 워크플로우를 하나하나 구성하는 컴포넌트 자체가 강력한 느낌이다.
- 이외에 Apache Airflow를 많이 사용하는것 같다. 가장 큰 장점은 워크플로우(DAG)의 모든 부분을 커스터마이징이 가능하다는점이다.
2. 모델 서빙 부분
모델 서빙부분에서는 일반적으로 "효율성"을 따지기때문에 이부분을 고려하여 적절한 서비스를 선택해야한다.
- 일반적으로는 vLLM을 많이 활용한다. 구성이 쉽고 OpenAI Compatible Server로 쉽게 운영이 가능해서 그런듯
Paged Attention을 지원한다. Paged Attention은 추후 서술하도록 하겠다.
- 두번째로 많이 사용하는것은 SGLang이다.
모델 서빙에 있어서 빼놓을 수 없는것이 레이턴시, TTFT, 쓰루풋인데 압도적으로 빠른 수준이다.
단점으로는 프로젝트명과 같이 Language이므로 백엔드/프론트 구현방법이 정해져있다. 이부분에 대해서 다른 파이썬프로젝트들과 호환이 안되므로 공수가 많이 들어갈 수 있다. (OpenAI Compatible, LangChain등 활용 불가능)
프롬프트 관련해서는 이후 서술하도록 하겠다.
3. 출력 품질
모델의 생성 능력, 정확도, 문맥 이해도 등을 평가하고 요구사항에 부합하는 출력 품질을 제공하는 모델을 선택한다.
"무조건 성능이 좋은 모델"을 선택하라는것이 아니며 적합한 모델을 선택하는것이 키 포인트이다.
일반적으로 파라미터 수가 증가되면 성능이 향상된다.
파라미터수가 많을수록 3B, 7b, 13B, 70B, 170B등 더 복잡한 패턴을 학습하였기때문에 더 높은 품질의 텍스트가 생성된다. API기반의 서비스의 경우 대부분 SOTA급의 퍼포먼스를 가지고있기때문에, 대형모델로 분류되어 일반적인 태스크를 처리하는데 문제가 없다.
아래는 본인이 생각하는 모델성능 예시이다.
- 소형모델 : 1-6B모델을 말한다. SLM, sLM, sLLM등으로도 불리운다. 간단한 텍스트 완성이 가능하고 기본적인 질문 응답이 가능하다.
- 중형모델 : 7B-13B모델을 말한다. 이 모델부터 복잡한 지시나 상세한 응답등이 가능하고 맥락유지가 가능하다. 하지만 실제로 활용하기에는 파인튜닝이 필수라고 생각된다
- 대형모델: 70B이상의 모델을 말한다. 미묘한 뉘앙스나 복잡한 추론 등이 가능하다.
물론 모델 크기만으로 출력품질이 결정되지는 않고 정제기법등이 실제로 사용자의 경험면에서는 영향이 크다고 할 수 있겠다.
(RLHF, DPO, SFT는 시간나면 작성해보는것으로)
추가적으로 Reasoning모델 (Time Scale Model)의 경우는 제외하였으나 Distill 모델의 경우 중형모델에서도 복잡한 추론등이 어느정도는 가능하다. 하지만 그만큼 추론시간이 증가하게 되므로, 복잡한 추론등이 필요한 워크플로우에만 사용하는것이 좋다.
출력 품질에 직접적인 영향을 미치는 요소는 모델 추론 파라미터에도 존재하는데 컨텍스트길이, 온도등이 있다.
4. 컨텍스트 윈도우
처리 가능한 텍스트 길이를 고려해서 필요한 컨텍스트 사이즈를 충족하는 모델을 선택해야한다.
긴 텍스트를 처리해야하는경우 충분한 크기의 컨텍스트 윈도우를 가진 모델을 선택해야한다.
간혹 동일한 모델 내에서도 컨텍스트 윈도우 사이즈가 다른 모델이 있다. 모델에 들어가는 컨텍스트가 길면 이를 정확히 활용하는것들이 어려워지는데, 이런 모델같은경우는 "긴 컨텍스트"를 유지하면서 "짧은 작업"을 처리할 수 있도록 설계되어있다.
보통 모델에서 Token수를 따로 표기하는경우가 대부분.
 |
 |
(https://huggingface.co/Qwen/Qwen2.5-14B-Instruct-1M)
5. 지연시간
모델의 응답속도가 중요한 애플리케이션들이 있다. 보통 실시간 처리를 요구하거나 대화형 애플리케이션에 사용되는 케이스이다.
지연시간은 모델이 입력에대해 응답하는 시간을 나타낸다. 일반적으로 Streaming형식으로 사용자에게 제공되므로 TTFT, 쓰루풋이 중요하다.
(1) TTFT (Time To First Token)
- AI모델이 입력을 받은 이후에 첫번째 토큰을 출력하기까지 걸리는 시간이다. 사용자의 체감부분에 직접적으로 연관되어있다.
- 대화형 애플리케이션에서 가장 중요한 지표로 낮은 TTFT가 사용자의 경험을 크게 향상시킬 수 있다.
- 일반적으로 대화형 애플리케이션에서 TTFT는 0.5초(500ms)이하로 동작해야하며, 이보다 긴 경우 사용자는 시스템에 문제가 생겼다(응답하지 않는다)라고 느낄 수 있다.
(2) Throughput
- 쓰루풋은 단위시간당 처리할 수 있는 양을 의미하며 보통 Token per second (TPS)로 측정한다.
- TTFT가 첫 토큰을 생성하는데 초점이 맞춰져있다면, 쓰루풋은 이후 얼마나 빠른속도로 토큰을 생성하는지와 관계있다.
- 특히 긴 출력이 필요한 작업에 중요하다. (코드나 문서 요약 등)
- 평균적인 사람의 말하기 속도는 "단어"기준이긴 하지만 초당 2.5단어 정도이다.
- 따라서 텍스트 생성속도는 최소 10~10TPS정도는 되어야하며, 이상적인 속도는 40~60TPS이다.
- 영어기준으로 1토큰은 5자정도이며, 한국어는 2자정도에 해당된다.
이 지연시간은 직접 측정할수도 있으며, 위에서 서술한 프레임워크에서는 지연시간을 테스트할 수 있도록 제공하고있다.
SGLang이 선호되는것도 이 지연시간 측면에서 유리한것들이 많기때문이다.
또한 API형태로 제공되는 모델의 경우에는 다음 웹서비스를 활용하면 이 지연시간에 대해 확인할 수 있다. (https://artificialanalysis.ai/)
6. 예산
모델 구축이나 운영비용을 고려하여 예산 제약 조건내에서 최적의 모델을 선택해야한다.
일반적으로 모델이 클수록, 사용량이 높을수록, 기능이 많을수록 비용이 높게 측정되며(GPU 리소스 측면)
API를 활용할경우에는 모델성능이 높을수록 일반적으로 토큰당 비용이 증가한다. 다른 프로바이더끼리는 제외.
일반적으로 모델 프로바이더 홈페이지나 Pricing Document에서 확인이 가능하다.
GPU의 경우, 모델을 선택하고 해당 모델을 돌리기 위한 컴퓨트 머신을 구축해야하는데, 일반적으로 고려해야하는것은 TFLOPS, VRAM이다.
테라플롭스의 경우 모델의 생성 속도에 관계가 있고 VRAM의 경우 모델 자체를 탑재할 수 있는가에 대한 제약사항이 된다.
내가 가지고 있는 GPU로 특정 LLM 돌릴 수 있는가? 에 대한 내용으로는 다음 계산식을 활용한다.
(모델의 가중치 메모리 크기) + (모델의 가중치 메모리 크기 * 0.3) <= GPU의 VRAM 크기
멀티 GPU를 활용하여 부족한 VRAM을 공유메모리로 활용하는 방법도 있고, 양자화된 모델을 활용하여 Precision을 줄이고 높은 성능의 모델을 활용할 수도 있다. 이 내용은 단독으로 다뤄야 할 정도로 중요한 내용이므로 기회가 되면 소개하도록 하겠다.
이부분에 대해서 쉽게 계산해주는 웹서비스도 있다. (https://huggingface.co/spaces/Vokturz/can-it-run-llm)
사용하고 있는 GPU정보와, HuggingFace의 모델카드를 입력하면 자동으로 계산해준다. (양자화 모델까지도)
7. 처리해야하는 데이터 형식
만약 LLM 애플리케이션 파이프라인에서 텍스트 이외에 코드나 이미지 등 다양한 데이터 형식을 처리할 수 있어야 한다면 멀티모달 모델을 고려해야한다.
일반적으로 중급 이상 모델이나 API로 제공되는 모델의 경우 대부분이 멀티모달이라 여러타입의 데이터를 처리할 수 있지만 그렇지 않은경우도 있기때문에 반드시 한번은 확인해야한다.
만약 텍스트만 처리 가능한 모델을 활용하는데, 여러 형식을 처리할 수 있어야 하는경우, 이미지의 경우 Description을 추출하여 입력을 하는 구조를 추가하거나, CSV, Table데이터의 경우에는 마크다운 텍스트 테이블형태로 변환하여 넣어야 할 수 있다.
이경우에는 Docling을 추천한다. Docling을 활용하면 사용자의 파일입력에 대해 (HWP 제외) 마크다운 혹은 docstag형식의 텍스트로 간단하게 변환해준다. (내부적으로 VL모델과 소형 모델을 활용하는 듯 하다.)
 |
<!-- image --> ## Docling Technical Report Version 1.0 Christoph Auer Maksym Lysak Ahmed Nassar Michele Dolfi Nikolaos Livathinos Panos Vagenas Cesar Berrospi Ramis Matteo Omenetti Fabian Lindlbauer Kasper Dinkla Lokesh Mishra Yusik Kim Shubham Gupta Rafael Teixeira de Lima Valery Weber Lucas Morin Ingmar Meijer Viktor Kuropiatnyk Peter W. J. Staar AI4K Group, IBM Research R¨ uschlikon, Switzerland ## Abstract This technical report introduces Docling , an easy to use, self-contained, MITlicensed open-source package for PDF document conversion. It is powered by state-of-the-art specialized AI models for layout analysis (DocLayNet) and table structure recognition (TableFormer), and runs efficiently on commodity hardware in a small resource budget. The code interface allows for easy extensibility and addition of new features and models. |
본 내용에서는 모델만을 다루므로 여기까지만 간단하게 소개하겠다.
8. 벤치마크
개인적으로, LLM이 일반적으로 태스크를 처리하는 부분에 있어서 상향평준화 되어있기 때문에 벤치마크 점수가 중요한가 싶기도 하다.
예를들어, 코딩관련한 애플리케이션을 만드는경우에는 SWE라는 절대적인 소프트웨어 엔지니어링 벤치가 있지만 이것이 100%라고는 생각하지 않는다. (개인적인 생각이다.)
Aier의 코드 편집 리더보드에 따르면 코드 단일 편집에 대해서는 OpenAi의 o1모델이 정확하게 완료한 비율이 84.2%에 달하지만 실질적으로 코드는 단일 편집기능보다는 전체적으로 애플리케이션이 동작되는것이 중요하므로 색다른 접근법이 필요하다.
대표적인 예로 Aider의 다국어 리더보드가 있다. (https://aider.chat/docs/leaderboards/) 여기서 다국어는 다수의 프로그래밍 랭귀지를 말한다. 다음과 같이 리더보드를 소개하고있다.
- 225개 코딩 연습을 완료하기 위해 소스 파일을 편집하도록 요구한다.
- 여기에는 C++, Go, Java, JavaScript, Python 및 Rust와 같은 많은 인기 있는 프로그래밍 언어로 된 연습이 포함된다.
- 225개 연습은 LLM에게 강력한 코딩 도전을 제공하기 위해 Exercism이 해당 언어로 제공하는 가장 어려운 연습으로 의도적으로 선택되었다.
때문에 자신의 애플리케이션에 적용할 수 있는 의미있는 리더보드를 탐색후에 적절한 모델을 찾아보는것이 오히려 도움이 될 수 있다.
모델 선택부분에 있어서 더 떠오르는것들이 있다면 추가하도록 하겠다.
'LLM' 카테고리의 다른 글
| LangGraph를 활용하여 Agentic Pattern 구현하기 (1) | 2025.05.13 |
|---|---|
| RAG 구축에 있어서 고려해야 할 점들 (0) | 2025.05.07 |
