개요: 이 기사는 ByteDance 인프라 엔지니어 Liu Chang과 ByteDance 기계 학습 시스템 엔지니어 Zhang Yongqiang이 CommunityOverCode Asia 2023에서 "ByteDance Spark는 Wanka 모델 추론 실습을 지원합니다"의 기조 연설을 편집한 것입니다.

클라우드 네이티브화 개발 과정에서 Kubernetes는 강력한 생태학적 구축 기능과 영향력으로 인해 빅데이터 및 AI를 포함한 점점 더 많은 유형의 로드 애플리케이션을 Kubernetes로 마이그레이션할 수 있게 되었습니다. Byte는 내부적으로 Hadoop에서 Kubernetes로의 Spark 마이그레이션을 탐색합니다. 클라우드 네이티브 작업을 실행합니다. ByteDance의 빅 데이터 리소스 관리 아키텍처와 Spark의 배포 발전은 대략 세 단계로 나눌 수 있습니다.

첫 번째 단계는 전적으로 YARN을 기반으로 하는 오프라인 리소스 관리입니다. YARN을 대규모로 사용하여 빅데이터 클러스터를 관리하면 리소스 운영 및 유지 관리 비용을 줄이면서 Spark 리소스 활용도를 효과적으로 향상시킬 수 있습니다.
두 번째 단계는 오프라인 리소스의 혼합 배포 단계입니다. YARN과 Kubernetes의 하이브리드 배포 클러스터를 구축하여 오프라인 리소스의 전반적인 활용도를 더욱 향상시킵니다. 하이브리드 배포 기술을 통해 클러스터와 단일 시스템 모두의 리소스 활용도가 크게 향상되었습니다. 리소스 활용도가 향상된다는 것은 더욱 완전한 격리 수단이 필요하다는 것을 의미합니다. 따라서 우리는 Spark의 컨테이너화된 배포를 점차적으로 추진하기 시작했습니다.
세 번째 단계는 완전한 클라우드 네이티브 배포입니다. 오프라인 로드는 더 이상 관리를 위해 다른 아키텍처를 사용하지 않으며, 기술 스택과 리소스 풀은 진정으로 통합되며 Spark의 클라우드 기본성도 점차적으로 구축되고 개선됩니다.

물론 클라우드 네이티브는 업계에서 거의 만장일치의 개발 추세인데 왜 클라우드 네이티브를 사용할까요? Kubernetes를 통합 리소스 관리 기반으로 사용하는 이유는 무엇입니까? 세 가지 주요 이점이 있습니다. 첫 번째는 효율적인 운영 및 유지 관리입니다. Kubernetes는 온라인 로드이든 빅 데이터 로드이든 관계없이 지속적인 개발, 통합 및 배포를 쉽게 달성할 수 있습니다. 두 번째는 리소스 풀링 입니다 . 통합된 클라우드 기반 기반은 인프라 오버헤드를 줄이고 리소스 전송 효율성을 더욱 향상시킵니다. 리소스 활용 측면에서 전체 데이터 센터의 활용률을 보다 포괄적이고 완전히 향상시켜 효율성을 높일 수 있습니다. . 세 번째는 생태적 번영 입니다. Kubernetes는 기본 운영 및 유지 관리 시설, 상위 계층 애플리케이션 관리, 기본 네트워크 및 스토리지 등 표준화된 인터페이스 정의를 제공하여 모든 수준에서 생태적 발전을 촉진합니다. . 등 관리에는 Spark의 클라우드 네이티브 사용을 용이하게 하는 다양한 옵션이 있습니다.

ByteDance Spark 규모

ByteDance는 업계 최고의 Spark 비즈니스 규모를 보유하고 있으며 매일 수백만 개의 오프라인 작업을 실행하고 수백만 개의 코어, 수만 개의 GPU 카드 리소스를 점유하고 총 클러스터 크기는 수만 노드에 이릅니다. 이러한 대규모 Spark 로드는 Spark를 완전히 기본적으로 구현하기가 쉽지 않음을 의미합니다. 실제로 우리가 생각하는 질문은 다음과 같습니다. Spark 작업 배포는 Standalone을 통한 정적 배포인가요, 아니면 K8s Native를 통한 동적 배포를 사용해야 합니까? K8s에서 테넌트 수준 리소스 관리 및 Spark 작업 제어를 구현하는 방법은 작업이 제출될 때 또는 포드가 생성될 때 수행되어야 합니까? Spark의 일정 요구 사항을 어떻게 지원하나요? Spark에서 작업을 제출할 때 많은 수의 Pod 생성으로 인해 예약 병목 현상이 발생합니까? 이러한 대규모 운영 아키텍처 마이그레이션의 경우 어떻게 주변 기능을 구축하고 운영 마이그레이션 전후의 경험을 원활하게 할 수 있습니까?

Spark의 클라우드 네이티브화 탐색 과정에서 파트너는 GPU 요구 사항이 매우 높은 수많은 오프라인 일괄 처리 작업을 포함하는 많은 문제에 직면했습니다. 온라인 서비스를 완전히 사용할 수 없으며 전체 활용도가 낮습니다. 머신러닝은 Spark의 중요한 파트너입니다. 우리는 위의 문제를 해결하고 주변 생태계를 강화하기 위해 협력합니다. Spark는 비즈니스를 위한 목표 엔진 개선을 수행했으며 비즈니스도 Spark의 클라우드 기반 리소스, 일정 관리 및 관리의 이점을 얻었습니다. .

Spark 클라우드 네이티브 솔루션 및 엔진 개선 사항

Spark 클라우드 네이티브 기술 솔루션의 현재 주류 사용 방법에는 Spark Native 및 Google의 오픈 소스 Spark Operator가 포함됩니다. 두 가지 방법은 동일한 목표를 달성하고 궁극적으로 Spark-submit 명령줄 도구를 호출합니다. 차이점은 Google의 Spark Operator가 더 풍부한 의미 체계를 지원하고 Operator 및 Mutatingwebhook를 통해 K8에 더 가까운 풍부한 기능을 주입한다는 것입니다.

Byte Spark 클라우드 네이티브 기술 솔루션에는 두 가지가 있습니다. 첫 번째는 Yodel을 통해 일정을 잡기 위해 Kubelet 또는 Gödel에 제출할 필요가 없는 원활한 마이그레이션입니다. Arcee를 통해 스케줄링 시스템에 제출됩니다. 여기서 설명해야 할 개념은 다음과 같습니다. Gödel은 Byte에서 개발한 분산 리소스 예약 시스템입니다. 이는 YARN 및 Kubernetes의 리소스 예약 기능을 호스팅하고 Kubernetes 및 YARN의 리소스 풀, 할당량, 예약 및 격리를 통합합니다. YARN 작업 유형을 지원하고 YARN의 RM 및 NM 구성 요소를 변환하는 Byte 자체의 연산자입니다. Arcee는 Byte가 독자적으로 개발한 통합 클라우드 기반 빅데이터 사업자로, Spark, Flink 등의 빅데이터 부하를 보다 편리하게 관리할 수 있습니다. Yodel과 Arcee의 차이점은 Yodel은 "YARN 프로토콜과 호환되는" Gödel 솔루션의 빅데이터인 반면, Arcee는 "K8s 프로토콜과 호환되는" Gödel 솔루션의 빅데이터라는 점입니다. 동일한 Gödel Scheduler 및 Kubelet 기술을 재사용합니다.

이 관행은 Arcee Operator를 통해 제출되는 완전한 클라우드 기반 배포입니다. Arcee의 핵심 기능에는 주로 작업 수명 주기 관리, 작업 리소스 관리 및 일부 엔진 사용자 정의 기능이 포함됩니다.

아르씨 소개

Arcee 의 핵심 설계 아이디어 는 YARN의 2단계 관리 모델인 2단계 작업 관리를 기반으로 하는 2단계 작업 관리입니다. 즉, 주로 빅데이터 작업 생성 및 유지를 담당하는 중앙 관리 서비스인 AM이 컴퓨팅을 생성하고 유지 관리합니다. 노동자. Spark 작업에 따라 Arcee는 드라이버를 생성하고 드라이버는 필요한 실행자를 생성합니다. 이 관리 모델은 빅데이터 업무 현황을 효과적으로 관리 및 표현하고, 업무 관리 전략을 맞춤화할 수 있습니다. 한편, 컴퓨팅 엔진이 컴퓨팅 작업의 운영을 완전히 제어하고 필요에 따라 리소스 사용량을 조정할 수 있는 기능도 갖추고 있습니다.

Arcee Operator에는 6개의 모듈이 포함되어 있습니다 . Arcee CRD 모듈은 ArceeApplication과 ArceeCommand 의 두 가지 리소스 유형을 정의합니다. ArceeApplication은 특정 작업을 설명하는 데 사용되며 ArceeCommand는 주로 Webhook 모듈 에 사용되는 작업을 설명합니다. Application/Pod에 대한 구성 주입 및 확인을 사용합니다. PodSetManager 는 작업 리소스 관리를 담당하고 , EngineManager 는 일부 엔진 사용자 정의 기능을 구현하는 데 사용됩니다. 배치 스케줄러를 사용하여 Spark와 같은 빅데이터 인터페이스 작업을 완료합니다.

전체 작업 제출 프로세스는 Arnold(기계 학습 플랫폼)가 Spark 작업 제출을 시작하고 Spark 클라이언트를 호출한 후 K8s에 작업을 제출하는 데 필요한 매개변수를 채우는 것입니다. Arcee 모드에서 Spark 클라이언트는 내장된 Arcee 클라이언트를 사용하여 Webhook에 의해 사전 처리되고 APIServer에 제출되는 Spark ArceeApplication을 생성합니다. 다음으로 Arcee Controller는 애플리케이션의 생성 이벤트를 수신하고 해당 작업 상태를 생성하고 애플리케이션의 설명에 따라 드라이버를 생성합니다. Arcee는 요청에 따라 모든 실행자를 계속 모니터링합니다. 관련 구성 주입도 수행합니다. 애플리케이션의 드라이버 및 실행기의 모든 포드는 리소스 사용 통계를 위해 Arcee의 PodsetManager에서 유지 관리되고 다른 모듈에 관련 정보를 제공합니다.

Arcee의 스파크

Spark on Arcee는 Spark 네이티브 배포 모델을 어느 정도 개선한 것으로 간주될 수 있습니다. 주요 차이점은 Spark 클라이언트에 내장된 K8s 클라이언트가 드라이버 로드 관리를 담당하는 구성 요소로 대체된다는 것입니다. Arcee Operator가 되며 Driver와 Executor는 유지 관리를 위해 통합된 Arcee 애플리케이션을 갖게 됩니다. Arcee는 또한 작업 수명주기 관리, 일정 보호 및 기타 관련 기능을 제공합니다.

스파크 엔진 최적화

이전 섹션에서 소개한 비즈니스 배경 사례를 기반으로 Spark 엔진 측에서는 다음과 같은 개선 사항을 적용했습니다. 각 문제의 발생 및 해결 방법은 다음과 같습니다.

MPS 상태 이상을 방지하기 위해 실행 프로그램이 정상적으로 종료됩니다.

현재 GPU를 사용해야 하는 일부 Spark 데이터베이스 플러시 작업은 K8s에서 실행되고 온라인 서비스와 혼합됩니다. 이러한 작업은 MPS를 통해 호스트의 GPU 장치를 공유합니다. MPS는 Nvidia에서 제공하는 다중 프로세스 서비스 기술로, 프로세스는 기본 시분할 다중화 대신 GPU에서 공간 분할 다중화를 수행합니다.) 커널 실행 시 여러 공유 프로세스 중 하나가 종료되면 하드웨어 수준에서 치명적인 예외가 발생하기 쉽습니다. 이로 인해 GPU의 다른 프로세스가 종료되므로 각 프로세스의 정상적인 종료를 처리해야 합니다.

K8에서 실행하면 특정 일정상의 이유로 리소스가 소진되어 컨테이너가 퇴거되거나 종료될 수 있습니다. 우리는 Driver, Executor, Daemon 및 Worker 관계에서 다양한 Executor 및 Worker의 종료 상황을 주의 깊게 분석했습니다. 컨테이너 환경에서 Executor Graceful Exit를 구현하고 종료 신호를 캡처하고 자동으로 cudaDeviceSync를 수행함으로써 MPS가 오프라인 종료로 인해 정의되지 않은 상태에 있는 것을 방지합니다.
할당량을 통해 수많은 보류 중인 Pod 문제를 해결합니다.

Spark는 DynamicAllocation을 지원합니다. 실제 사용 시 사용자는 일반적으로 Max를 비교적 큰 값으로 설정합니다. 현재 Arnold는 Max를 시작하기에 충분한 수의 Pending Pod가 생성되는 것을 방지하기 위해 Max를 기준으로 Quota 확인을 수행합니다. 실행자는 실제로 K8s에 제출할 수 있습니다. 그렇지 않으면 Arnold 서비스의 대기열에서 기다립니다. 그러나 현재 Max to Check Quota를 사용하는 경우 리소스 낭비가 쉽다는 단점이 있습니다. 대기열에 Max보다 작은 할당량이 있는 경우 현재 작업의 특성에 따라 현재 리소스를 사용하기 위해 작업을 먼저 시작할 수 있습니다. 그러나 현재 할당량 확인 논리로 인해 이 리소스 부분이 삭제됩니다. 사용할 수 없으며 작업은 항상 상위 계층에 대기합니다. 이 문제는 다음 방법으로 해결할 수 있습니다.
- Spark.kubernetes.allocation.batch.size 매개변수를 사용하여 각 배치에서 끌어오는 Pod 수를 제어합니다.
- Spark.kubernetes.allocation.maxPendingPods 매개변수를 통해 단일 작업에 대한 최대 Pening Pod 수를 제한합니다.
- 그러나 매개변수 조정으로는 동일한 기간에 동일한 대기열에 대량으로 제출되는 문제를 해결할 수 없으므로 Webhook을 사용하여 대기열을 기반으로 할당량을 확인할 수 있습니다. 할당량이 없으면 Pod 생성이 실패합니다. Spark는 이 문제를 해결하기 위해 Exception을 처리하고, Pod 생성 전략을 추가하고, 생성 시간 간격을 기하급수적으로 늘리는 등의 작업을 수행합니다.
혼합 위치의 불안정한 리소스 시나리오 에서 운영의 강력한 최적화

몇 가지 예를 들면, 리소스 안정성 최적화를 예약하는 동안 여러 스트레스 테스트 테스트 중에 Spark Executor Pod가 비정상적으로 거부(UnexpectedAdmissionError)되는 경우가 종종 있습니다. 중앙 집중식 조사를 통해 일련의 Kubelet 로직에서 여러 경쟁 조건 문제가 수정되었으며 평균 일일 혼합 리소스가 한도 채우기 비율에서 안정적인 증가에 도달했습니다. 또한 일련의 조정 및 변환을 수행하여 리소스 사용량 관찰을 용이하게 하기 위해 일부 GPU 표시기 수집 지점을 추가하고 블랙리스트 및 추측과 같은 매개변수를 통해 리소스 불안정성에 대한 작업의 내결함성을 개선했습니다.

주변 생태적 통합

Spark on K8s 환경에서는 전체 클러스터, 컨테이너, 작업의 실행 상태를 관찰하고, 로그 및 모니터링을 기반으로 문제를 빠르게 찾아 적시에 처리하는 데 도움이 되는 로그 및 모니터링 표시기도 매우 중요합니다. . 따라서 Spark 클라우드 네이티브화 과정에서 Trace 시스템이 점차 구축되었습니다. Arcee Operator 및 Gödel 스케줄러는 일부 작업 표시기를 제공하고 Spark는 비즈니스 표시기를 제공하며 독립형 Metrics Collector 구성 요소는 물리적 시스템 표시기와 컨테이너 표시기를 제공합니다. 로그의 경우 각 Node에서 실행되는 Log Agent는 지정된 경로의 로그를 수집하고 자동으로 로그 플랫폼에 업로드하여 분석 및 쿼리를 수행합니다. Arnold 머신러닝 교육 플랫폼을 기반으로 모든 지표와 로그를 실시간으로 쿼리할 수 있으며, 특정 데이터 테이블도 제공됩니다. 등. . 동시에 Arnold는 이미지 관리를 통해 적시에 업데이트를 따라잡을 수도 있습니다.

완카 모델 추론 연습

현재 클러스터는 주로 오프라인 클러스터와 온라인 클러스터로 구분됩니다. 오프라인 클러스터는 주로 교육 작업에 중점을 두고 주로 작업 처리량에 중점을 둡니다. 온라인 클러스터는 주로 온라인 추론 서비스에 중점을 둡니다. 총 수만 개의 GPU 카드가 포함된 T4, A10 및 A30과 같은 소형 카드를 중심으로 대기 시간 및 처리량에 중점을 둡니다.

주된 모순

현재 주요 모순은 오프라인 클러스터 할당량이 완전히 할당되었다는 것입니다. 논리적으로 말하면 리소스가 할당되었지만 오프라인 클러스터의 전반적인 활용도에는 여전히 개선의 여지가 많습니다. 또한, 충족되지 않은 내부 컴퓨팅 요구 사항도 많이 있습니다. 예를 들어, 우리 클러스터는 실제로는 돌과 같습니다. 돌이 가득 차 있을 수도 있지만 실제로는 이 틈에 더 많은 공간이 채워질 수 있습니다. 따라서 우리의 문제 정의는 이러한 격차를 찾아 모래로 채우는 것, 즉 적절한 재사용 가능한 자원을 찾아 적절한 작업을 제시하는 것입니다.

자원

오프라인 클러스터: 품질이 낮은 작업

첫 번째는 오프라인 클러스터의 우선순위가 낮은 작업입니다. 이 부분은 전체적으로 오프라인 클러스터에 속하며 지연에 민감하지 않습니다. 이러한 유휴 리소스는 우선순위가 낮고 여유 시간이 있을 때 우선순위가 낮은 작업을 예약합니다. 그러다가 우선순위가 높은 작업이 있으면 선점하게 됩니다. 동시에 이는 전체 카드의 자원이며, 오프라인 제출 자체에는 명확한 규칙이 없고 전반적인 격리 수준이 상대적으로 낮기 때문에 공급에 대한 명확한 규칙이 없습니다.

온라인 -> 오프라인 : 타이드

또 다른 부분은 온라인에서 오프라인으로의 조석 자원이다. 이 부분은 온라인 클러스터의 유휴 자원을 오프라인 클러스터에 빌려주는 부분이다. 이 부분도 전체 카드 자원이며, 그 공급은 다음과 같다. 비즈니스의 부침에는 분명한 패턴이 있습니다. 온라인 비즈니스가 정점에 도달하면 자동 확장을 통해 리소스가 비워지고 정점에 도달하면 용량이 늘어납니다. 다시 확장되면 클러스터는 오프라인 포드를 제거합니다. 이는 중간 격리 수준이며, 오프라인 포드는 동일한 머신에서 실행되어야 하지만 카드는 계속 격리될 수 있습니다.

온라인->오프라인: 일반 코로케이션

다른 부분은 온라인에서 오프라인으로의 일반적인 코로케이션 리소스입니다. 이 부분은 실제로 온라인 클러스터에서 상대적으로 활용도가 낮은 GPU의 컴퓨팅 성능 중 일부를 오프라인 클러스터에 빌려준다는 의미입니다. 전체 카드를 사용하지 않고 비어 있습니다. 컴퓨팅 성능을 재사용할 수 있으며 전체 구현은 Virtual-Kubelet + ByteCUDA + MPS를 기반으로 합니다.

ByteCUDA는 자체 개발한 CUDA Hook입니다. 상위 계층에서 메모리 격리 및 시분할 다중화에 대한 일부 작업을 수행합니다. 하위 계층 MPS는 공간 분할 다중화를 통해 전체 격리 수준을 향상시킵니다. 빌려준 것은 실제로 비통합 카드 리소스입니다. 즉, 하나의 카드를 여러 가지 용도로 사용할 수 있습니다. 이 카드에는 온라인 작업과 오프라인 작업이 있을 수 있습니다. 장점은 공급량이 상대적으로 안정적이라는 것입니다. 서비스의 이 부분은 모두 동일한 카드에서 실행되며 가장 높은 격리 수준을 갖습니다.

일반적인 코로케이션에 관해 우리가 갖는 가장 큰 질문은 오프라인이 온라인에 영향을 미치는 것을 방지하는 방법입니다. 우선, 메모리 격리와 컴퓨팅 성능 격리를 수행해야 합니다. 또한 로드 적응형 동적 대출 알고리즘 또는 대출 전략을 사용하여 창 기간 내 GPU의 일부 전력 소비를 관찰한 다음 이를 기반으로 판단합니다. 온라인 세계가 덜 영향을 받을 수 있도록 오프라인 계산에서는 온라인 계산 요청을 적극적으로 피해야 합니까?

또한 MPS는 결함 전파 문제로 유명합니다. 위에서 언급한 문제는 우아한 종료로 해결됩니다. 위 렌더링을 보면 코로케이션 전후의 온라인 처리량이 거의 변하지 않고 지연이 약 0.75ms 증가한다는 것을 알 수 있습니다. 실제로는 가동률이 원래 10%에서 70%로 증가했지만 이는 전체 수익에 미치는 영향은 적지만 가동률이 크게 향상되었습니다.

일

자원 다음에는 작업이 있는데, 이를 모래라고 부릅니다. 첫 번째는 그의 수요가 충분히 커야 한다는 것입니다. 그렇지 않으면 "조작"할 필요가 없습니다. 또한 이것들은 그 자체로 단편화된 자원이기 때문에 필요한 작업의 크기는 상대적으로 적당해야 하며 특별히 큰 작업이 될 수 없습니다. 또한 이러한 작업은 디스크, 네트워크 등과 같은 격리되지 않은 리소스를 과도하게 소비해서는 안 되며, 이러한 리소스는 탄력적이기 때문에 리소스의 자동 확장 및 축소에도 적응할 수 있어야 합니다. 리소스는 작업을 확장할 때 자동으로 사용되어야 합니다. 리소스는 축소될 때 이러한 축소로 인해 방해를 받지 않습니다.

Spark 기반 오프라인 추론 작업

위의 구현 요구 사항을 기반으로 Spark 기반 오프라인 추론 작업이 최종적으로 잠겼습니다. 첫째, 내부 오프라인 추론 요구 사항이 많기 때문에 수요가 충분히 크고 추론 작업 프로세스가 상대적으로 간단합니다. 그리고 Executor 간에는 아무것도 없습니다. 통신 요구를 위해 온라인 카드, RDMA 등이 필요하지 않습니다. 게다가 실제로 많은 양의 데이터가 Spark와 호환되는 HDFS에 저장됩니다. 동시에 Spark의 데이터 처리 및 데이터 배포 기능과 동적 할당을 기반으로 용량을 동적으로 확장 및 축소하는 기능도 사용해야 합니다.

SDK 빌드

작업을 잠근 후 우리가 해야 할 일은 모범 사례를 최대한 캡슐화하는 것입니다. 위는 Pytorch 및 Tensorflow와 같은 일반적인 모델 추론을 지원하는 Tide Box인 SDK의 개략도입니다. 파티션 수준 체크포인트. 이러한 방식으로 리소스를 인출할 때 계산을 반복할 필요가 없으므로 컴퓨팅 파워의 낭비를 피할 수 있으며 일괄 처리 지원을 통해 전체 리소스 활용도를 향상시킬 수 있습니다.

플랫폼 구축

SDK가 빌드된 후 플랫폼 구축도 매우 중요한 측면입니다. 우리는 사용자가 Spark Submit을 통해 직접 명령을 실행하는 것을 원하지 않으므로 제어가 불편합니다. 따라서 Arnold 머신러닝 플랫폼은 이러한 리소스를 통합적으로 관리하는 기반으로 사용되며, 노트북 개발 및 디버깅을 기반으로 사용자가 수동으로 제출을 검색하지 않고도 필요한 변수를 미리 설정할 수 있습니다. . 동시에 다양한 시나리오에서 리소스를 전환하는 것이 상대적으로 편리합니다.

또한 작업 시작 방법은 업스트림 이벤트 트리거링, 타이밍 트리거링, API 트리거링 등과 같은 다양한 방법을 지원할 수 있어 사용자 사용을 용이하게 합니다. 예를 들어 일부 파이프라인 또는 사용자 자동화 요구 사항을 구성하려는 경우 이러한 방법을 통해 유연하게 구현할 수 있습니다. 또한, 작업의 운영 및 유지 관리도 매우 중요합니다. 한 번의 클릭으로 과거 작업을 확인하고 문제를 역추적할 수 있는 기능을 구현할 수 있습니다.

작업-자원 매칭

Spark 추론 작업에는 여러 가지 유형이 있는데, 그 중 하나는 갑작스러운 긴급 수요입니다. 리소스 수요 중 이 부분은 상대적으로 크고 시간도 시급하며 일반적으로 이 부분에는 오프라인 저최적화를 사용해야 합니다. Tide는 더욱 포괄적인 카드와 강력한 컴퓨팅 성능을 갖춘 리소스입니다. 또한 정기적인 재실행이 필요하고 상대적으로 큰 리소스 요구 사항이 있으며 평균적인 작업 긴급도가 있는 작업을 일괄적으로 역추적하고 이러한 리소스를 정기 및 일반 혼합 배포에 사용해야 합니다. 일상적인 작업은 일일 수준일 수 있으며 중간 수준의 리소스 요구 사항을 갖습니다. 우리는 이를 지원하기 위해 상대적으로 더 안정적이고 안정적인 일반 코로케이션 리소스 공급을 사용할 것입니다.

온라인 대출에서 오프라인까지의 최대 상태는 약 10000+ Tidal GPU입니다. 일반적인 혼합 배포는 약 20000+입니다. 이 부분도 오프라인 혼합 배포로 인해 전체 활용도가 약 100개 이상 증가했습니다. 작업의 최대 제한은 5,000개 이상의 GPU입니다. 그렇지 않으면 사용자가 이를 더욱 늘릴 수 있으며, 이로 인해 일반적인 데이터베이스 브러싱 작업을 실행하려면 9.5일 동안 안정적인 리소스가 필요합니다. 이런 탄력적인 자원을 통해 일정이 7.5시간으로 단축되어 완료되었습니다.

미래 전망

앞으로 우리의 유연한 코로케이션 리소스는 전반적인 리소스 활용도를 향상시킬 뿐만 아니라 전체 리소스를 최적화하기 위해 더 많은 작업을 수행해야 합니다. 첫째, 온라인 운영에 대한 영향을 피하여 오프라인에서 더 많이 사용하고 더 높은 활용률을 달성하도록 노력하십시오. 또한 전체 규모와 수익을 확대하려면 더 많은 비즈니스를 연결해야 합니다. 동시에 불필요한 리소스 롤백으로 인해 발생하는 관련 문제를 최대한 줄이거나 방지합니다.

ByteDance Spark는 Wanka 모델 추론 실습을 지원합니다.