올라마가 모델을 불러올 때의 메모리 부담과 요청 대기를 줄이는 미리보기 버전을 공개했다. 통합 그래픽, CPU와 메모리를 공유하는 그래픽 장치 이용자는 모델 로딩 실패를 줄이는 변경을, 여러 요청을 받는 서비스 운영자는 생성 요청을 함께 처리하는 기능을 확인할 수 있다.
1. 로딩 실패와 생성 대기에 각각 대응
2026년 11월 10일 공개된 v0.40.17-rc0는 모델을 올리는 단계와 요청을 처리하는 단계의 병목, 처리를 늦추는 주요 지점을 각각 손봤다. 같은 메모리를 나눠 쓰는 그래픽의 로딩 문제와 여러 요청이 겹칠 때의 대기 시간을 겨냥한 변경이다.
통합 그래픽 쪽은 모델 데이터가 같은 메모리 예산, 장치가 사용할 수 있는 메모리 한도를 중복 점유하는 문제를 줄인다. MLX 쪽은 한 요청이 끝날 때까지 다음 요청을 세워 두는 대신, 여러 요청이 계산 자원을 나눠 쓰도록 했다.
2. Vulkan 통합 그래픽은 메모리 맵으로 읽는다
기존 로딩 방식은 CPU에 남는 모델 데이터를 Vulkan의 호스트 버퍼라는 저장 공간에 둔다. 이 공간도 가중치, 모델이 학습한 수치 정보와 같은 장치 메모리 예산을 쓰므로, 통합 그래픽에서는 메모리 점유가 대략 두 배가 되고 로딩이 실패할 수 있다고 올라마 변경 제안서는 설명했다. 보고된 증상에는 메모리 고정 할당 실패와 윈도 AMD 환경의 오류가 포함됐다.
올라마는 Vulkan 통합 그래픽을 감지하면 mmap을 자동으로 선택해 메모리 맵 방식으로 읽도록 했다. 직접 입출력, 운영체제 캐시를 거치지 않는 읽기 방식으로도 호스트 버퍼를 피할 수 없어 로딩 경로 자체를 바꾼 것이다. 적용 대상은 CPU와 메모리를 공유하는 통합 그래픽이다.
아래는 변경된 함수의 원문 일부다.
// appendLoadModeArgs selects llama-server's single model loading mode. Integrated
// GPUs share memory with the CPU: Linux CUDA/ROCm use direct I/O to skip the page
// cache, while Vulkan uses mmap because non-mmap loads place CPU-resident tensors
// in a host buffer drawn from the same device budget as the weights.
func appendLoadModeArgs(params []string, opts api.Options, gpus []ml.DeviceInfo) []string {
for _, g := range gpus {
if !g.Integrated {
continue
}
if strings.EqualFold(g.Library, "Vulkan") {3. MLX가 여러 생성 요청을 함께 처리
MLX 모델은 OLLAMA_NUM_PARALLEL로 동시에 처리할 생성 요청 수를 정할 수 있다. 기본은 한 요청이며, 값을 높이면 활성 요청마다 메모리가 더 필요하다. 설정을 2로 두면 두 요청이 함께 들어왔을 때 차례를 기다리는 요청도 먼저 토큰을 받기 시작할 수 있다.
여러 요청은 함께 계산할 수 있는 부분을 묶어 처리하되, 요청별 캐시, 재사용할 데이터를 임시 보관하는 공간과 응답 흐름은 따로 유지한다. 한 요청의 입력을 전부 처리한 뒤 다음으로 넘어가는 대신, 프롬프트, 모델에 입력하는 지시와 문맥을 2048토큰씩 나눠 응답 생성과 번갈아 처리하는 방식이다. 사용자가 설정하는 예시는 다음과 같다.
OLLAMA_NUM_PARALLEL=2회사 발표 기준 성능 측정은 NVFP4 양자화, 모델 수치를 줄여 메모리를 아끼는 변환 모델을 Apple M5 Max에서 실행한 결과이며, 값은 초 단위 중앙값이다. 두 클라이언트가 동시에 요청한 조건에서, 기준선은 순차 처리하고 변경본은 요청을 교차 처리했다. 아래 표는 대기 요청이 응답을 받기 시작하는 시간과 두 요청이 모두 끝나는 시간을 보여 준다.
표: 동시 요청의 응답 시작과 전체 완료 시간
조건: NVFP4, p4096/g256, Apple M5 Max; OLLAMA_NUM_PARALLEL=2; 두 클라이언트 동시 제출; 기준선은 main의 순차 처리, 변경본은 교차 처리
단위: 초(중앙값)
| 모델 | 두 번째 시작·기준선 | 두 번째 시작·변경본 | 모두 완료·기준선 | 모두 완료·변경본 |
|---|---|---|---|---|
| Gemma 4 12B | 7.45 | 4.69 | 9.57 | 10.19 |
| Qwen 3.8 27B | 13.84 | 9.90 | 17.23 | 20.07 |
| Nemotron 3.5 Lightning 30B-A3B | 3.31 | 1.65 | 4.99 | 4.93 |
이 조건에서는 대기 요청의 응답 시작이 세 모델 모두 앞당겨졌다. 두 요청의 전체 완료 시간은 Gemma와 Qwen에서 늘었고 Nemotron은 비슷했다. 단일 요청 성능은 기준선과 가까운 수준이라고 변경 제안서는 설명했다.
4. 응답 대기와 처리 비용의 맞바꿈
동시 처리는 대기 요청에 먼저 응답하는 대신, 첫 요청이 쓰던 그래픽 계산 자원을 나눠 쓴다. 생성할 내용을 미리 추측해 속도를 높이는 기법도 여러 요청이 실행되는 동안에는 멈춘다. 운영자가 얻는 이익은 대기 시간 단축이며, 그 대가는 요청별 메모리 증가와 일부 모델의 전체 완료 시간 증가다.
요청마다 따로 둔 캐시에는 요청이 쉬는 동안에도 메모리가 남고, 입력의 공통 앞부분이 중복 저장된다. 개발진은 캐시 보관 예산을 공유하고 유휴 메모리를 회수하며 공통 입력을 재사용하는 후속 개선을 계획했다.
이번 배포는 미리보기 버전이며, 측정 결과는 표에 적힌 모델·설정·하드웨어 조건에 해당한다.
v0.40.17-rc0는 공유 메모리 환경의 로딩 부담을 줄이고 MLX의 대기 요청에 먼저 응답하는 길을 열지만, 동시 생성은 메모리와 전체 완료 시간의 비용을 함께 따져야 한다.