8장. 성능 튜닝과 모델 설정
8.1 GPU offload 설정
GPU offload는 모델 연산이나 가중치의 일부를 GPU로 보내는 설정입니다. 모델 전체가 GPU 메모리에 올라가면 빠르지만, VRAM이 부족한 환경에서는 일부만 GPU에 올리고 나머지는 RAM/CPU에 둘 수 있습니다. 이때 GPU에 얼마나 올릴지 조정하는 것이 성능에 영향을 줍니다.
LM Studio는 모델 로드 시 context length와 GPU offload ratio 같은 load-time parameter를 설정할 수 있습니다. GPU offload를 무조건 최대로 올리는 것이 항상 답은 아닙니다. VRAM이 부족한데 무리하게 올리면 로딩 실패나 불안정이 생길 수 있습니다. 반대로 너무 낮게 두면 GPU를 충분히 활용하지 못해 느려집니다.
[이미지 8-1] LM Studio 모델 로드 설정 화면.
8.2 context length 설정
context length는 모델이 한 번에 볼 수 있는 토큰 범위입니다. 이 값을 높이면 더 많은 코드와 문서를 넣을 수 있습니다. 하지만 메모리 사용량도 늘어납니다. 코딩 작업에서 context length를 너무 낮게 잡으면 관련 파일을 충분히 넣지 못합니다. 너무 높게 잡으면 느려지고 메모리 부족이 생길 수 있습니다.
초보자는 모델이 지원하는 최대 컨텍스트를 무작정 쓰지 않는 것이 좋습니다. 예를 들어 모델이 32K 토큰을 지원한다고 해서 항상 32K로 둘 필요는 없습니다. 현재 파일 질문이나 짧은 리팩터링은 8K로도 충분할 수 있습니다. 프로젝트 구조 설명이나 여러 파일 분석이 필요할 때만 늘립니다. 1M 컨텍스트 크기를 지원하는 클라우드 모델이 있지만, 모델의 기억 관련 문제를 피하려고 컨텍스트 크기를 절반 또는 1/4만 쓰는 프로그래머도 있습니다.
context length는 모델 품질에도 영향을 줄 수 있습니다. 너무 긴 입력을 주면 모델이 중요한 지시를 놓칠 수 있습니다. 따라서 컨텍스트를 늘리기 전에 먼저 불필요한 내용을 줄이는 편이 좋습니다. README 전체보다 관련 섹션만, 파일 전체보다 관련 함수와 타입 정의만 넣는 식입니다.
8.3 temperature, top-p, max tokens의 의미
temperature는 응답의 무작위성을 조절하는 값입니다. 낮을수록 더 일관되고 보수적인 답을 합니다. 높을수록 다양한 답을 만들 수 있지만 코드 작업에서는 실수가 늘 수 있습니다. 코딩 작업에서는 보통 낮은 temperature가 좋습니다. 특히 리팩터링, 테스트 생성, 버그 수정처럼 정확성이 중요한 작업에서는 0~0.3 사이에서 시작하는 것을 권장합니다.
top-p는 후보 토큰의 누적 확률 범위를 제한하는 샘플링 설정입니다. 간단히 말해 모델이 너무 넓은 후보에서 마음대로 고르지 않게 하는 장치입니다. 초보자는 temperature와 top-p를 동시에 복잡하게 조정하기보다 기본값을 유지하고, 문제가 있을 때 하나씩 바꾸는 편이 좋습니다.
max tokens는 모델이 생성할 최대 토큰 수입니다. 너무 낮으면 답변이 중간에 끊깁니다. 너무 높으면 불필요하게 긴 답을 만들 수 있습니다. 자동완성은 짧게, 코드 설명은 중간 정도, 리팩터링이나 테스트 생성은 조금 길게 잡습니다.
[표 8-1] 주요 생성 파라미터.
8.4 코딩 작업에 맞는 추천 파라미터
코딩 작업의 기본값은 보수적으로 잡는 편이 좋습니다. 코드 생성은 창의적인 글쓰기와 다릅니다. 새롭고 재미있는 답보다 정확하고 일관된 답이 중요합니다. 따라서 temperature는 낮게, max tokens는 작업 크기에 맞게, context length는 필요한 만큼만 설정합니다.
자동완성에서는 짧은 출력이 중요합니다. 너무 긴 제안은 개발자의 의도를 덮어버릴 수 있습니다. temperature도 낮게 둡니다. 채팅에서는 설명이 필요하므로 max tokens를 조금 더 줍니다. 리팩터링에서는 출력 형식을 엄격하게 요구합니다. “변경된 코드만 출력”, “diff 형식으로 출력”, “설명은 5줄 이내”처럼 제약을 줍니다.
추천값은 절대값이 아닙니다. 모델과 런타임에 따라 다릅니다. 이 책에서는 출발점만 제시합니다. 자동완성은 temperature 0.1 ~ 0.3, 짧은 max tokens. 코드 수정은 temperature 0 ~ 0.2, 충분한 max tokens. 문서화나 설명은 temperature 0.3 ~ 0.5 정도로 시작할 수 있습니다. 실제 값은 도구의 옵션 범위에 맞춰 조정합니다.
8.5 자동완성용 모델과 에이전트용 모델을 다르게 쓰기
자동완성용 모델과 에이전트용 모델은 요구사항이 다릅니다. 자동완성용 모델은 빠르고 짧게 답해야 합니다. 에이전트용 모델은 더 긴 컨텍스트를 읽고, 계획을 세우고, 변경 범위를 지켜야 합니다. 이 둘을 같은 모델로 처리하면 어느 한쪽이 불편해질 수 있습니다.
가능하다면 자동완성에는 작은 코딩 모델을 사용합니다. 채팅과 리팩터링에는 더 큰 코딩 모델을 사용합니다. 에이전트 작업에는 지시를 잘 따르는 모델을 사용합니다.
역할 분리는 비용이 아니라 체감의 문제입니다. 자동완성이 빠르면 개발자는 자주 씁니다. 채팅 모델이 조금 느려도 답변 품질이 좋으면 기다릴 수 있습니다. 반대로 자동완성 모델이 느리면 기능을 꺼 버리게 됩니다. 따라서 자동완성은 작고 빠르게, 채팅은 조금 더 똑똑하게 구성하는 것이 좋습니다.
8.6 느린 응답을 빠르게 만드는 방법
느린 응답을 해결하는 첫 번째 방법은 모델을 줄이는 것입니다. 더 작은 파라미터 수, 더 낮은 양자화, 더 짧은 컨텍스트를 사용합니다. 두 번째는 GPU 활용을 높이는 것입니다. GPU offload 설정을 확인하고, 드라이버와 백엔드가 제대로 동작하는지 봅니다. 세 번째는 프롬프트를 줄이는 것입니다. 불필요한 파일과 긴 이전 대화를 줄이면 처리할 토큰이 줄어듭니다.
네 번째는 작업을 나누는 것입니다. “전체 프로젝트를 분석해 주세요”보다 “이 폴더의 역할을 요약해 주세요”, “이 파일에서 인증 관련 함수만 설명해 주세요”처럼 나눕니다. 모델이 읽을 양이 줄고, 결과도 검토하기 쉬워집니다. 다섯 번째는 동시에 실행 중인 프로그램을 줄이는 것입니다. 로컬 AI는 개발 장비의 자원을 직접 쓰기 때문에 주변 환경이 중요합니다.
속도 문제를 해결할 때는 원인을 구분해야 합니다. 첫 토큰까지 오래 걸리는지, 생성 속도가 느린지, 모델 로딩이 오래 걸리는지, IDE가 멈추는지에 따라 해결책이 다릅니다. 첫 토큰이 느리면 프롬프트와 컨텍스트가 너무 길 수 있습니다. 생성 속도가 느리면 모델 크기나 GPU 활용 문제일 수 있습니다. 로딩이 느리면 디스크와 모델 크기 문제일 수 있습니다.
[표 제안 8-2] 느린 응답 원인별 해결책. 열은 “증상”, “가능한 원인”, “우선 시도할 조치”, “추가 조치”로 구성합니다.
8.7 로컬 모델이 멈추거나 뻗을 때 해결법
로컬 모델이 멈추는 이유는 다양합니다. 메모리가 부족할 수 있습니다. GPU 드라이버 문제가 있을 수 있습니다. 모델 파일이 손상되었거나, 런타임과 모델 포맷이 맞지 않을 수 있습니다. 컨텍스트가 너무 길거나, 동시에 여러 요청이 들어가서 서버가 버티지 못할 수도 있습니다.
해결은 기본으로 돌아가는 것이 좋습니다. 먼저 앱과 서버를 재시작합니다. 상황에 따라 운영체제를 재시작해야 될 수도 있습니다. 다음으로 더 작은 모델을 로드해 봅니다. 작은 모델이 정상 동작하면 원래 모델이 장비에 부담이었을 가능성이 큽니다. 작은 모델도 실패하면 설치나 런타임 문제일 수 있습니다. 그다음 모델 파일을 다시 다운로드하거나, LM Studio를 최신 안정 버전으로 업데이트합니다.
에러가 반복되면 로그를 봐야 합니다. LM Studio의 로그, 운영체제의 시스템 로그, GPU 드라이버 오류를 확인합니다.
[실습 8-1] 의도적으로 context length를 낮게/높게 바꿔 응답 속도와 메모리 사용량을 비교