LLM 벤치마크의 간헐적 지연: 원인 분석과 측정 규약

모델 구조별 추론 성능을 비교하던 중 간헐적 지연을 관측했다. 모델과 실행 옵션이 같아도 일부 반복에서 시간이 늘었다. 이 변동을 구조의 효과와 구분하지 못하면, 시스템의 일시적인 상태를 아키텍처의 특성으로 오인할 수 있다.

로그 출력, CPU 이동, 예열 방식, 주파수를 차례로 조사했다. CPU 실행 상태가 GPU 추론 시간에 영향을 준다는 사실을 확인했다. 자연 발생 지연의 원인은 일부만 좁혔다.

기존 자료를 재분석한 뒤, 목표로 정한 10% 수준의 구조 차이를 탐색할 근거가 있다고 판단했다. 측정 규약을 고정하고 진단을 종료했다.

연구 목표와 후보 공간

에이전트의 성능 법칙 발견 능력을 평가하기 위해 Transformer 후보 공간을 정의하고, 구조 비교에 앞서 측정 신뢰성을 검증했다.

최종 목표는 Jetson Orin Nano와 Snapdragon Elite NPU 노트북에 맞는 모델 구조와 실행 조건을 찾는 것이다. 먼저 RTX PRO 6000 Blackwell에서 후보 생성과 측정 파이프라인을 검증했다. 장치 간 성능 순위가 유지되는지는 각 타깃에서 검증해야 한다.

후보 공간은 dense Llama 계열의 decoder-only Transformer로 제한했다. 헤드 차원, 헤드 수, GQA 비율, MLP 비율, 레이어 수, 양자화, 시퀀스 길이를 바꾼다. 여기서 GQA 비율은 Q 헤드 수를 KV 헤드 수로 나눈 값이다.

초기 명세는 25개 구조, 75개 고유 GGUF, 100개 실행 조건이다. 구조마다 길이 512에서 F16·Q8_0·Q4_0을 비교하는 75개 조건을 정의했다. 여기에 다른 길이를 비교하는 25개 조건을 더했다. 첫 RTX 파일럿은 작은·중간·큰 구조의 9개 GGUF와 12개 조건으로 제한했다. prefill과 decode를 분리해 분석 항목은 24개다.

GGUF는 모델 데이터를 저장하는 파일 형식이다. llama.cpp 실행기를 백엔드에 맞게 빌드했다. 각 구조의 무작위 가중치를 GGUF로 생성해 로드하고 실행 비용을 측정했다. 문장 품질은 평가하지 않았다. 학습된 가중치와 실행 경로·성능이 같은지도 검증하지 않았다.

연구 가설은 다음과 같다.

H1: 에이전트가 기호 회귀(PySR)보다 적은 측정으로 roofline 예측의 잔차를 설명하는 규칙을 찾는가? 여기서 잔차는 계산량·메모리 이동량으로 예상한 비용과 실제 측정의 차이다.
H3: 에이전트는 노이즈를 법칙으로 오인하거나, 자신이 만든 가설을 반박할 실험을 회피하는가?

두 가설을 평가하려면 구조 효과와 측정 변동을 구분해야 한다. 이를 위해 반복 측정과 원인 분석을 먼저 수행했다.

실행 조건과 분석 단위

실행 조건과 예열 횟수를 고정하고, 프로세스 내부 반복의 평균을 분석 단위로 삼았다.

실험 환경은 RTX PRO 6000 Blackwell 96GB, Intel Core i9-10900X, CUDA 13, NVIDIA 드라이버 580.173.02였다. llama.cpp는 커밋 48e985756788b4a6c50933a88e0af1aa8412b68d로 고정했다. 전체 레이어 GPU offload, CPU 스레드 4개, batch 512, ubatch 128, flash attention off, KV cache F16을 사용했다. 시스템 클록·governor 정책은 바꾸지 않았다.

prefill에서는 입력 S개 토큰의 처리 시간을 측정했다. decode에서는 길이 S의 KV 상태를 준비한 뒤 64 step의 시간을 측정했다. 컨텍스트 길이는 S부터 S+63까지 늘어난다. 별도 표기가 없으면 decode 수치는 64 step 전체 시간이다.

초기 반복에서 지연을 관측한 뒤 후속 프로토콜을 정했다. 새 프로세스마다 25회 실행하고 앞 20회를 예열로 고정했다. 뒤 5회로 대표값을 계산하되 원본 25회는 모두 보존했다. 개별 측정값에 따라 표본을 제외하지 않았다.

분석 단위는 프로세스다.

독립 프로세스 1개
  ├─ 앞 20회: 고정 예열, 원자료 보존
  └─ 뒤  5회: 평균 → 프로세스 대표값 1개

독립 프로세스 10개
  └─ 대표값 10개의 중앙값 → 해당 조건의 대표 시간

프로세스 내부의 5회 반복은 실행 상태를 공유한다. 따라서 10개 프로세스에서 얻은 50개 타이밍의 독립 표본 수를 50으로 계산하지 않았다. 프로세스 간에도 같은 세션의 온도나 부하 변화에 따른 상관이 남을 수 있다.

반복 횟수와 안정성 판정

반복을 3회에서 10회로 늘려도 대표값은 비슷했지만, 드문 지연이 더 드러나 안정성 기준을 통과한 항목은 줄었다.

이전 3라운드와 동일한 조건을 새로운 10라운드로 반복했다. 24개 항목에 각각 새 프로세스 10개, 총 240개 프로세스다. 원본 타이밍은 6,000개, 예열 뒤 보존한 타이밍은 1,200개였다.

지표	관측 결과
이전 대비 대표값 변화의 절댓값 중앙값	약 0.12%
이전 대비 대표값 변화의 최대 절댓값	약 1.24%
기존 안정성 표시를 통과한 항목	22/24 → 17/24

기존 안정성 기준은 라운드 간 상대 범위와 프로세스 내부 변동계수(CV)가 각각 5% 이하인지 확인했다. 상대 범위는 (최댓값−최솟값)/중앙값, CV는 표준편차/평균이다. 이 기준은 변동을 표시할 뿐 통계적 동등성을 검정하지 않는다.

반복 횟수가 늘면 드문 지연을 관측할 확률도 높아진다. 최댓값이나 범위에 기반한 판정은 반복 횟수에 민감하다. 새 10라운드에서 3라운드를 고르는 120개 조합을 계산했다. 통과 항목은 20~24개로, 이전의 22개도 이 범위에 들었다. 조합끼리 표본을 공유하므로 독립 재현 실험 120회로 해석할 수는 없다.

대표값은 재현됐지만 간헐적 지연은 남았다. 통과 항목 수가 줄었다는 사실만으로 실행 환경이 악화됐다고 결론 내릴 수 없다.

프로파일러와 로그의 영향

로그는 실행 비용의 일부를 설명했지만 지연의 단일 원인은 아니었고, 프로파일러의 오버헤드는 원인 분석을 제한했다.

Nsight로 지연 구간을 추적했다. 해당 설정에서는 약 18~96%의 오버헤드가 발생했고 trace도 일부 누락됐다. 따라서 이 trace로 비계측 실행의 지연 원인을 판단하기 어려웠다. 오버헤드 수치는 이번 설정에 한정된다.

로그는 별도 대조 실험으로 확인했다. 파일 출력, 출력 폐기, 로그 비활성화를 균형 순서로 비교했다. 로그 off에서는 대표 시간이 Q8 약 3.08%, F16 약 2.04% 줄었다. 그러나 로그를 꺼도 지연은 남았다.

로그 출력은 실행 비용을 늘렸다. 그러나 로그를 제거해도 지연이 남았으므로 단일 원인으로 볼 수 없다. 계측 도구의 오버헤드도 원인 분석에 앞서 측정해야 한다.

CPU 실행 시간과 비실행 시간

경과 시간과 주 스레드의 CPU 시간을 함께 측정해, CPU 실행이 길어진 지연과 비실행 구간이 길어진 지연을 구분했다.

호스트 코드는 GPU 연산을 요청하고 완료를 기다린다. 전체 경과 시간과 주 스레드의 CPU 실행 시간을 함께 측정해 지연을 두 유형으로 나눴다.

경과 시간과 CPU 실행 시간으로 나눈 지연 유형. 원인은 별도로 검증해야 한다.

CPU 실행 시간이 늘었다면 호스트 작업량이나 실행 속도가 달라졌을 가능성이 있다. 경과 시간만 늘었다면 CPU에서 실행되지 않은 구간을 조사해야 한다. 여기서는 경과 시간−CPU 시간으로 비실행 시간을 근사했다. 이 값만으로 runnable 상태의 스케줄링 대기와 다른 대기를 구분할 수는 없다.

주 스레드를 특정 CPU에 고정한 배치에서는 꼬리 지연을 관측하지 못했다. 사건 수가 적어 고정 효과를 확정할 수는 없다.

강제 CPU 이동과 복구 대조 실험

강제 CPU 이동 뒤 늘어난 decode 시간은 GPU를 사용하지 않는 CPU-only 활동으로도 대부분 회복됐다.

주 스레드를 CPU 6과 8 사이에서 이동시키는 조건과 그대로 두는 조건을 비교했다. 이동 작업 자체는 측정 타이머 밖에 두었다. 그 실험에서 이동 조건의 decode는 짝 비교 기준 Q8 7.669%, F16 2.315% 느렸다. 두 형식 모두 24개 짝 전부에서 이동 조건이 느렸다.

이동한 CPU에서 GPU decode로 예열하자 지연이 줄었다. 이때는 CPU도 함께 실행되므로 GPU 캐시나 모델 데이터의 효과를 분리할 수 없었다.

이를 분리하기 위해 비슷한 길이의 세 가지 활동을 비교했다.

측정 전 활동	확인하려던 것
sleep	시간이 지나기만 해도 회복되는가
CPU-only 정수 연산	GPU·모델 데이터 접근 없이 회복되는가
GPU decode 예열	실제 decode 활동으로 회복되는가

이동 조건에서 Q8은 sleep 뒤 약 18.181ms, CPU-only 뒤 14.881ms, decode 예열 뒤 14.823ms였다. F16은 각각 21.876ms, 19.447ms, 19.440ms였다. CPU-only 활동으로도 대부분 회복됐다.

GPU 연산이나 모델 데이터 접근 없이도 회복됐으므로 GPU·모델 캐시만으로 설명하기는 어렵다. CPU 주파수가 유일한 원인인지는 검증하지 못했다. 예열 비용은 측정 타이머 밖에 있으므로 이 결과가 전체 요청 시간의 개선을 뜻하지도 않는다.

후속 실험마다 KV 복원 등 프로토콜이 달랐다. 따라서 캠페인 간 시간과 변화율을 동일한 기준값에 대한 개선으로 합산하지 않았다.

주파수 관측과 인과 추론의 한계

정수 작업에서는 주파수와 처리량의 연관을 확인했지만, 자연 decode 지연 전체를 주파수 변화로 설명할 근거는 확보하지 못했다.

CPU 이동 뒤 정수 작업을 1ms 구간으로 나눠 실행하고 APERF/MPERF 카운터를 읽었다. 주파수와 처리량은 이동 후 떨어졌다가 함께 회복됐다. 정수 작업에서는 두 값의 연관을 확인했다.

decode에서도 같은 현상이 발생하는지 확인했다. 기본 affinity와 주 스레드 고정, 주파수 계측 off/on을 교차해 24라운드·192프로세스를 실행했다. 강제 이동이나 추가 예열 없이 자연 지연을 관측했다.

자연 지연은 세 건이었다.

사례	관측한 사실	남은 한계
CPU 실행 시간 증가형 두 건	전체 약 22.39ms·22.54ms, CPU 이동 동반	주파수 계측 off에서 발생해 주파수 하락 여부를 모름
CPU 비실행 시간 증가형 한 건	전체 21.6405ms, CPU 시간 19.0399ms, 차이 약 2.6016ms	누가 CPU를 점유했는지와 정확한 대기 상태는 모름

비실행 시간 증가형에서는 비자발적 문맥 전환 5회가 관측됐다. 유효 주파수는 같은 프로세스의 다른 반복과 비슷했다. 이 사례를 큰 주파수 하락으로 설명할 근거는 없다. 나머지 두 건은 주파수를 측정하지 않았으므로 판단을 보류했다.

APERF/MPERF에는 해당 CPU에서 실행된 다른 작업과 인터럽트도 포함될 수 있다. 서로 다른 CPU의 카운터 차이를 계산하지 않도록 이동을 관측한 구간은 무효 처리했다. 관측 사이에 이동했다 돌아온 경우는 놓칠 수 있다.

Q8과 F16의 정상 주파수 수준도 달랐다. 따라서 정수 작업에서 측정한 약 4.6GHz를 F16 decode의 정상 기준으로 적용하지 않았다.

재분석과 진단 종료 기준

기존 240프로세스의 재분석을 근거로 10% 수준의 구조 차이를 탐색할 수 있다고 판단해 진단을 종료했다.

스케줄러 추적과 CPU 정책 대조 실험은 후속 과제로 남겼다. 현재 연구에서는 아키텍처 차이를 비교할 수 있는지가 우선이다.

누적 결과를 Claude Code의 Fable과 두 차례 검토했다. 첫 답변은 “자연 지연의 주파수 기전이 반증됐다”, “2% 미만은 식별할 수 없다”고 주장했다. 원자료가 두 주장을 뒷받침하지 않는다고 반론했고, Fable은 이를 철회했다. 이 검토는 사람이 주도한 탐색이다. H1/H3의 에이전트 성과에는 포함하지 않았다.

진단 종료 기준은 기존 목표인 10% 수준의 구조 차이를 탐색할 근거가 있는지로 정했다. 추가 GPU 실험 없이 기존 240프로세스를 재분석했다.

원자료의 25회와 앞 20회 제외·뒤 5회 평균을 대조했다.
이전 캠페인과 바이너리·모델·runner 해시, 환경 및 런타임 일치를 확인했다.
프로세스 평균들의 CV는 최대 **3.873%**였다.
조건별로 모집단 중앙값의 순서통계 신뢰구간을 계산했다. 구간 끝점과 관측 중앙값의 상대 차이는 최대 **4.502%**였다.

표본 10개를 정렬한 뒤 두 번째 값과 아홉 번째 값을 구간 끝점으로 사용했다. 독립·동일분포의 연속 표본을 가정하면 신뢰수준은 약 97.85%다. 이는 조건별 모집단 중앙값의 구간이다. 24개 조건의 동시 신뢰구간이나 두 구조 차이의 검정으로 해석할 수 없다. 더 보수적인 동시 구간에서는 상한/하한 비율이 1.10을 넘는 조건도 있었다. 모든 조건의 10% 차이를 확증한 결과는 아니다.

보조 분석에서는 관측 분포에서 두 그룹을 복원추출하고 한쪽에 ±10% 차이를 주입했다. 이 차이를 검출한 비율은 높았다. 다만 관측하지 못한 꼬리나 날짜별 드리프트는 재현하지 못한다. 따라서 이 비율로 미래 검정력을 보장할 수 없다.

이 결과를 근거로 구조 파일럿을 재개하기로 했다. 새 구조의 효과와 불확실성은 해당 측정 자료로 다시 평가한다.

측정 규약 v1과 진단 재개 조건

기존 프로토콜을 v1으로 고정하고, 비교를 막는 변동이나 연구 목표의 변화가 생길 때만 관련 진단을 재개한다.

24개 항목의 반복 자료를 확보한 기존 프로토콜을 v1으로 고정했다. 로그 off와 CPU 고정은 전체 구조에서 검증하지 않았다. 이 조건을 채택하면 규약 버전과 기준값을 새로 만들고 기존 자료와 분리한다. v1 측정값에는 로그 출력 비용이 포함된다.

항목	고정한 내용
실행 조건	고정 llama.cpp 커밋과 모델 해시, 전체 offload, threads 4, batch 512, ubatch 128, flash attention off, KV F16
CPU·로그·계측	기본 affinity, stderr 파일 출력, host/MSR/Nsight 계측 없음, GPU 경계 상태 기록
반복과 대표값	조건·phase당 10프로세스, 각 20회 예열+5회 보존, 프로세스 평균들의 중앙값
순서와 기준 모델	순서를 무작위화한 라운드, 중간 Q8·S512 모델을 phase별 기준으로 반복
변동과 꼬리	원자료 보존, 대표값과 별도 보고, 느린 표본을 선택적으로 제거하지 않음
비용	로드·예열·실패를 포함한 전체 하드웨어 시간을 기록

기준 모델의 첫 5라운드와 뒤 5라운드 대표값이 5% 넘게 달라지면 배치를 검토 대상으로 표시한다. 이 임계값은 새 운영 규칙이다. 안정성 경계로 검증하지 않았으며 표본 삭제에도 사용하지 않는다. 규약을 자동 적용하는 실행기는 아직 구현하지 않았다.

다음 조건에서만 관련 진단을 재개한다.

기준 모델의 드리프트나 실행 조건 불일치가 발생한다.
새 구조의 측정 불확실성 때문에 목표 효과를 비교할 수 없다.
배포 환경의 꼬리 지연을 연구 목표로 정한다.

자연 CPU 이동형 지연과 주파수의 관계, CPU 비실행 구간의 정확한 원인은 미해결 상태다.

교훈과 후속 실험

후속 실험은 실행 상태를 통제한 구조 비교부터 시작하고, 에이전트 평가는 규칙의 예측력뿐 아니라 반증과 불확실성 보고까지 포함한다.

모델과 실행 옵션을 고정해도 실행 상태까지 같아지지는 않았다. CPU 배치, 직전 활동, 로그와 계측이 측정값에 영향을 줬다.

후속 실험에서는 목표 효과 크기와 대표값을 먼저 정한다. 예열·로그·CPU 배치·반복 수를 고정하고 대표 성능과 꼬리 지연을 분리해 보고한다. 강제 개입으로 재현한 현상은 자연 지연에서 별도로 검증한다. 진단의 종료 기준도 실험 전에 명시한다.

에이전트는 규칙의 예측력과 적용 범위, 반증 실험 선택, 불확실성 보고를 기준으로 평가한다. 정답을 아는 합성 기기와 학습에 쓰지 않은 개입 조건을 준비한다. 에이전트와 기준선에는 같은 측정 접근 권한을 주고 비용을 기록한다.

다음 실험에서는 규약 v1으로 Q8 아키텍처 후보를 비교한다. 이후 실제 타깃에서 성능을 검증하고, 최소 에이전트와 PySR 등의 기준선을 같은 측정 예산으로 평가한다.

데이터와 범위

공개 자료는 10라운드의 프로세스 평균과 재분석 결과이며, 결론은 관측한 환경과 통계적 가정에 한정된다.

본문 수치는 2026년 10월 15일까지의 실험 기록에 근거한다. 공개 자료에는 기존 10라운드 캠페인의 프로세스 평균과 재분석 결과를 담았다. 다른 진단의 원본 trace는 포함하지 않았다.

공개 자료에서 장치 식별자와 내부 경로는 제외했다. 신뢰구간과 재표본화 결과는 관측 분포와 독립성 가정에 한정된다. 다른 날짜·장치·가중치·아키텍처는 별도로 검증해야 한다.