온라인 언어 모델에는 적어도 두 개의 시계가 있습니다. 첫 토큰까지의 시간(TTFT)은 요청 수락, 캐시 조회, 프리필을 포함합니다. 출력 토큰당 시간(TPOT)은 반복되는 디코드 경로의 지연을 잽니다. 여기에 프리픽스 캐시, 프리필과 디코드의 분리, 텐서 병렬화, 전문가 병렬화가 붙습니다[2][3]. SLO를 넘긴 요청 하나의 원인은 스케줄링, 통신, 느린 커널, 과부하 링크, 캐시 상태, 아주 짧은 자원 경합 중 어디에나 있을 수 있습니다.
모든 것을 상세히 추적하면 해결될 듯하지만 커널과 통신 이벤트를 상시 기록하면 CPU, GPU 메모리, 스토리지를 사용해 추론 서비스 자체를 바꿉니다. Alibaba의 StriaTrace는 필요한 근거를 단계적으로 수집합니다[1]. 비용이 작은 구조 정보는 계속 남기고, 이상이 나타날 때만 상세 기록을 확장합니다. 두 주요 서비스의 1,700개 넘는 인스턴스에서 6개월간 운영됐으며 하루 요청량은 1억8천만 건 이상입니다. 보고된 추적 오버헤드는 1% 미만이고 비교 대상보다 97.8% 낮습니다. 이 자료로 19종의 근본 원인을 진단했습니다.
추론 추적 기록은 학습 추적 기록과 달라야 할 이유
학습 관측은 긴 반복 단계와 반복되는 집합 통신 구간을 요약하는 경우가 많습니다. 온라인 추론은 프롬프트 길이, 출력 길이, 캐시 상태, 도착 시점이 다른 요청을 섞습니다. 프리필과 디코드가 서로 다른 장비에서 실행될 수도 있습니다. 짧은 이상은 반복 단계 평균에 묻히고, 모든 이벤트를 남기면 보관할 수 없는 양이 됩니다.
StriaTrace는 운영 환경 경험에서 세 원칙을 뽑았습니다. 동기화 지점은 기다림을 드러내므로 인과 관계의 경계를 보존합니다. 요청의 임계 경로에 있는 이벤트만 지연시간을 늘립니다. 상세 이벤트는 이상 구간 가까이에서 가치가 가장 큽니다. 상시 계층은 단계를 재구성하고 어떤 단계가 정상 범위를 벗어났는지 알 수 있을 정도의 타이밍을 기록합니다. 트리거가 작동하면 의심 구간의 커널과 통신 정보를 더 깊게 수집합니다.
항상 영상을 찍기보다 비행 기록 장치를 두는 방식에 가깝습니다. 성긴 기록으로 언제 어디서 느려졌는지 찾고, 확대된 기록으로 그 시간을 무엇이 썼는지 확인합니다. 요청과 단계의 동작이 트리거를 만들기 때문에, 일반 프로파일러를 붙이기 전에 사라지는 간헐적 이상도 잡을 수 있습니다.
느린 단계에서 원인 후보로
기록만으로는 SLO 위반을 설명할 수 없습니다. StriaTrace는 추론 단계마다 실행 상황에 맞춘 성능 상한선을 회귀 분석으로 계산합니다. 일반적인 루프라인(roofline)은 연산량과 데이터 이동량, 하드웨어 한계를 연결합니다. 추론에서는 요청 상태, 배치 구성, 모델 단계에 따라 예상 경계도 달라져야 합니다. 정상적으로 처리할 일이 많아 오래 걸린 단계와 주어진 조건에서 제 성능을 내지 못한 단계를 구분하는 역할입니다.
진단 단계는 비정상 단계를 서빙 스택의 이벤트와 지표에 맞춰 봅니다. 연산 한계에서 벗어나면 커널 실행이나 자원 경합을 살피고, 통신 형태의 이탈이면 집합 통신과 네트워크 신호를 확인합니다. 동기화 경계의 대기 시간을 보면 늦게 도착한 구성원과 그 구성원을 기다리느라 영향을 받은 구성원을 분리할 수 있습니다. 결과는 모든 경우를 증명하는 단일 원인이 아니라, 엔지니어가 조사할 수 있도록 추적 기록의 문맥을 붙인 좁은 후보 목록입니다.
분산 추론에서는 하나의 원인이 여러 증상으로 복제됩니다. 전문가 병렬 랭크 하나가 느리면 모든 피어의 집합 통신 시간이 길어집니다. 이용률만 보면 영향을 받은 랭크가 여럿 나타납니다. 임계 경로와 동기화 근거는 지연을 처음 만든 랭크와 그것을 기다린 랭크를 구분합니다.
운영 환경 수치가 확인해 주는 범위
배포 규모는 구체적입니다. 1,700개가 넘는 인스턴스, 두 개의 대형 서비스, 하루 1억8천만 건 이상의 요청, 6개월의 운영 환경 운영입니다. 통합형 배치와 prefill-decode 분리형 배치를 모두 포함하며 텐서 병렬, 데이터 병렬 구성에서도 사용됐습니다. 개발, 시험, 릴리스 과정에서 수백 건의 이상을 19개 근본 원인 유형으로 분류했습니다.
오버헤드 수치의 분모도 구분해야 합니다. 논문은 추적 오버헤드가 1%보다 작고, 평가한 다른 추적 방식보다 97.8% 낮다고 보고합니다. 97.8%는 추론 지연시간 개선율이 아닙니다. 관측 도구가 추가한 비용의 감소율입니다. 지나간 뒤 프로파일러를 붙이는 대신 추적 기록을 계속 켜 둘 수 있다는 데 운영 가치가 있습니다.
선택적으로 보는 만큼 보이지 않는 것도 있는 구조
선택적 추적은 트리거에 의존합니다. 생성 내용의 품질만 나빠지고 타이밍에는 이상이 없다면 StriaTrace가 찾을 대상이 아닙니다. 모든 요청이 서서히 느려지면 릴리스 비교나 외부 SLO가 잡지 않는 한 새로운 정상 범위에 흡수될 가능성도 있습니다. 상관관계는 진단 범위를 줄이지만, 함께 움직인 지표들이 사실은 같은 하위 원인의 결과일 수도 있습니다.
또 하나의 한계가 있습니다. 논문은 근본 원인 유형과 운영 환경 사례를 제시하지만, 외부 독자가 진단 정밀도와 재현율을 계산할 수 있는 공개 정답 데이터셋은 제공하지 않습니다. 실제 활용 범위의 근거는 강하지만 잘못된 진단 비율을 하나의 비교 숫자로 요약하지는 않았습니다. 비슷한 시스템을 검토하는 운영자라면 트리거를 어떻게 보정하는지, 상세 구간을 얼마나 보관하는지, 상위 원인 후보가 실제 수정으로 이어진 비율이 얼마인지 확인해야 합니다.
StriaTrace의 핵심은 관측 비용을 배분하는 방식입니다. 대규모 추론에서는 모든 이벤트를 계속 기록할 수 없고, 평균 카운터만으로는 원인을 설명하기 어렵습니다. 인과 구조는 상시 보존하되 이상이 감지된 요청에만 상세 기록을 추가할 수 있습니다. 이 방식은 진단을 장애 뒤에 수행하는 임시 프로파일링이 아니라 서빙 경로의 설계 요소로 만듭니다.
추적 예산은 트래픽 양보다 인과관계를 따라야 할 이유
실제 운용 결과에서 더 일반적인 관측 원칙을 읽을 수 있습니다. 사건의 가치는 발생 횟수와 비례하지 않습니다. 동기화 지점은 드물지만 어느 구성 요소가 핵심 경로를 늦출 수 있었는지 알려 줍니다. 세부 커널 사건은 많지만 SLO 위반으로 시간과 요청 범위를 좁히기 전에는 대부분 쓸모가 없습니다. StriaTrace는 상시 예산을 인과 구조에 쓰고, 유용할 가능성이 높아진 뒤에만 상세 정보를 수집합니다. 단순히 요청 표본 수를 줄인 것과 달리 부하를 낮추면서도 진단 근거를 보존하는 이유입니다.
이 방식에는 상세 기록을 여는 조건이 틀릴 수 있다는 새로운 실패 지점도 생깁니다. 희소 추적이 이상을 설명하는 동기화 관계를 남기지 못하면, 이후에 아무리 상세한 기록을 열어도 사라진 원인을 복원할 수 없습니다. 따라서 운영자는 부하 하나가 아니라 두 종류의 포착 범위를 측정해야 합니다. 실제 사건 중 쓸 수 있는 상세 기록을 연 비율과, 열린 상세 구간 중 올바른 진단으로 이어진 비율입니다. 논문의 19개 근본 원인 유형은 범위가 넓음을 보여 주지만, 도입자는 자신의 커널, 병렬화, 요청 라우팅에서 이 범위를 다시 검증해야 합니다.
용량 관점에서 최종 산출물은 보기 좋은 추적 기록이 아닙니다. SLO 아래에 머문 시간이 얼마나 줄었고 정상화에 들어간 엔지니어링 시간이 얼마나 감소했는지가 중요합니다. 진단마다 완화 조치, 재발 여부, 고객 영향을 연결하고 대표 사례를 회귀 시험으로 남기면 추적은 사후 분석 도구에서 배포 개선 체계로 바뀝니다. StriaTrace의 핵심 통찰은 추론 규모의 관측이 단계적인 판단 과정이라는 점입니다. 어디를 볼지 정할 구조만 계속 남기고, 근거가 생길 때 비싼 관측 창을 열며, 같은 원인이 실제 서비스에 다시 도달하지 않았음을 확인해야 합니다.
꼬리 지연에도 인과관계가 붙은 분모가 필요합니다. p99 하나에는 큐 대기, 프리필, 토큰별 디코딩, 인스턴스 사이 전송, 커널 실행, 네트워크 지연이 섞입니다. 평균 시간이 가장 큰 구성 요소를 줄여도 드물게 나타나는 핵심 경로가 그대로일 수 있습니다. StriaTrace의 동적 경계는 구성 요소를 전체 장비의 고정 기준과 비교하지 않고 해당 요청의 동작 조건에서 느렸는지를 묻는다는 점에서 유용합니다. 도입자는 모델 버전, 시퀀스 길이, 배치 정책, 하드웨어 세대가 바뀔 때도 모델이 잘 보정되는지 확인해야 합니다. 어제 트래픽으로 학습한 경계는 정상적인 작업부하 변화를 사건 경보의 홍수로 바꿀 수 있습니다.
선택적 상세 기록은 데이터 거버넌스 측면의 장점과 의무를 함께 만듭니다. 사건을 덜 모으면 저장량과 프롬프트, 식별자, 모델 동작이 노출될 표면이 줄어듭니다. 그러나 상세 기록이 열린 구간은 운영자가 오래 보관하고 자세히 살펴볼 가능성이 높은 비정상 요청입니다. 실제 설계에서는 추적 단계와 같은 세밀도로 민감 정보 제거, 접근 권한, 보존 기간을 정해야 합니다. 관측 비용은 실행 부하만이 아닙니다. 저장량 증가, 개인정보 노출, 잘못된 상세 기록 조건이 소모하는 사람의 주의까지 포함해야 상시 추적과 선택적 추적을 공정하게 비교할 수 있습니다.
포착 재현율이 첫 신뢰성 지표
선택적 추적은 상세 기록을 열 시점을 판단해 비용을 줄입니다. 이 판단 자체가 진단 시스템 앞의 검출기가 되며, 사건을 설명할 유일한 요청을 놓칠 수 있습니다. 따라서 독립 신호로 확인한 사건 가운데 쓸 수 있는 핵심 경로를 남기고 충분한 상세 구간을 연 비율을 먼저 측정해야 합니다.
큐 대기, 느린 집합 통신, 커널 정지, 라우팅 오류, 점진적 회귀는 서로 다른 신호를 냅니다. 갑작스러운 지연 봉우리에 맞춘 조건은 모든 요청이 조금씩 느려지는 릴리스를 놓칠 수 있습니다. 릴리스 카나리와 통제된 장애 주입으로 동기화 지점, 링크, 배치 큐, 커널을 의도적으로 늦춘 뒤 희소 기록이 인과 구조를 남기고 상세 창이 올바른 구간에서 열리는지 회귀 시험할 필요가 있습니다.
진단은 운영 결과까지 닫혀야 할 이유
원인 후보 목록이 최종 산출물은 아닙니다. 각 진단을 적용한 완화 조치, SLO 위반 변화, 같은 징후의 재발 여부와 연결해야 합니다. 느린 인스턴스를 우회해 서비스가 회복돼도 근본 원인은 열, 펌웨어, 네트워크 경로, 특정 커널에 남아 있을 수 있습니다. 사건 기록이 지연 회복에서 끝나면 우회 조치를 원인으로 잘못 학습하게 됩니다.
사람의 주의도 비용에 포함해야 합니다. 실행 오버헤드가 낮아도 불안정한 후보를 많이 만들어 엔지니어가 오래 읽으면 비싼 관측 시스템입니다. 첫 SLO 위반부터 실행 가능한 가설, 완화, 확인까지 걸린 시간과 사건당 엔지니어 시간을 함께 기록해야 선택적 상세 기록의 운영 가치를 판단할 수 있습니다.
추적 기록도 민감 정보
추론 기록에는 요청 식별자, 프롬프트에서 유래한 길이, 모델 라우팅, 고객 정보, 시간 패턴이 들어갈 수 있습니다. 선택적 수집은 전체 양을 줄이지만 이상 요청을 더 오래 보관하게 만들 수 있습니다. 상시 계층에는 인과관계 복원에 필요한 식별자와 동기화 시간만 남기고, 상세 필드는 별도 권한이 없으면 제거하거나 제한된 메타데이터로 바꿔야 합니다.
StriaTrace의 운영 가치는 희소 계층의 포착 재현율, 작업 변화에 맞는 동적 경계, 검증된 조치로 닫히는 진단 과정이 함께 있을 때 생깁니다. 이 조건을 갖추면 추적은 배포 뒤에 붙는 비용이 아니라 이미 확인한 장애 경로가 운영 환경으로 돌아오지 않게 하는 릴리스 기준이 됩니다.
관측 용량도 핵심 경로를 따라 계획해야 합니다. 요청 수가 늘었다는 이유만으로 모든 상세 기록 예산을 같은 비율로 키울 필요는 없습니다. 새로운 병렬화나 분리형 서빙이 동기화 경계를 늘리면 같은 요청률에서도 더 많은 인과 구조를 남겨야 합니다. 반대로 근본 원인과 관계없는 반복 사건은 요약해 사람의 주의를 보존할 수 있습니다. 저장량, 분석 처리량, 사건당 검토 시간을 함께 보여 줘야 관측 계층의 다음 병목을 찾을 수 있습니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약입니다. 인용 논문의 주장과 결과를 우리 표현으로 다시 썼습니다. 원문의 문장, 표, 도판은 옮기지 않았으며 두 도판은 이 글을 위해 새로 만들었습니다. USENIX는 발표 페이지에서 논문을 공개합니다. 저작권 (c) 2026 원저자.