모델선정 최적화 - 100-hours-a-week/3-team-ssammu-wiki GitHub Wiki

AI 모델 추론 성능 최적화

1. 개요

AI 기반 커리어 탐색 서비스의 핵심 기능인 CS 면접 답변에 대한 피드백 생성에서 모델의 추론 성능 최적화는 필수적임. AI 모델의 추론 성능 분석을 통해 병목 요소를 파악하고, 해당 서비스에 적합한 최적화 기법을 어떻게 적용할 것인지 계획을 설명하려고 함.

2. 모델 성능 비교

모델명 Hugging Face 경로 속도 (tokens/sec) VRAM 사용량 (MB)
DeepSeek-V2 Chat 7B deepseek-ai/DeepSeek-V2-Chat - -
Qwen2.5-7B-Instruct Qwen/Qwen2.5-7B-Instruct 18.68 5564.99
Mistral-7B-Instruct-v0.3 mistralai/Mistral-7B-Instruct-v0.3 19.03 4496.57
LLaMA-3-8B Instruct meta-llama/Meta-Llama-3-8B-instruct 18.638 6047.93
Llama-2-ko-7b-Chat kfkas/Llama-2-ko-7b-Chat 27.11 13720.25
gemma-2-9b-it google/gemma-2-9b-it 10.17 6867.19
gemma-ko-7b beomi/gemma-ko-7b 27.61 17083.89
KoAlpaca Polyglot 12.8B beomi/KoAlpaca-Polyglot-12.8B 20.62 7706.31

2-1. GPT Evaluator

LLM의 성능은 단순한 정확도나 속도만으로는 충분히 평가할 수 없음. 특히 CS 면접 피드백 생성 서비스에서는 모델의 답변이 얼마나 질문 의도에 부합하고, 현실적인 조언을 담고 있으며, 자연스럽고 논리적인 문장으로 구성되어 있는지가 매우 중요함.

하지만 기존의 BLEU, ROUGE와 같은 텍스트 유사도 기반 평가지표는:

  • 단답형 응답에 유리하고,
  • 창의적인 문장 구조나 표현을 오히려 패널티로 간주할 수 있으며,
  • 실무적 조언이나 문맥 이해력 등을 정확히 반영하지 못하는 한계가 있음.

AI 모델의 응답 품질은 단순한 문장 생성 능력 그 이상으로, 질문에 맞는 적절한 정보 전달, 문맥 이해, 실무 활용성, 문법적 자연스러움 등 다양한 요소가 복합적으로 작용하기 때문에 GPT 평가 모델(OpenAI GPT-4)를 활용하여 모델이 생성한 응답을 실제 사람처럼 평가하도록 구성함.

항목 설명
정확성 및 논리성 답변이 사실에 기반하며, 논리적인 흐름으로 전개되는가? 기술 개념에 오류나 비약은 없는가?
문맥 및 질문 적합성 질문의 의도를 제대로 이해하고, 그에 맞는 핵심 내용을 포함하고 있는가? 질문과 어긋난 답변은 없는가?
표현력 및 언어 자연스러움 문장이 매끄럽고 가독성이 높으며, 문법이나 어휘 선택이 자연스러운가? 전문성을 해치지 않으면서도 전달이 쉬운가?
실무 적합성 및 구체성 실무에 직접 활용 가능한 통찰이나 조언이 포함되어 있는가? 이론에 그치지 않고 실질적인 내용이 있는가?

2-2. 모델 선정 기준 및 통합 스코어

  • 평가 항목
항목 설명 중요도
응답 품질 GPT 기반 평가 40% (가중치 0.4)
추론 속도 모델이 얼마나 빠르게 tokens/sec를 처리하는지 20% (0.2)
VRAM 효율 GPU 메모리 사용량이 낮을수록 좋음 20% (0.2)
비용 효율 동일 시간 기준 실제 GPU 비용이 낮을수록 유리함 20% (0.2)

  • 응답 품질 (GPT 평가 기준)

  • 속도 (tokens/sec)

  • VRAM 효율 (메모리 사용량 낮을수록 높게 평가)

  • GPU 비용 효율 (시간당 GPU 단가 기준)

    • GPU 비용 기준표

      VRAM 조건 GPU 종류 시간당 비용 (USD)
      ≤ 16 GB T4 $0.4
      ≤ 24 GB L4 $1.2
      ≤ 40 GB A100 $3.0
      > 40 GB H100 $
      모델명 VRAM 사용 (GB) GPU 비용 ($/h)
      Gemma-ko-7B 16.68 1.2
      Llama-2-ko-7b-Chat 13.40 0.4
      Mistral-7B-Instruct-v0.3 4.39 0.4
      Qwen2.5-7B-Instruct 5.43 0.4
      KoAlpaca-Polyglot-12.8B 7.53 0.4
      Meta-LLaMA-3-8B-Instruct 5.91 0.4

  • 정규화 및 통합 스코어 산정 방법

    각 항목에 대해 모델별 점수를 최소~최대 기준으로 정규화(min-max normalization) 한 후, 정해진 가중치를 곱하여 최종 통합 스코어를 계산하였다.

  • 통합 평가 결과

image

모델명 응답 품질 속도 VRAM 효율 비용 효율 통합 스코어
Qwen2.5-7B-Instruct 1.000 0.050 0.915 1.000 0.793
Mistral-7B-Instruct-v0.3 0.853 0.011 1.000 1.000 0.743
Meta-LLaMA-3-8B-Instruct 0.890 0.000 0.877 1.000 0.731
Llama-2-ko-7b-Chat 0.282 0.976 0.267 1.000 0.561
KoAlpaca-12.8B 0.000 0.223 0.745 1.000 0.394
Gemma-ko-7B 0.288 1.000 0.000 0.000 0.351

3. 최종 선정 모델

모델명 응답 품질 속도 VRAM 효율 비용 효율 통합 스코어
Qwen2.5-7B-Instruct 1.000 0.050 0.915 1.000 0.793
Mistral-7B-Instruct-v0.3 0.853 0.011 1.000 1.000 0.743
Meta-LLaMA-3-8B-Instruct 0.890 0.000 0.877 1.000 0.731

모델 통합 평가 결과에서 Qwen2.5-7B-Instruct가 가장 높은 스코어(0.793)를 기록하였으나, 실제 서비스 환경에서의 안정성, 최적화 호환성, 운영 신뢰성, 커스터마이징 가능성 등을 종합적으로 고려한 결과, 최종적으로 Mistral-7B-Instruct-v0.3이 가장 적합한 모델로 선정되었다.

  • Qwen2.5-7B의 한계

    Qwen2.5-7B는 응답 품질이 매우 높고 비용 효율성도 우수하지만, 다음과 같은 실질적인 문제점으로 인해 실시간 서비스 적용에는 제약이 존재한다:

    • Tokenizer 충돌 및 vLLM 비호환: Qwen은 Hugging Face 표준 tokenizer가 아닌 custom tokenizer를 사용하며, vLLM에서 decode 충돌, 문장 깨짐 등의 현상이 다수 보고됨.
    • FlashAttention 호환성 미흡: 일부 버전만 FlashAttention을 제한적으로 지원하며, 공식적으로 FlashAttention2를 내장한 구조는 아님 → 추론 최적화에 불리함.
    • GPTQ 적용 시 문제 발생: Qwen GPTQ 양자화 버전 일부에서 로딩 오류 및 정확도 저하 문제가 보고되며, Hugging Face에서 공식적으로 안정적인 GPTQ 포맷이 부족함.
    • LoRA 적용 범위가 좁음: LoRA 적용 시 사용 가능한 레이어가 제한적이며, PEFT 라이브러리와의 호환성이 Mistral에 비해 낮음.

    이러한 문제들로 인해 Qwen은 실험용 성능 기준에서는 매우 우수하더라도, 운영 환경에서 수백 개 요청을 동시에 처리하고, 최적화 기법을 조합해야 하는 실시간 서비스에는 불안정 요소가 큼.

  • 선정된 모델 : Mistral-7B-Instruct-v0.3

    Mistral은 성능 자체는 Qwen보다 약간 낮지만, 서비스에 직접 도입 가능한 수준의 기술적 안정성과 최적화 호환성을 기반으로 다음과 같은 결정적인 이유로 최종 선정됨:

    1. vLLM 완전 호환 + 안정적 병렬 처리
    • tokenizer 구조가 Hugging Face 표준에 부합하여 decode 충돌 없음.
    • vLLM 기반 추론 시 수십~수백 개 요청을 안전하게 병렬 처리 가능 → 실시간 서비스 운영 적합
    1. FlashAttention2 내장
    • 모델 구조 자체가 FlashAttention2를 내장하고 있어 긴 입력 길이에서도 속도 저하 최소화
    • 추가 커스터마이징 없이도 vLLM, transformers에서 바로 적용됨.
    1. GPTQ, LoRA 등 최적화 적용성 우수
    • GPTQ 기반 INT4 양자화 시 정확도 손실이 적고 로딩 오류 없음 (TheBloke 등 안정 배포)
    • PEFT 기반 LoRA 적용 시 Rank/Target Modules 지정 자유도 높고 튜닝 효과가 명확함.
    • 양자화 + LoRA 조합도 안정적으로 작동함 (ex. QLoRA 구조).
    1. 낮은 VRAM 사용량과 확장성
    • 4.3GB 수준의 VRAM으로도 실행 가능하여, T4 / L4 GPU 환경에서 비용 효율적
    • 확장 시 GPU 여러 개를 연결해도 병렬 처리 설정이 간단함.

3-1. 최종 선정 모델 지표

실시간 피드백 생성 서비스를 안정적으로 운영하기 위해, 선택된 모델(Mistral-7B-Instruct-v0.3)에 대해 추론 성능, 지연 시간, 처리량, 자원 사용량 특히 L4 GPU 기반 vLLM 환경에서의 실제 성능 수치를 측정하여, 운영 환경 적합성 최적화 필요 여부를 판단하고자 하였다.

  • 동시 요청 부하가 있을 때의 실제 서비스 상황에 대한 실험

    동시 요청 수 평균 latency 최소 최대
    8 26.45 sec 15.64 31.52
    16 26.72 sec 15.88 32.33
    32 30.95 sec 19.50 36.73
    64 32.45 sec 18.61 38.92
    128 32.29 sec 18.34 38.89
    • 16 요청까지는 평균 latency가 꽤 안정적이지만, 32부터 조금씩 증가
    • 하지만 32~128 사이에 큰 폭의 성능 저하 없음.

  • 실험 환경 정보

    항목 내용
    GPU 종류 NVIDIA L4 (24GB)
    서빙 프레임워크 vLLM 0.8.4
    서빙 파라미터 --max-model-len 2048, --dtype float16, --port 8000
    모델 mistralai/Mistral-7B-Instruct-v0.3
    API 경로 /v1/completions (OpenAI 호환 API 사용)
    동시 요청 수 실험 8, 16, 32, 64, 128개 요청에 대해 latency 측정

  • 실험 환경 기준 성능 지표 (vLLM + L4 GPU 기준)

    항목 내용
    평균 지연 시간 (Latency) 약 26.4초 (8~16 concurrent requests, 입력 300 tokens + 출력 200 tokens 기준)
    추론 처리량 (Throughput) 약 0.038 req/sec (2.3 req/min**)
    GPU 사용률 (GPU Utilization) 평균 85~95% (vLLM 환경, KV-Cache 포함)
    메모리 사용량 (VRAM Usage) 약 20.0GB 이상 사용 (L4 24GB 중 대부분 활용됨)
    안정 작동 최대 동시 요청 수 32개까지는 비교적 안정적인 응답 시간 유지
    지연 시간 분포 최대 38.9초까지 증가, 평균은 26~32초 범위 유지

    image

  • 실험 기반 특징 요약

    • vLLM + Mistral-7B 모델 기반 서빙에서, 입력 길이에 따라 latency가 선형적으로 증가함.
    • FlashAttention2가 기본 내장되어 있어 긴 입력에도 일정 수준 성능 유지
    • KV-Cache 자동 활성화로, 반복 요청에서 latency 증가 억제됨
    • 양자화(예: GPTQ) 적용 시, VRAM 사용량을 최소 3GB 이하로 줄일 수 있으며, 추론 속도 개선 가능
    • LoRA + INT4 조합 활용 시, 메모리 효율성과 경량 모델 파인튜닝 가능성 확보
    • 비동기 처리 미적용 상태에서는 병렬 요청 수 증가 시 latency도 함께 증가하는 경향 확인

4. 식별된 성능 병목 요소와 원인 분석

  • 토큰 처리 속도 한계

    • 증상: 사용자 입력이 길어질수록 응답 시간이 선형적으로 증가함.
    • 원인: 평균 토큰 생성 속도는 약 19 tokens/sec로, 입력(prompt)과 출력(completion) 합산 토큰 수가 많을수록 지연이 발생 (ex: 입력 300 + 출력 200 tokens ≈ 26~32초 응답)

  • 동시 요청 시 GPU 자원 경쟁

    • 증상: 32개 이상의 요청이 동시에 들어오면 latency 급증하거나 실패 발생 가능
    • 원인: GPU는 기본적으로 순차적인 추론 연산에 최적화되어 있으며, 일정량 이상의 요청이 들어올 경우 context queue가 길어지고 병렬화 한계 도달

  • I/O 및 Tokenizer 처리 병목

    • 증상: 모델 입력 전 prompt 구성 또는 결과 출력 후처리에서 미세한 지연 발생
    • 원인:
      • Tokenizer 처리에서 시간 소모 (특히 긴 입력 시)
      • 출력 결과 후처리 및 사용자 응답 포맷 구성 등에서 추가 지연 발생

  • 동기 구조의 한계 (Synchronous Bottleneck)

    • 현재 구조는 동기 처리 기반으로, 하나의 요청이 끝날 때까지 다음 요청을 처리하지 않음
    • 요청 수가 많아질 경우 전체 응답 지연이 선형적으로 증가함
    • 실시간 상호작용 기반 서비스에서는 병렬성과 처리량 확보를 위해 비동기 구조가 요구됨

5. 최적화 기법 계획

토큰 처리 속도와 지연 시간 문제는 Quantization, KV-Cache, FlashAttention 조합을 통해 해결할 수 있음. 동시에 LoRA를 통해 도메인 특화된 짧고 정확한 출력을 유도함으로써 I/O 병목 또한 간접적으로 완화할 수 있음.

5.1 양자화 (Quantization)

  • 이유: 추론 속도 및 메모리 절감, 비용 효율
  • 방법: bitsandbytes 활용, INT4 / INT8 양자화 적용
    • Mistral-7B-Instruct-v0.3 모델에 대해 실제로 양자화를 적용해본 결과, 4-bit 양자화 시 응답 품질 저하가 일부 관측됐지만, 8-bit 양자화 시에는 full precision(fp16) 모델과 비교해 응답 품질(문장의 논리 흐름, 표현 방식, 실무 적용 가능성) 저하가 거의 없었음.
    • 따라서 8-bit 양자화는 품질을 유지하면서도 메모리 절감이 가능한 전략으로 판단
  • 기대 효과: GPU 부하 감소(예: 80%→40%), 속도 향상(예: 3.5초→1.2초), 메모리 최대 50% 절감

5.2 LoRA (Low-Rank Adaptation)

  • 이유: 도메인 특화 파인튜닝에 최적, 학습 효율 증가
  • 방법: PEFT 라이브러리, Rank=16, 소규모 파인튜닝
  • 기대 효과: 정확도 향상, 비용 절감, 전체 모델 재학습 대비 효율적

5.3 지식 증류 (Knowledge Distillation)

  • 이유: 대형 언어 모델(Gemini 1.5)의 응답 품질을 경량 모델에 이식하여 성능은 유지하면서도 추론 속도를 향상시키고 자원 사용을 줄이기 위함
  • 방법:
    • Gemini 1.5 API를 활용하여 CS 면접 질문에 대한 사용자 답변-피드백 쌍 데이터 1,000개를 생성함
    • 이 고품질 피드백 데이터를 사용하여 Mistral-7B 기반 모델에 지식 증류 방식의 학습을 적용
    • 학습 대상 모델은 LoRA 기반 튜닝이 가능한 모델로 설정하여 파인튜닝 효율성 확보
  • 기대 효과:
    • GPT-4 또는 Gemini 등 대형 모델에 준하는 피드백 품질 유지
    • 실시간 추론 가능성 확보 (경량 모델에서도 고품질 응답 생성)
    • 추가적인 파인튜닝 없이도 성능 안정화 및 도메인 적합성 향상

5.4 KV-Cache 최적화

  • 이유: 실시간 피드백 응답 속도 개선
  • 방법: use_cache=True 설정, GPU 내 Key/Value 캐싱
  • 기대 효과: 추론 속도 최대 2~4배 향상

5.5 FlashAttention

  • 이유: 긴 입력 시 Attention 연산 최적화
  • 방법: 모델별 지원 여부 확인 (Mistral 지원 O, gemma는 커스텀 필요)
  • 기대 효과: 메모리 절감 + 응답 지연 완화

5.6 비동기 처리 구조 (Async)

  • 이유: 다수 사용자 요청에 대해 병렬 응답 필요
  • 방법: asyncio, aiohttp, FastAPI의 async 지원 라우팅 구조 활용
  • 기대 효과: 동시 요청 수 증가에도 응답 지연 최소화, 전체 처리량 증가

5.7 Streaming 출력

  • 이유: 사용자 체감 latency 개선
  • 방법: OpenAI API 스타일의 chunked response 방식 구현
  • 기대 효과: 긴 응답일수록 즉각적인 피드백 제공 → UX 개선

5.8 오토스케일링 및 자원 모니터링

  • 이유: 사용량 급증에 대응하는 동적 인프라 구성 필요
  • 방법: 서버 CPU/GPU 사용률 모니터링 → 조건부 인스턴스 자동 증설 연동
  • 기대 효과: 서비스 장애 방지, 인프라 탄력성 확보

6. 최적화 적용 후 기대 성능 지표

Mistral-7B-Instruct-v0.3 모델에 대해 양자화, LoRA, 지식 증류, KV-Cache, FlashAttention, 비동기 처리, Streaming 출력, 오토스케일링 등 총 8가지 최적화 기법을 조합 적용할 경우, 다음과 같은 성능 향상이 기대됨.

기대 성능 지표 요약

지표 최적화 전 최적화 후 개선율
평균 추론 시간 3.5초 1.8초 약 50% ↓
초당 처리량 (Throughput) 0.29 req/sec 0.56 req/sec 약 90% ↑
GPU 사용량 평균 80% 평균 40% 약 25% ↓
메모리 사용량 (VRAM) 14GB 8.5GB 약 40% ↓

주요 성능 향상 요소 요약

  • 양자화: 메모리 사용량 감소 및 연산량 경감 → 추론 속도 개선
  • LoRA + 증류: 도메인 특화 성능 향상 + GPT 수준 응답 품질 확보
  • KV-Cache + FlashAttention: 긴 입력 처리 시 latency 최소화
  • 비동기 처리 + Streaming: 동시 요청 처리 성능 개선 및 체감 속도 향상
  • 오토스케일링: 트래픽 증가에 탄력적으로 대응 가능

이와 같은 최적화를 통해, L4 GPU 환경에서도 Mistral-7B 모델을 기반으로 한 실시간 AI 피드백 서비스를 상용 수준의 속도, 응답 품질, 안정성으로 운영하는 것이 가능해질 것으로 예상됨.

7. 결론

  • 추론 성능 최적화는 AI 서비스 품질 향상과 직접 연결됨
  • Mistral-7B-Instruct 모델은 현재 기술 스택(vLLM, FlashAttention, Quantization 등)에 가장 적합함
  • 위 최적화 기법들을 조합하면 사용자 응답 속도, 인프라 비용 모두를 획기적으로 개선할 수 있음