표준이라던 TEI 추론 서버가 내 맥에서는 10배 느렸다

질문

개인 메모리 검색 한 번이 30초 타임아웃에 걸려 죽었다.
고칠 방법은 문서에 있었다. Hugging Face의 TEI(Text Embeddings Inference) 서버를 리랭커로 붙이면 된다고 했다.

그 "된다"는 어디서 측정된 값인가?
벤더의 벤치마크는 벤더의 기계에서 돌았다.
내 기계는 그 기계가 아니다.

판정

성능 주장은 벤더 발표 수치가 아니라 내 런타임의 실측으로 검증한 뒤에만 채택 근거가 된다.

검색이 죽는 구간을 단계별로 갈라보니 리랭킹이 35~55초를 먹고 있었다. 크로스인코더 모델을 가상머신의 CPU로 돌리고 있었기 때문이다.
표준 해법은 TEI였다. 같은 모델을 TEI 서버에 올리고 붙여서 재봤다.
같은 모델, 같은 HTTP 인터페이스인데 맥의 GPU에서 직접 돌리는 경로보다 10배 느렸다. 그래서 기각했다.

대신 같은 모델을 맥의 GPU에서 돌리는 작은 서버를 직접 짜서 사이드카로 붙였다. Hindsight 쪽에서 보는 호출 형식은 TEI와 같게 맞췄다.
검색 왕복 55.8초가 1.8~2.6초로 떨어졌다.

바뀐 것은 하드웨어가 아니라 판단 근거다.
"이게 표준 해법이다"를 "내 기계에서 이 숫자가 나온다"로 갈아끼웠다.

근거

원인을 먼저 계량했다

타임아웃은 증상이다. 원인은 단계를 갈라야 보인다.
고칠 지점이 정해진 뒤 같은 모델을 경로만 바꿔 같은 입력으로 돌렸다.

같은 모델, 같은 60쌍, 경로와 정밀도만 다르게
가상머신 CPU 35~55초
맥 호스트 CPU 2.66초
맥 GPU 단정밀 0.60초
맥 GPU 반정밀 0.17~0.28초

200배는 단위 연산 벤치의 값이고 55.8초와 1.8초는 배포 후 종단 왕복이다.
두 숫자는 같은 자로 잰 것이 아니라서 나란히 놓지 않는다.

표준 경로를 실측하고 기각했다

권장되는 길은 TEI였다. 잘 만들어졌고 널리 쓰인다. 그래서 쟀다.
왜 느린지는 파헤치지 않았다. 채택 판단에 필요한 것은 이유가 아니라 내 조건에서의 값이다.
구현만 교체했으므로 되돌리는 비용은 설정 한 줄이었고, 리랭커 입력 길이 상한은 512토큰으로 잠갔다.

기준 자체도 다시 쟀다

배포하고 나니 계획서의 합격선이 남았다. 리랭킹 구간 1초 미만.
실측은 무필터 검색 1.08초, 일반 질의 0.14~0.17초였다. 무필터 쪽이 선을 넘겼다.

입력 길이 상한을 절반으로 내리면 0.70초가 나온다. 기준은 통과한다.
그 길을 택하지 않았다.

계획이 정한 합격선 - 리랭킹 1초 미만
그 선이 나온 근거 - 165~281자 균일 벤치, 후보당 4밀리초
실제 메모리뱅크 - 후보당 10.6밀리초
기준 통과용 대안의 대가 - 순위 상관 0.9995가 0.984로

도달할 수 없게 그어진 선을 순위 품질을 팔아 맞추는 셈이었다.
계획의 기준은 미달로 확정해 남기고 실측값을 새 기준으로 수락했다.

벤더 수치를 의심하는 규율은 남의 수치에만 걸리는 게 아니었다.
내가 며칠 전에 적어둔 목표치도 내 워크로드가 아닌 곳에서 나온 숫자였다.

한계·재검토 트리거

이 판정은 기계 한 대, 워크로드 하나의 실측이다.
TEI가 다른 하드웨어에서 어떤 값을 내는지는 아무것도 말하지 않는다.
같은 이유로 이 글의 200배도 남에게 그대로 옮길 수 있는 숫자는 못 된다.
옮길 수 있는 것은 같은 모델과 같은 호출 형식을 고정하고 경로만 바꾸는 실험 설계다.

비용도 있다. 사이드카는 내가 유지한다.
상주 데몬과 워치독, 지연 상한을 감시하는 게이트가 딸려 왔다.
TEI를 썼다면 그 비용은 남의 것이었다.

2026-09 기준 / 재검토 트리거: TEI가 같은 모델·같은 호출 형식·같은 기계에서 자체 사이드카의 지연에 도달하는 것이 관측되면 사이드카를 은퇴시키고 이 판정을 다시 연다.