기술 분석 및 사례 공유: 듀얼 엔진 GPU 컨테이너 가상화의 사용자 모드 및 커널 모드

​하드웨어 컴퓨팅 성능의 효율성을 극대화하는 방법은 모든 리소스 운영자와 사용자의 큰 관심사입니다. 선도적인 AI 기업인 Baidu는 아마도 업계에서 가장 포괄적인 AI 애플리케이션 시나리오를 보유하고 있을 것입니다.

이 기사에서는 복잡한 AI 시나리오에서 GPU 컨테이너 가상화 솔루션과 공장 내 모범 사례를 공유하고 논의합니다.

아래 그림의 왼쪽과 오른쪽 부분은 다양한 경우에 여러 번 표시되었습니다. 여기에 배치한 주요 목적은 컴퓨팅 성능에 대한 수요, 즉 하드웨어 컴퓨팅 성능의 기하급수적인 증가와 리소스 활용도를 강조하는 것입니다. 실제 적용 시나리오. 낭비 사이의 모순.

왼쪽 부분은 OpenAI의 통계입니다. 2012년부터 모델 학습에 필요한 컴퓨팅 성능이 3.4개월마다 두 배씩 증가했습니다. AlphaGoZero와 같은 대형 모델의 경우 학습 컴퓨팅 성능이 30만 배 증가했습니다. 그리고 이러한 추세는 계속됩니다. . 한편, 컴퓨팅 성능에 대한 수요가 증가함에 따라 주류 AI 가속 장치의 컴퓨팅 성능도 2년마다 두 배로 증가하고 있습니다. 반면에 리소스 활용 효율성은 하드웨어 성능의 전체 활용을 제한합니다.

오른쪽 부분은 2021년 페이스북의 데이터센터 머신러닝 부하 분석 결과입니다. 장애, 스케줄링, 타임슬라이스 낭비, 공간 단위 낭비 등의 링크에서 AI 컴퓨팅 파워가 많이 손실됩니다. 실제 컴퓨팅 파워 활용도는 30% 미만입니다. 이는 국내 주요 인프라 사업자들이 직면한 현 상황이기도 하다고 생각합니다.

온라인 클러스터의 활용률이 30% 미만이라고 방금 말씀드렸는데, 이는 많은 학생들의 인식과 일치하지 않을 수 있습니다. 온라인에 있는 많은 학생들은 모델과 알고리즘의 개발자일 수 있습니다. 우리의 일반적인 이해는 학습 및 테스트 중에 활용도가 매우 높게 유지될 수 있으며 심지어 100% 활용도에 도달할 수도 있다는 것입니다.

그러나 모델이 생산 환경에 출시되면 많은 제약을 받게 되며 이러한 제약으로 인해 가동률이 기대에 크게 미치지 못합니다. ​

제한된 공간을 사용하여 주요 제약 사항을 요약해 보겠습니다.

• 모델 특성: 각 모델 네트워크가 다르며 호출되는 기본 연산자 조합이 다르므로 GPU 활용도에 큰 영향을 미칩니다.
• 서비스 SLA: 다양한 시나리오의 서비스에는 다양한 SLA가 필요합니다. 일부 서비스는 실시간 요구 사항이 높으며 심지어 10ms 이내에 엄격하게 제어해야 합니다. 그러면 이러한 서비스는 배치 크기를 늘려도 활용도를 높일 수 없거나 심지어 배치 크기는 1뿐입니다.
• 트래픽 패턴: 다양한 모델 알고리즘은 작업 중에 자주 호출될 수 있는 OCR 인식과 같은 다양한 애플리케이션 시나리오를 제공합니다. 음성 인식은 출퇴근 시간이나 엔터테인먼트, 여가 시간에 더 자주 호출되며, 이는 하루 종일 GPU 사용률의 최고치와 최저치 변동으로 이어집니다.
• 최적화 효과: 모델의 반복 빈도와 적용 범위 시나리오에 따라 모델의 최적화 세분성도 다릅니다. 완전히 최적화되지 않은 모델 활용률은 높은 수준에 도달하기 어렵다고 생각할 수 있습니다.
• 용량 중복성: 모델이 온라인 상태가 되기 전에 세부적인 용량 계획을 수행해야 합니다. 최대 트래픽은 얼마이며 여러 지역이 필요한지 여부는 이 과정에서 무시하기 어려운 용량 중복성으로 인해 발생합니다. 평상시에는 문제가 발생합니다.

위의 제약 하에서, 실제 생산 환경의 가동률은 우리가 다음에 보여주고 싶은 것일 수도 있습니다. 우리는 복잡하고 변화하는 온라인 생산 환경에서 이러한 활용 패턴을 추출합니다.

• 낮은 평균 유형: 위 왼쪽 그림과 같이 실제 온라인 추론 비즈니스입니다. 모델 특성 및 서비스 SLA의 한계로 인해 GPU의 최대 사용률은 10%에 불과하며 평균 사용률은 10%에 불과합니다. 더욱 낮아질 것입니다.
• Peak and Valley 변동 유형: 아래 왼쪽 그림과 같이 전형적인 온라인 추론 비즈니스 활용 패턴입니다. 낮 시간에 서비스가 최고조에 달하며 심야부터 활용도가 가장 낮습니다. 다음날 아침 하루 평균 이용률은 20%에 불과하며, 최저 이용률은 10% 미만입니다.
• 단기 급증 유형: 오른쪽 상단 그림과 같이 활용 곡선은 기본적으로 왼쪽 하단 그림과 동일하지만 밤의 황금 시간대에 두 가지 뚜렷한 활용 피크가 있습니다. 피크 기간의 서비스 품질을 충족하기 위해 이 서비스는 배포 프로세스 중에 큰 버퍼를 예약하며 평균 리소스 사용률은 30%를 조금 넘습니다.
• 기간 트리거형: 아래 오른쪽 그림과 같이 일반적인 온라인 교육 시나리오의 활용 모드입니다. 온라인 교육 작업은 오프라인 교육과 온라인 추론 사이에 있는 주기적인 일괄 처리 작업입니다. 예를 들어, 데이터 배치는 15분마다 도착하지만 이 데이터 배치를 훈련하는 데는 2~3분밖에 걸리지 않으며 GPU는 오랜 시간 동안 유휴 상태입니다.

AI 애플리케이션 시나리오는 복잡하고 변경 가능합니다. 위에는 네 가지 일반적인 시나리오만 나열되어 있습니다. 복잡한 시나리오에서 비즈니스 성능과 리소스 효율성의 균형을 맞추는 방법은 GPU 가상화에서 직면하는 첫 번째 과제입니다.

GPU 가상화 프로세스에서 우리가 직면한 두 번째 과제는 완전한 GPU 격리 및 혼합 메커니즘이 부족하다는 것입니다.

현재 주류 NVIDIA GPU를 예로 들어보겠습니다. 일반적인 AI 소프트웨어 및 하드웨어 생태계는 애플리케이션 및 프레임워크 계층, 런타임 계층, 드라이버 계층, 하드웨어 계층 등 여러 수준으로 나뉩니다.

우선, 최상위 레이어는 PaddlePaddle, TensorFlow, PyTorch 등과 같은 다양한 공통 프레임워크를 포함하는 사용자 애플리케이션입니다. 애플리케이션 계층 아래에는 다양한 공통 연산자 라이브러리 및 하드웨어 런타임 액세스 인터페이스를 포함하여 하드웨어 공급자가 캡슐화한 API 인터페이스 계층이 있습니다. 이 API 인터페이스 계층 아래에는 하드웨어와 통신하는 드라이버 계층이 있습니다. 이 계층은 커널 상태에 있으며 장치와 직접 통신하는 소프트웨어 인터페이스 계층입니다. 하단에는 오퍼레이터 실행을 담당하는 실제 AI 가속 하드웨어가 있다.

기존 가상화 솔루션은 드라이버 커널 상태 및 하드웨어 가상화 로직과 결합하여 구현됩니다. 이 두 수준은 하드웨어 공급자의 핵심 IP이며 일반적으로 비공개 소스입니다. 나중에 언급하겠지만 현재 GPU 기반 격리 메커니즘은 유연성 및 할당 강도 측면에서 클라우드 기반 시나리오의 사용 요구 사항을 충족할 수 없습니다.

격리 메커니즘 외에도 기존 하이브리드 배포 메커니즘은 복잡한 시나리오의 요구 사항을 충족하기 어렵습니다. 업계에는 공유 일정을 위한 오픈 소스 솔루션이 많이 있으며, 이러한 오픈 소스 솔루션은 단순히 두 가지 작업을 예약합니다. 리소스 레벨에서 하나로. 실제 시나리오에서 단순 공유는 비즈니스 간 상호 영향, 롱테일 지연, 심지어 처리량 저하를 초래하므로 단순 공유를 프로덕션 환경에 실제로 적용할 수 없게 됩니다.

위의 활용 패턴 분석 섹션에서 비즈니스와 시나리오에 따라 활용 패턴이 다르다는 것을 확인했습니다. 비즈니스 시나리오를 추상화하고 하이브리드 솔루션을 사용자 정의하는 방법은 프로덕션 환경 구현의 핵심입니다.

모두에게 GPU 개발과 가상화의 역사에 대한 보다 포괄적인 이해를 제공하기 위해 여기서는 GPU 가상화의 개발 역사를 그림을 사용하여 보여줍니다.

일반 컴퓨팅에서 GPU의 적용은 G80 시대의 Tesla 아키텍처로 거슬러 올라갈 수 있습니다. 범용 프로세서 SM을 사용하여 원래 그래픽 이미지 프로세서를 별도의 정점과 픽셀로 대체하는 통합 셰이더를 구현하는 1세대 아키텍처입니다. 파이프라인.

Baidu가 도입한 최초의 GPU는 Fermi 아키텍처로 거슬러 올라갑니다. 이 시점부터 업계에는 수많은 가상화 솔루션이 등장했으며, 그 중 대부분은 API 하이재킹에 중점을 두고 있습니다. 여기서 대표적인 것이 원래 학계에서 유지관리하는 프로젝트인 rCUDA이다. 최근까지 일정한 빈도의 업데이트와 반복을 유지해 왔지만, 학문적 연구에 초점을 맞춰 제작 환경에서 널리 사용되지는 않은 것으로 보인다.

Baidu의 대규모 GPU 도입은 Kepler 아키텍처를 기반으로 이루어졌습니다. Kepler 아키텍처는 Baidu가 자체 개발한 슈퍼 AI 컴퓨터 X-MAN의 시대를 열었습니다. X-MAN 1.0은 최초로 단일 머신 16카드 구성을 구현하며, PCIe 하드웨어 수준에서 CPU와 GPU의 유연한 바인딩 및 유연한 비율을 실현할 수 있습니다. 단일 카드의 성능에 국한되어 당시에는 세분화보다는 확장을 더 고려했습니다.

이후의 Pascal 아키텍처, Volta 아키텍처, Turing 아키텍처의 성능은 급속히 향상되었으며 가상화에 대한 수요는 점점 더 뚜렷해졌습니다. 초기 Kepler 아키텍처부터 NV는 처음에는 그래픽 렌더링 및 원격 데스크톱 시나리오를 대상으로 한 GRID vGPU 가상화 솔루션을 공식적으로 제공했습니다. 2019년경에는 AI와 고성능 컴퓨팅 시나리오를 위한 솔루션도 제공됐다. 그러나 이러한 솔루션은 가상 머신을 기반으로 하며 AI 시나리오에서는 거의 사용되지 않습니다.

Ampere 세대에서 NV는 SM, MEM, L2 캐시 등 여러 하드웨어 리소스를 하드웨어 수준에서 분할하여 우수한 하드웨어 격리 성능을 제공하는 MIG 인스턴스 분할 솔루션을 출시했습니다. 그러나 이 솔루션은 Ampere 아키텍처부터 지원되며 카드 모델에 특정 제한 사항이 있습니다. A100, A30 등 일부 모델만 지원할 수 있습니다. 그리고 슬라이싱 후에도 단일 인스턴스의 성능은 T4의 컴퓨팅 파워를 초과하여 현재 프로덕션 환경의 효율성 문제를 잘 해결할 수 없습니다.

모두가 GPU 아키텍처와 가상화의 역사에 대해 어느 정도 인상을 받은 후 GPU 가상화 구현의 주요 수준, 즉 기술 경로를 자세히 소개하겠습니다.

리소스 가상화 격리를 달성하려면 먼저 시간 또는 공간 차원에서 분리 가능한 리소스가 필요합니다. 사용자 관점에서는 여러 작업을 동시에 또는 병렬로 실행할 수 있습니다.

여기에서는 사용자 모드, 커널 모드 및 하드웨어의 여러 수준에서 병렬성 또는 동시성 공간에 대해 논의합니다.

NV의 소프트웨어 및 하드웨어 생태계는 비공개 소스이므로 여기의 회로도는 포괄적인 아키텍처 백서, 리버스 페이퍼 및 우리 자신의 이해를 바탕으로 작성되었습니다. 모든 사람이 제때에 부정확성을 수정하기를 바랍니다.

사용자 모드 솔루션

이 그림을 위에서 아래로 살펴보겠습니다. 우선 GPU의 관점에서는 여러 프로세스가 자연스럽게 동시 발생합니다. 즉, 시분할 다중화됩니다. 드라이버와 하드웨어는 시간 분할 회전에서 작업 전환을 담당합니다. 이 메커니즘 계층을 사용하면 API 수준에서 컴퓨팅 리소스 및 비디오 메모리 리소스에 대한 제한을 구현하여 가상화 효과를 얻을 수 있습니다. 여기서 API는 두 개의 레이어로 나눌 수 있습니다. 첫 번째 레이어는 드라이버 API입니다. 이 API 레이어는 드라이버에 가깝고 이 레이어를 제어하는 ​​한 모든 상위 레이어 호출이 GPU에 액세스할 수 있는 유일한 방법입니다. API의 경우 사용자의 리소스 액세스를 제어하는 ​​것과 같습니다. 여기서 NV가 제공하는 MPS 기술은 공간 분할 다중화를 실현할 수 있으며 이는 비즈니스 성과를 더욱 최적화할 수 있는 가능성도 제공한다는 점을 언급하겠습니다. 이후 구현실습 부분에서 자세히 확장해보도록 하겠습니다.

커널 상태 솔루션

다음 계층은 커널 상태입니다. 가상 머신 수준의 전체 가상화든 반가상화든, 지난 2년 동안 주요 클라우드 공급업체의 컨테이너 솔루션이든 시스템은 커널에서 구현됩니다. 커널 상태에서 가장 큰 어려움은 통화 차단 및 MMIO 하이재킹과 관련하여 많은 레지스터와 MMIO 동작이 잘 문서화되어 있지 않아 복잡한 리버스 엔지니어링이 필요하다는 것입니다.

하드웨어 솔루션

커널 상태 아래에는 하드웨어 계층이 있습니다. 이 계층에서는 NV의 MIG 기술이든 Baidu Kunlun의 SR-IOV 기술이든 컴퓨팅 성능이 하드웨어 로직에서 구현됩니다. 공간 분할 다중화. 예를 들어 Kunlun은 1/3과 1/2의 하드웨어 분할을 달성할 수 있고 A100은 1/7의 최소 세분성으로 리소스 분할을 달성할 수 있습니다.

위에서 GPU 가상화의 과제와 현재 상황을 소개하는 데 많은 시간을 할애했습니다. 다음으로 Baidu가 이러한 과제에 내부적으로 어떻게 대응하는지 살펴보겠습니다.

이 사진은 듀얼 엔진 GPU 컨테이너 가상화 아키텍처인 Baidu Smart Cloud를 보여줍니다.

여기서 컨테이너가 강조되는 이유는 미래에는 AI 풀 링크 애플리케이션이 점차 클라우드 네이티브 플랫폼으로 수렴되어 완전한 컨테이너 개발, 훈련 및 추론을 달성할 것이라고 믿기 때문입니다. Gartner 조사에 따르면 2023년에는 AI 작업의 70%가 컨테이너에 배포될 예정입니다. Baidu의 내부 컨테이너화는 2011년에 시작되어 현재 10년 이상의 배포 및 최적화 경험을 보유하고 있습니다. 우리는 또한 실제 생활에서 연마된 제품 기능과 최적화 경험의 이 부분을 커뮤니티와 대다수의 사용자에게 제공하기 위해 최선을 다하고 있습니다.

여기에서도 듀얼엔진이 강조됩니다. 전체 아키텍처에서 우리는 사용자 모드와 커널 모드라는 두 가지 격리 엔진 세트를 사용하여 격리, 성능, 효율성 및 기타 측면에 대한 사용자의 다양한 요구 사항을 충족합니다.

격리 엔진 위에는 리소스 풀링 계층이 있습니다. 이 계층은 소프트웨어 및 하드웨어 시스템에 대한 깊은 이해를 기반으로 하며 AI 가속 리소스의 분리, 원격성 및 풀링을 점진적으로 구현합니다. 이는 미래를 위해 구축하는 풀링 추상화입니다. 인프라 계층.

리소스 풀링 레이어 위에는 Matrix/k8s 통합 리소스 스케줄링 레이어가 있습니다(여기서 Matrix는 Baidu 공장의 컨테이너화된 스케줄링 시스템입니다). 스케줄링 메커니즘 위에는 다양한 비즈니스 시나리오를 기반으로 다양한 리소스를 추상화합니다. 혼합 전략에는 공유 혼합, 선제 혼합, 시분할 혼합, 조수 혼합 등이 포함됩니다. 이러한 혼합 유통 전략은 후속 실무 부분에서 자세히 확장됩니다.

리소스 격리 및 리소스 스케줄링에 의존하는 것은 모델 개발, 모델 교육, 온라인 추론을 포함하는 AI 비즈니스의 풀 링크 시나리오입니다.

다음으로 각각 사용자 모드 및 커널 모드 격리 엔진의 구현을 공유하겠습니다.

다음 그림은 사용자 공간 격리 엔진의 핵심 아키텍처에 대한 개략도입니다. 아키텍처 다이어그램의 맨 위에는 PaddlePaddle, TensorFlow, PyTorch 등과 같이 일반적으로 사용되는 다양한 프레임워크가 포함된 사용자 애플리케이션이 있습니다.

사용자 애플리케이션 아래에는 일련의 API Hook 인터페이스가 있습니다. 이 인터페이스 세트를 기반으로 GPU 리소스의 로컬 사용 및 원격 마운트를 실현할 수 있습니다. 프레임워크가 의존하는 기본 동적 라이브러리를 교체함으로써 리소스 제어 및 격리가 달성됩니다. 이 솔루션은 애플리케이션에 완전히 투명하며 필요한 라이브러리 교체 작업이 컨테이너 엔진 및 예약 부분에 의해 자동으로 완료되었다는 점에 유의하는 것이 중요합니다.

CUDA API는 결국 Hook 이후 두 경로를 통해 실행자에 도달합니다. 여기서 디바이스 관리 API 등 대부분의 API는 Hook을 거친 후 어떠한 작업도 수행하지 않고 직접 Executor로 전달되어 실행됩니다. 리소스 애플리케이션과 관련된 소수의 API는 차단 계층을 거치며, 이를 통해 일련의 사용자 공간 가상화 기능이 구현될 수 있습니다. 이 레이어의 로직은 충분히 효율적으로 구현되며 성능에 미치는 영향은 거의 무시할 수 있습니다.

현재 사용자 모드 격리 엔진은 기본 비디오 메모리 격리 및 컴퓨팅 전력 격리를 포함하여 풍부한 격리 및 제어 기능을 제공할 수 있습니다. 또한 인코더 격리, 고품질 선점, 비디오 메모리 과잉 분배, 비디오 메모리 풀링 등 다양한 고급 기능을 확장했습니다. ​

사용자 모드 솔루션의 장점은 우수한 성능과 낮은 롱테일 대기 시간입니다. 지연에 민감한 온라인 추론 비즈니스와 같이 메커니즘 성능과 극도의 효율성을 추구하는 비즈니스 시나리오에 적합합니다. ​

격리를 기반으로 원격 기능을 제공합니다. 원격 기능을 도입하면 리소스 구성의 유연성과 사용 효율성이 크게 향상됩니다. 이에 대해서는 이 글의 끝부분에서 자세히 설명하겠습니다.

이 공유는 기술 공유입니다. 여기서는 모든 사람의 비즈니스 아이디어와 기술 토론을 활성화하기 위해 작은 공간을 사용하여 원격 기술의 핵심 사항과 어려움을 확장하겠습니다.

이전 가상화 챌린지에서 언급한 소프트웨어 및 하드웨어 기술 스택에 따르면 GPU에 대한 원격 액세스는 일반적으로 하드웨어 링크 계층, 드라이버 계층, 런타임 계층 및 사용자 계층에서 구현될 수 있습니다. 비즈니스 시나리오에 대한 이해와 결합하여 현재 가장 적합한 것은 런타임 레이어라고 믿습니다.

런타임 레이어 기술 경로와 이를 구현하는 방법을 결정합니까? 기술의 요점은 무엇입니까? 우리는 이것이 주로 의미론적 일관성의 문제라고 생각합니다. 런타임 원격성에 따라 원래 로컬 프로세스는 클라이언트와 서버라는 두 프로세스로 분할되어야 합니다. CUDA 런타임은 비공개 소스이므로 내부 구현 논리를 탐색할 수 없습니다. 프로세스를 분할한 후 원래 프로그램 논리와 API 의미 체계가 유지되는지 확인하는 방법 여기서는 일대일 스레드 모델을 사용하여 API 내에서 논리와 의미 체계 정렬을 보장합니다.

원격 구현의 어려움은 동적 라이브러리 libcudart.so 외에도 수천 개의 다양한 API 인터페이스가 포함된 cuDNN, cuBLAS 및 cuFFT와 같은 일련의 동적 라이브러리 및 API의 문제입니다. . 우리는 컴파일 기술을 사용하여 헤더 파일의 자동 구문 분석 및 코드 자동 생성을 달성하고 리버스 엔지니어링을 통해 숨겨진 API 분석을 완료합니다.

원격 솔루션 0-1에 대한 솔루션 적응 후 후속 하위 호환성은 실제로 상대적으로 해결하기 쉽습니다. 현재 CUDA API는 비교적 안정적인 것으로 보이며 새 버전에는 약간의 점진적인 조정만 필요합니다.

공간 분할 다중화와 시분할 다중화는 위에서 여러 번 언급되었습니다. 자세한 설명은 다음과 같습니다.

• 시간 분할 다중화: 이름에서 알 수 있듯이 시간 조각 수준에서 다중화됩니다. 이는 단일 시간 분할에서 하나의 GPU 프로세스만 실행되는 CPU 프로세스 스케줄링과 유사합니다. 여러 GPU 프로세스는 마이크로 수준에서 교대로 실행되며 동시 실행만 가능합니다. 이는 또한 특정 시간 범위 내에서 프로세스가 컴퓨팅 리소스를 제대로 활용할 수 없으면 이러한 컴퓨팅 리소스가 낭비되는 결과를 낳습니다.
• 공간 분할 다중화: 시분할 다중화와 달리 공간 분할 다중화에서는 특정 마이크로 순간에 이 GPU의 리소스가 완전히 사용되지 않는 한 여러 프로세스가 GPU에서 동시에 실행될 수 있습니다. 커널을 시작할 수 있습니다. 두 프로세스의 커널은 인터리브되어 마이크로 수준에서 실행되므로 실제로 병렬성을 실현하고 GPU 리소스를 더욱 활용할 수 있습니다.

개요 섹션에서 소개한 것처럼 커널 상태 가상화 및 NVIDIA vGPU 가상화를 비롯한 현재 일반적인 가상화 방법은 실제로 하위 수준의 타임 슬라이스 회전을 기반으로 하는 시분할 다중화 솔루션입니다. ​

NV는 다중 프로세스 동시성 시나리오를 위한 다중 프로세스 서비스 솔루션인 MPS를 출시했습니다. 이 솔루션은 공간 분할 다중화를 달성할 수 있으며 현재 효율성과 성능을 모두 고려한 유일한 솔루션입니다. ​

다음은 MPS에 대한 간략한 소개입니다. MPS는 두 프로세스의 컨텍스트를 하나의 프로세스로 병합하는 것과 같습니다. 병합된 프로세스는 이전 두 프로세스의 커널을 함께 엮어 실행합니다. 여기에는 두 가지 이점이 있습니다.

• 프로세스 간 컨텍스트 전환이 필요하지 않아 컨텍스트 전환 오버헤드가 줄어듭니다.
• 동시에 서로 다른 프로세스의 커널이 인터리브되어 리소스 공간 활용도가 향상됩니다.

MPS에 관해 말하자면, 비판을 받아온 단점, 즉 결함 격리 문제를 언급해야 합니다. ​

이 MPS 안정성 문제를 해결하는 방법은 무엇입니까? Baidu Intelligent Cloud는 스케줄링, 컨테이너 엔진 및 비즈니스 연결 유지를 결합하여 완전한 프로세스 통합 및 공유 솔루션 세트를 제안합니다.

• kill 명령 리디렉션을 통해 비즈니스 프로세스의 우아한 종료 달성
• MPS 상태 감지 메커니즘을 통해 상태 확인 및 정지된 애니메이션 감지 달성
• 서비스 keepalive를 사용하여 사용자 프로세스의 자동 재시작 실현

이 솔루션은 비즈니스(지연- 민감한 중요 비즈니스) 90% 이상의 리소스를 보유하고 있으며 2년 이상 실행되어 왔으며 최고의 성능을 제공하면서도 대부분의 사용자의 안정성 요구를 충족할 수 있다고 믿습니다.

MPS가 점점 더 많이 채택됨에 따라 NV는 MPS의 안정성을 지속적으로 향상시키고 있습니다. 미리 좋은 소식이 있습니다. NV는 정지된 애니메이션 상태 감지 및 우아한 프로세스 종료를 포함하여 올해 하반기에 MPS의 안정성을 크게 향상할 예정이며, 이러한 기능은 MPS 제품의 일부가 될 예정입니다. MPS 활용이 더욱 향상될 예정입니다.

고품질 선점 기능을 소개하기 전에 먼저 고품질 선점의 비즈니스 시나리오를 공유하겠습니다. 공장 안팎의 다양한 사용자들과의 논의에 따르면 대부분의 AI 애플리케이션 생산 환경은 대기 시간 민감도에 따라 온라인, 니어라인, 오프라인의 세 가지 유형의 작업으로 나눌 수 있습니다.

• 온라인 작업은 대기 시간이 가장 높으며 일반적으로 사용자 요청에 실시간으로 응답하는 추론 작업입니다.
• 니어라인 작업은 일반적으로 일괄 처리 작업이며 단일 로그 지연에 대한 요구 사항은 없습니다. 데이터 배치 완료 시간 몇 시간에서 몇 분까지의 요구 사항
• 대기 시간에 대한 요구 사항이 없고 처리량에만 초점을 맞춘 오프라인 작업은 일반적으로 모델 교육 작업입니다.

지연에 민감한 작업을 고품질 작업으로 정의하고 지연에 민감하지 않은 니어라인 및 오프라인 작업을 품질이 낮은 작업으로 정의한다면. 그리고 두 가지 유형의 작업이 혼합되면 서로 다른 작업 우선순위에 따라 서로 다른 커널 시작 우선순위가 정의되는데, 이것이 위에서 언급한 고품질 선점 기능입니다. ​

구현 원리는 아래 그림과 같습니다. 사용자 모드 격리 엔진은 고품질 작업과 저품질 작업을 위해 논리적 커널 대기열을 유지합니다. 전체 로드가 낮을 때 두 큐는 동시에 커널을 시작할 수 있습니다. 이때 두 큐의 커널은 인터리브되어 함께 실행됩니다. 로드가 증가하면 계층적 시작 모듈은 고품질 작업의 실행 지연을 보장하기 위해 낮은 품질 대기열의 시작을 즉시 기다립니다.

이 기능의 장점은 온라인 작업의 영향을 줄이거나 피하면서 오프라인 처리량을 보장한다는 것입니다.

마찬가지로 먼저 시분할 혼합의 정의와 시나리오를 소개하겠습니다.

시간 공유 믹싱은 믹싱 모드에서 타임 슬라이스 회전이 포함된 공유 믹싱과 약간 비슷합니다. 차이점은 시분할 하이브리드 배포는 비디오 메모리에 대한 비디오 메모리 스왑 솔루션을 제안하지 않는다는 점입니다. 이는 비디오 메모리를 오랫동안 점유하지만 컴퓨팅 성능이 간헐적으로 사용되거나 가끔 트리거되는 시나리오에서 유용합니다. 프로세스에 컴퓨팅 성능이 필요할 때 비디오 메모리에 대한 액세스 권한을 얻습니다. 프로세스가 계산을 완료하면 비디오 메모리에 대한 액세스 권한을 해제하여 권한을 기다리는 다른 프로세스가 실행 기회를 얻을 수 있도록 합니다. 간헐적으로 유휴 상태인 GPU 리소스를 완전히 활용할 수 있습니다.

시분할 믹싱의 핵심 기술은 비디오 메모리 스왑입니다. 이를 CPU 메모리 스왑과 비교할 수 있습니다. 특정 프로세스의 메모리가 충분하지 않으면 시스템은 특정 전략에 따라 시스템 메모리 리소스의 일부를 디스크로 스왑하여 실행 중인 프로세스를 위한 공간을 확보합니다.

비디오 메모리 스왑의 구현 원리는 아래 그림과 같습니다. 우리는 비디오 메모리의 물리적 주소에 비디오 메모리 풀을 유지하고 상위 계층은 리소스 잠금을 사용하여 GPU 사용 권한이 있는 프로세스를 결정합니다. 프로세스가 잠금을 획득하면 비디오 메모리는 메모리나 디스크에서 물리적 비디오 메모리 풀로 이동되고 프로세스에서 사용할 가상 주소 공간에 추가로 매핑됩니다. 프로세스가 잠금을 해제하면 프로세스의 가상 메모리 공간이 예약되고 실제 메모리는 메모리나 디스크로 이동됩니다. 잠금은 상호 배타적입니다. 하나의 프로세스만 잠금을 얻을 수 있습니다. 다른 프로세스는 대기 대기열에 보류되어 있으며 FIFO 방식으로 리소스 잠금을 얻습니다.

위에서는 사용자 모드 격리 엔진의 기능적 구현을 ​​소개합니다. 실제 애플리케이션에서 성능은 어떻고 사용자에게 미치는 영향은 무엇입니까? 여기서는 테스트 데이터로 직접 이동합니다.

아래 그림은 공개 테스트 세트인 MLPerf에서 대표적인 모델인 ResNet-50 Server를 선택한 시나리오에서의 데이터 비교입니다. 그림의 열은 왼쪽에서 오른쪽으로 배타적, 네이키드 혼합, 사용자 모드 격리 및 커널 모드 격리에서의 성능을 나타냅니다.

왼쪽 그림은 평균 처리량을 비교한 것입니다. 추론 시나리오에서는 어떤 솔루션이 처리량 하에서 압력 값에 직접 도달할 수 있는지를 알 수 있습니다. 추론 시나리오의 처리량은 가상화 성능을 잘 보여줄 수 없으며, 프로덕션 환경에서 구현할 때 대기 시간에 더 주의해야 한다는 점을 여기서 설명하고 싶습니다.

오른쪽 사진은 P99 분위수 지연 비교입니다. 낮은 압력(QPS = 40)의 사용자 모드에서는 네이키드 믹싱이 롱테일 지연에 미치는 영향이 기본적으로 동일한 반면 커널 모드는 롱테일 지연에 약간 더 큰 영향을 미치는 것을 알 수 있습니다. 시분할 다중화를 사용한다. 우리는 QPS = 60일 때 공간 분할 다중화의 장점이 롱테일 지연에 미치는 영향을 크게 줄여줍니다. 압력이 더욱 증가함에 따라 사용자 모드 프로세스 융합 솔루션은 다른 하이브리드 배포 방법보다 훨씬 더 뛰어납니다.

롱테일 지연 제어는 사용자 모드만큼 좋지는 않지만 커널 모드는 격리 측면에서 장점이 있어 격리 요구 사항이 강한 시나리오에 더 중점을 둡니다.

커널 모드 격리 엔진의 기술적 구현을 ​​살펴보겠습니다.

먼저 다음을 포함하여 커널 상태 가상화 구현의 특성을 살펴보겠습니다.

커널 상태 구현, 우수한 격리: 비디오 메모리의 1% 수준 할당, 컴퓨팅 성능 및 오류 격리를 지원합니다. 컴퓨팅 성능은 P4, V100, T4, A100/A10/A30 및 기타 주류 GPU를 지원하고 GPU 드라이버 버전 410~510을 지원하며 사용자 모드 운영 환경을 변경할 필요가 없습니다.

사용자 모드 구현과 달리 커널 모드 가상화의 GPU 격리 기능은 커널 모드에서 구현됩니다. 아래 그림의 왼쪽 절반은 커널 상태 가상화 구현의 아키텍처 다이어그램입니다. 맨 아래부터 상위 계층까지 GPU 하드웨어, 커널 계층 및 사용자 계층입니다.

하드웨어 수준은 당사의 GPU입니다. 이 GPU는 베어메탈 GPU일 수도 있고 투명 GPU일 수도 있습니다.

커널 레이어 아래에는 실제로 GPU의 기능을 제어하는 ​​GPU의 원본 드라이버가 있습니다. 그리고 GPU 드라이버 위에는 우리가 구현한 GPU 가상화용 커널 모듈이 있습니다. GPU 차단 노란색 부분의 드라이버에는 메모리 차단, 컴퓨팅 파워 차단, 컴퓨팅 파워 스케줄링 등 세 가지 기능이 포함되어 있습니다. 비디오 메모리 격리와 컴퓨팅 성능 격리는 별도로 구현됩니다.

사용자 레이어, 첫 번째는 차단 인터페이스입니다. 이 인터페이스는 차단 모듈에서 제공하며 두 부분으로 나누어집니다. 하나는 장치 파일 인터페이스이고 다른 하나는 차단 모듈을 구성하기 위한 인터페이스입니다. 장치 파일은 컨테이너에 제공됩니다. 먼저 컨테이너를 살펴보겠습니다. 컨테이너의 상단은 애플리케이션, 하단은 cuda 런타임, 하단은 드라이버 api/nvml api 등을 포함한 cuda 기본 라이브러리입니다. 장치 파일을 가짜 장치 파일로 컨테이너에 제공함으로써 상위 계층 CUDA가 액세스할 때 장치 파일에 액세스하게 됩니다. 이로써 CUDA 기본 라이브러리에 의한 GPU 드라이버에 대한 액세스 차단이 완료됩니다.

​커널에 있는 차단 모듈은 액세스된 모든 시스템 호출을 가로채어 이를 가로채서 구문 분석한 다음 실제 액세스를 실제 GPU 기본 드라이버로 리디렉션합니다. GPU 기본 드라이버가 처리를 완료한 후 결과를 차단 모듈에 반환하고, 차단 모듈은 이를 다시 처리한 후 마지막으로 결과를 컨테이너의 기본 라이브러리에 반환합니다.

간단히 말하면 장치 파일을 시뮬레이션하여 GPU 드라이버에 대한 기본 라이브러리의 액세스를 차단하고 차단, 구문 분석, 삽입 등의 작업을 통해 비디오 메모리 및 컴퓨팅 성능 차단을 완료합니다.

현재 비디오 메모리 격리는 주로 비디오 메모리 정보, 비디오 메모리 할당, 비디오 메모리 해제 등 모든 비디오 메모리 관련 시스템 호출을 가로채는 방식으로 이루어집니다. 또한 현재 메모리 격리는 정적으로만 설정할 수 있으며 동적으로 변경할 수 없습니다. 사용자 모드는 비디오 메모리의 과도한 개발을 지원할 수 있지만 커널 모드는 아직 비디오 메모리의 과도한 개발을 지원할 수 없습니다.

컴퓨팅 파워 격리 측면에서 프로세스의 CUDA 컨텍스트를 가로채서 관련 정보를 얻습니다. 스케줄링 객체는 프로세스 관련 CUDA 컨텍스트입니다. CUDA Context에 해당하는 컴퓨팅 자원에는 컴퓨팅 자원(Execution)과 메모리 복사(Copy) 자원이 포함된다. 각 GPU에는 이 GPU의 모든 CUDA 컨텍스트를 예약하는 하나의 커널 스레드가 있습니다.

우리는 4개의 커널 모드 컴퓨팅 전력 스케줄링 알고리즘을 구현했습니다:

• 고정 공유: 각 POD에는 고정 컴퓨팅 전력 리소스가 할당됩니다. 즉, 전체 GPU의 컴퓨팅 전력은 n개의 공유로 고정적으로 나뉩니다. 각 POD는 1/n 컴퓨팅 성능으로 나뉩니다.
• 균등 공유: 모든 활성 POD는 컴퓨팅 성능 리소스를 균등하게 공유합니다. 즉, 활성 POD 수는 n개이고 각 POD는 컴퓨팅 성능의 1/n을 공유합니다.
• 가중치 공유: 각 POD는 가중치에 따라 컴퓨팅 파워 리소스를 할당합니다. 즉, 전체 GPU의 컴퓨팅 파워는 가중치 값에 따라 각 POD에 할당됩니다. POD에 비즈니스 부하가 있는지 여부에 관계없이 컴퓨팅 파워는 가중치에 따라 할당됩니다.
• Burst Weight Share: Active POD는 가중치에 따라 컴퓨팅 파워 리소스를 할당합니다. 즉, 각 POD에는 가중치 값이 할당되고 Active POD에는 가중치 비율에 따라 컴퓨팅 파워가 할당됩니다.

커널 모드는 타임 슬라이스를 통해 컴퓨팅 성능을 예약하기 때문에 지연에 민감한 비즈니스에는 그다지 우호적이지 않습니다. 우리는 온라인 서비스와 오프라인 서비스의 코로케이션을 통해 온라인 서비스의 응답 속도를 크게 향상시킬 수 있는 오프라인 코로케이션 기술을 특별히 개발했습니다. 이를 통해 오프라인 서비스가 GPU 컴퓨팅 리소스를 공유하고 GPU 리소스 활용률을 높이는 목표를 달성할 수 있습니다. . 오프라인 혼합 배포의 특징은 다음과 같습니다.

• 온라인 POD: 일반적으로 소량의 컴퓨팅 성능을 차지하는 추론 작업입니다.
• 오프라인 POD: 일반적으로 컴퓨팅 성능의 대부분을 차지하는 훈련 작업입니다.

온라인 POD에 작업 로드가 있으면 즉시 오프라인 POD를 점유하고 모든 컴퓨팅 성능을 사용하여 추론 서비스를 제공합니다. 작업 로드가 끝나면 컴퓨팅 성능이 오프라인 POD로 해제됩니다. ​

다음은 커널 모드 컴퓨팅 성능 격리 평가 결과입니다.

테스트 환경은 단일 카드 V100 SXM2 16G입니다. 테스트에서는 horovod 프레임워크와 모델을 사용하여 테스트합니다. resnet50입니다.

POD 1과 POD 2의 무게 비율은 1:2입니다.

위 그림의 결과에서 POD 1과 POD 2의 처리량 비율은 45~50%로 약 1/2로 사전 설정된 값과 일치하는 것을 알 수 있습니다. 동시에, POD SUM은 Native에 비해 2~4%의 손실이 있습니다. 컴퓨팅 파워 격리를 위해서는 Cuda Context에서의 스위칭 작업이 필요하기 때문에 손실이 불가피하지만, 우리의 손실은 5% 이내라고 할 수 있습니다. 공차 범위 내에서.

커널 모드와 사용자 모드의 특징을 비교해 보겠습니다.

결함 격리 측면에서 커널 상태는 사용자 상태에 비해 이점이 있으며 커널 상태는 기본 라이브러리를 교체할 필요가 없습니다. 사용자 모드 컴퓨팅 전력 스케줄링은 시분할과 공간 분할 다중화를 채택하고 커널 모드는 시분할 다중화를 채택합니다. 사용자 모드의 고급 기능에는 오프라인 코로케이션, 비디오 메모리를 메모리에 과잉 분산, 인코딩 및 디코딩 인스턴스(AI 가속기 카드의 인코딩 및 디코딩 리소스 독립적 할당)가 포함되며, 커널 모드.

가상화 기술을 사용하여 AI 시나리오에서 GPU 활용 효율성을 높이는 방법 공장의 실제 사례를 기반으로 대규모 AI 시나리오의 모범 사례를 공유해 보겠습니다.

먼저 추론 서비스의 일반적인 시나리오를 살펴보겠습니다. 모델 자체 아키텍처 또는 높은 서비스 대기 시간 요구 사항으로 인해 일부 작업은 배치 크기가 매우 작은 구성에서만 실행될 수 있거나 배치 크기가 1인 경우에도 실행될 수 있습니다. 이는 장기적으로 낮은 GPU 활용률로 직접 이어지며 심지어 최대 활용률도 10%에 불과합니다.

이 시나리오에서 가장 먼저 고려해야 할 사항은 활용도가 낮은 여러 작업을 혼합하는 것입니다.

이 믹싱 전략을 공유 믹싱으로 요약합니다. 개발, 교육 또는 추론 시나리오에서 활용도가 낮은 여러 작업 간에 공유 혼합을 사용할 수 있습니다.

위에서 언급한 프로세스 융합 기술과 결합하면 서비스 지연 보장을 기반으로 2개 인스턴스 또는 심지어 여러 인스턴스의 공유 혼합을 달성하고 리소스 활용도를 2배 이상 높일 수 있습니다. ​

동시에 대부분의 GPU에는 독립적인 인코딩 및 디코딩 리소스가 있습니다. 대부분의 시나리오에서는 왼쪽 아래 그림과 같이 리소스가 오랫동안 유휴 상태로 유지됩니다. 공유된 컴퓨팅 리소스를 기반으로 인코딩 또는 디코딩 인스턴스를 혼합하여 리소스 성능을 더욱 향상시키고 유휴 리소스를 활성화할 수 있습니다.

추론 서비스의 일반적인 부하 패턴은 하루 종일 뚜렷한 최고점과 최저점 변동이 있고 예측할 수 없는 단기적인 트래픽 급증이 있다는 것입니다. 이는 피크 값이 높더라도 평균 활용도가 매우 낮고 평균 값이 30% 또는 심지어 20% 미만인 경우가 많다는 것을 보여줍니다.

이런 변동은 당연합니다. 단기간에 급증하는 서비스의 효율성을 최적화하는 방법은 무엇입니까? 선제적인 하이브리드 전략을 제안합니다.

선점형 믹싱은 지연에 민감하지 않은 저품질 작업과 피크 값이 높고 지연에 민감한 고품질 서비스를 혼합하는 것입니다. 여기서 고품질과 저품질은 사용자가 정의하고 리소스 신청 시 명시적으로 선언합니다. Baidu의 내부 관행에서는 니어라인 및 오프라인 데이터베이스 브러싱 또는 교육 작업을 낮은 품질로 정의합니다. 이러한 유형의 비즈니스에는 처리량에 대한 특정 요구 사항이 있으며 기본적으로 대기 시간에 대한 요구 사항이 없습니다.

가상화 기능의 고품질 선점 메커니즘을 사용하여 고품질 작업이 항상 리소스를 점유하는 주도권을 갖습니다. 트래픽이 최저 수준에 있을 때는 전체 카드의 로드가 높지 않으며, 트래픽이 최고 수준에 도달하거나 단기적인 급증이 발생하면 최적 수준이 낮은 작업이 정상적으로 실행될 수 있습니다. 실시간으로 감지하고 커널 세분성에서 컴퓨팅 성능을 선점합니다. 이때 품질이 낮은 작업은 고품질 작업의 서비스 품질을 보장하기 위해 흐름이 제한되거나 완전히 보류될 수도 있습니다.

이 하이브리드 모드에서는 비디오 메모리가 부족할 수 있으며 컴퓨팅 성능에 중복성이 많이 있을 수 있습니다. 이러한 종류의 시나리오를 위해 우리는 암시적 비디오 메모리 초과 전송 메커니즘을 제공합니다. 사용자는 환경 변수를 사용하여 품질이 낮은 작업에 비디오 메모리를 과도하게 배포하고 더 많은 인스턴스를 배포하여 컴퓨팅 성능을 항상 사용하여 활용률 최저점을 채우고 전반적인 활용 효율성을 극대화할 수 있습니다.

영구 그래픽 메모리와 간헐적인 컴퓨팅 성능 트리거 시나리오인 세 번째 유형의 비즈니스 시나리오에 익숙하실 것입니다. 대표적인 대표적인 사업으로는 개발 업무와 온라인 교육이 있습니다.

온라인 교육을 예로 들어보겠습니다. 우리는 온라인 교육이 필요한 추천 모델과 같이 일별 또는 시간별 사용자 데이터를 기반으로 많은 모델을 온라인으로 업데이트해야 한다는 것을 알고 있습니다. 처리량이 실시간으로 가득 차는 오프라인 훈련과 달리 온라인 훈련은 일괄 데이터를 축적하고 훈련 세션을 시작해야 합니다. Baidu 내에서 일반적인 모델은 데이터 배치가 15분 안에 도착하지만 실제 훈련 시간은 2~3분에 불과합니다. 남은 시간 동안 훈련 프로세스는 비디오 메모리에 상주하며 다음 배치까지 기다립니다. 의 데이터가 업스트림에서 도착합니다. 이 기간 동안 가동률이 장기간 0이 되어 자원의 낭비가 많이 발생하였습니다.

이 유형의 작업에서는 기본적으로 비디오 메모리가 가득 차 있기 때문에 위에서 언급한 공유 믹싱이나 선점형 믹싱을 사용할 수 없습니다. 앞서 언급한 비디오 메모리 스왑 메커니즘과 결합하여 우리는 시간 공유 믹싱 전략을 제안했습니다.

시간 공유 믹싱은 타임 슬라이스 회전의 공유 믹싱과 유사하지만 이때 비디오 메모리도 컴퓨팅 컨텍스트에 따라 들어오고 나가게 됩니다. 기본 가상화 계층은 비즈니스에 계산이 필요한 시기를 감지할 수 없으므로 각 GPU 카드에 대해 전역 리소스 잠금을 유지합니다. 그리고 사용자가 호출할 수 있도록 해당 C++ 및 Python 인터페이스를 캡슐화합니다. 사용자는 계산이 필요한 경우에만 이 잠금을 신청하면 되며 비디오 메모리는 자동으로 다른 공간에서 비디오 메모리 공간으로 교체됩니다. 계산이 완료된 후 잠금이 해제되고 해당 비디오 메모리가 해제됩니다. 메모리나 디스크 공간으로 교체되었습니다. 이 간단한 인터페이스를 사용하여 사용자는 여러 작업에 대한 GPU의 시간 공유 및 독점 사용을 달성할 수 있습니다. 온라인 교육 시나리오에서 시간 공유 혼합을 사용하면 전체 활용도를 높이는 동시에 리소스를 최대 4/5까지 절약할 수 있습니다.

위에서 언급한 세 가지 시나리오의 모범 사례는 Baidu 내부 비즈니스에서 대규모로 검증되고 구현되었습니다. 바이두베이지·AI 이기종 컴퓨팅 플랫폼에도 관련 기능이 출시됐으며, 즉시 적용해 볼 수 있다.

여기에서는 아직 내부 검증 중인 기능에 대해 약 3분간 이야기하겠습니다. 이러한 기능은 대규모 AI 시나리오에서 흔히 발생하는 불균등한 배포 및 배포를 더욱 해결하기 위해 가까운 시일 내에 Baidu Baige 플랫폼에서 완료될 예정입니다. 수급불균형, 자원분열 등의 문제.

인프라 분야에 종사하는 학생들은 리소스 분리 및 풀링과 같은 개념을 자주 듣게 됩니다. 풀링(Pooling)의 개념을 어떻게 구현하고 이를 실제 생산성으로 전환할 수 있는지에 대해 우리는 적극적으로 탐구하고 추진해 왔습니다. 이미 2015년에 업계 최초로 PCIe Fabric 솔루션을 기반으로 한 하드웨어 풀링 솔루션을 구현했고, 이를 Baidu 내에서 대규모로 구현했습니다. 이것이 방금 언급한 X-MAN 1.0입니다(현재는 4.0으로 진화했습니다). PCIe 패브릭 네트워크를 통해 CPU와 GPU 간의 상호 연결을 구성하여 리소스의 동적 할당을 달성하고 다양한 시나리오에서 비율 문제를 해결합니다. 하드웨어 연결 및 프로토콜에 의해 제한되는 이 솔루션은 캐비닛 내의 풀링만 해결할 수 있습니다.

소프트웨어 레이어 풀링은 더 유연하다고 생각되는 기술 솔루션입니다. 데이터 센터 네트워크가 계속해서 업그레이드됨에 따라 100G 또는 심지어 200G 네트워크도 향후 인프라의 표준 구성이 될 것이며 고속 네트워크는 리소스 풀링을 위한 통신 고속도로를 제공할 것입니다.

리소스의 분리 및 풀링은 비즈니스에 더 큰 유연성을 제공하고 성능 최적화를 위한 더 큰 상상력의 여지를 제공합니다. 예를 들어, CPU와 GPU 간의 비율 문제, 개발 시나리오의 장기적인 자원 점유 수급 불균형 문제 및 효율성 저하 문제, 훈련 시나리오의 자원 단편화 작업 차단 문제, 장비 비정상 훈련 재시작 문제 등이 있습니다. 이러한 시나리오는 모두 풀링 및 파생 솔루션으로 해결될 수 있습니다.

마지막으로 위에서 공유한 모든 가상화 기술과 모범 사례가 Baidu Baige AI 이기종 컴퓨팅 플랫폼에서 출시되었습니다. Baidu Intelligent Cloud 공식 웹사이트에서 "Baidu Baige"를 검색하면 즉시 AI 작업을 가속화하고 비즈니스 상상력을 자극할 수 있습니다!

Q & A Selection

Q: 일반 리소스는 네임스페이스와 cgroup을 통해 컨테이너화됩니다. 리소스 제어를 달성하기 위해 GPU가 어떤 기술을 사용하는지 물어봐도 될까요?

A: 네임스페이스와 cgroup은 모두 커널에서 제공하는 메커니즘이며 기본적으로 하드웨어에서 제공하는 관련 기능에 의존합니다. 이는 현재 GPU에는 존재하지 않습니다. GPU는 현재 오랫동안 비공개 소스로 제공될 것입니다. 하드웨어 공급자만이 커널 메인라인으로 업스트림할 수 있는 이러한 기능을 제공할 수 있습니다. 현재 타사 솔루션은 모두 사용자 모드 또는 커널 모드의 비표준 구현이며 현재 이를 네임스페이스 및 cgroup 범주에 포함할 수 있는 방법이 없습니다. 그러나 GPU 가상화가 구현하고자 하는 것은 이러한 인터페이스 하의 상응하는 메커니즘이라고 볼 수 있으며, 그것이 표준화될 수 있는지 여부는 또 다른 더 큰 문제입니다.

Q: GPGPU 가상화 기술 외에 NPU 관련 가상화 기술도 개발했나요? NV 기술 스택에서 분리할지 여부입니다. 감사해요!

A: 여기서 언급된 NPU는 일반적으로 현재의 모든 AI 가속 하드웨어를 가리키는 네트워크 처리 장치여야 한다는 것을 이해합니다. 우리는 다른 AI 가속 하드웨어의 가상화 적응을 위해 노력하고 있습니다. 첫 번째는 Kunlun 코어입니다. 위에서 언급한 가상화 기능을 Kunlun 코어에 적용했습니다. 장면이 확장됨에 따라 다른 주류 가속 하드웨어도 계속해서 조정될 것입니다.

Q: 사용자 모드와 커널 모드는 서로 다른 제품인가요?

A: 동일한 제품이지만 기본 구현 방법이 다르지만 사용자 인터페이스 수준이 통일되어 있습니다.

Q: 사용자 공간 가상화는 어느 정도의 세분성을 달성할 수 있나요?

A: 컴퓨팅 파워는 1% 세분화로 나눌 수 있고, 비디오 메모리는 1MB로 나눌 수 있습니다.

Q: 커널 모드 가상화로 인해 제어 오버헤드가 더 커지나요?

A: 커널 상태 가상화는 시간 분할을 기반으로 합니다. 여기서 오버헤드는 시간 분할로 인해 발생하므로 필연적으로 컴퓨팅 성능이 저하됩니다. 애플리케이션 성능에 발생하는 오버헤드를 말한다면 커널 모드가 유저 모드보다 클 것이라는 것은 사실이다.

Q: 시분할 시행 계획에 따르면 온라인 추론에서는 자유 경쟁의 평균 시간이 더 빨라진 느낌이 듭니다.

A: 테스트 결과에 따르면 성능이 좋은 것부터 나쁜 것 순으로 프로세스 융합, 네이키드 믹싱(자유 경쟁), 하드 리미트 격리 순입니다.

Q: k8s 클러스터에서 GPU의 두 가지 가상화 방식이 공존할 수 있나요?

A: 메커니즘과 원리상 공존은 가능합니다. 하지만 현재는 제품 관점에서 디자인이 너무 복잡해지는 것을 원하지 않아 여전히 분리되어 있습니다. 후속 사업에서 폭넓은 수요가 있을 경우 유사한 공존 솔루션 출시를 고려할 예정입니다.

Q: k8s 스케줄러 확장 방법을 자세히 소개해주실 수 있나요? GPU 토폴로지와 총 볼륨을 보고하려면 노드의 에이전트가 필요합니까?

A: 예, 리소스(비디오 메모리 리소스 및 컴퓨팅 파워 리소스 포함)와 토폴로지 정보를 업로드하려면 독립 실행형 에이전트가 필요합니다.

Q: 시간과 공간 분 선택에 관해 제안할 사항이 있나요?

A: 지연에 민감한 온라인 추론 작업의 경우 프로세스 융합을 기반으로 하는 공간 분할 솔루션을 선택하는 것이 좋습니다. 엄격한 격리가 필요한 시나리오의 경우 시간 공유 솔루션을 선택하는 것이 좋습니다. 다른 장면 선택에서는 둘 사이에 차이가 없습니다.

Q: 커널 모드는 어떤 CUDA 버전을 지원할 수 있나요? NV가 업데이트되면 Baidu Smart Cloud의 업데이트 주기는 얼마나 걸리나요?

A: 커널 상태는 커널에서 가상화되므로 CUDA 버전에 대한 특별한 요구 사항은 없습니다. 현재 모든 CUDA 버전이 지원됩니다. NV가 CUDA를 업데이트한다면 특별한 지원 작업은 없을 것으로 예상됩니다.

Q: 커널 모드를 사용하려면 Baidu Smart Cloud에서 제공하는 특수 OS 이미지를 사용해야 하나요? 전용 드라이버?

A: 커널 모드에서는 특별히 OS 이미지를 제공하기 위해 Baidu Smart Cloud가 필요하지 않습니다. 현재 우리는 centos7과 ubuntu를 지원합니다. 하지만 이를 사용하려면 자체 배포 프레임워크를 사용해야 합니다. 컨테이너 이미지에 대한 특별한 요구 사항은 없으며 모두 투명하게 지원될 수 있습니다.

Q: 퍼블릭 클라우드에서만 사용할 수 있나요? 비공개로 배포할 수 있나요?

A: 퍼블릭 클라우드와 프라이빗 클라우드 모두 배포 및 사용할 수 있습니다.

위 내용은 기술 분석 및 사례 공유: 듀얼 엔진 GPU 컨테이너 가상화의 사용자 모드 및 커널 모드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!