제가 이것을 만들었습니다. 네, 맞습니다. 제 주요 프로젝트(yangble5)는 클라우드 업스트림(upstreams)으로의 라우팅에 관한 것이며, 이것이 로컬 추론(local inference)과 정반대라는 점을 알고 있습니다. 공개 사항: 저는 yangble5를 유지 관리하며 cache_bench.py를 작성했습니다. 저는 CLIProxyAPI와 관련이 없습니다. 영어가 제 모국어가 아닙니다. 이 초안을 다듬기 위해 LLM을 사용했으며, 이후 기술적 주장과 링크를 수동으로 확인했습니다. 제가 이것을 여기에 게시하는 이유는, 이것을 만드는 과정에서 독립형 벤치마킹 스크립트를 작성해야 했기 때문입니다. 이곳의 누구도 제 프록시 설정에는 관심이 없겠지만, 캐시 사용량을 보고하는 Anthropic 호환 /v1/messages 엔드포인트를 위해 설계된 도구는 실제로 여러분이 사용할 만한 것입니다. 포함된 트레이스(trace)는 CLIProxyAPI/Gemini 사용 관례를 검증하는 것이지, 모든 호환 가능한 구현을 검증하는 것은 아닙니다. 저는 원래 기준점(baseline)을 얻기 위해 이 스크립트를 작성했습니다. 긴 컨텍스트 페이로드(long context payload)를 사용한 초기 테스트에서, 2회차 이상의 읽기 속도(read rates)가 사실상 제로로 급락했습니다. 벤치마크 도구가 이 증상을 포착했지만, 라운드당 JSONL 행이 계정이나 선택된 업스트림 식별자 없이 수치적 사용량과 지연 시간(latency)만 기록했기 때문에, 왜 그런지 알아내기 위해 CLIProxyAPI의 소스 코드를 파헤쳐야 했습니다. 확인 결과, CLIProxyAPI의 동일 별칭(same-alias) 모델 풀(model pool)은 인증 ID(auth ID), 제공자(provider), 요청된 별칭(requested alias)을 키로 사용하는 공유 라운드 로빈 오프셋(round-robin offset)을 사용하여 멤버를 선택하며, 해당 키에는 세션 식별자(session identity)가 포함되지 않았습니다. 라우팅 전략과 세션 어피니티(session affinity)가 자격 증명 선택에는 참여하지만, 풀 멤버 선택을 세션 스티키(session-sticky)하게 만들지는 않습니다. 이로 인해 하나의 대화에 대한 캐시 지역성(cache locality)이 여러 업스트림 모델로 분산될 수 있습니다. 저는 이 동작을 업스트림에 보고했으며( https://github.com/router-for-me/CLIProxyAPI/issues/4600 ), 모델 풀을 완전히 우회함으로써(fill-first 및 12시간 세션 어피니티를 사용하는 직접적인 1:1 모델 별칭 사용) 제 설정에서 이를 해결했습니다. 저의 초기 '제로에 가까운 웜 리드(warm reads)'는 관찰 결과일 뿐, 통제된 풀 대 직접(pool-vs-direct) A/B 테스트가 아니므로, 측정된 인과적 개선을 주장하는 것은 아닙니다. 해당 해결책을 적용한 후, 깨끗한 트레이스를 캡처하기 위해 벤치마크를 다시 실행했습니다.

제 수치를 신뢰할 필요는 없습니다. 직접 리포지토리(repo)를 가져와 오프라인에서 로그를 다시 재생해 볼 수 있습니다: python tools/cache_bench.py --replay evidence/run-749k-20260721.jsonl. 해당 수정된 트레이스(trace)를 다시 재생하면, 워밍 라운드(warm rounds) 전체에 걸쳐 엔드포인트가 보고한 토큰 가중치 기반 프롬프트 캐시(prompt-cache) 읽기 비율이 99.53%로 출력됩니다. 도구 자체가 출력하는 한정 조건들을 포함하여, 해당 실행에 대한 정확한 제약 조건은 다음과 같습니다: 이 도구는 이 하네스(harness)의 상한선(라운드당 15개 토큰의 꼬리 부분)일 뿐, 일반적인 값은 아니라고 명시적으로 경고합니다. 라운드당 단 15개의 토큰만 추가하는 것은 읽기 비율을 인위적으로 100%에 가깝게 밀어 올리는 반면, 실제 대화에서는 수백 또는 수천 개의 토큰이 추가됩니다. 이는 워밍 라운드 2에서 4까지의 토큰 가중치 기준입니다. 이 트레이스에서 라운드 1은 콜드 요청(cold request)이었으며 정확히 0%로 측정되었으므로 제외되었습니다. 엔드포인트는 요청을 수락했으며 748,918개의 입력 토큰(~749K)을 보고했습니다. 저는 이 길이에서 회상(recall) 능력이나 모든 토큰이 추론(inference)에 영향을 미치는지 여부는 테스트하지 않았습니다. 이것은 지연 시간(latency)에 대한 주장이 아닙니다. 세 번의 워밍 라운드 중 두 번이 콜드 라운드보다 느렸습니다. 단일 머신, 2026-07-21에 실행된 단일 실행(Windows 11)이며, 제공자의 부하를 제어할 수 없는 공유 업스트림(upstream)을 대상으로 했습니다. 기반이 되는 프록시 엔진은 CLIProxyAPI 7.1.23이었습니다. CLIProxyAPI는 외부 MIT 라이선스 프로젝트이며, 제가 작성한 것이 아니며 그 공로를 주장하지도 않습니다. 벤치마킹 스크립트와 트레이스 파일은 리포지토리에 있습니다: https://github.com/shark0120/yangble5 /u/Appropriate_Heat_866 에 의해 제출됨 [link] [comments]