로컬 AI는 점점 나아지고 있지만, 메모리 문제는 해결되지 않고 있습니다.

작가 릭 앨런 | 2026년 9월 3일 | 일체 포함, 모두

더 작은 모델도 1년 전보다 훨씬 더 많은 작업을 수행할 수 있습니다. 하지만 더 큰 모델은 여전히 성능의 한계를 높일 수 있으며, 이러한 모델을 둘러싼 작업 부하에는 매개변수 개수만으로는 예측할 수 없는 더 많은 메모리가 필요합니다.

로컬 AI는 빠르게 발전하고 있습니다. 향상된 학습, 정제, 양자화 및 모델 아키텍처 덕분에 최근까지 훨씬 더 큰 모델이 필요했던 작업을 더 작은 모델로 처리할 수 있게 되었습니다. 이제 PC 및 워크스테이션용으로 설계된 모델은 추론하고, 이미지를 이해하고, 도구를 호출하고, 문서를 처리하고, 에이전트 기반 워크플로의 일부로 실행될 수 있습니다.

이는 로컬에서 수행할 수 있는 작업의 범위를 변경하는 것입니다. 그렇다고 모델 크기나 메모리 용량이 더 이상 중요하지 않다는 의미는 아닙니다.

소형 모델의 성능이 향상되고 있지만, 대형 모델은 여전히 추론 능력, 정확도, 지식 범위, 다국어 지원 성능, 그리고 어려운 작업에서의 신뢰성 측면에서 더 나은 결과를 제공할 수 있습니다. 한편, 유용한 로컬 AI 워크로드의 정의는 단순히 하나의 모델을 로드하고 하나의 질문에 답하는 것을 넘어 확장되고 있습니다. 이제 우리는 로컬 AI가 더 큰 맥락을 처리하고, 다양한 유형의 데이터를 이해하고, 도구를 사용하고, 개인 정보를 검색하고, 이전 작업을 유지하며, 때로는 여러 모델이나 에이전트를 동시에 실행할 수 있기를 기대합니다.

해당 모델은 더 효율적일 수 있지만, 전체 작업량이 반드시 줄어드는 것은 아닙니다.

소형 모델은 한계를 높이는 것이지, 최고 수준을 높이는 것이 아닙니다.

파라미터 개수는 모델 성능을 측정하는 완벽한 척도가 아닙니다. 잘 훈련된 12B 모델은 크기가 몇 배나 큰 기존 모델보다 성능이 뛰어날 수 있습니다. 양자화는 모델 실행에 필요한 메모리 양을 크게 줄일 수 있습니다. MoE(Mixture-of-Experts) 아키텍처는 각 토큰에 대해 모델 파라미터 중 일부만 활성화하여 컴퓨팅 요구 사항을 낮출 수 있습니다.

이러한 발전 덕분에 더 넓은 범위의 시스템에서 유용한 로컬 AI를 구현할 수 있게 되었습니다. 하지만 그렇다고 해서 더 큰 모델이 무의미해지는 것은 아닙니다.

모델 품질은 단순히 파라미터 개수뿐만 아니라 아키텍처, 학습 데이터, 학습 후 처리, 정밀도, 평가 대상 워크로드에 따라 달라집니다. 하지만 추론, 코딩, 다국어 지원, 멀티모달 지원과 같은 복잡한 작업에서는 모델 용량이 클수록 성능이 향상될 수 있습니다. 작은 모델은 벤치마크나 특정 작업에서는 좋은 성능을 보일 수 있지만, 복잡한 엔터프라이즈 워크플로우 전반에 걸쳐 일관된 성능을 제공하지 못할 수도 있습니다.

실질적인 문제는 소형 모델과 대형 모델 중 어느 쪽이 "승리"했는지를 넘어서는 것입니다. 오히려 어떤 모델이 작업 부하에 대해 허용 가능한 품질을 제공하는지, 그리고 로컬 시스템에 해당 모델을 실행할 충분한 메모리가 있는지가 더 중요합니다.

이 기능은 모델을 넘어서는 메모리를 추가합니다.

모델 가중치는 메모리 요구 사항 중 가장 눈에 띄는 부분일 뿐입니다. 최신 로컬 AI 애플리케이션은 다음과 같은 용도로도 메모리가 필요할 수 있습니다.

긴 컨텍스트와 그와 관련된 KV 캐시

검색된 문서 및 기업 데이터

이미지, 오디오 또는 비디오 입력

도구 정의, 호출 및 결과

요원의 계획 및 이전 행동

모델 임베딩 및 재순위 지정

여러 사용자, 세션 또는 에이전트

재사용 가능한 프롬프트 및 사전 계산된 컨텍스트

이러한 요구 사항은 애플리케이션이 실행되는 동안 누적됩니다.

애플리케이션 시작 시점에 적합한 모델은 긴 컨텍스트 창을 처리할 용량이 부족할 수 있습니다. 에이전트는 관리하기 쉬운 프롬프트로 시작하여 수십 단계에 걸쳐 소스 문서, 검색 결과, 도구 출력, 코드, 계획 및 이전 응답을 추가할 수 있습니다.

동시성은 문제를 더욱 악화시킵니다. 각 활성 세션은 자체적인 키-값(KV) 캐시를 필요로 할 수 있습니다. 동일한 기본 모델을 공유하더라도 여러 에이전트가 작업의 서로 다른 부분을 담당하면 메모리 사용량이 크게 증가할 수 있습니다. 모델을 적합시키는 것은 필수적이지만, 더 이상 충분조건은 아닙니다.

긴 문맥 정보는 무료가 아닙니다.

긴 컨텍스트는 이제 표준 모델 기능이 되었습니다. 현재 모델들은 수십만 또는 심지어 백만 개의 토큰에 달하는 컨텍스트 창을 제공한다고 광고합니다. 하지만 모든 로컬 시스템이 전체 창을 효과적으로 활용할 수 있는 것은 아닙니다.

추론 과정에서 시스템은 이전에 처리된 토큰에서 파생된 정보를 저장하는 키-값(KV) 캐시를 생성합니다. KV 캐시를 통해 모델은 새로운 토큰이 생성될 때마다 전체 히스토리를 다시 계산하지 않고도 추론을 계속할 수 있습니다. 컨텍스트가 커짐에 따라 KV 캐시의 크기도 증가합니다. 또한 모델 아키텍처, 배치 크기 및 동시 세션 수에 따라서도 크기가 커집니다.

애플리케이션은 오래된 컨텍스트를 삭제하거나, 요약하거나, 필요할 때 정보를 다시 계산하는 방식으로 메모리 사용량을 제어할 수 있습니다. 각 옵션에는 비용이 따릅니다. 모델은 유용한 세부 정보를 잃거나, 이전 작업을 재구성하는 데 추가적인 연산 시간을 소비하거나, 응답 시간이 더 오래 걸릴 수 있습니다.

따라서 대규모의 광고된 컨텍스트 창은 모델의 기능이자 인프라 요구 사항입니다.

도구 사용은 프롬프트를 작업량으로 바꿉니다.

도구 호출 자체는 특별히 메모리를 많이 사용하지 않습니다. 하지만 그 주변 과정은 메모리 사용량이 많을 수 있습니다. 에이전트는 지침과 작업으로 시작합니다. 그런 다음 파일을 검사하고, API를 호출하고, 데이터베이스를 검색하고, 코드를 실행하고, 결과를 평가하고, 계획을 수정하고, 다시 시도할 수 있습니다. 관련 출력은 에이전트의 작업 컨텍스트에 추가되어 에이전트가 다음에 수행할 작업을 결정할 수 있도록 합니다.

코딩 에이전트는 대규모 저장소에서 반복적으로 작업할 수 있습니다. 연구 에이전트는 수많은 문서를 처리하고 인용, 메모 및 중간 결론을 보존할 수 있습니다. 비즈니스 에이전트는 답변을 생성하기 전에 여러 시스템에서 데이터를 가져올 수 있습니다.

그 결과는 하나의 큰 프롬프트가 아닙니다. 프롬프트, 검색된 정보, 도구 결과 및 결정이 순차적으로 확장되는 형태입니다. 이것이 바로 에이전트형 AI가 메모리 논의의 초점을 모델 용량에서 작업 부하 용량으로 옮기는 이유입니다.

멀티모달은 단순히 이미지를 추가하는 것 이상의 의미를 지닙니다.

로컬 모델들도 점차 멀티모달 기능을 갖추게 되고 있습니다. 하나의 애플리케이션에서 텍스트, 이미지, 오디오, 문서, 화면 캡처 또는 비디오를 처리할 수 있습니다. 일부 멀티모달 모델은 이러한 입력들을 하나의 아키텍처 내에서 처리합니다. 다른 애플리케이션들은 파이프라인으로 연결된 여러 개의 특화된 모델을 사용합니다. 어느 방식이든 메모리 사용량 증가를 수반합니다.

시스템은 기본 언어 모델, 양식별 구성 요소, 중간 표현 및 입력에서 생성된 컨텍스트를 저장해야 할 수 있습니다. 문서를 검토하고, 도표를 이해하고, 회의 내용을 듣고, 비즈니스 도구를 호출할 수 있는 로컬 어시스턴트는 텍스트만 지원하는 챗봇보다 훨씬 유용합니다.

또한 업무량이 더 많습니다.

MoE 모델은 전체 모델 용량이 아닌 컴퓨팅 성능을 줄입니다.

MoE 모델은 모델 효율성과 메모리 요구량이 함께 증가할 수 있는 또 다른 사례를 보여줍니다. MoE 모델은 여러 개의 전문가 네트워크를 포함하지만 각 토큰에 대해 일부 네트워크만 활성화합니다. 이를 통해 모든 계산에 모든 매개변수를 사용하지 않고도 더 큰 전체 용량을 제공할 수 있습니다. 활성화된 매개변수 수는 상대적으로 적을 수 있지만 전체 전문가 네트워크 집합은 여전히 매우 클 수 있습니다.

대부분의 전문가가 특정 시점에 비활성 상태임에도 불구하고 모든 전문가를 GPU 메모리에 유지하면 용량이 소모됩니다. 반대로 상주하는 전문가 수를 줄이면 메모리를 절약할 수 있지만, 모델이 토큰을 특정 전문가에게 전달할 때 시스템이 해당 전문가를 로드해야 합니다.

MoE는 계산 효율성을 높여줍니다. 하지만 활동하지 않는 전문가들을 사라지게 하지는 않습니다.

메모리는 계층 구조를 갖게 되고 있다.

메모리 용량 제한에 대한 일반적인 해결책은 GPU 메모리 또는 시스템 DRAM을 추가하는 것입니다. 전체 워크로드가 최대 속도로 실행되어야 하는 경우에는 여전히 최선의 해결책이지만, 항상 실용적인 것은 아닙니다.

GPU 메모리는 가격이 비싸고 용량이 제한적입니다. 워크스테이션 DRAM은 더 많은 용량을 제공하지만 역시 용량에 한계가 있습니다. 플래시 메모리는 훨씬 저렴한 가격으로 더 많은 용량을 제공하지만, GPU 메모리나 DRAM보다 지연 시간이 더 깁니다.

플래시 메모리가 GPU 메모리만큼 빠른지 여부가 중요한 질문이 아닙니다. 실제로 그렇지 않습니다. 이제 진짜 중요한 질문은 모든 작업 부하가 항상 가장 빠른 메모리 계층을 차지해야 하는지 여부입니다.

활성 모델 데이터와 현재 컨텍스트에는 빠른 액세스가 필요합니다. 비활성 MoE 전문가, 이전 KV 캐시, 재사용 가능한 프롬프트 접두사 및 사전 계산된 RAG 콘텐츠는 필요할 때까지 더 큰 메모리 계층에 저장할 수 있습니다. 이러한 리소스를 지능적으로 관리하면 로컬 시스템이 GPU 및 DRAM 용량이 허용하는 것보다 더 크거나 더 오래 걸리는 워크로드를 실행할 수 있습니다.

Pascari aiDAPTIV가 도움을 드릴 수 있는 부분

Pascari aiDAPTIV는 GPU 메모리, 시스템 메모리 및 고내구성 플래시 메모리에 걸쳐 효과적인 AI 메모리를 확장합니다. 지원되는 AI 런타임과 통합되어 소프트웨어가 SSD를 일반 시스템 저장소로 취급하는 대신 특정 AI 데이터를 관리할 수 있도록 합니다. 워크로드 및 런타임에 따라 모델 데이터, MoE 전문가, KV 캐시 또는 자주 사용되는 RAG 콘텐츠에 대한 사전 계산된 KV 항목을 포함할 수 있습니다.

이는 다음과 같은 몇 가지 실질적인 결과를 가져옵니다.

사용 가능한 GPU 및 시스템 메모리를 초과하는 전체 가중치를 가진 모델을 실행합니다.

모든 전문가를 상주시키는 대신 MoE 전문가를 동적으로 불러오는 방식을 채택하지 마십시오.

세션 수가 증가함에 따라 더 많은 KV 캐시를 유지합니다.

안정적인 공유 컨텍스트가 존재하는 경우 이전에 계산된 컨텍스트를 재사용합니다.

자주 검색되는 콘텐츠를 미리 캐시하여 반복적인 프리필을 줄입니다.

GPU를 추가하지 않고 메모리 제약이 있는 미세 조정 워크로드를 실행하세요.

그 결과는 전체 워크로드를 GPU 메모리에서 실행하는 것과 완전히 동일하지는 않습니다. 성능은 계층 간 데이터 이동량과 워크로드가 해당 데이터를 필요로 하는 빈도에 따라 달라집니다. 하지만 대안으로 모델 축소, 컨텍스트 단축, 동시성 제한, GPU 추가 또는 워크로드를 아예 실행하지 않는 것 등이 있는 경우, 이러한 절충안은 유용할 수 있습니다.