128GB에서 120B 로컬 LLM 병목

세 줄 요약

무슨 변화/핵심 이슈인가: 128GB 메모리에서 120B급 로컬 LLM을 돌릴 때 병목은 파라미터 수만이 아니라 정밀도(quantization), KV 캐시, 컨텍스트 길이, 동시성/배치, 백엔드 오버헤드로 갈린다.
왜 중요한가: 모델 카드에 262,144 토큰(네이티브), 128,000 ISL, BF16/MXFP4 같은 표기가 있으면, 같은 “120B급”이라도 메모리 사용 방식과 운영 목표가 달라질 수 있다.
독자는 뭘 하면 되나: 모델명부터 고르기보다 목표 컨텍스트 길이와 동시 요청 수를 먼저 정한 뒤, 모델 카드의 컨텍스트/정밀도 표기와 백엔드 지원을 기준으로 설정을 검증한다.

노트북을 닫기 전에 로컬 LLM 창을 하나 더 띄운다. 모델은 120B급이고, 메모리는 128GB다. “가중치만 올리면 되겠지”라고 생각한 순간부터 문제가 시작된다. 120B급 로컬 구동의 병목은 ‘파라미터 수’만이 아니라 정밀도(quantization), KV 캐시(컨텍스트가 길수록 커지는 메모리), 그리고 백엔드 오버헤드가 좌우한다는 점을 먼저 인정해야 한다.

예: 한 사용자는 긴 문서에서 근거를 뽑아 요약하려고 하고, 다른 사용자는 짧은 질문을 반복하며 답을 확인한다. 둘 다 같은 크기의 모델을 띄우려 하지만, 필요한 컨텍스트와 동시성 조건이 달라서 병목 지점도 달라진다.

이 글은 128GB 메모리 환경(예: M4 Max급 구성)에서 120B급 LLM을 로컬로 굴릴 때 어떤 메모리 항목이 발목을 잡는지를 정리하고, 공식 문서로 확인 가능한 1차 자료 기준에서 Qwen/Qwen3.5-122B-A10B와 gpt-oss-120b를 “실사용 선택 프레임”으로 비교한다. 다만 이번 조사 범위에서 두 모델 카드 모두 **추론 속도(tokens/s)**나 필요 VRAM/메모리(GB) 같은 정량 요구량을 공식 수치로 고정해 제시하진 않았다. 따라서 결론은 “128GB에서 된다/안 된다”가 아니라, 되게 만드는 설정의 방향과 선택 기준에 가깝다.

현황

128GB 환경에서 120B급 로컬 LLM을 운영하면, 메모리 사용은 보통 세 덩어리로 나뉜다. 가중치(Weights), KV 캐시(Key/Value cache), 그리고 런타임/프레임워크의 **오버헤드(그래프, 버퍼, 임시 텐서, 페이지 캐시 등)**다. 이 중 KV 캐시는 사용자가 체감하기 전까지 과소평가되기 쉽다. 컨텍스트를 길게 잡거나 동시 요청을 늘리면 KV 캐시가 빠르게 커지고, 같은 120B급이라도 짧은 단일 채팅과 긴 문서 기반 작업에서 결과가 달라질 수 있다.

이번 조사에서 공식 모델 카드로 확인한 후보는 두 가지다.

Qwen/Qwen3.5-122B-A10B: 모델 카드에 컨텍스트 길이 262,144 토큰(네이티브), 최대 1,010,000 토큰까지 확장 가능이라고 적혀 있다. 벤치마크 예시로 MMLU‑Pro 86.7, LongBench v2 60.2, GPQA Diamond 86.6, SWE-bench Verified 72.0을 함께 제시한다. 이 점수들은 “성능을 단정”하기보다, 모델 카드가 어디(장문/코딩/추론 등)에 초점을 두는지 읽는 단서로 쓰는 편이 안전하다.

분석

이 이슈가 중요한 이유는 “돌아가느냐”만의 문제가 아니라, 내가 필요한 컨텍스트 길이와 감당 가능한 지연시간을 함께 맞추는 문제이기 때문이다.

Qwen3.5-122B-A10B가 제시하는 **262,144 토큰(네이티브)**은 장문 작업에 유리할 수 있다. 다만 실제로 그 길이를 쓰면 KV 캐시가 커질 가능성이 있다.
gpt-oss-120b는 128,000 ISL을 명시하고, BF16/MXFP4 및 BF16 activations 권장 같은 운용 힌트를 준다. 이 표기는 “어떤 정밀도 전제를 두고 설계/배포되는지”를 추정할 근거가 된다.

또한 128GB는 여유를 보장하는 숫자라기보다, 설정에 따라 빠르게 닿을 수 있는 제약 조건이다. 장문 컨텍스트를 붙이면 가중치보다 KV 캐시가 먼저 병목이 될 수 있고, 이때 체감은 백엔드(추론 엔진)가 다음을 어떻게 처리하는지에 따라 달라질 수 있다.

특정 정밀도/포맷 최적화 정도
KV 캐시 운용 방식(캐시 재사용, 페이지드 캐시, 프리필/디코드 분리 최적화 등)
동시성에서의 메모리 공유 효율

하지만 이번 조사에서 확인한 1차 문서만으로는 “128GB에서의 안정적인 설정값”이나 “실제 tokens/s”를 수치로 고정해 말하기 어렵다. 따라서 모델 선택은 모델 자체만이 아니라 백엔드·정밀도·캐시 정책을 포함한 스택 선택으로 다루는 편이 정직하다.

실전 적용

목표를 “120B를 128GB에서 돌린다”로 두면 판단 기준이 흐려진다. 대신 “내 작업에 필요한 컨텍스트 길이와 동시 요청 수를 정하고, 그 조건에서 메모리 한도를 넘지 않게 운영한다”로 바꾸는 편이 재현 가능하다.

장문이 핵심이라면, 모델 카드에 **262,144 토큰(네이티브)**처럼 긴 컨텍스트를 명시한 계열이 후보가 될 수 있다. 단, KV 캐시 비용이 설계 항목으로 들어간다.
상대적으로 짧은 상호작용을 반복한다면, 128,000 ISL처럼 목표 컨텍스트가 더 낮게 제시된 모델이 운영 측면에서 유리할 수도 있다. 또한 BF16/MXFP4, BF16 activations 권장 같은 표기는 “어떤 효율화 전제”가 있는지 확인하는 체크포인트가 된다.

오늘 바로 할 일:

목표 컨텍스트 길이를 먼저 정하고(예: 128,000 ISL 또는 262,144 토큰 같은 표기와 대응), 그 길이에서 KV 캐시가 병목이 되는지 관찰한다.
동시 요청 수를 정한 뒤 배치/동시성을 낮은 값에서 단계적으로 올리면서, 메모리 사용과 지연시간이 무너지는 지점을 기록한다.
후보 모델 카드에서 컨텍스트 길이(262,144 / 1,010,000 / 128,000)와 정밀도 힌트(BF16, MXFP4, BF16 activations 권장)를 확인하고, 사용 중인 백엔드가 이를 지원하는지 검증한다.

FAQ

Q1. 128GB면 120B급을 로컬로 돌릴 수 있나?
A. 단정하기 어렵다. 가중치 외에도 KV 캐시와 오버헤드가 변수다. 특히 컨텍스트 길이와 동시 요청 수가 커지면, 같은 모델도 한계를 드러낼 수 있다.

Q2. 컨텍스트 길이가 긴 모델이 항상 더 나은가?
A. 그렇지 않다. 예를 들어 **262,144 토큰(네이티브)**을 제시하는 모델은 장문 작업에 유리할 수 있지만, 그 길이를 실제로 쓰면 KV 캐시 비용이 커질 수 있다. 필요한 길이를 먼저 정하고 그 범위에서 최적화하는 편이 안전하다.

Q3. 모델 카드에서 무엇을 우선 확인해야 하나?
A. (1) 컨텍스트 길이 표기(예: 128,000 ISL, 262,144 네이티브, 1,010,000 확장) (2) 권장 정밀도/혼합 정밀도 힌트(예: BF16 activations 권장, MXFP4 언급) (3) 워크로드와 가까운 벤치마크 신호(예: MMLU‑Pro 86.7, LongBench v2 60.2, SWE‑bench Verified 43.1) 순으로 보면 시행착오를 줄이는 데 도움이 된다.

결론

128GB에서 120B급을 운영하는 문제는 “큰 모델을 한 번 띄우기”가 아니라, 컨텍스트·KV 캐시·정밀도·동시성·오버헤드의 예산 편성에 가깝다. Qwen3.5-122B-A10B의 262,144 토큰(네이티브) 및 1,010,000 확장 표기, gpt-oss-120b의 128,000 ISL 및 BF16/MXFP4, BF16 activations 권장 같은 표기는 모델의 운영 전제를 읽는 신호가 된다. 다음 단계는 모델명부터 고르는 것이 아니라, 목표 컨텍스트와 동시성을 먼저 고정하고, 그 조건에서 버티는 스택(백엔드 + 정밀도 + 캐시 정책)을 찾는 것이다.

Aionda

128GB에서 120B 로컬 LLM 병목

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기