메모리와 모델
최종 업데이트
35B MoE가 더 작은 밀집 모델보다 빠를 수 있는 이유
35B MoE와 27B Dense는 한 토큰의 계산량이 달라요.
MoE1는 여러 전문가 중 일부만 선택해 계산하는 모델 구조예요. 전체 35B·활성 약 3B인 모델은 저장할 가중치는 크지만 토큰2당 계산량을 줄일 수 있어요. 이 경로를 효율적으로 실행하는 장비에서는 더 작은 27B Dense보다 답이 빠르게 이어지는 조합도 생겨요.
빈 문자열에서 오류가 나는 함수를 고칠 때 두 모델을 비교해볼게요. 같은 코드와 요청을 보내면 첫 응답과 코드 생성 속도를 비교할 수 있어요. 여기에 테스트를 통과하기까지 걸린 시간을 더하면, 내 코딩 작업에서 어느 모델이 유리한지도 판단할 수 있어요.
MoE는 사용할 전문가 경로만 계산해요.
Dense는 새 토큰을 만들 때 각 층의 가중치 대부분을 사용해요. MoE는 라우터가 토큰에 맞는 전문가를 골라 공유 부분과 함께 계산하죠. 전체 35B라도 활성 약 3B라면, 모델 전체보다 작은 부분이 그 토큰의 계산에 참여해요. 그래서 전체 크기가 큰 모델의 계산량이 더 작아지는 경우가 생겨요.
실행 프로그램3이 선택된 가중치를 빠르게 공급하고 전문가 연산을 효율적으로 처리하면, 계산량을 줄인 효과가 디코드4 속도로 이어져요. 라우팅과 불규칙한 데이터 접근에 드는 시간도 있으므로 같은 장비의 실제 실행 결과를 함께 살펴보는 게 중요해요.
전체 가중치가 들어가는 구성을 준비해요.
다음 토큰은 다른 전문가를 선택할 수 있어요. 실행 중 모델 전체의 가중치에 접근할 수 있어야 하므로, 실제 배포 파일 크기와 양자화5를 확인해요. KV 캐시6와 실행 프로그램, 편집기와 브라우저가 사용할 공간도 남겨야 평소 작업 조건으로 비교할 수 있어요.
전부 VRAM7에 들어가는 모델과 일부를 RAM8으로 오프로딩9하는 모델은 데이터를 가져오는 경로가 달라요. 오프로딩은 실행 가능한 크기를 넓혀주지만 이동 시간이 더해져요. 각 모델의 파일명과 가중치 배치를 기록하면, 계산을 줄인 효과와 데이터 이동의 영향을 함께 이해할 수 있어요.
같은 코드와 입력 조건으로 첫 응답을 비교해요.
문제 함수와 관련 호출부, 오류 로그를 두 모델에 똑같이 보내요. ‘반환 형식은 유지하고 빈 입력을 안전하게 처리해줘’처럼 수정 범위를 정하면 결과도 비교하기 쉬워요. 첫 모델이 수정한 파일 대신 같은 기준 커밋이나 복사본에서 각각 시작하고, 실행 로그와 diff를 따로 보관하세요.
모델 파일·양자화·실행 프로그램·생각 모드·입력·출력 상한·동시 요청 수를 함께 적어요. 처음 자료를 읽는 프리필10과 답을 생성하는 디코드를 나누고, 첫 토큰 시간과 전체 완료 시간을 기록하세요. 모델마다 토큰 분할 방식이 달라 tok/s와 작업 완료 시간을 함께 비교하는 편이 좋아요.
개인 코딩 도우미는 먼저 요청 한 건으로 비교해요. 팀 서버라면 동시 요청도 따로 시험하세요. 서로 다른 입력은 다른 전문가를 선택할 수 있어 메모리 접근과 스케줄링이 달라져요. 전체 처리량11과 함께 각 사용자의 대기 시간을 기록하면 돼요.
테스트를 통과한 수정까지의 시간을 기록해요.
빈 입력과 일반 입력을 각각 넣고 기존 호출부의 테스트를 실행해요. 반환 형식이 유지되고 오류가 해결됐는지 확인하세요. 실패하면 같은 모델에 테스트 로그를 보내 수정하게 하고, 다시 diff를 검토한 뒤 테스트를 실행해요. 이 후속 시간까지 포함하면 내 작업이 실제로 빨라졌는지 판단할 수 있어요.
사이트 비교 화면에서는 장비와 입력 길이를 유지하고 35B MoE와 27B Dense를 바꿔볼 수 있어요. 모델마다 권장 포맷과 가속이 달라 실제 사용할 구성의 체감을 살펴보는 데 도움이 돼요. 캐시 여유를 남기고 적재되는 후보 가운데, 내 코드에서 필요한 수정이 나오는 모델을 고르면 돼요.
용어 각주
MoE — 여러 전문가 하위망 중 일부를 입력에 따라 선택해 사용하는 모델 구조입니다. 총 파라미터 수와 한 토큰 처리에 활성화되는 파라미터 수는 다를 수 있습니다.
본문으로 돌아가기토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다.
본문으로 돌아가기런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 합니다.
본문으로 돌아가기토큰 디코드 — 입력과 앞서 만든 답변을 바탕으로 다음 출력 토큰을 차례로 생성하는 단계입니다.
본문으로 돌아가기양자화 — 모델의 가중치나 계산값을 더 적은 비트로 표현해 저장 공간과 메모리 사용량을 줄이는 방법입니다. 표현 단계가 거칠어져 정확도에도 영향을 줄 수 있습니다.
본문으로 돌아가기KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.
본문으로 돌아가기VRAM — 그래픽카드의 GPU가 사용하는 메모리입니다. 모델 가중치와 계산 중간값을 저장합니다.
본문으로 돌아가기시스템 RAM — 프로그램이 실행되는 동안 데이터를 임시로 보관하는 시스템 메모리입니다.
본문으로 돌아가기오프로딩 — 메모리가 부족할 때 모델 데이터 일부를 GPU 메모리에서 시스템 RAM이나 저장장치로 옮겨 처리하는 방식입니다. 데이터 이동이 추가됩니다.
본문으로 돌아가기프리필 — LLM이 입력 프롬프트를 읽고 각 토큰의 내부 표현을 계산하는 단계입니다. 입력이 길수록 처리할 토큰이 많아집니다.
본문으로 돌아가기처리량 — 일정 시간 동안 처리하거나 생성한 작업량입니다. 토큰/초, 요청/초처럼 단위를 함께 확인해야 비교할 수 있습니다.
본문으로 돌아가기
자주 묻는 질문
- 이 글에서 가장 먼저 확인할 것은 무엇인가요?
- MoE는 여러 전문가 중 일부만 선택해 계산하는 모델 구조예요. 전체 35B·활성 약 3B인 모델은 저장할 가중치는 크지만 토큰당 계산량을 줄일 수 있어요. 이 경로를 효율적으로 실행하는 장비에서는 더 작은 27B Dense보다 답이 빠르게 이어지는 조합도 생겨요.
- 필요한 메모리는 어느 정도인가요?
- 개인 코딩 도우미는 먼저 요청 한 건으로 비교해요. 팀 서버라면 동시 요청도 따로 시험하세요. 서로 다른 입력은 다른 전문가를 선택할 수 있어 메모리 접근과 스케줄링이 달라져요. 전체 처리량과 함께 각 사용자의 대기 시간을 기록하면 돼요.