공식 추론 서버는 내 기계에서 10배 느렸다

질문

조회 한 번이 30초 타임아웃으로 죽었다.
고칠 방법은 이미 문서에 있었다. 공식 추론 서버를 붙이면 된다.

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

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

조회가 죽는 구간을 갈라보니 재정렬이 35~55초를 먹고 있었다.
표준 경로는 공개 추론 서버 Text Embeddings Inference였다. 붙여서 재봤다.
같은 모델, 같은 계약인데 네이티브 경로보다 10배 느렸다. 그래서 기각했다.

같은 모델을 이 기계의 가속기에서 돌리는 사이드카를 짜고 계약만 그대로 물렸다.
왕복 55.8초가 1.8~2.6초로 떨어졌다.

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

타임아웃은 증상이지 원인이 아니다.
고칠 자리가 정해진 뒤 같은 모델을 경로만 바꿔 같은 입력으로 돌렸다.

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

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

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

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

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

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

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

공칭을 의심하는 규율은 남의 수치에만 걸리지 않는다.
내가 며칠 전에 적어둔 목표치도 내 워크로드가 아닌 곳에서 나온 숫자였다.

이 판정은 기계 한 대, 워크로드 하나의 실측이다.
공식 경로가 다른 하드웨어에서 어떤 값을 내는지는 아무것도 말하지 않는다.
같은 이유로 이 글의 200배도 남이 쓸 수 있는 숫자가 아니다.
쓸 수 있는 것은 재보는 순서뿐이다.

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

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