WEBVTT

00:00:00.000 --> 00:00:02.500
경고 메시지가 뜨더니 그 후로는 아무 소식이 없었습니다.

00:00:02.720 --> 00:00:05.200
gpu 사용료는 가속기가 실세 없이 작동하는 것처럼 치솟았지만

00:00:05.200 --> 00:00:07.300
출력은 마치 불이 꺼진 것처럼 느려졌습니다.

00:00:07.440 --> 00:00:10.180
대시보드는 정상이었지만 고객들은 불편을 겪었습니다.

00:00:10.480 --> 00:00:11.360
뭔가 이상했습니다.

00:00:11.720 --> 00:00:15.000
gpu 사용료는 거의 0에 가까운데 지연 시간은 급증했습니다.

00:00:15.240 --> 00:00:18.540
경고도 위험 신호도 없이 시간은 그저 흘러갈 뿐이었습니다.

00:00:18.760 --> 00:00:21.860
모든 정황은 정상처럼 위장한 하나의 병리 현상을 시사합니다.

00:00:22.140 --> 00:00:23.040
이제 약속드립니다.

00:00:23.360 --> 00:00:27.240
우리는 원인을 추적하고 범인을 밝혀내고 병리 현상을 해결할 것입니다.

00:00:27.240 --> 00:00:32.340
cpu 풀백, coda와 onnx 텐소르 버전 불일치, 컨테이너 구성 오류라는

00:00:32.340 --> 00:00:36.100
세 가지 오류 유형을 분석하고 해결 전후의 지연 시간, 처리량,

00:00:36.440 --> 00:00:38.440
gpu 사용률을 통해 이를 입증할 것입니다.

00:00:38.640 --> 00:00:43.540
사례 설정, 환경, 그리고 피해자 프로필, 모든 구성에는 이야기가 담겨 있으며

00:00:43.540 --> 00:00:46.640
이 이야기는 압박을 받는 평범한 테넌트에서 시작됩니다.

00:00:46.840 --> 00:00:50.400
이 워크로드는 텍스트 이미지 확산 처리이며 안정적인 확산 변형은

00:00:50.400 --> 00:00:54.540
512x512 해상도에서 실행되고 1024x1024까지 확장 가능합니다.

00:00:54.540 --> 00:00:58.200
트래픽은 버스트 형태로 발생하며 동시 요청수는 8에서 32개입니다.

00:00:58.340 --> 00:01:00.360
배치 크기는 1에서 8개로 유동적입니다.

00:01:00.600 --> 00:01:02.480
서비스 수준은 테일 레이턴시에 매우 영격하며

00:01:02.480 --> 00:01:05.440
p95점수 미달시 크레딧 및 페널티가 직접적으로 복과됩니다.

00:01:05.620 --> 00:01:08.780
사용된 모델은 특별히 독창적이지는 않지만 모델 선택이 매우 중요합니다.

00:01:08.940 --> 00:01:10.560
onnx는 안정적인 확산 파이프 라인,

00:01:10.820 --> 00:01:13.800
x포머즈 또는 스케일드 도트 프로덕트 어텐션과 같은 크로스 어텐션 최적화,

00:01:14.080 --> 00:01:16.940
그리고 처리 단계수를 줄이는 대신 품질을 우선시하는 스케줄러 선택 기술을 개발했습니다.

00:01:16.940 --> 00:01:20.820
이러한 생태계는 기반 시설이 제대로 구축되었을 때 가속화될 것으로 기대됩니다.

00:01:20.980 --> 00:01:22.900
하드웨어 사양은 스펙상으로는 훌륭합니다.

00:01:23.100 --> 00:01:27.340
클라우드 환경에서는 엔비디아 RTX 및 A 시리즈 그래픽카드가 16에서 32GB 위 VRAM을 제공합니다.

00:01:27.500 --> 00:01:30.420
호스트와 디바이스 사이에는 PCIe 슬롯이 마치 통행료 징수처럼 자리잡고 있습니다.

00:01:30.660 --> 00:01:31.920
제대로 구성되었을 때는 충분히 빠르지만,

00:01:32.200 --> 00:01:34.360
아이오 바인딩이 페이징 전송으로 전환될 때는 성능 저하를 초래합니다.

00:01:34.540 --> 00:01:36.560
이러한 환경에서는 모든 것이 위도적으로 결정됩니다.

00:01:36.740 --> 00:01:38.620
툴체인은 익숙한 계층 구조로 이루어져 있습니다.

00:01:38.620 --> 00:01:40.180
파이토치는 내보내기에 사용되고,

00:01:40.480 --> 00:01:42.520
ONNX 런타임 또는 텐소르가 추론을 담당합니다.

00:01:42.680 --> 00:01:44.960
CUDA 드라이버는 모든 것의 하위 계층에 위치합니다.

00:01:45.160 --> 00:01:47.860
어텐션 커널은 버전이 일치하면 빠른 속도를 제공합니다.

00:01:48.060 --> 00:01:49.280
배포는 연격하게 컨테이너화 되고,

00:01:49.600 --> 00:01:50.560
이미지는 변경 불가능하며,

00:01:50.800 --> 00:01:53.740
CI로 제어되는 롤아웃 방식과 정책에 따른 블루, 그린 배포 방식을 따릅니다.

00:01:53.920 --> 00:01:57.520
이러한 제약 조건은 안전성을 확보하는 동시에 결함을 조기에 발견하여 숨길 수 있도록 합니다.

00:01:57.700 --> 00:01:59.760
비즈니스적 이해관계는 추상적이지 않습니다.

00:01:59.960 --> 00:02:01.620
요청당 비용이 마진을 결정합니다.

00:02:01.620 --> 00:02:05.140
GPU 예약은 커널 실행 여부와 관계없이 시간 단위로 요금이 부과됩니다.

00:02:05.340 --> 00:02:08.560
지연 시간이 몇 초에서 30초로 늘어나면 처리량이 급격히 감소합니다.

00:02:08.760 --> 00:02:11.720
구성 오류 하나만으로도 가속기가 과부하 상태로 작동하여 비용이 많이 들고,

00:02:12.100 --> 00:02:14.640
아무런 작업도 하지 않고 대기열 처리에 아무런 도움이 되지 않습니다.

00:02:14.840 --> 00:02:17.420
자세히 살펴보면 문제의 원인은 명확해집니다.

00:02:17.580 --> 00:02:22.160
동시 실행수는 16개, 배치 처리수는 2개로 설정하여 512개의 GPU에서 VRM 상한선을 준수하고,

00:02:22.520 --> 00:02:24.620
품질 향상을 위해 2025개로 단계적으로 늘립니다.

00:02:24.820 --> 00:02:27.040
페넌트는 일관된 P95 점수를 기대합니다.

00:02:27.040 --> 00:02:31.400
하지만 트레이스 데이터는 불규칙적인 지연시간, P50과 P95 사이의 큰 차이,

00:02:31.660 --> 00:02:36.380
그리고 명확한 이유 없이 5%에서 40% 사이를 오르락 내리락하는 GPU 듀티 사이클을 보여줍니다.

00:02:36.580 --> 00:02:38.500
CPU 그래프는 다른 진실을 드러냅니다.

00:02:38.700 --> 00:02:41.560
전처리 작업이 없는데도 코어 사용률이 최고치에 달하는 현상이 나타납니다.

00:02:41.760 --> 00:02:43.600
이러한 현상은 3가지 가능성을 시사합니다.

00:02:43.820 --> 00:02:45.400
첫째, CPU 폴백입니다.

00:02:45.640 --> 00:02:50.260
CUDA 또는 텐소르 실행 공급자가 로드되지 않으면 엔진은 조용히 CPU 그래프를 선택합니다.

00:02:50.480 --> 00:02:53.000
모델은 작동하지만 지연시간이 10에서 30배 증가합니다.

00:02:53.200 --> 00:02:54.800
둘째, 버전 불일치입니다.

00:02:54.800 --> 00:02:59.500
ONNX 런타임이 특정 CUDA 버전을 기준으로 컴파일되었는데 노드에서는 다른 버전을 실행하고 있고,

00:02:59.960 --> 00:03:02.540
펜소르 엔진은 무효화되고 일반 커널로 다시 빌드된 경우입니다.

00:03:02.720 --> 00:03:05.300
사용률은 나타나지만 빠른 경로가 사라집니다.

00:03:05.500 --> 00:03:10.120
셋째, 컨테이너 구성 오류, 과도하게 큰 이미지, GPU 장치 마운트 누락,

00:03:10.480 --> 00:03:12.340
잘못된 엔비디아 컨테이너 툴킷 설정,

00:03:12.780 --> 00:03:15.820
그리고 부하시 지연시간을 증폭시키는 메모리 영역 할당 문제입니다.

00:03:16.000 --> 00:03:20.020
결국, 이는 모델에 대한 미스터리가 아니라 인프라의 정확성에 대한 문제입니다.

00:03:20.020 --> 00:03:24.800
우리는 아티팩트, 공급자 순서, 기능 로그, 장치 마운트를 추적하고,

00:03:24.940 --> 00:03:29.780
이를 세 가지 확실한 지표인 지연시간, 처리량 및 GPU 사용률과 연관시킬 것입니다.

00:03:31.020 --> 00:03:34.720
증거 파일 A, CPU 풀백, 조용한 방해꾼,

00:03:35.280 --> 00:03:38.920
몇 초면 충분해야 할 요청이 그렇지 않으면 서문제가 시작되었습니다.

00:03:39.140 --> 00:03:40.800
GPU 미터는 너무 조용했습니다.

00:03:41.160 --> 00:03:43.660
반면 CPU 그래프는 화재 경보처럼 치솟았습니다.

00:03:43.660 --> 00:03:45.900
자세히 살펴보니 엔진이 선택을 했습니다.

00:03:46.180 --> 00:03:48.400
GPU 비용이 드는 작업을 CPU에서 실행한 것입니다.

00:03:48.580 --> 00:03:49.880
경고는 발생하지 않았습니다.

00:03:50.080 --> 00:03:51.320
결국 출력은 반환되었습니다.

00:03:51.660 --> 00:03:53.980
이것이 바로 조용한 방해꾼, CPU 풀백입니다.

00:03:54.200 --> 00:03:55.560
왜 중요한지는 간단합니다.

00:03:55.820 --> 00:03:58.240
CPU에서의 안정적인 확산은 시간 동기화입니다.

00:03:58.500 --> 00:04:01.200
모델은 작동하지만 지연시간이 10에서 30배 느려지고,

00:04:01.380 --> 00:04:02.720
처리량이 급격히 떨어집니다.

00:04:02.920 --> 00:04:05.760
밀리초 단위로 판매되는 환경에서는 이러한 차이가 치명적입니다.

00:04:06.000 --> 00:04:07.520
비용은 계속 GPU 시간을 계산하지만,

00:04:07.660 --> 00:04:08.940
장치는 작업을 수행하지 않습니다.

00:04:09.140 --> 00:04:10.720
타임라인을 통해 패턴이 드러났습니다.

00:04:10.720 --> 00:04:13.680
CUDA를 사용하여 로컬에서 실행된 컨테이너는 매우 빠르게 작동했습니다.

00:04:13.820 --> 00:04:16.280
약간 다른 드라이버 스택을 사용하는 클러스터 노드에 배포했는데,

00:04:16.720 --> 00:04:19.800
동일한 컨테이너들이 부팅되고 상태 프로브를 제공한 후 상태가 저하되었습니다.

00:04:20.040 --> 00:04:22.460
상태 엔드포인트는 서버가 작동 중인지만 확인했을 뿐,

00:04:22.820 --> 00:04:25.000
GPU가 실제로 실행 중인지는 확인하지 않았습니다.

00:04:25.180 --> 00:04:27.800
이런 환경에서는 모든 것이 위도적으로 발생합니다.

00:04:27.980 --> 00:04:29.140
아무런 경고도 없습니다.

00:04:29.500 --> 00:04:33.120
핵심적인 원인은 ONNX 런타임의 실행 공급자 순서입니다.

00:04:33.440 --> 00:04:37.380
엔진은 목록을 받아서 텐소를, CUDA, CPU 순으로 시도합니다.

00:04:37.380 --> 00:04:42.260
CUDA 초기화에 실패하면 잘못된 드라이버, 누락된 라이브러리, 장치 마운트 실패 등,

00:04:42.460 --> 00:04:44.580
ORT는 조용히 CPU 실행 공급자들 사용합니다.

00:04:44.740 --> 00:04:46.960
예외도, 크래시도 발생하지 않고 로그에 한 줄만 남습니다.

00:04:47.220 --> 00:04:48.500
그것도 눈에 잘 띄지 않는 곳에 말이죠.

00:04:48.660 --> 00:04:50.680
CUDA 실행 공급자들 사용할 수 없습니다.

00:04:50.960 --> 00:04:52.040
CPU로 전환합니다.

00:04:52.280 --> 00:04:54.460
이 줄은 대부분의 팀이 익지 않는 고백과 같습니다.

00:04:54.860 --> 00:04:58.280
이상한 점은 사용률 차트가 처음에는 정상적으로 보인다는 것입니다.

00:04:58.500 --> 00:05:01.520
요청은 여전히 완료되고, 서비스 맵도 녹색으로 표시되지만,

00:05:01.960 --> 00:05:06.060
GPU 듀티 사이클은 5%에 머무르는 반면 CPU 사용자 시간은 높게 유지됩니다.

00:05:06.060 --> 00:05:09.340
P50 지연 시간은 4배로 증가하고, P95는 무너집니다.

00:05:09.460 --> 00:05:11.480
트래픽이 급증하면 상황은 더욱 악화됩니다.

00:05:11.640 --> 00:05:13.680
Q가 쌓이고 자동 스케일링으로 인해 복제본이 늘어나는데,

00:05:14.020 --> 00:05:15.660
이 복제본들은 모두 동일한 결함을 물려받습니다.

00:05:15.860 --> 00:05:19.080
마치 릴레이 경주에서 단거리 선수가 나타나지 않아 사서가 대신 뛰는 것과 같습니다.

00:05:19.360 --> 00:05:21.720
바통은 움직이지만 경주 속도로는 움직이지 않습니다.

00:05:21.920 --> 00:05:25.780
다시 말해, 시스템은 전체 SLO 예산을 희생하면서 정확성을 제공합니다.

00:05:26.000 --> 00:05:28.720
부팅 시퀀스를 추적하면 오류가 빠르게 누적됩니다.

00:05:28.920 --> 00:05:33.160
공급자로드 로그에는 드라이버 버전 확인과 함께 CUDA 초기화 시도가 표시됩니다.

00:05:36.060 --> 00:05:39.300
노드의 12버전만 있는 경우 초기화가 실패합니다.

00:05:39.500 --> 00:05:44.300
엔비디아 컨테이너 툴킷이 구성되지 않은 경우 컨테이너 내부에 장치 마운트가 나타나지 않습니다.

00:05:44.500 --> 00:05:46.700
데브, 엔비디아도 없고 리브쿠다도 없습니다.

00:05:47.000 --> 00:05:52.020
따라서 팟 사양에서 GPU를 명시적으로 요청하지 않으면 스케줄러는 장치를 할당하지 않습니다.

00:05:52.240 --> 00:05:55.620
이러한 문제 중 하나라도 발생하면 조용한 다운그레이드가 발생합니다.

00:05:55.840 --> 00:05:56.920
재현은 간단합니다.

00:05:57.200 --> 00:06:02.020
잘못 구성된 노드에서 간단한 추론을 실행하면 예상되는 텐서 RT 실행 공급자,

00:06:02.020 --> 00:06:06.980
CUDA 실행 공급자 대신 공급자, CPU 실행 공급자가 출력됩니다.

00:06:07.180 --> 00:06:10.680
워쿰프 12 프롬프트 하나를 누르면 GPU는 유유 상태로 유지됩니다.

00:06:10.880 --> 00:06:15.280
CPU 스레드 사용량이 급증하고 이미지 반환 시간이 2에서 6초가 아닌 20에서 40초로 늘어납니다.

00:06:15.460 --> 00:06:22.280
적절한 드라이버와 마운트가 설치된 노드에서 동일한 프롬프트를 실행하면 훨씬 짧은 시간 안에 완료되고 GPU 듀티의 사이클이 안정적인 범위로 상승합니다.

00:06:22.480 --> 00:06:25.580
이러한 증거는 현재의 안전장치가 형식적인 것에 불과함을 시사합니다.

00:06:25.580 --> 00:06:28.500
서버가 응답하기 때문에 상태 프로브는 200을 반환합니다.

00:06:28.660 --> 00:06:31.080
GPU 경로가 활성화되었는지 확인하는 시작 검증이 없습니다.

00:06:31.360 --> 00:06:34.940
성능 프로브가 존재하지 않으므로 오케스트레이션은 복제본이 정상이라고 판단합니다.

00:06:35.160 --> 00:06:37.800
시스템은 가속과 에뮬레이션을 구분할 수 없습니다.

00:06:38.120 --> 00:06:39.760
대응책은 설계상 투박합니다.

00:06:40.040 --> 00:06:43.960
GPU 실행 공급자가 없거나 성능이 저하된 경우 하드 실패를 발생시켜야 합니다.

00:06:44.200 --> 00:06:47.040
프로덕션 환경에서는 CPU로 시작하지 않도록 해야 합니다.

00:06:47.260 --> 00:06:51.260
프로세스 시작 시 공급자들 열거하고 텐서 RT 또는 CUDA 가로드 되었는지,

00:06:51.740 --> 00:06:53.960
장치수가 예상과 일치하는지 검증해야 합니다.

00:06:53.960 --> 00:06:56.840
기능 세트, QD에는 사용 가능한 텐서 코어,

00:06:57.100 --> 00:07:01.000
메모리 제한을 로그에 기록하고 누락된 항목이 있으면 0이 아닌 종료 코드를 반환해야 합니다.

00:07:01.140 --> 00:07:02.900
가용성을 희생하더라도 무결성을 유지하고,

00:07:03.240 --> 00:07:05.700
오케스트레이터가 정상적인 노드에서 재스케줄링 하도록 합니다.

00:07:05.860 --> 00:07:08.500
이를 유지하기 위해 IO 바인딩 검증을 강제합니다.

00:07:08.720 --> 00:07:12.660
입력과 출력을 장치 메모리에 바인딩하고 시작 시 간단한 추론을 검증합니다.

00:07:12.860 --> 00:07:16.020
융합된 어텐션 커널을 테스트하는 워밍업 실행을 한 번 수행합니다.

00:07:16.240 --> 00:07:20.260
타이밍이 지연 시간 기준을 초과하면 성능 저하 경로로 간주하고 파드를 실패 처리합니다.

00:07:20.260 --> 00:07:23.400
결정 론적 시드를 사용하는 카나리 프롬프트 세트를 추가합니다.

00:07:23.580 --> 00:07:25.620
지연 시간을 기준선 기간과 비교합니다.

00:07:25.840 --> 00:07:29.260
편차가 허용치를 초과하면 프로덕션을 중단하고 배포를 중지합니다.

00:07:29.460 --> 00:07:32.140
이는 다소 가혹해 보일 수 있지만 대안은 더 나쁩니다.

00:07:32.380 --> 00:07:35.520
시간과 예산을 낭비하면서 작동하는 클러스터를 만드는 것입니다.

00:07:35.740 --> 00:07:41.020
공급자 순서를 고정하고 CPU 폴백을 거부하며 시스템이 작동 중임을 입증하기 전에는 활성 상태로 간주하지 않습니다.

00:07:41.220 --> 00:07:43.440
그래야만 녹색 표시가 가속을 의미합니다.

00:07:43.440 --> 00:07:54.100
증거 파일 B, 버전 불일치, CUDA, ONNX, 텐소르 B 호환성, GPU가 사용되지 않은 경우 GPU가 존재하더라도 최대 속도로 작동할 수 있는지 여부가 다음 질문입니다.

00:07:54.280 --> 00:07:56.020
증거는 더 미묘한 오류를 시사합니다.

00:07:56.280 --> 00:07:59.680
버전은 실행될 만큼 일치하지만 고속 경로를 활성화할 만큼은 일치하지 않습니다.

00:07:59.880 --> 00:08:03.100
시스템이 가속화된 것처럼 보이지만 클럽을 자세히 살펴보면 그렇지 않다는 것을 알게 됩니다.

00:08:03.280 --> 00:08:04.880
왜 이것이 중요한지는 간단합니다.

00:08:05.080 --> 00:08:07.900
확산 파이프라인은 어텐션 성능에 따라 성패가 좌우됩니다.

00:08:07.900 --> 00:08:17.440
ONNX 런타임과 텐소르가 CUDA, CON 또는 텐소르 버전이 일치하지 않아 예상하는 커널을 로드하거나 융합할 수 없는 경우 조용히 일반 구현으로 전환됩니다.

00:08:17.620 --> 00:08:23.940
모델은 작동하지만 사용률은 30에서 50% 수준을 유지하고 지연시간은 예산을 초과합니다.

00:08:24.180 --> 00:08:26.920
빌드는 동일해 보이지만 작업 속도는 느려집니다.

00:08:27.140 --> 00:08:29.220
자세히 살펴보면 결과는 정확합니다.

00:08:29.460 --> 00:08:32.200
공급자 로드 로그에는 성공 메시지가 표시됩니다.

00:08:32.460 --> 00:08:35.980
기본 커널로 되돌아가거나 X포머즈가 비활성화된 것입니다.

00:08:35.980 --> 00:08:42.160
호환되지 않는 엔진 재구축으로 인해 텐소르 플랜 역 직렬화가 실패하고 노든의 컴파일이 트리거되는 것을 볼 수 있습니다.

00:08:42.360 --> 00:08:46.400
특정 마이너 버전의 텐소르에서 빌드된 엔진은 다른 마이너 버전에서 역 직렬화되지 않습니다.

00:08:46.580 --> 00:08:51.300
재구축은 완료되지만 결과 플랜에서 융합 어텐션이나 FP16 최적화가 누락될 수 있습니다.

00:08:51.500 --> 00:08:55.680
이렇게 경쟁이 종료되고 급격한 사용량 급증 없이 텐서 코어 듀티 사이클은 안정적으로 유지됩니다.

00:08:55.840 --> 00:08:57.600
여기서 직관에 반하는 부분이 나옵니다.

00:08:57.760 --> 00:09:00.440
팀들은 이 시스템이 최적의 상태로 실행된다고 해석합니다.

00:09:00.440 --> 00:09:03.040
하지만 이 환경에서는 모든 것이 우연이 아닙니다.

00:09:03.240 --> 00:09:10.480
스컬리드 프로덕트 어텐션이 활성화되어 있지 않거나 엑스포머즈 가꿔져 있거나 컨이 작업 공간이 제한적이라고 보고하면 성능이 급격히 저하됩니다.

00:09:10.640 --> 00:09:15.700
간단히 말해 바이너리가 일치하지 않으면 네모리 이동량이 많고 연산 밀도가 낮은 커널이 사용되기 때문입니다.

00:09:15.840 --> 00:09:18.220
PCI 이 관련 문제가 트레이스에서 드러나게 됩니다.

00:09:18.420 --> 00:09:20.700
동시성이 증가함에 따라 테일 레이턴시가 변동합니다.

00:09:20.900 --> 00:09:22.720
스택을 자물쇠 세트라고 생각해보세요.

00:09:22.720 --> 00:09:28.060
드라이버, CUDA 툴킷, CON, ONNX 런타임 빌드 플래그, 그리고 텐소르가 있습니다.

00:09:28.300 --> 00:09:31.220
자물쇠의 톱니 하나라도 어긋나 면 열쇠가 반만 돌아갑니다.

00:09:31.420 --> 00:09:33.720
ORT는 실행 공급자별로 기능 그래프를 제공합니다.

00:09:34.460 --> 00:09:42.680
컴파일된 ORT가 CUDA 12.1을 예상하지만 노드 드라이버가 12.1을 제공하는 경우 CUDA는 제한된 기능으로 로드되거나 아예 로드되지 않습니다.

00:09:42.880 --> 00:09:49.840
노드에서 텐소르가 8.6인데 실행 계획이 8.4로 생성된 경우 역직렬화가 실패하고 보수적 인 방식으로 다시 생성됩니다.

00:09:49.840 --> 00:09:55.200
이 시스템은 속도보다 정확성을 우선시하며 그로 인한 실질적인 손실이 벤치마크를 통해 입증됩니다.

00:09:55.400 --> 00:10:00.000
X포머즈 또는 SDP가 활성화된 경우 확산 어텐션은 실제 처리 시간을 현저하게 단축합니다.

00:10:00.180 --> 00:10:05.540
연구 결과는 해상도와 배치 크기에 따라 어텐션 경로에서 최대 2에서 5배의 속도 향상이 일관되게 나타남을 보여줍니다.

00:10:05.700 --> 00:10:09.160
버전 변경으로 인해 이러한 기능을 비활성화하면 해당 속도 향상 효과를 잃게 됩니다.

00:10:09.360 --> 00:10:12.560
토큰 병합, 톰은 이러한 속도 향상과 함께 작동합니다.

00:10:12.800 --> 00:10:17.540
융합 커널이 없으면 메모리 대역폭과 최적화되지 않은 레이아웃으로 인해 이점이 제한됩니다.

00:10:17.540 --> 00:10:21.420
1024x1024 이하의 동시 처리 환경에서는 이러한 격차가 더욱 커집니다.

00:10:21.540 --> 00:10:25.200
이러한 문제의 원인을 추적하려면 먼저 기능열거, 케퍼빌리티 이뉴머레이션 부터 시작하십시오.

00:10:25.300 --> 00:10:28.640
시작 시 정확한 공급자 목록과 보고된 기능을 출력하십시오.

00:10:28.740 --> 00:10:37.900
텐소르 버전, FP16 및 INTA 사용 가능 여부, 최대 작업 공간, 컨컨볼 루션 휴리스틱, 멀티 GPU용 NCCL 존재 여부 등을 확인하십시오.

00:10:38.060 --> 00:10:41.040
ONNX 런타임의 경우 EP 우선 순위를 출력하십시오.

00:10:41.180 --> 00:10:43.800
텐소르, CUDA, CPU 순으로 출력합니다.

00:10:44.020 --> 00:10:46.860
어떤 공급자가 실제로 그래프 노드에 바인딩 되는지 확인하십시오.

00:10:47.540 --> 00:10:52.320
텐소르가 융합커널을 사용하는 텐소르에 할당되었는지 또는 일반 CUDA 커널에 할당되었는지 여부를 로그에 기록합니다.

00:10:52.460 --> 00:10:53.880
다음으로 환경을 조사합니다.

00:10:54.100 --> 00:10:55.180
드라이버를 커리합니다.

00:10:55.440 --> 00:10:58.400
엔비디아 SMI는 커널 모듈과 CUDA 호환성을 보여줍니다.

00:10:58.600 --> 00:11:00.340
컨테이너의 라이브러리 버전을 읽습니다.

00:11:00.600 --> 00:11:04.060
리브쿠다, 리브커블라스, 리브컨, 리븐빔퍼 등을 확인합니다.

00:11:04.280 --> 00:11:11.400
이미지에 CUDA 12.3 라이브러리가 포함되어 있지만 호스트 드라이버가 최대 12.2까지만 지원하는 경우 런타임 호환 모드가 제약 조건과 함께 로드될 수 있습니다.

00:11:11.400 --> 00:11:18.300
이미지가 텐소르 8.6 헤더를 예상하지만 노드 플러그인이 8.4를 제공하는 경우 API 호출 성능이 저하되거나 특정 최적화가 무효화될 수 있습니다.

00:11:18.480 --> 00:11:21.420
해결책은 단순한 희망사항이 아니라 빌드 매트릭스를 사용하는 것입니다.

00:11:21.600 --> 00:11:23.780
단일 소스에서 정확한 버전을 고정합니다.

00:11:24.000 --> 00:11:30.500
드라이버 호환성, CUDA 마이너 버전, 헌, YT 빌드 해시 및 텐소르 버전을 포함하는 기본 이미지를 만듭니다.

00:11:30.680 --> 00:11:35.940
해당 매트릭스를 기반으로 추론 이미지를 생성하고 노드 레이블 및 승인 검사를 통해 일치하지 않는 노드를 거부합니다.

00:11:35.940 --> 00:11:41.340
배포하는 정확한 텐소르 버전에 맞춰 각 모델 변형 및 해상도에 대한 텐소르 엔진을 미리 빌드하고 캐시하세요.

00:11:41.520 --> 00:11:44.220
계획 파일은 매트릭스와 연결된 아티팩트로 취급하세요.

00:11:44.440 --> 00:11:47.280
프로덕션 환경에서 노드 내 엔진 빌드에 절대 의존하지 마세요.

00:11:47.440 --> 00:11:50.000
이는 버전 변동을 숨기고 콜드 스타트 시간을 늘립니다.

00:11:50.260 --> 00:11:54.020
이를 확실히 하려면 커널 기능을 검증하는 CI 스모크 테스트를 추가하세요.

00:11:54.220 --> 00:11:59.060
대상 드라이버와 함께 격리된 런어에서 컨테이너를 실행하고 텐소르가 FP16 커널을 로드하고

00:11:59.060 --> 00:12:05.340
어텐션 노드가 융합되고 IO 바인딩이 활성화되고 X포머즈 또는 SDP가 승인되었는지 확인하세요.

00:12:05.520 --> 00:12:13.060
결정 론적 프롬프트 세트를 실행하고 지연 시간이 기준 선창을 초과하거나 로그에 대체 언어가 포함되어 있으면 빌드를 실패시키세요.

00:12:13.260 --> 00:12:19.060
롤백시 코드와 성능 특성을 모두 복구할 수 있도록 기능 스냅 샷을 이미지 다이제스트와 함께 저장하세요.

00:12:19.900 --> 00:12:23.060
결국 버전 변동은 버그가 아니라 속도 저하의 원인입니다.

00:12:23.840 --> 00:12:27.020
시스템은 실행될 것이고 클럭이 이를 증명할 것입니다.

00:12:27.020 --> 00:12:32.920
증거 파일 시 컨테이너 잘못된 구성으로 인한 효율성 저하는 설계상이 문제입니다.

00:12:33.040 --> 00:12:37.180
버전이 일치하더라도 컨테이너 내부에서 효율성이 저하될 수 있습니다.

00:12:37.460 --> 00:12:44.160
증거에 따르면 느린 메모리 누수, 이미지 크기 증가, GPU 연결 부족, 그리고 부하 시 지연 시간을 왜곡하는 할당자 동작이 원인입니다.

00:12:44.340 --> 00:12:46.980
충돌은 발생하지 않지만 모든 것이 저하됩니다.

00:12:47.240 --> 00:12:49.060
왜 이것이 중요하냐면 간단합니다.

00:12:49.320 --> 00:12:51.740
컨테이너는 런타임 환경을 그대로 보여줍니다.

00:12:52.000 --> 00:12:56.120
이미지가 너무 커서 콜드 스타트가 지연되면 복제본이 제때 도착하지 못합니다.

00:12:56.120 --> 00:13:01.760
GPU 장치가 마운트 되지 않았거나 런타임에 필요한 플래그가 없으면 실행 공급자가 제대로 작동하지 않습니다.

00:13:01.940 --> 00:13:06.220
메모리 영역이 램 사용량 급증으로 인해 페이징을 유발하고 극심한 부하 급증을 초래하면 문제가 발생합니다.

00:13:06.380 --> 00:13:07.980
겉보기에는 문제가 없어 보입니다.

00:13:08.200 --> 00:13:10.540
컨테이너는 모든 요청에 조용히 부하를 줍니다.

00:13:10.820 --> 00:13:13.840
하지만 자세히 살펴보면 빌드 시점의 아티팩트가 누적됩니다.

00:13:14.040 --> 00:13:19.360
멀티 스테이지 빌드가 없기 때문에 컴파일러, 헤더, 테스트 자산으로 인해 이미지 크기가 2GB를 초과합니다.

00:13:19.360 --> 00:13:24.060
다컬인워 파일이 없으면 노트북, 캐시, 실험적인 가중치가 프로덕션 레이어에 포함됩니다.

00:13:24.200 --> 00:13:27.400
배포할 때마다 수 기가바이트의 데이터가 네트워크를 통해 전송됩니다.

00:13:27.600 --> 00:13:31.680
이러한 상황이 노드풀 전체로 확장되면 콜드 스타트는 예외적인 현상이 아니라 정책이 됩니다.

00:13:31.940 --> 00:13:32.360
증거는 명확합니다.

00:13:33.160 --> 00:13:35.440
도커 위 기록이 이러한 문제를 여러 겹으로 보여줍니다.

00:13:35.640 --> 00:13:38.080
런타임 분석은 두 번째 성능 저하 단계를 보여줍니다.

00:13:38.300 --> 00:13:41.560
명시적인 GPU 플래그가 없거나, 도커의 GPU가 없거나,

00:13:42.020 --> 00:13:44.180
키번의 내 장치 플러그인 구성이 누락된 경우,

00:13:44.680 --> 00:13:46.860
프로세스는 엔비디아 장치를 인식하지 못합니다.

00:13:46.860 --> 00:13:51.120
엔비디아 컨테이너 툴킷의 잘못된 구성으로 인해 리부쿠다가 숨겨지기도 합니다.

00:13:51.260 --> 00:13:55.220
이로 인해 실행 공급자가 제약 조건 없이 로드되거나 아예 로드되지 않는 문제가 발생합니다.

00:13:55.400 --> 00:13:57.840
리그, 메모리 통합, 다 적용되지 않아 워크로드가 메모리 슬라이스를 두고

00:13:57.840 --> 00:14:00.240
경쟁하고 스케줄러가 이를 제대로 인식하지 못해 성능 저하가 발생합니다.

00:14:00.400 --> 00:14:02.560
로그는 깔끔하게 유지되지만 성능은 서서히 떨어집니다.

00:14:02.720 --> 00:14:04.580
메모리 동작은 세 번째 성능 저하 단계입니다.

00:14:04.780 --> 00:14:08.580
기본적으로 ONNX 런타임은 CUDA 메모리 아레나 캐시에 메모리 할당을 적극적으로 저장합니다.

00:14:08.580 --> 00:14:14.000
동시성이 높은 환경에서는 아레나가 메모리를 과도하게 예약하여 새로운 요청을 처리하지 못할 때까지 안정적인 것처럼 보입니다.

00:14:14.160 --> 00:14:20.180
고정 메모리가 설정되지 않아 호스트 장치 간 데이터 전송이 페이징 버퍼를 통해 이루어지면서 PCIe가 병목 현상을 일으킵니다.

00:14:20.360 --> 00:14:25.480
IO가 장치에 바인딩되지 않아 텐서가 CPU와 GPU 사이를 오가며 보이지 않는 지연 시간을 발생시킵니다.

00:14:25.640 --> 00:14:28.740
극단적인 경우부터 성능이 악화되고 그 다음으로 중간값에 영향을 미칩니다.

00:14:28.960 --> 00:14:30.920
실제 환경에서 나타나는 증상은 다음과 같습니다.

00:14:31.240 --> 00:14:34.440
GPU 사용률이 적당한 수준임에도 불구하고 실질적인 처리량은 뒤처집니다.

00:14:34.440 --> 00:14:39.780
가벼운 부하에서의 지연 시간은 허용 가능한 수준이지만 동시 접속자가 많아지면 P95 지수가 불안정해지다가 예측할 수 없이 급증합니다.

00:14:39.900 --> 00:14:44.060
간헐적인 메모리 부족 OOM 오류로 인해 트래픽이 최고조에 달했을 때 복제본이 재설정되어 직단 행동이 발생합니다.

00:14:44.220 --> 00:14:47.580
재시작이 연쇄적으로 발생하고 자동 스케일링이 제대로 작동하지 않으며 Q가 재부축됩니다.

00:14:47.740 --> 00:14:52.060
운영자는 모델이 무겁다고 생각하여 잘못된 원인을 찾으려 하지만 실제로는 컨테이너 정책이 문제를 야기합니다.

00:14:52.220 --> 00:14:54.100
컨테이너 위생관리는 증거 처리와 같습니다.

00:14:54.420 --> 00:14:56.040
다단계 빌드는 흔적을 제거합니다.

00:14:56.040 --> 00:14:59.000
컴파일러와 개발 도구는 런타임에 절대 사용되지 않습니다.

00:14:59.180 --> 00:15:02.780
대포판이 없거나 간소화된 기본 이미지는 문제를 최소화하고 풀링 시간을 단축합니다.

00:15:02.980 --> 00:15:06.000
도커 슬림 또는 다이브 감사를 통해 빌드에서 살아남은 항목을 확인할 수 있습니다.

00:15:06.220 --> 00:15:08.520
다커리노어 파일은 의도치 않은 대량 생성을 방지합니다.

00:15:08.720 --> 00:15:11.220
결과적으로 포렌식 분석에서 문제가 없는 깨끗한 상태를 유지할 수 있습니다.

00:15:11.440 --> 00:15:13.080
실행되어야 하는 항목만 실행됩니다.

00:15:13.320 --> 00:15:15.400
GPU 사용에는 명확한 구문이 필요합니다.

00:15:15.620 --> 00:15:19.180
도커에서는 모든 GPU를 선언하거나 정확한 미그 슬라이스를 지정해야 합니다.

00:15:19.180 --> 00:15:22.100
큐버넷에서는 엔비디아 컴 GPU 리소스를 요청하고

00:15:22.100 --> 00:15:25.120
장치 플러그인이 드라이버 브랜치와 일치하는지 확인해야 합니다.

00:15:25.320 --> 00:15:28.340
시작 시 장치 존재 여부와 드라이버 호환성을 검증해야 합니다.

00:15:28.560 --> 00:15:31.720
엔비디아 SME 및 LD 설정은 장식용이 아니라 승인검사입니다.

00:15:31.940 --> 00:15:35.200
누락되거나 일치하지 않는 부분이 있으면 위반사항으로 기록하고 종료하십시오.

00:15:35.340 --> 00:15:38.200
그런 다음 ONNX 런타임과 텐소르를 위도적으로 조정하십시오.

00:15:38.340 --> 00:15:41.740
프로덕션 환경에서는 실행 공급자 순서를 GPU 경로로만 고정하십시오.

00:15:41.880 --> 00:15:45.000
CUDA 메모리 영역이 작업 세트를 초과하여 메모리를 과도하게 사용하는 경우

00:15:45.000 --> 00:15:46.960
비활성화하거나 재조정하는 것을 고려하십시오.

00:15:46.960 --> 00:15:50.440
증가를 제한하거나 사전 할당을 예측 가능한 범위로 설정하십시오.

00:15:50.540 --> 00:15:54.200
정확도 가이드라인이 허용하는 경우 FP16을 기본적으로 활성화하십시오.

00:15:54.340 --> 00:15:57.140
INT8은 정확도 테스트 뒤에 게이트를 설정하십시오.

00:15:57.280 --> 00:15:58.940
입력이 계산이 수행되는 위치에 도착하도록

00:15:58.940 --> 00:16:00.460
IO를 장치 메모리에 바인딩하고

00:16:00.460 --> 00:16:03.820
헤드 오브 라인 블록킹을 방지하기 위해 스트림을 신중하게 선택하십시오.

00:16:03.980 --> 00:16:06.800
상태와 성능, 두 가지 게이트를 연격하게 관리하십시오.

00:16:06.960 --> 00:16:10.020
상태는 단순히 200 응답이 아니라 검증된 성능 스냅샷입니다.

00:16:10.240 --> 00:16:12.380
공급자가 로드되었는지, 융합된 커널이 있는지,

00:16:12.380 --> 00:16:15.680
텐서 코어가 인식되었는지, IO 바운드 상태 인지 등을 확인합니다.

00:16:15.820 --> 00:16:20.480
성능은 시작 시 적절한 지연 시간과 사용률 하한선을 갖는 기준 프롬프트 세트입니다.

00:16:20.720 --> 00:16:24.280
컨테이너가 이 두 가지 조건을 모두 충족하지 못하면 서비스에 허용되지 않습니다.

00:16:24.480 --> 00:16:28.620
CI 애플 사이즈 예산을 설정하여 임계 값을 초과하는 이미지는 빌드에 실패하도록 합니다.

00:16:28.840 --> 00:16:33.060
다이제스트별로 이미지 내용의 차이점을 기록하여 롤백시 코드와 무결성을 복원합니다.

00:16:33.300 --> 00:16:35.380
컨테이너는 단순히 소프트웨어를 배포하는 것이 아니라

00:16:35.380 --> 00:16:38.080
스트레스 상황에서의 동작 방식을 인코딩한다는 증거가 있습니다.

00:16:38.080 --> 00:16:42.920
컨테이너가 GPU에 대해 시끄럽거나 무겁거나 모호한 정보를 제공할 경우 가속을 형식적인 절차로 전락시킵니다.

00:16:43.040 --> 00:16:46.740
반대로 컨테이너가 간결하고 명확하며 적극적일 경우 비용을 지불한 빠른 경로를 유지합니다.

00:16:46.900 --> 00:16:48.720
이 환경에서는 모든 것이 의도적입니다.

00:16:48.940 --> 00:16:51.660
컨테이너는 GPU가 제 역할을 하도록 돕거나 방해가 됩니다.

00:16:51.940 --> 00:16:54.660
마치 포렌식 연구소처럼 명확한 지표들이 모든 것을 증명합니다.

00:16:54.840 --> 00:16:58.080
지연 시간, 처리량, 활용률, 증거가 의견보다 중요함으로

00:16:58.080 --> 00:17:01.420
프롬프트 설정을 수정하고 시드를 고정하고 워밍업을 실행합니다.

00:17:01.420 --> 00:17:09.400
동일한 스케줄러와 단계를 사용하되 512비트의 경우 2025에서 1024비트의 경우 50으로 1024배 확장하여 부하를 파악합니다.

00:17:09.580 --> 00:17:12.800
동시 실행수는 16으로 유지하고 30이까지 점진적으로 늘립니다.

00:17:13.020 --> 00:17:16.680
배치 크기는 1부터 시작하여 VRAM 한계에 도달할 때까지 점진적으로 증가시킵니다.

00:17:16.840 --> 00:17:19.700
추측도 변명도 없이 오직 시간과 카운터만 사용합니다.

00:17:19.920 --> 00:17:21.680
지연 시간이 가장 먼저 증명됩니다.

00:17:21.920 --> 00:17:25.060
성능 저하 상태에서 CPU 폴백 또는 일반적인 어텐션 경로,

00:17:25.300 --> 00:17:28.340
512X512 크기에서 P50는 두 자릿수까지 늘어납니다.

00:17:28.520 --> 00:17:30.400
P955가 실제 상황을 보여줍니다.

00:17:30.400 --> 00:17:35.860
Q가 작은 비효율성을 누적시키면서 P95는 예측 불가능하게 20에서 40초까지 변동합니다.

00:17:36.040 --> 00:17:41.020
1024X1024 크기의 50단계로 설정하면 P95는 도착하자마자 허용 범위를 벗어납니다.

00:17:41.220 --> 00:17:50.400
개선 후 GPU EP가 잠금되고 융합 어텐션이 활성화되고 IO가 장치에 바인딩되면 P50은 한자릿수 초반으로 돌아오고 P95는 허용 범위 내에서 압축됩니다.

00:17:50.580 --> 00:17:53.040
범위가 줄어들고 시스템이 예측 가능해집니다.

00:17:53.240 --> 00:17:54.740
처리량도 이를 뒷받침합니다.

00:17:54.960 --> 00:17:58.340
동시 접속자 16명일 때 성능 저하 경로는 아주 적은 양의 데이터만 처리합니다.

00:17:58.340 --> 00:18:02.540
각 인스턴스가 자체적으로 멈추기 때문에 복제본을 추가해도 분당 이미지 처리량은 거의 증가하지 않습니다.

00:18:02.700 --> 00:18:05.420
32명으로 확장하면 처리량이 아니라 경안만 증가합니다.

00:18:05.620 --> 00:18:07.380
수정 후에는 관계가 정상화됩니다.

00:18:07.560 --> 00:18:12.980
분당 이미지 처리량은 펜서코어 듀티 사이클이 포화되거나 VRM-E 배치 처리를 제한할 때까지 거의 선형적으로 증가합니다.

00:18:13.180 --> 00:18:14.780
기울기 차이가 이를 뒷받침합니다.

00:18:15.020 --> 00:18:18.080
실제로 작업이 더 빨리 완료되는 것이지 단순히 소음만 커지는 것이 아닙니다.

00:18:18.240 --> 00:18:19.800
활용률 분석이 이를 증명합니다.

00:18:19.800 --> 00:18:24.920
이전에는 GPU 듀티 사이클이 50%에서 10% 사이를 오르락내리락하며 긴 평탄한 구간을 보였습니다.

00:18:25.060 --> 00:18:29.560
PCIe 카운터에는 페이징 가능한 전송으로 인한 잡음이 나타났습니다.

00:18:29.780 --> 00:18:35.640
이후에는 듀티 사이클이 높은 수준으로 안정화되고 펜서코어의 활용도가 눈에 띄게 높아졌습니다.

00:18:35.860 --> 00:18:39.100
CPU는 오케스트레이션 및 간단한 전처리 작업으로 복귀합니다.

00:18:39.300 --> 00:18:44.080
PCIe 스파이크는 고정 메모리와 IO 바인딩으로 불필요한 트래픽이 제거되면서 감소합니다.

00:18:44.320 --> 00:18:46.860
이러한 변화를 설명할 수 있는 유일한 방법은 실제 가속입니다.

00:18:46.860 --> 00:18:48.780
스트레스 테스트를 추가로 진행했습니다.

00:18:48.960 --> 00:18:53.700
512x512 스텝 2025에서 고정 경로는 꼬리 스파이크 없이 16개의 동시 처리를 유지합니다.

00:18:53.880 --> 00:18:56.640
32개로 늘려도 시스템은 안정적으로 성능이 저하됩니다.

00:18:56.820 --> 00:19:00.160
P95는 예측 가능한 방식으로 증가하며 혼란스럽게 증가하지 않습니다.

00:19:00.360 --> 00:19:04.240
1024x1024 스텝 50에서는 이러한 차이가 더욱 두드러집니다.

00:19:04.420 --> 00:19:07.040
저하된 경로는 타임아웃으로 인해 문제가 발생합니다.

00:19:07.240 --> 00:19:12.800
강화된 경로는 VRAM 경계일까지 배치 1에서 2에서 사용 가능한 P50과 허용 가능한 P95를 유지합니다.

00:19:13.020 --> 00:19:14.960
여기서 아레나와 스트림이 중요해집니다.

00:19:14.960 --> 00:19:17.680
튜닝 후 헤드 오브 라인 블록킹이 줄어듭니다.

00:19:17.820 --> 00:19:20.240
비용 측면은 간단한 산술 계산으로 설명할 수 있는데

00:19:20.240 --> 00:19:23.340
융합된 어텐션 FP16과 IO 바인딩이 검증되면

00:19:23.340 --> 00:19:25.720
GPU 시간당 요청수가 2에서 5배 증가합니다.

00:19:25.900 --> 00:19:28.520
이에 따라 이미지 1000개당 실효 비용이 감소합니다.

00:19:28.800 --> 00:19:32.760
이미지가 작고 엔진이 사전 구축되어 있기 때문에 콜드 스타트 페널티가 줄어듭니다.

00:19:32.960 --> 00:19:35.540
노드는 첫 번째 터치 시 컴파일 세금을 지불하지 않습니다.

00:19:35.760 --> 00:19:37.040
원장은 로그와 일치합니다.

00:19:37.280 --> 00:19:39.180
검증을 통해 우연한 실행을 방지합니다.

00:19:39.380 --> 00:19:42.500
다른 마이너 드라이버 버전을 사용하는 두 번째 노드 풀에서 반복합니다.

00:19:42.500 --> 00:19:46.300
강화된 이미지는 설계상 일치하지 않는 노드에서 시작되지 않습니다.

00:19:46.460 --> 00:19:49.080
따라서 결과는 비교 가능하며 혼동되지 않습니다.

00:19:49.320 --> 00:19:51.060
기능 스냅샷을 교차 확인합니다.

00:19:51.240 --> 00:19:54.980
동일한 공급자 순서, 동일한 텐소르, 동일한 커널 어설션을 사용합니다.

00:19:55.160 --> 00:19:57.860
프롬프트 세트를 다시 실행하고 분포를 다시 캡처합니다.

00:19:58.080 --> 00:20:00.220
히스토그램이 겹치면 신뢰도가 높아집니다.

00:20:00.400 --> 00:20:02.960
그렇지 않을 경우 성능 차이가 그 이유를 설명합니다.

00:20:03.140 --> 00:20:05.900
결국 숫자는 논쟁을 불러 일으키지 않고 유죄를 입증합니다.

00:20:06.100 --> 00:20:09.600
지연 시간은 줄어들고 처리량은 확장되며 활용률은 안정화됩니다.

00:20:09.600 --> 00:20:14.560
문제는 가설이 아니라 측정 가능하며 모든 그래프에 흔적을 남깁니다.

00:20:15.140 --> 00:20:18.420
해결 프로토콜은 반복 가능한 강화 체크리스트입니다.

00:20:18.640 --> 00:20:20.220
접근 제어가 최우선입니다.

00:20:20.460 --> 00:20:24.260
텐소르 또는 CUDA 실행 공급자가 없으면 시작을 거부합니다.

00:20:24.480 --> 00:20:30.880
공급자들 열거하고 장치수를 확인하고 성능 스냅샷, 컨, FP16, INTA 작업 공간을 출력합니다.

00:20:31.080 --> 00:20:33.620
누락된 항목이 있으면 0이 아닌 종료 코드를 반환합니다.

00:20:33.820 --> 00:20:35.380
가용성은 무결성을 따릅니다.

00:20:35.380 --> 00:20:36.960
버전 고정이 핵심입니다.

00:20:37.120 --> 00:20:42.420
단일 매트릭스 드라이버 브랜치, 컨까지의 CUDA 마이너 버전, ONNX 런타임 빌드 해시, 텐소르를 유지합니다.

00:20:42.580 --> 00:20:44.860
해당 매트릭스를 기반으로 추론 이미지를 빌드합니다.

00:20:45.060 --> 00:20:46.900
노드의 레이블을 지정하여 일치시킵니다.

00:20:47.060 --> 00:20:48.820
동일성 기준에 따라 접근을 허용합니다.

00:20:49.040 --> 00:20:51.760
모델 및 해상도별로 사전 빌드된 텐소르 엔진을 사용합니다.

00:20:51.960 --> 00:20:53.380
계획은 런타임 추측이 아닌 결과물입니다.

00:20:54.220 --> 00:20:55.880
컨테이너 위생은 진실을 보존합니다.

00:20:56.120 --> 00:20:57.780
멀티 스테이지 빌드를 사용하십시오.

00:20:57.780 --> 00:21:00.140
런타임을 배포판 없이 또는 간소화된 형태로 유지하십시오.

00:21:00.220 --> 00:21:01.860
엄격한 다커리노어를 포함하십시오.

00:21:02.000 --> 00:21:04.320
도커 히스토리와 간소화 감사를 통해 검증하십시오.

00:21:04.460 --> 00:21:06.380
CI에서 풀 크기 예산을 설정하십시오.

00:21:06.520 --> 00:21:10.420
크기가 커지는 이미지는 실패 처리하고, 이미지에 서명하고, 다이제스트별로 내용을 비교하십시오.

00:21:10.540 --> 00:21:16.020
GPU를 먼저 구성하고, EP 순서를 텐소르 CUDA로 고정하고, 프로덕션 환경에서 CPU 공급자들 비활성화하십시오.

00:21:16.140 --> 00:21:19.880
개발 환경에서 엔비디아 존재 여부와 엔비디아 컨테이너 툴킥 버전을 확인하십시오.

00:21:19.880 --> 00:21:24.200
MVIDIA.com GPU를 명시적으로 요청하거나, 라이선스를 혼합하여 사용하고, 시작시 검증하십시오.

00:21:24.300 --> 00:21:25.640
런타임을 최적화하십시오.

00:21:25.780 --> 00:21:27.900
FP16을 기본적으로 활성화하십시오.

00:21:28.080 --> 00:21:30.600
INTA는 정확도 검사를 통해 검증하십시오.

00:21:30.740 --> 00:21:37.300
IO를 장치 메모리에 직접 바인딩하고, 고정 메모리를 활성화하고, 스트림을 선택하여 헤드 오브 라인 블록킹을 방지하십시오.

00:21:37.440 --> 00:21:41.660
ORT CUDA 아레나가 작업 세트를 벗어나 멈추면 재조정하거나 비활성화하십시오.

00:21:41.660 --> 00:21:47.300
성능 SLO를 코드로 설정하고, 결정 론적 프롬프트, 지연시간 창 및 사용률 하한선을 사용하여 시작시 자체 테스트를 수행하십시오.

00:21:47.360 --> 00:21:49.420
백로그가 감소하면 실패 처리하십시오.

00:21:49.520 --> 00:21:56.060
관찰 가능성, 요청별 GPU 매트릭, 성능 저하 경로 알림, 카나리 프롬프트 및 비교 가능한 기준선을 추가하십시오.

00:21:56.160 --> 00:22:00.340
성능 게이트와 위반 시 자동 롤백 기능을 갖춘 블루, 그린 테스트를 배포하세요.

00:22:00.540 --> 00:22:04.180
프로토콜을 강제 적용하면 가속 성능이 추정이 아닌 입증 가능해집니다.

00:22:04.360 --> 00:22:06.760
이 테스트에서 얻을 수 있는 교훈은 임상적인 관점입니다.

00:22:06.760 --> 00:22:10.280
CPU 폴백, 버전 변동, 컨테이너 용량 증가는 버그가 아닙니다.

00:22:10.420 --> 00:22:12.880
이러한 현상은 차단할 수 있는 예측 가능한 오류 패턴입니다.

00:22:13.040 --> 00:22:18.780
프로토콜을 실행하고, GPU 사용률을 측정하고, 성능이 저하된 경로를 차단하고, 버전을 고정하고, 엔진을 아티팩트로 취급하세요.

00:22:18.960 --> 00:22:26.980
ONNX 런타임 및 펜소르 메모리 동작, 그리고 아레나를 비활성화해야 하는 시점에 대한 더 자세한 내용은 이 시리즈의 다음 사례를 시청하고 랩노트를 구독하세요.