핵심 요약 (Key Takeaways)

• 이 벤치마킹은 실시간 gpt-4o-mini 호출 및 제공업체가 보고한 토큰 사용량을 사용하여, 모드당 100개의 측정된 요청과 25개의 워크로드 제품군에 대해 5가지 시맨틱 캐시 (semantic-cache) 모드를 비교합니다.
• 두 시맨틱 캐시 모드 모두 100번의 호출 중 65번의 LLM 호출을 방지했습니다. 정확한 캐시 (exact-cache) 재사용은 25번을 방지했습니다. 시맨틱 캐시 모드들은 동일한 적격성 정책 (eligibility policy)을 사용했기 때문에 동일한 재사용 결정을 내렸습니다.
• 측정된 원격-기본 (remote-primary) 토폴로지에서, 적격한 Oracle True Cache 읽기는 기본 경로 시맨틱 조회 (primary-route semantic lookup)와 비교했을 때 캐시 히트 조회 지연 시간 (cache-hit lookup latency)을 줄였습니다: 비 LLM 평균 지연 시간은 약 10.8 ms인 반면, 기본 경로는 166.6 ms였습니다.
• 쓰기 (Writes), 미스 (misses), 캐시 채우기 (cache population) 및 벤치마크 이벤트 기록은 여전히 기본 데이터베이스 (primary database)를 통해 흐릅니다. Oracle True Cache는 쓰기 대상이 아닌 읽기 최적화 (read optimization)로서 측정되었습니다.

시맨틱 캐싱 (Semantic caching)은 실제로 비용을 지불하는 요소, 즉 실시간 LLM 호출, 토큰 사용량, 실제 소요 시간 (wall-clock time) 또는 읽기 경로의 지연 시간 (latency)을 줄일 때 그 가치를 증명합니다. 이 시리즈의 이전 기사들은 정확한 조회 (exact lookup), 벡터 조회 (vector lookup), 범위 지정된 재사용 정책 (scoped reuse policy), 거부 사례 (rejection cases) 및 True Cache 라우팅 (routing)의 메커니즘을 입증했습니다. 이 기사에서는 더 큰 실시간 워크로드 하에서 해당 패턴을 실행할 때 어떤 일이 발생하는지 측정하고 5가지 모드를 나란히 비교합니다.

중요한 변화는 토폴로지 (topology)입니다. 동일 호스트 설정은 경로 선택과 정확성을 증명하는 데는 훌륭하지만, Oracle True Cache가 줄이고자 하는 네트워크 거리를 압축해 버립니다. 이번 벤치마크를 위해 애플리케이션과 Oracle True Cache는 Phoenix 호스트에서 함께 실행되었고, 기본 Oracle AI Database 26ai 인스턴스는 Ashburn에서 실행되었습니다.

이를 통해 캐시 계층 (cache tier)에 실제적인 역할을 부여합니다. Phoenix 벤치마크 호스트에서 Ashburn 기본 리스너 (primary listener)로의 반복적인 TCP 연결 시간 프로브 (connect-time probes)는 20개 샘플에 대해 평균 약 52.0 ms, 중앙값 52.1 ms, p95 52.4 ms를 기록했습니다. 이는 비현실적인 배포 환경을 인위적으로 만들지 않고도 읽기 경로 (read route)를 의미 있게 만들기에 충분한 격차입니다.

이는 여전히 하나의 벤치마크 하네스 (benchmark harness), 하나의 워크로드 믹스 (workload mix), 하나의 동시성 설정 (concurrency setting), 하나의 제공자 모델 (provider model), 그리고 하나의 애플리케이션 형태 (application shape)를 대상으로 한 결과입니다. 이 수치들을 보편적인 운영 환경의 성능 주장으로 받아들이지 말고, 이 토폴로지 (topology)에 대해 측정된 증거로 취급하십시오.

원격-기본(Remote-Primary) 벤치마크 토폴로지

그림 1. 벤치마크 호스트와 Oracle True Cache는 Phoenix에서 함께 실행되는 반면, 기본 Oracle AI Database 26ai 인스턴스는 Ashburn에서 실행됩니다. 이는 읽기 캐시 계층 (read cache tier)과 기본 데이터베이스 사이에 현실적인 네트워크 격차를 유지합니다.

측정된 실행에는 커밋 e5ec761의 공개 데모 리포지토리가 사용되었습니다. Spring Boot 벤치마크 하네스 (benchmark harness)와 Oracle True Cache는 Phoenix 호스트에서 실행되었습니다. 기본 Oracle AI Database 26ai 인스턴스는 Ashburn에서 실행되었습니다. 실시간 OpenAI 호출을 통해 LLM 지연 시간 (latency) 및 토큰 계산 (token accounting)을 제공하였으며, 벤치마크 코드는 요청당 경로 (route), 결정 (decision), 지연 시간 (latency) 증거를 기록했습니다.

이러한 배치는 읽기 캐시에 의존하는 애플리케이션을 설계할 때 일반적으로 사용하는 방식에 더 가깝습니다. 애플리케이션을 캐시 계층 근처에 두고, 쓰기 (writes) 및 권위 있는 상태 (authoritative state)는 기본 (primary)에 유지하며, 구성된 경우 캐시를 사용하여 읽기 집약적인 트래픽이 더 멀리 떨어진 데이터베이스 경로로부터 보호되도록 합니다.

벤치마크 측정 항목

이 벤치마크는 동일한 레이블이 지정된 워크로드에 대해 다섯 가지 모드를 비교합니다. 단순히 "캐싱이 더 빠른가?"를 묻는 것이 목적이 아닙니다. 정확한 재사용 (exact reuse), 시맨틱 재사용 (semantic reuse), 읽기 라우팅 (read routing), LLM 호출 (LLM calls), 그리고 캐시 생성 비용 (cache-population cost)을 분리하는 것이 목적입니다.

no-cache는 베이스라인 (baseline)입니다. 캐시 조회를 수행하지 않으며, 모든 요청이 실시간 LLM을 호출하고, 재사용 가능한 데이터를 아무것도 기록하지 않습니다.

exact-cache는 먼저 정확한 키 조회 (exact key lookup)를 수행합니다. 정확한 히트 (exact hits)는 LLM을 거치지 않습니다. 미스 (misses)가 발생하면 LLM을 호출하고 기본 데이터베이스를 통해 재사용 가능한 캐시 상태를 기록합니다.

semantic-cache-primary는 기본 데이터베이스 경로를 대상으로 정확한 조회 (exact lookup) 및 벡터 검색 (vector search)을 수행합니다. 승인된 정확한 일치 (exact hits) 및 시맨틱 일치 (semantic hits)는 LLM을 거치지 않습니다. 미스 (misses) 및 유사 미스 (near misses)는 LLM을 호출하고 기본 데이터베이스에 쓰기 (write through)를 수행합니다.

semantic-cache-true-cache는 동일한 정확한 조회 및 시맨틱 조회 로직을 수행하지만, 적격한 읽기 전용 벡터 검색에는 Oracle True Cache를 사용합니다. 승인된 정확한 일치 및 시맨틱 일치는 LLM을 거치지 않습니다. 미스 및 유사 미스는 여전히 LLM을 호출하고 기본 데이터베이스에 쓰기를 수행합니다.

semantic-cache-write-through는 측정된 모든 요청에 대해 LLM을 호출하고 기본 데이터베이스에 쓰기를 수행합니다. 이는 읽기 재사용이 아닌, 인제스션 (ingestion) 및 쓰기 경로 (write-path) 비용을 측정합니다. 이 모드에서는 벤치마크가 동일한 측정 모드 동안 작성된 항목을 재사용하지 않도록 의도적으로 실행되므로, 결정 횟수 (decision count)는 순수한 미스 경로 (miss-path)의 증거가 됩니다.

그림 2. 다섯 가지 모드는 벡터 검색 실행 여부, 사용되는 데이터베이스 경로, 그리고 라이브 LLM 호출 시점을 변경하면서 워크로드 (workload)를 고정 상태로 유지합니다.

테스트 프레임워크 (harness)는 측정된 요청당 하나의 이벤트 행 (event row)을 기록합니다. 해당 행에는 모드, 재사용 결정, 데이터베이스 경로, 라이브 LLM 호출에 대한 원시 provider_calls 이벤트 횟수, 요청 지연 시간 (request latency), LLM 지연 시간 (LLM latency), 비-LLM 지연 시간 (non-LLM latency), OpenAI 응답 사용 필드(usage fields)의 토큰 수, 그리고 구성된 백만 토큰당 가격 기준 예상 비용이 포함됩니다.

이번 라이브 실행을 위해, 벤치마크는 60 s의 OpenAI 요청 타임아웃, 첫 번째 시도 후 최대 2회의 재시도, 그리고 1500 ms의 재시도 백오프 (retry backoff)를 사용했습니다. 이를 통해 일시적인 서비스 지연이 측정값에서 숨겨지지 않고 결과에 나타나도록 했습니다.

그림 3. 벤치마크 러너(benchmark runner)는 각 모드에 대해 동일한 워크로드(workload)를 전송하고 LLM 사용량, 결정(decisions), 데이터베이스 경로(database route), 지연 시간(latency), 토큰(tokens) 및 예상 비용을 기록합니다.

측정 실행에 사용된 정확한 배포 구성

시간 측정 결과를 살펴보기 전에, 인프라 구성을 명확히 하는 것이 도움이 됩니다. 측정 실행에는 두 개의 리전(region)을 사용하는 OCI 레이아웃이 사용되었습니다. 애플리케이션과 Oracle True Cache는 Phoenix에 함께 배치되었고, 기본(primary) Oracle AI Database 26ai 인스턴스는 Ashburn에 배치되었습니다.

구성 요소	배치 위치	사용된 구성
Spring Boot 벤치마크 앱	OCI us-phoenix-1	벤치마크 VM에서 Oracle True Cache와 나란히 실행됨
...

그림 4. 측정 실행에는 두 개의 OCI 리전, 별도의 VCN 및 퍼블릭 서브넷(public subnets), 애플리케이션과 Oracle True Cache를 모두 호스팅하는 Phoenix 벤치마크 VM, 그리고 Ashburn DB 시스템 프라이머리가 사용되었습니다. 운영자 SSH, JDBC 트래픽 및 True Cache 서비스 트래픽에 필요한 포트만 개방되었습니다.

네트워크 제어는 의도적으로 좁게 설정되었습니다. Phoenix 벤치마크 VM은 CIDR 10.74.0.0/16인 VCN semantic-cache-phx-vcn과 CIDR 10.74.10.0/24인 퍼블릭 서브넷 semantic-cache-phx-public에 위치했습니다. Ashburn 프라이머리 데이터베이스는 CIDR 10.64.0.0/16인 VCN semantic-cache-benchmark-vcn과 CIDR 10.64.10.0/24인 퍼블릭 서브넷 semantic-cache-benchmark-public에 위치했습니다.

DB 시스템 네트워크 보안 그룹(Network Security Group)은 운영자 허용 목록(allowlist) 및 벤치마크 호스트 /32로부터만 22번 포트의 SSH와 1521번 포트의 SQL*Net 트래픽을 허용했습니다. 벤치마크 호스트 네트워크 보안 그룹은 운영자 허용 목록으로부터 22번 포트의 SSH를 허용하고, Ashburn 데이터베이스 호스트로부터 35220번 포트의 Oracle True Cache 리스너(listener) 트래픽을 허용했습니다. True Cache 인스턴스는 읽기 전용 적용 모드(read-only apply mode)로 설정되어, 기본(primary) 쓰기가 권한을 유지하는 동안 적절한 읽기 요청을 처리할 수 있었습니다.

이러한 레이아웃 덕분에 측정된 결과는 이전의 동일 호스트(same-host) 테스트보다 더 유용합니다. 애플리케이션은 Oracle True Cache와 가깝게 유지된 반면, 기본 데이터베이스는 OCI 리전 간에 실제 원격 종속성(remote dependency)으로 남아 있었기 때문입니다.

측정 실행에 사용된 구성 (Configuration)

벤치마크 구성은 검토하기에 충분히 작으면서도, 여러 워크로드 패밀리(workload families)에 걸친 재사용 동작을 보여줄 수 있을 만큼 충분히 크게 의도적으로 설정되었습니다.

설정 (Setting)	값 (Value)
모드당 요청 수 (Requests per mode)	100
...

각 측정된 캐시 모드 이전에, 테스트 프레임워크(harness)는 워크로드 패밀리당 하나의 캐시 엔트리를 시딩(seed)하고 설정된 프리웜(prewarm) 일시 중지 시간을 기다렸습니다. 이는 캐시 중심 모드들이 프리웜 비용을 측정 구간 내에 숨기지 않고, 따뜻한 상태(warm)로 시작되었음을 의미합니다.

프리웜 횟수가 25가 아닌 26인 이유는, 불일치(mismatch) 지향형 워크로드 패밀리 하나가 기본 범위(primary scope)와 해당 시나리오에서 사용되는 대체 불일치 범위(alternate mismatch scope)를 모두 사전 시딩하기 때문입니다. 이를 통해 범위 지정 재사용(scoped-reuse) 확인이 우연한 콜드 미스(cold miss)에 의존하지 않고 이벤트 스트림 내에서 명시적으로 유지됩니다.

이 결과 세트의 벤치마크에는 동시성(concurrency) 1이 사용되었습니다. 이는 벤치마크의 초점이 부하 테스트 포화(load-test saturation)가 아닌 시맨틱 캐시(semantic-cache) 동작에 맞춰져 있는 동안, 데이터베이스 경로 증거와 지연 시간(latency) 계산을 더 쉽게 해석할 수 있도록 합니다.

데이터베이스 경로 증거 (Database Route Evidence)

LLM 호출을 피했다는 사실만으로는 Oracle True Cache가 의도된 읽기 경로를 처리했음을 증명할 수 없습니다. 따라서 벤치마크는 경로 가시성(route visibility)을 확인하고 각 측정된 요청에 대해 사용된 경로를 기록했습니다.

증거 항목 (Evidence item)	측정값 (Measured value)
가시적인 기본 경로 객체 (Primary route objects visible)	2
...

요청당 이벤트 스트림(event stream)은 모드별 경로 수를 다음과 같이 기록했습니다:

모드 (Mode)	기본 경로 이벤트 (Primary route events)	True Cache 경로 이벤트 (True Cache route events)	데이터베이스 경로 없음 (No database route)
no-cache	0	0	100
...

이러한 경로 수는 중요합니다. semantic-cache-true-cache 모드는 적합한 읽기 전용 조회(read-only lookup) 트래픽을 True Cache를 통해 라우팅한 반면, 미스(miss), 쓰기(write) 및 벤치마크 이벤트 기록은 계속해서 기본 데이터베이스를 사용했습니다.

exact-cache 분리 또한 예상된 결과입니다. 이 테스트 프레임워크(harness)에서 프롬프트 해시(prompt-hash) 조회는 구성된 읽기 경로를 사용하므로, 정확히 일치하는 히트(exact-hit) 읽기는 True Cache 측에서 나타날 수 있습니다. 미스(miss)가 발생하는 요청은 여전히 새로운 생성 및 쓰기(write-back)를 위해 기본 데이터베이스로 흐릅니다.

모드별 결과 (Results by Mode)

첫 번째 결과 세트는 실제 경과 시간(wall-clock time), 처리량(throughput), 그리고 지연 시간 백분위수(latency percentiles)를 비교합니다. 이는 엔드 투 엔드(end-to-end) 요청 측정값이므로, 라이브 LLM을 더 자주 호출하는 모드는 자연스럽게 제공자 측의 변동성(variance)을 더 많이 포함하게 됩니다.

모드 (Mode)	요청 수 (Requests)	실제 경과 시간 (Wall clock)	초당 요청 수 (Requests/sec)	p50	p95	p99
no-cache	100	142365 ms	0.70	1225 ms	2080 ms	5175 ms
...

그림 5. LLM 시간과 비(non)-LLM 시간으로 분리된 엔드 투 엔드(end-to-end) 지연 시간. 라이브 LLM의 변동성이 여전히 상단 막대(top-line bars)를 지배하고 있으며, 이것이 아래의 캐시 히트(cache-hit) 뷰가 필수적인 이유입니다.