llama.cpp Gemma 4: 프리필 최적화, 처리량 개선

1. 앞선 층의 계산 결과를 재사용하는 구간을 줄였다

11월 3일 병합된 변경은 앞선 층의 계산 결과를 보관하는 KV 캐시를 재사용하고 새 값을 저장하지 않는 층에서, 출력에 필요 없는 토큰 계산을 건너뛴다. 입력 토큰을 미리 처리하는 프리필 단계의 중간 배치, 입력을 나눠 처리하는 묶음에서는 이 층들을 건너뛰고 마지막 배치에서 한 행만 처리하는 방식으로, 이미 받은 계산 결과를 활용하는 구간에서 중복 작업을 덜어낸 셈이다.

개발진은 각 층에 공급하는 입력 표현인 층별 임베딩의 배율 계산을 정리하고, 데이터의 연속 복사도 피하도록 바꿨다.

아래는 원문 변경 코드의 적용 조건이다. 캐시 공유 층의 존재와 동시에 다루는 입력 흐름이 하나인지 등을 확인해, 필요한 중간 결과까지 잘라내지 않도록 한다.

    // KV-shared layers do not write to the KV cache, so prune non-output token rows before the first KV-shared layer
    bool prune_shared = crop_before_nextn(inp_out_ids) &&
                        hparams.n_layer_kv_from_start > 0 && hparams.n_layer_kv_from_start < n_layer &&
                        !cparams.embeddings && cparams.n_seq_max == 1;
    for (int il = (int) hparams.n_layer_kv_from_start; prune_shared && il <= n_layer; ++il) {
        prune_shared = !cparams.embeddings_layer_inp[il];
    }

2. M4 Pro에서 E2B의 긴 입력 처리량이 상승했다

변경 요청 작성자는 공식 Google QAT, 양자화 영향을 반영해 학습한 Q4_0 모델로 변경 전 master, 개발 기준 코드의 변경 전 버전과 변경본을 비교했다. M4 Pro에서 Metal·BLAS와 스레드 10개를 사용한 E2B 측정은 세 입력 길이 모두 프리필 처리량, 초당 입력 토큰 처리 수가 크게 늘었다.

표: E2B 입력 길이별 프리필 처리량

조건: M4 Pro, MTL,BLAS, 스레드 10개, gemma4 E2B Q4_0, 3.10 GiB, 4.63 B

단위: 초당 토큰 수, ± 열은 원문 수치의 오차 부분

같은 환경의 128토큰 생성 측정은 109.65에서 110.98토큰/초로 비슷했다. 개선의 중심은 답변을 이어 쓰는 속도보다 입력을 읽는 속도에 있다.

3. E4B도 입력 길이 전반에서 개선됐다

작성자의 M4 Pro 측정에서 E4B도 같은 방향의 변화를 보였다. 아래 표는 E4B만 묶었으며, 하드웨어와 스레드 설정은 앞선 시험과 같고 모델 크기와 매개변수 수는 다르다.

표: E4B 입력 길이별 프리필 처리량

조건: M4 Pro, MTL,BLAS, 스레드 10개, gemma4 E4B Q4_0, 4.79 GiB, 7.46 B

단위: 초당 토큰 수, ± 열은 원문 수치의 오차 부분

같은 환경의 128토큰 생성 처리량은 63.39에서 63.62토큰/초였다. E4B 역시 입력 처리량의 상승과 생성 속도의 유지가 함께 나타났다.

작성자는 텍스트·이미지·오디오 입력의 출력이 변경 전과 같았고, 16K·32K 길이의 프롬프트도 시험했다고 보고했다.

4. CPU와 스냅드래곤에서도 입력 처리량이 늘었다

작성자의 M4 Pro CPU 시험은 같은 공식 양자화 모델과 스레드 10개를 사용했다. 512토큰 입력에서 E2B는 629.04에서 1811.26, E4B는 326.06에서 543.23토큰/초로 높아졌다.

스냅드래곤 S26+에서는 OpenCL·HTP, 스레드 6개, 소배치 크기 1024, HTP0 장치, ngl, GPU에 올릴 층 수를 정하는 설정 값 -1 조건으로 측정했다. 같은 공식 E2B 모델에서 512토큰 입력은 2303.07에서 5099.01, 8192토큰 입력은 1896.88에서 4686.80토큰/초로 증가했다. 플랫폼별 결과는 각 환경 안의 변경 전후 차이를 보여 준다.

5. 이득을 얻으려면 서버의 동시 처리 구성을 살펴야 한다

작성자가 10월 30일 공개한 M4 Pro·Metal의 서버 시험에서는 13,789토큰 입력을 통합 KV, 하나로 묶어 쓰는 캐시 구성으로 처리할 때 4.22초, 분할 KV, 나눠 쓰는 캐시 구성으로는 11.72초가 걸렸다. 여러 토큰을 미리 예측하는 MTP의 미사용·사용 순으로 처리량은 통합 KV에서 3261.9·3264.4, 분할 KV에서 1175.2·1175.0토큰/초였다.

병합 시점의 잘라내기 조건은 통합 KV를 쓰는 단일 시퀀스, 한 번에 처리하는 입력 흐름이며, 기본 서버처럼 여러 시퀀스를 쓰거나 임베딩을 추출하는 구성은 대상에서 빠진다. 26B는 프롬프트 처리 중 모든 층이 캐시에 값을 저장하므로 작성자는 이 최적화의 이득이 없다고 설명했다.

입력 계산을 덜어내는 이익의 대가는 활용할 수 있는 운영 구성의 폭이다. 여러 요청을 동시에 처리하는 서버라면 단일 시퀀스에서 얻은 입력 처리량뿐 아니라 기존의 동시 처리 요구도 함께 따져야 한다.

이번 최적화의 가치는 답변 생성 자체보다 긴 입력의 대기 시간을 줄이는 데 있으며, 도입 판단의 출발점은 모델과 서버 구성이다.