온라인 언어 모델에는 적어도 두 개의 시계가 있다. 첫 token까지의 시간(TTFT)은 요청 수락, cache 조회, prefill을 포함한다. 출력 token당 시간(TPOT)은 반복되는 decode 경로의 지연을 잰다. 여기에 prefix cache, prefill과 decode의 분리, tensor parallelism, expert parallelism이 붙는다[2][3]. SLO를 넘긴 요청 하나의 원인은 scheduling, 통신, 느린 kernel, 과부하 link, cache 상태, 아주 짧은 자원 경합 중 어디에나 있을 수 있다.
모든 것을 상세히 추적하면 해결될 듯하지만 kernel과 통신 event를 상시 기록하면 CPU, GPU memory, storage를 사용해 추론 service 자체를 바꾼다. Alibaba의 StriaTrace는 필요한 근거를 단계적으로 수집한다[1]. 비용이 작은 구조 정보는 계속 남기고, 이상이 나타날 때만 상세 기록을 확장한다. 두 주요 service의 1,700개 넘는 instance에서 6개월간 운영됐으며 하루 요청량은 1억8천만 건 이상이다. 보고된 tracing overhead는 1% 미만이고 비교 대상보다 97.8% 낮다. 이 자료로 19종의 근본 원인을 진단했다.
추론 trace는 학습 trace와 달라야 한다
학습 관측은 긴 iteration과 반복되는 collective 구간을 요약하는 경우가 많다. 온라인 추론은 prompt 길이, 출력 길이, cache 상태, 도착 시점이 다른 요청을 섞는다. prefill과 decode가 서로 다른 장비에서 실행될 수도 있다. 짧은 이상은 iteration 평균에 묻히고, 모든 event를 남기면 보관할 수 없는 양이 된다.
StriaTrace는 production 경험에서 세 원칙을 뽑았다. synchronization point는 기다림을 드러내므로 인과 관계의 경계를 보존한다. 요청의 critical path에 있는 event만 지연시간을 늘린다. 상세 event는 이상 구간 가까이에서 가치가 가장 크다. 상시 계층은 stage를 재구성하고 어떤 step이 정상 범위를 벗어났는지 알 수 있을 정도의 timing을 기록한다. trigger가 작동하면 의심 구간의 kernel과 통신 정보를 더 깊게 수집한다.
항상 영상을 찍기보다 비행 기록 장치를 두는 방식에 가깝다. 성긴 기록으로 언제 어디서 느려졌는지 찾고, 확대된 기록으로 그 시간을 무엇이 썼는지 확인한다. 요청과 step의 동작이 trigger를 만들기 때문에, 일반 profiler를 붙이기 전에 사라지는 간헐적 이상도 잡을 수 있다.
느린 step에서 원인 후보로
기록만으로는 SLO 위반을 설명할 수 없다. StriaTrace는 추론 step을 위한 회귀 기반 동적 roofline을 만든다. 일반적인 roofline은 연산량과 데이터 이동량, hardware 한계를 연결한다. 추론에서는 요청 상태, batch 구성, 모델 단계에 따라 예상 경계도 달라져야 한다. 정상적으로 할 일이 많아 오래 걸린 step과 주어진 조건에서 제 성능을 내지 못한 step을 구분하는 역할이다.
진단 단계는 비정상 step을 serving stack의 event와 metric에 맞춰 본다. 연산 한계에서 벗어나면 kernel 실행이나 자원 경합을 살피고, 통신 형태의 이탈이면 collective와 network signal을 확인한다. synchronization 경계의 기다림을 보면 늦게 도착한 구성원과 그 구성원을 기다린 피해자를 분리할 수 있다. 결과는 모든 경우를 증명하는 단일 원인이 아니라, engineer가 조사할 수 있게 trace 문맥을 붙인 좁은 후보 목록이다.
분산 추론에서는 하나의 원인이 여러 증상으로 복제된다. expert-parallel rank 하나가 느리면 모든 peer의 collective 시간이 길어진다. utilization만 보면 동일한 피해자가 여럿 나타난다. critical path와 synchronization 근거는 늦은 생산자와 기다린 rank를 구분한다.
production 수치가 확인해 주는 범위
deployment 규모는 구체적이다. 1,700개가 넘는 instance, 두 개의 대형 service, 하루 1억8천만 건 이상의 요청, 6개월의 production 운영이다. 통합형 배치와 prefill-decode 분리형 배치를 모두 포함하며 tensor-parallel, data-parallel 구성에서도 사용됐다. 개발, 시험, release 과정에서 수백 건의 이상을 19개 근본 원인 유형으로 분류했다.
overhead 수치의 분모도 구분해야 한다. 논문은 tracing overhead가 1%보다 작고, 평가한 다른 tracing 방식보다 97.8% 낮다고 보고한다. 97.8%는 추론 지연시간 개선율이 아니다. 관측 도구가 추가한 비용의 감소율이다. 지나간 뒤 profiler를 붙이는 대신 trace를 계속 켜 둘 수 있다는 데 운영 가치가 있다.
선택적으로 보는 만큼 보이지 않는 것도 있다
선택적 tracing은 trigger에 의존한다. 생성 내용의 품질만 나빠지고 timing에는 이상이 없다면 StriaTrace가 찾을 대상이 아니다. 모든 요청이 서서히 느려지면 release 비교나 외부 SLO가 잡지 않는 한 새로운 정상 범위에 흡수될 가능성도 있다. 상관관계는 진단 범위를 줄이지만, 함께 움직인 metric들이 사실은 같은 하위 원인의 결과일 수도 있다.
또 하나의 한계가 있다. 논문은 근본 원인 유형과 production 사례를 제시하지만, 외부 독자가 진단 precision과 recall을 계산할 수 있는 공개 정답 dataset은 제공하지 않는다. 실제 활용 범위의 근거는 강하지만 잘못된 진단 비율을 하나의 비교 숫자로 요약하지는 않았다. 비슷한 시스템을 검토하는 운영자라면 trigger를 어떻게 보정하는지, 상세 구간을 얼마나 보관하는지, 상위 원인 후보가 실제 수정으로 이어진 비율이 얼마인지 확인해야 한다.
StriaTrace에서 가져갈 것은 관측 예산이라는 생각이다. 추론 규모에서 모든 기록은 공짜가 아니고, 평균 counter만으로는 설명할 수 없다. 인과 구조를 계속 보존하면서 요청이 이유를 제공할 때만 상세 정보에 비용을 쓰는 중간 지점이 있다. 이 방식은 진단을 장애 후의 긴급 profiler 작업이 아니라 serving path의 설계 요소로 만든다.
추적 예산은 트래픽 양보다 인과관계를 따라야 한다
실제 운용 결과에서 더 일반적인 관측 원칙을 읽을 수 있다. 사건의 가치는 발생 횟수와 비례하지 않는다. 동기화 지점은 드물지만 어느 구성 요소가 핵심 경로를 늦출 수 있었는지 알려 준다. 세부 커널 사건은 많지만 SLO 위반으로 시간과 요청 범위를 좁히기 전에는 대부분 쓸모가 없다. StriaTrace는 상시 예산을 인과 구조에 쓰고, 유용할 가능성이 높아진 뒤에만 상세 정보를 수집한다. 단순히 요청 표본 수를 줄인 것과 달리 부하를 낮추면서도 진단 근거를 보존하는 이유다.
이 방식에는 상세 기록을 여는 조건이 틀릴 수 있다는 새로운 실패 지점도 생긴다. 희소 추적이 이상을 설명하는 동기화 관계를 남기지 못하면, 이후에 아무리 상세한 기록을 열어도 사라진 원인을 복원할 수 없다. 따라서 운영자는 부하 하나가 아니라 두 종류의 포착 범위를 측정해야 한다. 실제 사건 중 쓸 수 있는 상세 기록을 연 비율과, 열린 상세 구간 중 올바른 진단으로 이어진 비율이다. 논문의 19개 근본 원인 유형은 범위가 넓음을 보여 주지만, 도입자는 자신의 커널, 병렬화, 요청 라우팅에서 이 범위를 다시 검증해야 한다.
용량 관점에서 최종 산출물은 보기 좋은 추적 기록이 아니다. SLO 아래에 머문 시간이 얼마나 줄었고 정상화에 들어간 엔지니어링 시간이 얼마나 감소했는지가 중요하다. 진단마다 완화 조치, 재발 여부, 고객 영향을 연결하고 대표 사례를 회귀 시험으로 남기면 추적은 사후 분석 도구에서 배포 개선 체계로 바뀐다. StriaTrace의 핵심 통찰은 추론 규모의 관측이 단계적인 판단 과정이라는 점이다. 어디를 볼지 정할 구조만 계속 남기고, 근거가 생길 때 비싼 관측 창을 열며, 같은 원인이 실제 서비스에 다시 도달하지 않았음을 확인해야 한다.
꼬리 지연에도 인과관계가 붙은 분모가 필요하다. p99 하나에는 큐 대기, 프리필, 토큰별 디코딩, 인스턴스 사이 전송, 커널 실행, 네트워크 지연이 섞인다. 평균 시간이 가장 큰 구성 요소를 줄여도 드물게 나타나는 핵심 경로가 그대로일 수 있다. StriaTrace의 동적 경계는 구성 요소를 전체 장비의 고정 기준과 비교하지 않고 해당 요청의 동작 조건에서 느렸는지를 묻는다는 점에서 유용하다. 도입자는 모델 버전, 시퀀스 길이, 배치 정책, 하드웨어 세대가 바뀔 때도 모델이 잘 보정되는지 확인해야 한다. 어제 트래픽으로 학습한 경계는 정상적인 워크로드 변화를 사건 경보의 홍수로 바꿀 수 있다.
선택적 상세 기록은 데이터 거버넌스 측면의 장점과 의무를 함께 만든다. 사건을 덜 모으면 저장량과 프롬프트, 식별자, 모델 동작이 노출될 표면이 줄어든다. 그러나 상세 기록이 열린 구간은 운영자가 오래 보관하고 자세히 살펴볼 가능성이 높은 비정상 요청이다. 실제 설계에서는 추적 단계와 같은 세밀도로 민감 정보 제거, 접근 권한, 보존 기간을 정해야 한다. 관측 비용은 실행 부하만이 아니다. 저장량 증가, 개인정보 노출, 잘못된 상세 기록 조건이 소모하는 사람의 주의까지 포함해야 상시 추적과 선택적 추적을 공정하게 비교할 수 있다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약이다. 인용 논문의 주장과 결과를 우리 표현으로 다시 썼다. 원문의 문장, 표, 도판은 옮기지 않았으며 두 도판은 이 글을 위해 새로 만들었다. USENIX는 발표 페이지에서 논문을 공개한다. 저작권 (c) 2026 원저자.