Hindsight의 reranker를 GPU 없이 CPU로 9배 빠르게 만들기 — batch size 최적화와 ONNX화

결론 (미리보기)

GPU가 없는 CPU 환경에서 Hindsight의 reranker (cross-encoder)가 느릴 때, 효과가 큰 순서대로 나열하면 다음과 같습니다.

대책	수행 내용	효과 (reranking p95, 본 기사의 환경)
batch size를 작게 만들기	RERANKER_LOCAL_BATCH_SIZE를 기본값인 32에서 2로 변경	7.98s → 3.12s (가장 큰 효과는 이것)
ONNX Runtime화 (+ tokenizer dispatch 수정)	reranker를 ONNX로 변환하고 스레드 설정을 최적화. 아울러 tokenizer를 올바른 fast path로 유도 (품질 지표도 개선)	3.12s → 0.88s. 단, 이는 두 가지 효과의 합계이며, ONNX 단독 기여도는 모델 추론에서 약 1.4x, 나머지는 tokenizer 수정 및 end-to-end 차이

누적하여 reranking 단계의 p95가 7.98s → 0.88s ≒ 9배가 되었습니다.

하지만 이 기사에서 가장 전하고 싶은 것은 이 한 문장입니다.

9배 개선의 대부분은 ONNX가 아니라, CPU에 맞지 않는 batch size를 수정한 효과였습니다.

ONNX화는 마지막 한 방이었고, 가장 먼저 의심해야 할 것은 batch size였다는 것이 이번의 배움입니다. 이하, 그 탐색 과정을 순서대로 기술하겠습니다.

본 기사는 「Hindsight를 GPU 없이 로컬에서 일본어로 운용하기 위한 설정 가이드」의 후속편입니다. 이전 기사에서 BUCKET_BATCHING이나 후보 수 축소에 대해서는 다루었지만, 본 기사는 reranker의 latency를 더욱 깊게 깎아내는 이야기에 집중합니다.

측정 조건

9배라는 숫자는 강력한 만큼 「부풀린 것이 아닌가」 하는 의심을 사기 쉬우므로, 먼저 측정 조건을 고정해 두겠습니다.

항목	값
호스트	Ryzen 5 5600G (6 코어 / 12 스레드, AVX2까지), Linux, GPU 없음
Hindsight	본 기사의 벤치는 모두 v0.5.6 기반으로 측정 (후술할 cutover에서 v0.6.2 기반으로 업데이트했으나, 그 차분은 본 기사의 수치에 포함하지 않음)
reranker 모델	hotchpotch/japanese-reranker-xsmall-v2 (ModernBERT-ja 계열, 약 36.8M params)
추론 런타임 (Inference Runtime)	PyTorch (sentence-transformers의 CrossEncoder) → ONNX Runtime (CPUExecutionProvider)
워크로드 (workload)	일본어 운용 query 11건 × 2개의 budget (low / mid). Hindsight의 recall API를 호출
측정 대상	recall 파이프라인 내 reranking 단계의 소요 시간 (tokenize를 포함한 end-to-end). 별도로 모델 추론 단독의 microbench도 실시
...

품질 지표로 사용한 keyword hit count는, 기대하는 기억·문서에 포함된 키워드가 상위 결과에 들어있는지를 확인하는 간이 지표입니다. 엄격한 IR 벤치마크가 아니라, 실제 운용 query에 대한 regression check (속도를 높인 결과 검색 품질이 떨어지지 않았는지 확인)로서 사용했습니다.

reranking 단계는 이번 환경에서 recall의 wall time 중 약 9할을 차지했습니다. 즉, reranker의 고속화는 곧 체감 속도와 직결됩니다.

시작하며 — 왜 reranker가 CPU에서 느린가

Hindsight는 LLM 에이전트에게 장기 기억을 부여하기 위한 셀프 호스트형 메모리 백엔드입니다. recall (기억 검색)에서는 벡터 검색과 lexical 검색으로 후보를 모은 뒤, cross-encoder reranker로 후보를 다시 정렬합니다. 이 reranker가 GPU가 없는 환경에서는 recall 전체의 병목(bottleneck)이 됩니다.

cross-encoder는 「query와 후보 문서의 쌍」을 한 건씩 모델에 통과시켜 점수를 내기 때문에, 후보 수만큼의 추론이 실행됩니다. GPU라면 batch를 크게 키워 병렬도로 밀어붙일 수 있지만, CPU에서는 이야기가 달랐습니다.

이번 스코프는 batch size (배치 크기) 최적화와 ONNX fp32화 두 가지입니다. 더 나아가 int8 양자화(Quantization)는 별도의 호스트와 별도의 모델에서 검증해야 하는 내용이므로, 마지막에 가볍게 언급하는 정도로만 다루겠습니다.

Step 0: baseline — 기본 batch size가 CPU에 맞지 않았다

먼저 현재 설정의 수치를 고정합니다. reranker는 hotchpotch/japanese-reranker-xsmall-v2를 사용하며, BUCKET_BATCHING=true (길이순으로 정렬한 뒤 배치화), batch_size는 미설정 상태로 기본값인 32를 사용합니다.

baseline (low budget):

지표	값
reranking p95	7.98s
...

reranking이 전체 실행 시간(wall time)의 약 9할을 차지합니다. 이 부분을 줄이면 전체가 빨라지는 구조입니다.

여기서 의문이 생깁니다. batch size 32라는 기본값은 애초에 CPU를 위한 것인가?

cross-encoder 라이브러리의 batch size 기본값은 GPU나 Apple Silicon (MPS)에서 처리량(throughput)을 확보하기 위해 튜닝된 값인 경우가 많습니다. GPU에서는 배치를 크게 잡을수록 연산기(arithmetic units)를 가득 채울 수 있어 유리합니다.

하지만 CPU 추론에서는 상황이 반대로 작용할 수 있습니다.

• 배치를 크게 잡으면, 쌍(pair)마다 다른 토큰(token) 길이를 **padding (패딩)**으로 흡수해야 하므로 무의미한 계산(padding 부분의 연산)이 늘어남
• 큰 텐서(tensor)는 **cache (캐시)**에 다 담기지 못해 메모리 대역폭(memory bandwidth)이 병목(bottleneck)이 됨
• 스레드 스케줄링(thread scheduling)이나 메모리 할당 오버헤드가 병렬성(parallelism)으로 얻는 이득을 갉아먹음

reranker는 쿼리(query)마다 후보 수와 문서 길이도 제각각이기 때문에, CPU에서는 "배치를 크게 하면 빨라진다"는 공식이 성립하지 않을 가능성이 있습니다. 이는 추측이므로, 다음 단계에서 실측을 통해 확인하겠습니다.

Step 1: batch size sweep — 작은 값이 효과적이었으며, 최속은 bs=2

HINDSIGHT_API_RERANKER_LOCAL_BATCH_SIZE를 2 / 4 / 8 / 16 / 32 / 64 / 128로 변경하며, 각각 컨테이너 재시작 → warmup (예열) → 측정을 수행했습니다.

reranking p95 (low budget):

batch size	reranking p95	baseline 대비
2	3.12s	-61%
4	4.06s (불안정, 후술)	-49%
8	3.72s	-53%
16	4.69s	-41%
...

결과는 명확했습니다. 적어도 이번 CPU workload에서는 기본값인 32보다 작은 batch size에서 큰 승산이 있었으며, 최속은 bs=2였습니다. 기본값인 32는 오히려 성능이 떨어지는 영역에 있습니다. 128까지 올리면 baseline보다 2.3배 느려졌습니다. BUCKET_BATCHING으로 길이를 정렬했음에도 배치가 크면 padding의 낭비가 지배적이 된다는 Step 0의 추측과 일치합니다 (단, "작을수록 단조롭게 빨라지지는 않는다"는 점은 후술하겠습니다).

품질(keyword hit count)은 어떤 batch size에서도 baseline과 동등하거나 그 이상이었으며, 악화는 없었습니다. 승자는 batch size = 2입니다. 이를 운영 환경에 적용했습니다.

env 설정에 한 줄만 추가하면 됩니다.

environment:
HINDSIGHT_API_RERANKER_LOCAL_BATCH_SIZE: "2"

함정: 단조롭지 않음 — bs=4의 골짜기

한 가지 주의할 점이 있습니다. "작을수록 빠르다"는 법칙이 단조롭지는 않았습니다. bs=4는 측정할 때마다 값이 흔들리고, 동일한 쿼리임에도 소요 시간이 단조 증가하는 등의 불안정함이 나타났습니다 (bs=2나 bs=8에서는 나타나지 않음).

원인을 단정 지을 수는 없습니다. CPU의 cache, 스레드 스케줄링, 입력 길이의 편차, bucket 경계에 긴 문장 쌍이 들어가는지 여부 등 — 여러 요인이 복합적으로 얽힌 영역입니다. 여기서 말할 수 있는 것은 단 하나뿐입니다.

batch size를 작게 만든다고 해서 반드시 단조롭게 빨라지는 것은 아니다. 그러므로,

자신의 실제 운영 워크로드 (workload)에서 스윕 (sweep)하여 결정한다. 이론적인 논리가 아니라 실측으로.

bs=2가 모든 측정에서 안정적으로 가장 빨랐기에, 골짜기(local minimum)를 밟지 않고 넘어갈 수 있었습니다.

Step 2: ONNX fp32화 — 마지막 한 걸음, 하지만 함정이 있음

batch size 조절로 7.98s → 3.12s까지 도달했습니다. 여기서부터는 추론 런타임 (inference runtime) 자체를 PyTorch에서 ONNX Runtime으로 교체합니다.

모델 변환

optimum-cli를 사용하여 ONNX로 변환합니다.

optimum-cli export onnx \
--model hotchpotch/japanese-reranker-xsmall-v2 \
--task text-classification \
...

fp32 (양자화 없음)이므로, 여기서 모델의 수치가 변해서는 안 됩니다. PyTorch와 ONNX로 동일한 쌍에 점수를 매겨 비교한 결과, raw logit의 최대 절대 차이는 6e-6, 순위 상관계수 (rank correlation, Spearman)는 1.000이었습니다. 순위는 완전히 보존되었습니다.

함정 1: intra_op_num_threads=1인 상태로 사용하면 PyTorch보다 느려진다

ONNX로 변환하는 것만으로는 빨라지지 않았습니다. 오히려 더 느려졌습니다.

모델 추론 단독 마이크로벤치마크 (microbench, 50개 쌍, median):

구성	median	PyTorch 대비
PyTorch baseline	336ms	1.00x
...

ONNX Runtime은 추론에 사용하는 스레드 수를 intra_op_num_threads로 제어합니다. 이를 1로 설정하면, 내부적으로 여러 스레드를 사용하는 PyTorch에 패배합니다 (위 표의 0.48x). intra_op_num_threads를 얼마로 설정해야 할지는 워크로드 (workload)와 CPU에 따라 다르므로, 마이크로벤치마크를 통해 1 / 2 / 4로 변화시키며 결정했습니다. 스레드 수를 높이고, BUCKET_BATCHING에 상응하는 길이 정렬을 병행하여 겨우 PyTorch 대비 1.39x를 달성했습니다.

역설적으로 말하면, ONNX화에 따른 모델 추론 단독의 기여도는 기껏해야 1.4배입니다. 이 점은 나중에 중요해집니다.

함정 2: 이중 sigmoid — 점수 해석을 기존 구현과 일치시키기

ONNX provider를 Hindsight에 통합할 때, 점수의 "형태"를 기존 구현과 맞출 필요가 있었습니다.

기존의 PyTorch 경로 (path)에서는 이 모델에 대해 CrossEncoder.predict()가 **sigmoid가 적용된 점수 (sigmoid-ed score)**를 반환하며, 그 후 Hindsight의 reranking 파이프라인이 다시 한번 sigmoid를 적용하여 정규화된 점수를 만들고, 이를 정렬 및 boost 계산에 사용합니다. 즉, 이 구성은 "sigmoid가 적용된 점수에 다시 한번 sigmoid를 적용하는" 캘리브레이션 (calibration) 상태였습니다.

반면, optimum으로 내보낸 ONNX는 raw logit을 그대로 반환합니다. 이를 Hindsight에 전달하면 sigmoid는 Hindsight 측에서 한 번만 적용되므로, 기존 경로와 점수의 캘리브레이션이 어긋나게 됩니다. 순위 자체는 단조 증가(monotonic)하므로 대부분 동일하지만, boost (recency / temporal 등)가 적용되는 방식이 달라집니다.

수학적으로 어느 쪽이 "옳은가"의 문제가 아니라, 기존 PyTorch 경로와 동일한 캘리브레이션을 재현하는 것이 목적입니다.

대책은 간단합니다. ONNX provider 측에서 sigmoid를 적용한 후 반환하면 됩니다.

scores = 1.0 / (1.0 + np.exp(-logits))

"속도를 높이는" 관점에서는 놓치기 쉽지만, 런타임을 교체할 때는 점수의 수치적 의미를 기존 구현과 일치시켜야 합니다 —— 이를 간과하면 속도는 빠르지만 동작이 변해버린 reranker가 만들어집니다.

correctness / parity check

런타임을 변경했다면 속도뿐만 아니라 "결과가 실용적으로 변하지 않았는지"를 확인해야 합니다. 이번에는 ONNX provider의 출력과 PyTorch 버전의 출력을 짧은 쌍과 512 token을 초과하는 긴 문장 쌍을 섞어서 비교했습니다.

체크	결과
score의 최대 절대 차이	6e-8
...
fp32 상태이므로 수치 차이는 극소입니다. 이 parity(동등성)를 확인한 후 본 운영 환경을 전환했습니다.

Step 3: 함정 — 모델을 빠르게 만들어도 tokenizer를 거치며 느려지고 있었다

이 부분이 이번에 가장 "당했던" 포인트입니다.

ONNX provider의 parity check는 사실 한 번 FAIL 했습니다. Spearman 상관계수가 0.62이고, top 순위도 일치하지 않았습니다. fp32에서 그렇게 차이가 날 리가 없습니다.

원인을 분리해 보니, 원인은 모델도 sigmoid도 아닌 tokenizer였습니다. 동일한 쌍, 동일한 tokenizer 설정임에도 불구하고 환경에 따라 token 열이 완전히 달랐던 것입니다.

환경	동일한 쌍의 token 수
새로운 transformers (fast path)	25
오래된 transformers (slow path로 fallback)	55

진짜 원인은 모델의 tokenizer_config.json에 있는 tokenizer_class 지정에 대해, 오래된 transformers가 범용적인 slow tokenizer path로 dispatch하고 있었던 것이었습니다. ModernBERT-ja를 위한 올바른 fast tokenizer가 아니라, 다른 방식의 tokenize가 이루어지고 있었습니다. token 열이 다르면 모델이 아무리 정확해도 출력은 변합니다.

대책과, speedup에 대한 올바른 귀속

ONNX provider 측의 대책은 transformers의 자동 dispatch에 맡기지 않고, tokenizer 파일을 직접 읽는 것입니다.

from tokenizers import Tokenizer
tok = Tokenizer.from_file("tokenizer.json")

이는 transformers 버전에 의존하지 않는다는 부수적인 장점도 있습니다. 수정 후, parity는 앞서 언급한 "최대 절대 차이 6e-8 / Spearman 1.000"까지 통과했습니다.

여기서 정직함에 대해 말씀드리고자 합니다. 이 tokenizer 수정은 ONNX화의 성과가 아닙니다.

• ONNX provider는 tokenizer를 직접 호출하므로 우연히 이 함정을 피할 수 있었던 것입니다.
• 하지만 동일한 수정은 컨테이너의 base image를 올려 transformers를 최신으로 만드는 것만으로도 얻을 수 있었습니다. (실제로 cutover를 기점으로 base image를 올렸더니, 기존의 PyTorch 버전 reranker도 올바른 fast tokenizer를 사용하게 되었습니다.)

즉, 후술할 speedup 분해표에서 ONNX 단계에 포함된 개선 사항 중, tokenizer 수정분은 ONNX 고유의 공로가 아니라 image 업데이트로도 얻을 수 있었던 개선입니다. 본 글에서는 그 부분을 구분하여 작성하겠습니다.

실제로 품질 지표(keyword hit count)는 이 수정으로 인해 약 13~30% 개선되었습니다. 이는 속도가 아닌 품질의 개선이며, 더욱이 ONNX 유래가 아닙니다. 이를 섞어서 말하는 것은 불성실한 태도입니다.

speedup의 분해 (waterfall)

지금까지의 증분(incremental)을 한 장으로 정리합니다. reranking 단계의 p95 (low budget) 기준입니다.

단계	구성	reranking p95	누적	비고
baseline	PyTorch / bs=32	7.98s	1.0x	GPU/MPS용 기본값에서 유래
batch size 최적화	PyTorch / bs=2	3.12s	2.6x	CPU에서는 이 부분이 최대 기여
ONNX fp32화 + tokenizer 수정	ONNX / bs=2	0.88s	9.1x	런타임 차이 + tokenizer 수정 포함

마지막 단계(3.12s → 0.88s, 약 3.5x)의 내용을 더 세분화하여 살펴보겠습니다.

ONNX 런타임 차이: 모델 추론 단독 microbench(마이크로벤치마크)에서는 PyTorch 대비 약 1.4x. 이것이 ONNX 고유의 기여분 -
tokenizer dispatch 수정: 나머지 대부분. 다만 이는 ONNX 고유의 특성이 아니라, image 업데이트를 통해서도 얻을 수 있었던 개선 사항 - 여기에 end-to-end 오버헤드 감소가 더해짐

참고로, tokenizer 수정만을 단독으로 측정한 것은 아닙니다(ONNX화와 동시에 이루어졌기 때문). "ONNX 고유 ≒ 1.4x"는 모델 추론 단독 microbench에서 가져온 수치이며, 3.5x와의 차이는 tokenizer 수정과 end-to-end 차이분이 메우고 있다고 해석할 수 있습니다.

production cutover (운영 전환) — 채택한 것 / 보류한 것

운영 환경에 투입한 조합은 다음과 같습니다.

채택:

• batch size = 2
• ONNX fp32 reranker (CPUExecutionProvider 사용, 스레드 설정 튜닝)
• tokenizer 직접 로드 (dispatch 수정)
• base image 업데이트 (transformers를 최신 버전으로 업데이트)

보류:

• int8 양자화 (quantization) — 후술. 운영 환경에는 적용하지 않음
• 단독으로는 느렸던 intra_op_num_threads=1
• query 단위의 과도한 튜닝 — 특정 query에 최적화해도 일반화되지 않음

cutover 이후에는 warmup → 대표 query를 통한 smoke test(HTTP 200 / reranking이 예상 범위 내에 있는지 / keyword hit가 0이 아닌지)를 확인하고 있습니다.

int8 양자화에 대하여 (teaser)

"fp32 다음에는 int8로 더 빠르게"라는 생각은 자연스러운 발상입니다. 이번에는 운영 환경에 적용하지 않았지만, 예비 검증을 통해 알게 된 결론만 언급하겠습니다.

int8의 속도 향상은 CPU의 명령어 세트(instruction set)에 크게 의존합니다. 핵심은 AVX-VNNI 계열의 명령어, 특히 AVX512-VNNI입니다.

• AVX512-VNNI를 탑재한 CPU (예를 들어 Ryzen 9 7950X3D와 같은 최신 데스크톱 CPU)에서는, 소형 모델인 xsmall-v2보다 훨씬 큰 다국어 reranker인 BAAI/bge-reranker-v2-m3 (약 278M params, 다국어 SOTA급)를 int8화하여, CPU만으로 실용적인 수준의 레이턴시(latency)를 확보할 수 있었습니다. GPU가 필수적이라고 여겨지는 SOTA reranker라도 명령어 세트만 갖춰져 있다면 CPU에서 돌릴 수 있다는 점이 int8의 흥미로운 부분입니다. 반면, AVX2까지만 지원하는 CPU (본 기사의 운영 호스트)에서 동일한 int8 모델을 구동하면 오히려 fp32보다 느려졌습니다.

즉, int8은 "CPU의 기능을 확인하고 활성화하는 opt-in" 방식이어야 하며, 무조건적으로 빨라지는 대책은 아닙니다. 게다가 소형 모델(xsmall-v2)의 int8화는 스코어의 식별력을 떨어뜨릴 위험도 있습니다. 자세한 내용은 별도의 기사에서 다루겠습니다.

요약

GPU가 없는 CPU 환경에서 cross-encoder reranker가 느릴 때:

• 먼저 batch size를 의심하라. GPU/MPS용 기본값이 CPU 실운용 환경에 적합하지 않을 수 있다. 이번 사례에서는 기본값인 32가 오히려 독이 되었으며, 이를 2로 변경하는 것만으로 7.98s → 3.12s로 단축되었다.
• base image를 최신 상태로 유지하라. 오래된 컨테이너 image는 reranker의 tokenizer가 느린 dispatch path로 빠질 수 있다 (본 기사에서는 0.5.x → 0.6.x로 해결). env를 수정하기 전에 먼저 토대를 의심하라. 속도와 검색 품질 모두에 영향을 준다.
• 자신의 workload로 sweep을 수행하라. "작을수록 빠르다"는 법칙은 단조롭지 않다 (bs=4 지점에서 골짜기가 발생). 이론적인 추측보다 실측이 중요하다.
• ONNX화는 효과가 있지만, 과신하지 마라. 스레드 설정을 정밀하게 조정했을 때, 모델 추론 단독으로 겨우 1.4x 정도의 향상이 있었다. 런타임(runtime)을 교체할 때는 sigmoid 등 점수 해석 방식도 기존 구현과 일치시켜야 한다.
• 한 번의 측정에는 하나의 변수만 움직여라. 이번에는 ONNX화와 tokenizer 수정이 동시에 이루어져, end-to-end 관점에서 순수한 ONNX의 기여도를 분리해낼 수 없었다. 요인별로 측정해야 나중에 "어떤 조치가 효과적이었는지" 헷갈리지 않는다.

ONNX는 마지막 한 끗이었습니다. 가장 큰 발견은 batch size였습니다.

칼럼: AI 코딩과 탐색 비용

서두에 썼듯이, 본 기사의 검증, 벤치마크, fork 구현은 모두 Claude Code와 함께 진행했습니다. 마지막으로, 그것이 내용에 어떻게 기여했는지 적어두겠습니다.

강조하고 싶은 점은 "AI가 정답을 내놓았다"가 아닙니다. 정확히는 탐색 횟수를 늘릴 수 있게 되었다는 점입니다.

• batch size sweep을 7개 지점에 대해 각각 컨테이너 재시작 → warmup → 측정 방식으로 반복 수행
• microbench 스크립트를 "intra_op 값을 변경하기", "길이 정렬 여부 추가하기" 등과 같이 수차례 다시 작성
• parity가 FAIL 되었을 때, 모델 → sigmoid → tokenizer 순으로 분리 가설을 다시 수립
• 측정 결과를 요인별로 분해하여, 어떤 조치가 얼마나 효과적이었는지 대조

이 작업들은 하나하나 어렵지는 않지만, 수동으로 하면 "번거로우니 그냥 32로 두자"라고 타협하기 쉬운 작업들입니다. AI 코딩은 이러한 "번거로우니까 생략하자"를 줄이는 방향으로 기여했습니다. bs=4의 골짜기와 같은 "직접 해보기 전에는 알 수 없는 불확실성"도 sweep을 아끼지 않았기에 발견할 수 있었습니다.

그 뒤에 "그렇다 해도 AI에게 맡기더라도 결국 판단은 인간이 한다"라고 덧붙이면 깔끔한 결론이 되겠지만, 이번에는 그렇지 않았습니다. 솔직하게 쓰겠습니다. 벤치마크 결과를 읽고 고찰하며, 가설을 세우고, parity FAIL의 원인을 "모델인가, sigmoid인가, tokenizer인가"로 분리하여 진정한 원인에 도달하는 —— 이러한 개선 루프의 대부분은 구현 담당인 Claude와, 크로스 리뷰 담당인 또 다른 AI 에ージェント(구현 담당과는 다른 계열의 모델) 사이의 상호작용으로 돌아갔습니다.

필자(인간)의 역할은 목표와 안전 경계를 정하고, 프로덕션에 투입할지 보류할지를 판단하는 것이었습니다. 기술적인 세부 사항에는 거의 관여하지 못했고, 오히려 도출되는 고찰로부터 배우는 입장이었다는 것이 솔직한 체감입니다. AI 시대의 탐색 비용을 논한다면, 과장 없이 여기까지 쓰는 것이 공정하다고 생각합니다.

본 기사는 실운용 기록을 바탕으로 일반화된 가이드입니다. 수치는 필자 환경의 실측값이며, CPU, 모델, workload에 따라 결과가 달라질 수 있습니다 (2026년 5월 기준).

Discussion