테이크아웃 광고를 위한 대규모 딥러닝 모델의 엔지니어링 실습

저자: Ya Jie Yingliang Chen Long 외

소개

Meituan의 음식 배달 사업이 지속적으로 발전함에 따라 음식 배달 광고 엔진 팀은 여러 분야에서 엔지니어링 탐구와 실습을 수행했으며, 일부 결과 결과. 순차적으로 공유할 예정이며, 내용은 주로 다음과 같습니다: ① 비즈니스 플랫폼화의 실천 ② 대규모 딥러닝 모델 엔지니어링의 실천 ③ 니어라인 컴퓨팅의 실천 - 규모의 인덱스 구축 및 온라인 검색 서비스 ⑤ 메커니즘 엔지니어링 플랫폼 실습. 얼마 전 비즈니스 플랫폼화 실천에 관한 책을 출간했습니다(자세한 내용은 "​​메이투안 테이크아웃 광고 플랫폼화 탐색 및 실습​​" 기사를 참조하세요). 이 기사는 일련의 기사 중 두 번째로, 온라인 대기 시간과 오프라인 효율성이라는 두 가지 측면에서 시작하여 대규모 딥 모델이 전체 링크 수준에서 발생하는 문제에 초점을 맞추고 대규모 광고 엔지니어링을 설명합니다. -스케일 딥 모델을 연습해 보세요. 모든 사람에게 도움이나 영감을 줄 수 있기를 바랍니다.

1 배경

검색, 추천, 광고(이하 검색 프로모션) 등 핵심 인터넷 비즈니스 시나리오에서는 사용자에게 고품질 서비스를 제공하기 위한 데이터 마이닝 및 관심도 모델링이 하나의 방식이 되었습니다. 사용자 경험을 개선합니다. 최근 몇 년 동안 검색 및 프로모션 비즈니스의 경우 데이터 배당 및 하드웨어 기술 배당의 도움으로 딥 러닝 모델이 업계에서 널리 구현되었습니다. 동시에 CTR 시나리오에서 업계는 단순한 DNN 소규모에서 점차 전환했습니다. 모델에서 수조 개의 매개변수가 포함된 대형 임베딩 모델 또는 초대형 모델까지. 테이크아웃 광고 사업 부문은 주로 "LR 얕은 모델(트리 모델)" -> "딥 러닝 모델" -> "대규모 딥 러닝 모델"의 진화 과정을 경험해 왔습니다. 전체적인 진화 추세는 인공적인 특징을 기반으로 한 단순한 모델에서 데이터를 핵심으로 하는 복잡한 딥러닝 모델로 점차 전환되고 있습니다. 대형 모델의 사용으로 모델의 표현력이 크게 향상되었고, 수요와 공급 측면을 더욱 정확하게 일치시키며, 후속 비즈니스 개발에 더 많은 가능성을 제공했습니다. 그러나 모델과 데이터의 규모가 계속 증가함에 따라 효율성과 다음과 같은 관계가 있음을 알 수 있습니다. 위 그림에서 볼 수 있듯이 데이터와 모델의 규모가 증가하면 해당 "기간"은 점점 길어집니다. 이 "기간"은 효율성에 반영되는 오프라인 수준에 해당하며 대기 시간에 반영됩니다. 그리고 우리의 작업은 이 "기간"의 최적화를 중심으로 수행됩니다.

2 분석

일반 소형 모델과 비교하여 대형 모델의 핵심 문제는 데이터의 양과 모델 규모가 수십, 심지어 수백 배 증가함에 따라 스토리지, 통신, 컴퓨팅 등이 전체 링크는 새로운 문제에 직면하게 되며 이는 결국 알고리즘의 오프라인 반복 효율성에 영향을 미칩니다. 온라인 지연 제약과 같은 일련의 문제를 해결하는 방법은 무엇입니까? 아래 표시된 것처럼 먼저 전체 링크에서 분석해 보겠습니다.

"기간"이 길어지며 이는 주로 다음 측면에 반영됩니다.

• 온라인 지연: 기능 수준에서 온라인 요청이 변경되지 않은 경우 기능 볼륨의 증가로 인해 IO 증가 및 기능 계산 시간 소모와 같은 특히 눈에 띄는 문제가 발생하며 기능 분석 및 컴파일이 필요합니다. 연산자, 특징 추출, 내부 작업 스케줄링, 네트워크 I/O 전송 및 기타 측면이 재구성됩니다. 모델 수준에서 모델은 수백 M/G에서 수백 G로 변경되었으며, 이로 인해 저장 공간이 두 자릿수 증가했습니다. 또한 단일 모델의 계산량도 엄청나게 증가했습니다(FLOP는 수백만에서 현재 수천만으로). 단순히 CPU에 의존하는 것만으로는 CPU+ 구축에 필요한 엄청난 컴퓨팅 성능을 해결할 수 없습니다. GPU+계층적 캐시 대규모 딥러닝 추론을 지원하려면 추론 아키텍처를 개발하는 것이 필수적입니다.
• 오프라인 효율성: 샘플 및 기능의 수가 몇 배로 증가함에 따라 샘플 구성 및 모델 학습 시간이 크게 길어지고 심지어 수용할 수 없게 될 수도 있습니다. 제한된 자원으로 대규모 샘플 구성과 모델 교육을 어떻게 해결하느냐가 시스템의 주요 문제입니다. 데이터 수준에서 업계는 일반적으로 두 가지 수준에서 문제를 해결합니다. 한편으로는 일괄 처리 프로세스의 제약 조건을 지속적으로 최적화하고, 다른 한편으로는 중앙 집중식에서 분산식으로 "일괄 처리"를 데이터 스트림으로 전환합니다. , 이는 데이터 준비 시간의 효율성을 크게 향상시킵니다. 훈련 수준에서는 아키텍처 수준 최적화와 결합된 하드웨어 GPU를 통해 가속화가 달성됩니다. 둘째, 알고리즘 혁신은 종종 사람에 의해 주도됩니다. 어떻게 새로운 데이터가 모델과 신속하게 일치할 수 있습니까? N명의 사람이 N개의 비즈니스 라인에 배치되어 동일한 최적화를 수행한다면 어떻게 발전할 수 있습니까? 하나의 사업 라인을 최적화하고 N-1개의 사업 라인에 동시에 방송함으로써 N-1 인력을 투입하여 새로운 혁신을 수행하게 되며, 이는 특히 향후 전체 모델 규모가 변경될 때 혁신 주기를 크게 단축할 것입니다. 수동 반복 비용이 필연적으로 증가하고, "사람이 기능/모델 찾기"에서 "기능/모델이 사람 찾기"로 심층적인 전환을 달성하고, "반복적인 혁신"을 줄이고, 모델과 데이터의 지능적인 일치를 달성할 것입니다.
• 파이프라인의 기타 문제: 기계 학습 파이프라인은 대규모 딥 러닝 모델 링크에만 국한되지 않지만 대규모 모델이 출시되면 다음과 같은 새로운 과제가 발생할 것입니다. ① 시스템 프로세스를 지원하는 방법 전체 ② 모델의 롤백 시간, 작업을 올바르게 수행하는 데 걸리는 시간, 작업을 잘못한 후 복구하는 데 소요되는 시간. 즉, 개발, 테스트, 배포, 모니터링, 롤백 등에서 새로운 요구가 발생할 것입니다.

이 기사에서는 온라인 대기 시간(모델 추론, 기능 서비스), 오프라인 효율성(샘플 구성, 데이터 준비)이라는 두 가지 측면에 중점을 두고 대규모 및 심층 애플리케이션을 점진적으로 설명합니다. 모델에 대한 광고 엔지니어링 실습. 다음 장에서 "지속 시간"을 최적화하는 방법과 기타 관련 문제를 공유할 예정이니 계속 지켜봐 주시기 바랍니다.

3 모델 추론

모델 추론 수준에서 테이크아웃 광고는 틈새 규모를 지원하는 DNN 모델로 대표되는 1.0 시대부터 효율적이고 로우 코드인 2.0 시대까지 세 가지 버전을 거쳤습니다. 멀티 비즈니스 반복을 지원하고 오늘날의 3.0 시대에는 점차 딥 러닝 DNN 컴퓨팅 성능과 대규모 스토리지에 대한 수요에 직면하고 있습니다. 주요 진화 추세는 아래 그림에 나와 있습니다.

대형 모델 추론 시나리오의 경우 3.0 아키텍처로 해결된 두 가지 핵심 문제는 "스토리지 문제"와 "성능 문제"입니다. 물론, 수백 개의 G+ 모델을 어떻게 반복할지, 계산 부하가 수십 배 증가할 때 온라인 안정성을 보장할지, 파이프라인을 어떻게 강화할지 등도 프로젝트가 직면한 과제입니다. 아래에서는 Model Inference 3.0 아키텍처가 "분산"을 통해 대규모 모델 스토리지 문제를 해결하는 방법과 CPU/GPU 가속을 통해 성능 및 처리량 문제를 해결하는 방법에 중점을 둘 것입니다.

3.1 분산

대형 모델의 매개변수는 주로 희소 매개변수와 밀도 매개변수의 두 부분으로 나뉩니다.

• 희소 매개변수: 매개변수 크기는 매우 커서 일반적으로 10억 수준 또는 심지어 10억/수백억 수준이며 이는 일반적으로 수백 G 수준의 대규모 저장 공간 점유로 이어집니다. 아니면 T레벨이라도요. 특징: ① 독립 실행형 로드의 어려움: 독립 실행형 모드에서는 모든 Sparse 매개변수를 기계 메모리에 로드해야 하므로 심각한 메모리 부족이 발생하여 안정성과 반복 효율성에 영향을 미칩니다. ② Sparse 읽기: Sparse의 일부만; 각 추론 계산마다 매개변수를 읽어야 합니다. 예를 들어 사용자 매개변수의 전체 양은 2억 수준이지만 각 추론 요청마다 하나의 사용자 매개변수만 읽어야 합니다.
• 밀도 매개변수: 매개변수 규모가 크지 않고 모델은 일반적으로 2~3개의 레이어로 완전히 연결되며 매개변수 크기는 백만/천만 수준입니다. 특징: ① 단일 머신 로드 가능: 밀도가 높은 매개변수는 약 수십 메가바이트를 차지하며 단일 머신 메모리는 정상적으로 로드할 수 있습니다. 예: 입력 레이어는 2000, 완전 연결 레이어는 [1024, 512, 256], 총 매개변수는 다음과 같습니다: 2000 * 1024 + 1024 * 512 + 512 * 256 + 256 = 2703616, 총 270만 개의 매개변수, 점유된 메모리는 100MB 이내입니다. ② 전체 읽기: 각 추론 계산에 대해 전체 양 매개변수를 읽어야 합니다.

따라서 대규모 모델 매개변수 규모 증가 문제를 해결하는 열쇠는 희소 매개변수를 단일 머신 저장소에서 분산 저장소로 변환하는 것입니다. 변환 방법은 두 부분으로 구성됩니다. ① 모델 네트워크 구조 변환 ② 희소 매개변수 내보내기 .

3.1.1 모델 네트워크 구조 변환

업계에서 분산 매개변수를 얻는 방법은 크게 두 가지 유형으로 나뉩니다. 외부 서비스에서 미리 매개변수를 얻어 예측 서비스에 전달하고, 예측 서비스에서 내부적으로 TF(TensorFlow)를 변환합니다. ) 분산 저장소에서 매개변수를 가져오는 연산자입니다. 아키텍처 수정 비용을 줄이고 기존 모델 구조에 대한 침입을 줄이기 위해 TF 연산자를 수정하여 분산 매개변수를 얻기로 결정했습니다.

일반적인 상황에서 TF 모델은 기본 연산자를 사용하여 Sparse 매개변수를 읽습니다. 핵심 연산자는 GatherV2 연산자이며 주로 두 부분으로 구성됩니다. ① 쿼리할 ID 목록 ② Sparse Embedding 저장. 매개변수 테이블.

연산자의 기능은 Embedding 테이블에서 ID 목록 인덱스에 해당하는 Embedding 데이터를 읽어서 반환하는 것입니다. 본질적으로 Hash 쿼리 프로세스입니다. 그 중 Embedding 테이블에 저장된 Sparse 매개변수는 단일 머신 모델의 단일 머신 메모리에 모두 저장됩니다.

TF 연산자 변환은 본질적으로 모델 네트워크 구조의 변환입니다. 변환의 핵심 포인트는 주로 두 부분으로 구성됩니다. ① 네트워크 그래프 재구성;

1. 네트워크 다이어그램 재구성: 모델 네트워크 구조를 변환하고 기본 TF 연산자를 사용자 정의 분산 연산자로 교체하는 동시에 기본 Embedding 테이블을 강화합니다.

• 분산 연산자 교체: 모델 네트워크를 순회하고, 교체해야 하는 GatherV2 연산자를 사용자 지정 분산 연산자 MtGatherV2로 교체하고, 업스트림 및 다운스트림 노드의 입력/출력을 동시에 수정합니다. .
• 네이티브 임베딩 테이블 강화: 네이티브 임베딩 테이블은 모델 네트워크 구조의 무결성을 유지할 수 있을 뿐만 아니라 스파스 매개변수에 의한 단일 머신 메모리 점유를 피할 수 있는 자리 표시자로 굳어집니다.

2. 사용자 정의 분산 연산자: ID 목록을 기반으로 Embedding 쿼리 프로세스를 수정하고, 로컬 Embedding 테이블에서 쿼리하고, 분산 KV에서 쿼리하도록 수정합니다.

• 요청 쿼리: 입력 ID를 중복 제거하여 쿼리 볼륨을 줄이고 동시에 샤딩을 통해 2차 캐시(로컬 캐시 + 원격 KV)를 쿼리하여 임베딩 벡터를 얻습니다.
• 모델 관리: 모델 임베딩 메타 등록 및 제거 프로세스와 캐시 기능 생성 및 삭제를 유지합니다.
• 모델 배포: 모델 리소스 정보 로드 및 임베딩 데이터를 KV로 병렬 가져오는 프로세스를 트리거합니다.

3.1.2 Sparse 매개변수 내보내기

• 샤딩된 병렬 내보내기: 모델의 Checkpoint 파일을 파싱하여 Embedding 테이블에 해당하는 Part 정보를 얻어 Part별로 나누어 통과시킨다. 여러 작업자 노드를 통한 각 부품 파일은 HDFS로 병렬로 내보내집니다.
• KV 가져오기: 여러 버킷을 미리 할당합니다. 버킷은 온라인 라우팅 쿼리를 용이하게 하기 위해 모델 버전과 같은 정보를 저장합니다. 동시에 모델의 임베딩 데이터도 버킷에 저장되고 샤딩을 통해 병렬로 KV로 가져옵니다.

전체 프로세스는 아래 그림과 같습니다. 오프라인 분산 모델 구조 변환, 니어라인 데이터 일관성 보장 및 온라인 핫스팟 데이터 캐싱을 통해 100G 대형 모델의 일반적인 반복 요구 사항을 보장합니다.

분산 스토리지에서 사용하는 스토리지는 외부 KV 기능임을 알 수 있으며, 이는 향후 더욱 효율적이고 유연하며 관리하기 쉬운 임베딩 서비스로 대체될 예정입니다.

3.2 CPU 가속

모델 자체의 최적화 방법 외에도 두 가지 주요 일반적인 CPU 가속 방법이 있습니다. ① AVX2, AVX512 명령어 세트 사용과 같은 명령어 세트 최적화 ② 가속 라이브러리(TVM 사용) , OpenVINO ).

1. 명령 세트 최적화: TensorFlow 모델을 사용하는 경우 TensorFlow 프레임워크 코드를 컴파일할 때 명령 세트 최적화 항목을 컴파일 옵션에 직접 추가하면 됩니다. 실습을 통해 AVX2 및 AVX512 명령어 세트의 도입으로 확실한 최적화 효과가 있으며 온라인 추론 서비스의 처리량이 30% 이상 증가한 것으로 입증되었습니다.
2. 가속 라이브러리 최적화: 가속 라이브러리는 추론 가속 효과를 달성하기 위해 네트워크 모델 구조를 최적화하고 통합합니다. 업계에서 일반적으로 사용되는 가속 라이브러리에는 TVM, OpenVINO 등이 있습니다. 그 중 TVM은 크로스 플랫폼을 지원하며 다양성이 뛰어납니다. OpenVINO는 Intel 제조업체의 하드웨어에 특별히 최적화되어 있으며 일반적인 다양성을 갖추고 있지만 가속 효과가 좋습니다.

아래에서는 CPU 가속을 위해 OpenVINO를 사용한 실제 경험에 중점을 둘 것입니다. OpenVINO는 압축 최적화, 가속 컴퓨팅 및 기계 학습 모델의 기타 기능을 지원하는 Intel에서 출시한 딥 러닝 기반 컴퓨팅 가속 최적화 프레임워크 세트입니다. OpenVINO의 가속 원리는 선형 연산자 융합과 데이터 정확도 교정의 두 부분으로 간단히 요약됩니다.

1. 선형 연산자 융합: OpenVINO는 모델 최적화 프로그램을 사용하여 모델 네트워크의 다층 연산자를 균일하게 선형적으로 융합하여 연산자 예약 오버헤드와 연산자 간의 데이터 액세스 오버헤드를 줄입니다. 예를 들어 Conv+ 연산자는 3개입니다. BN+Relu는 CBR 구조 연산자로 결합됩니다.
2. 데이터 정확도 교정: 모델이 오프라인으로 훈련된 후에는 추론 프로세스 중에 역전파가 필요하지 않으므로 FP16 또는 INT8 정확도로 다운그레이드하는 등 데이터 정확도를 적절하게 낮출 수 있습니다. 더 작은 공간, 더 낮은 추론 지연 시간.

CPU 가속은 일반적으로 고정 배치 후보 대기열에 대한 추론을 가속화하지만 검색 승격 시나리오에서는 후보 대기열이 동적인 경우가 많습니다. 즉, 모델 추론 전에 배치 일치 작업을 추가해야 합니다. 즉, 요청된 동적 배치 후보 대기열이 가장 가까운 배치 모델에 매핑되지만 이를 위해서는 N개의 일치 모델을 구축해야 하므로 메모리 사용량이 N배가 됩니다. . 현재 모델 볼륨은 수백 기가바이트에 이르렀고, 메모리도 심각하게 부족합니다. 따라서 가속을 위한 합리적인 네트워크 구조를 선택하는 것은 고려해야 할 핵심 문제입니다. 아래 사진은 전체적인 운영 구조입니다:

1. Network distribution: CTR 모델의 전체 네트워크 구조는 Embedding 레이어, Attention 레이어 및 MLP 레이어의 세 부분으로 추상화됩니다. Embedding 레이어는 데이터 수집에 사용되며 Attention 레이어에는 더 많은 논리적 작업이 포함되어 있습니다. 경량 네트워크 컴퓨팅, MLP 계층은 밀도가 높은 네트워크 컴퓨팅입니다.
2. 가속 네트워크 선택: OpenVINO는 순수 네트워크 계산에 더 나은 가속 효과를 가지며 MLP 계층에 잘 적용될 수 있습니다. 또한 대부분의 모델 데이터는 Embedding 레이어에 저장되며 MLP 레이어는 수십 메가바이트의 메모리만 차지합니다. MLP 계층 네트워크를 위해 여러 개의 배치가 분할되면 모델 메모리 사용량은 최적화 전(Embedding+Attention+MLP) ≒ 최적화 후(Embedding+Attention+MLP×Batch number)가 되며, 메모리 사용량에 미치는 영향 작을 것이다. 따라서 우리는 최종적으로 모델 가속 네트워크로 MLP 계층 네트워크를 선택했습니다.

현재 OpenVINO 기반 CPU 가속 솔루션은 프로덕션 환경에서 좋은 결과를 얻었습니다. CPU가 기준과 동일할 때 서비스 처리량은 40% 증가하고 평균 지연은 1% 감소합니다. 15%. CPU 수준에서 가속을 원할 경우 OpenVINO가 좋은 선택입니다.

3.3 GPU 가속

한편으로는 비즈니스가 발전함에 따라 비즈니스 형태가 점점 더 풍부해지고, 트래픽이 점점 더 많아지고, 모델이 더 넓고 깊어지고, 컴퓨팅 파워 소비가 급격히 증가합니다. 반면, 광고 시나리오는 주로 DNN 모델을 사용하며 다수의 희소 기능 임베딩 및 신경망 부동 소수점 연산을 포함합니다. 메모리 액세스 및 컴퓨팅 집약적인 온라인 서비스로서 낮은 대기 시간과 높은 처리량 요구 사항을 충족하는 동시에 단일 시스템의 컴퓨팅 성능에 대한 과제이기도 한 가용성을 보장해야 합니다. 컴퓨팅 리소스 요구 사항과 공간 간의 이러한 충돌이 잘 해결되지 않으면 비즈니스 개발이 크게 제한됩니다. 모델이 확대되고 심화되기 전에는 순수한 CPU 추론 서비스가 상당한 처리량을 제공할 수 있지만, 모델이 확대되고 심화된 후에는 계산이 다음과 같이 됩니다. 고가용성을 보장하기 위해서는 많은 양의 기계 자원을 소비해야 하므로 대형 모델을 온라인에서 대규모로 적용할 수 없습니다. 현재 업계의 일반적인 솔루션은 GPU를 사용하여 이 문제를 해결하는 것입니다. GPU 자체는 컴퓨팅 집약적인 작업에 더 적합합니다. GPU를 사용하려면 다음과 같은 과제를 해결해야 합니다. 즉, 가용성과 짧은 대기 시간을 보장하면서 사용 편의성과 다양성을 고려하면서 최대한 높은 처리량을 달성하는 방법입니다. 이를 위해 TensorFlow-GPU, TensorFlow-TensorRT, TensorRT 등과 같은 GPU에 대한 실제 작업도 많이 수행했습니다. TF의 유연성과 TensorRT의 가속 효과를 고려하기 위해 TensorFlow+TensorRT의 독립적인 2단계 아키텍처 설계.

3.3.1 가속 분석

• 이종 컴퓨팅: 우리의 아이디어는 CPU 가속과 일치합니다. 200G 딥 러닝 CTR 모델은 GPU에 직접 넣을 수 없으며 메모리 액세스 집약적인 연산자가 적합합니다. ( 예를 들어 Embedding 관련 연산) CPU, 계산 집약적인 연산자(예: MLP)가 GPU에 적합합니다.
• GPU를 사용할 때 주의해야 할 몇 가지 사항: ① 메모리와 비디오 메모리 간의 빈번한 상호 작용, ② 지연 시간 및 처리량 ③ 확장성과 성능 최적화를 위한 균형;
• 추론 엔진 선택: 업계에서 일반적으로 사용되는 추론 가속 엔진에는 TensorRT, TVM, XLA, ONNXRuntime 등이 있습니다. TensorRT는 다른 엔진보다 연산자 최적화에 더 심층적이므로 맞춤형 플러그인을 통해 구현 모든 운영자는 강력한 확장성을 가지고 있습니다. 또한 TensorRT는 일반적인 학습 플랫폼(Caffe, PyTorch, TensorFlow 등 )의 모델을 지원하며, 주변 장치도 점점 더 완벽해지고 있습니다(모델 변환 도구 onnx-tensorrt, 성능 분석 도구 nsys 등 ) 따라서 GPU 측 가속 엔진은 TensorRT를 사용합니다.
• 모델 분석: CTR 모델의 전체 네트워크 구조는 임베딩 레이어, 어텐션 레이어 및 MLP 레이어의 세 부분으로 추상화됩니다. 임베딩 레이어는 데이터 수집에 사용되며 CPU에 적합합니다. 더 많은 논리적 연산 및 경량화 네트워크 컴퓨팅의 경우 MLP 계층은 네트워크 컴퓨팅에 중점을 두고 이러한 계산을 병렬로 수행할 수 있으며 GPU 코어(Cuda Core, Tensor Core)를 최대한 활용하여 정도를 향상시킬 수 있습니다. 병렬성의.

3.3.2 최적화 목표

딥 러닝의 추론 단계는 컴퓨팅 능력과 지연 시간에 대한 요구 사항이 매우 높습니다. 훈련된 신경망을 추론 끝에 직접 배포하면 부족할 가능성이 높습니다. 또는 긴 추론 시간과 같은 문제가 발생합니다. 따라서 훈련된 신경망에 대해 특정 최적화를 수행해야 합니다. 업계에서 신경망 모델을 최적화하려는 일반적인 아이디어는 모델 압축, 서로 다른 네트워크 계층 병합, 희소화, 정밀도가 낮은 데이터 유형 사용 등 다양한 측면에서 최적화할 수 있습니다. 심지어 이를 기반으로 한 타겟 최적화도 필요합니다. 하드웨어 특성. 이를 위해 우리는 주로 다음 두 가지 목표를 중심으로 최적화합니다.

1. 지연 및 리소스 제약 하의 처리량: 레지스터 및 캐시와 같은 공유 리소스가 경쟁할 필요가 없는 경우 동시성을 높이면 리소스 활용도(CPU, GPU 등 활용도)를 효과적으로 향상시킬 수 있지만, 요청 대기 시간이 늘어날 수 있습니다. 온라인 시스템의 지연 제한은 매우 엄격하기 때문에 온라인 시스템의 처리량 상한은 단순히 자원 활용 지표를 통해 환산될 수 없으며 지연 제한 하에서 종합적으로 평가되어 자원 상한과 결합되어야 합니다. 시스템 지연 시간이 낮고 리소스(메모리/CPU/GPU 등) 활용도가 제한 요소인 경우 시스템 리소스 활용도가 낮을 ​​때 모델 최적화를 통해 리소스 활용도를 줄일 수 있습니다. 제약이 발생할 경우 융합 최적화, 엔진 최적화를 통해 지연 시간을 줄일 수 있습니다. 위의 다양한 최적화 방법을 결합함으로써 시스템 서비스의 포괄적인 기능을 효과적으로 향상시킬 수 있으며 이를 통해 시스템 처리량 향상이라는 목적을 달성할 수 있습니다.
2. 계산 제약 조건 하의 컴퓨팅 밀도: CPU/GPU 이기종 시스템에서 모델 추론 성능은 주로 데이터 복사 효율성과 컴퓨팅 효율성에 의해 영향을 받습니다. 이는 각각 메모리 액세스 집약적인 연산자와 계산 집약적인 연산자에 의해 결정됩니다. 효율성은 PCIe 데이터 전송, CPU/GPU 메모리 읽기 및 쓰기 등의 효율성에 영향을 받으며, 컴퓨팅 효율성은 CPU Core, CUDA Core, Tensor Core 등 다양한 컴퓨팅 장치의 컴퓨팅 효율성에 영향을 받습니다. GPU 등 하드웨어의 급속한 발전으로 인해 컴퓨팅 집약적인 사업자의 처리 능력이 급격히 증가하여, 메모리 접근 집약적인 사업자가 시스템 서비스 능력 향상을 방해하는 현상이 나타나고 있으며, 이에 따라 메모리 접근 집약적인 사업자는 감소하고 있다. 그리고 컴퓨팅 밀도를 향상시키는 것도 시스템 서비스 기능에 점점 더 중요해지고 있습니다. 즉, 모델 계산량이 크게 변하지 않을 때 데이터 복사 및 커널 실행을 줄이는 것입니다. 예를 들어, 모델 최적화 및 융합 최적화는 연산자 변환(Cast/Unsqueeze/Concat 및 기타 연산자 등)의 사용을 줄이는 데 사용되고 CUDA Graph는 커널 실행 등을 줄이는 데 사용됩니다.

다음에서는 위의 두 가지 목표에 중점을 두고 모델 최적화, 융합 최적화 및 엔진 최적화에서 수행한 작업 중 일부를 자세히 소개합니다.

3.3.3 모델 최적화

1. 계산 및 전송 중복 제거: 추론 중에 동일한 배치에는 사용자 정보가 하나만 포함되므로 추론 전에 사용자 정보를 배치 크기에서 1로 줄일 수 있습니다. 데이터 전송 복사 및 반복 계산 오버헤드를 줄이기 위해 추론 중에 다시 확장이 필요했습니다. 아래 그림과 같이 User 클래스 특징 정보를 추론 전 한 번만 조회하고, 사용자 관련 하위 네트워크에서만 잘라낸 후 연관성 계산이 필요할 때 확장하면 됩니다.

• 자동화된 프로세스: 반복 계산이 수행되는 노드를 찾습니다(red node). 해당 노드의 모든 리프 노드가 반복 계산 노드이면 해당 노드도 반복적으로 계산합니다. , 리프 노드부터 시작하여 모든 중복 노드에 대해 레이어별로 위쪽으로 검색하여 노드를 탐색하여 모든 빨간색과 흰색 노드의 연결선을 찾고 사용자 기능 확장 노드를 삽입하고 사용자 기능을 확장합니다.

2. 데이터 정확도 최적화 : 모델 학습에서는 경사를 업데이트하기 위해 역전파가 필요하므로 모델 추론에는 경사만 업데이트하면 됩니다. 효과 보장을 전제로 최적화를 위해 FP16 또는 혼합 정밀도를 사용하고, 메모리 공간을 절약하고, 전송 오버헤드를 줄이고, 추론 성능과 처리량을 향상시킵니다.

3. 계산 푸시다운: CTR 모델 구조는 주로 Embedding, Attention 및 MLP의 세 가지 계층으로 구성되며, Attention은 부분적으로 논리 중심이고 부분적으로 계산 중심입니다. , GPU의 잠재력을 최대한 활용하기 위해 CTR 모델 구조의 Attention 및 MLP 계산 로직의 대부분이 계산을 위해 CPU에서 GPU로 이동되어 전체 처리량이 크게 향상됩니다.

3.3.4 융합 최적화

온라인 모델 추론 중에 각 레이어의 작업은 GPU에 의해 완료됩니다. 실제로 CPU는 다양한 CUDA 커널을 시작하여 텐서를 매우 빠르게 계산합니다. CUDA 커널을 시작하고 각 레이어의 입출력 텐서를 읽고 쓰는 데 많은 시간이 낭비되는 경우가 많으며, 이로 인해 메모리 대역폭 병목 현상이 발생하고 GPU 리소스가 낭비됩니다. 여기서는 TensorRT 부분인 자동 최적화와 수동 최적화를 주로 소개하겠습니다. 1. 자동 최적화: TensorRT는 딥 러닝 애플리케이션에 짧은 지연 시간, 높은 처리량 추론 배포를 제공할 수 있는 고성능 딥 러닝 추론 최적화 도구입니다. TensorRT는 대규모 모델, 임베디드 플랫폼 또는 자율 주행 플랫폼에 대한 추론을 가속화하는 데 사용할 수 있습니다. TensorRT는 이제 TensorFlow, Caffe, MXNet 및 PyTorch와 같은 거의 모든 딥 러닝 프레임워크를 지원할 수 있습니다. TensorRT를 NVIDIA GPU와 결합하면 거의 모든 프레임워크에서 빠르고 효율적인 배포 및 추론이 가능해집니다. 그리고 일부 최적화에는 Layer Fusion, Kernel Auto-Tuning 등과 같은 사용자 참여가 너무 많이 필요하지 않습니다.

• Layer Fusion: TensorRT는 레이어 간에 수평 또는 수직으로 병합하여 네트워크 레이어 수를 크게 줄입니다. 간단히 말해서 일부 계산 작업을 융합하거나 일부 중복 작업을 제거하여 데이터 순환 시간과 비디오 메모리 수를 줄입니다. .빈번한 사용 및 스케줄링 오버헤드. 예를 들어 일반적인 네트워크 구조에는 Convolution 및 ElementWise Operation fusion, CBR fusion 등이 포함됩니다. 다음 그림은 fusion 프로세스 중 FusedNewOP가 다양한 Tactic을 포함할 수 있는 전체 네트워크 구조의 일부 하위 그래프에 대한 구조 다이어그램입니다. CudnnMLPFC, CudnnMLPMM, CudaMLP 등과 같은 마지막으로 지속 시간을 기준으로 융합 구조로 최적의 Tactic이 선택됩니다. 융합 작업을 통해 네트워크 계층 수를 줄이고 데이터 채널을 단축하여 동일한 구조를 병합하여 데이터 채널을 넓혀 GPU 리소스를 보다 효율적으로 사용한다는 목적을 달성합니다.

• Kernel Auto-Tuning: 네트워크 모델이 추론 중일 때 계산을 위해 GPU의 CUDA 커널을 호출합니다. TensorRT는 다양한 네트워크 모델, 그래픽 카드 구조, SM 수, 코어 주파수 등에 대해 CUDA 커널을 조정하고 다양한 최적화 전략 및 계산 방법을 선택하며 현재 상황에 적합한 최적의 계산 방법을 찾아 현재 모델을 보장할 수 있습니다. 특정 플랫폼에서 최상의 결과를 얻습니다. 위 그림은 최적화의 주요 아이디어입니다. 각 op에는 여러 커널 최적화 전략(cuDNN, cuBLAS 등)이 있습니다. 현재 아키텍처에 따르면 비효율적인 커널은 모든 최적화 전략에서 필터링되고 최적의 커널이 됩니다. 동시에 선택되어 궁극적으로 새로운 Network 를 형성합니다.

2. 수동 최적화: 우리 모두 알고 있듯이 GPU는 계산 집약적인 연산자에는 적합하지만 다른 유형의 연산자(경량 계산 연산자, 논리 연산 연산자 등)에는 적합하지 않습니다. .) 친절해요. GPU 계산을 사용할 때 각 작업은 일반적으로 여러 프로세스를 거칩니다. CPU가 GPU에 비디오 메모리 할당 -> CPU가 GPU에 데이터 전송 -> CPU가 CUDA 커널 시작 -> CPU가 데이터 검색 -> CPU가 GPU 비디오 메모리 해제. 스케줄링, 커널 실행, 메모리 액세스 등의 오버헤드를 줄이기 위해서는 네트워크 통합이 필요합니다. CTR 대형 모델의 유연하고 변경 가능한 구조로 인해 네트워크 융합 방법을 통일하기 어렵고 특정 문제에 대해서만 세부적으로 분석할 수 있습니다. 예를 들어 수직 방향에서는 Cast, Unsqueeze, Less가 융합되고, 수평 방향에서는 TensorRT 내부 ​​Conv, BN, Relu가 융합되며, 동일한 차원의 입력 연산자가 융합됩니다. 이를 위해 NVIDIA 관련 성능 분석 도구(NVIDIA Nsight Systems, NVIDIA Nsight Compute 등)를 사용하여 실제 온라인 비즈니스 시나리오를 기반으로 특정 문제를 분석합니다. 이러한 성능 분석 도구를 온라인 추론 환경에 통합하여 추론 프로세스 중에 GPU Profing 파일을 얻습니다. Profing 파일을 통해 우리는 추론 프로세스 전체에서 일부 연산자의 커널 실행 바운드 현상이 심각하고 일부 연산자 간의 격차가 크고 최적화의 여지가 있음을 명확하게 볼 수 있습니다. 다음 그림:

이를 위해 성능 분석 도구와 변환된 모델을 기반으로 전체 네트워크를 분석하고 TensorRT가 최적화한 부분을 찾은 다음 네트워크에서 최적화할 수 있는 다른 하위 구조에 대한 네트워크 통합을 수행하는 동시에 이러한 기능을 보장합니다. 하위 구조는 통합 후 컴퓨팅 밀도가 어느 정도 증가할 수 있도록 전체 네트워크가 일정 비율을 차지합니다. 어떤 종류의 네트워크 통합 방법을 사용할지는 특정 시나리오에 따라 유연하게 사용할 수 있습니다. 다음 그림은 통합 전과 후의 하위 구조 다이어그램을 비교한 것입니다.

3.3.5 엔진 최적화

1. 다중 모델 : 테이크아웃 광고의 사용자 요청 규모가 불확실하고 광고가 더 많을 때도 있고 적을 때도 있으므로 이러한 목적을 위해 여러 모델이 로드됩니다. 각 모델은 서로 다른 입력 배치에 해당합니다. 입력 스케일은 버킷과 카테고리로 나누어지고, 패딩은 여러 개로 나누어져 Batch가 고정되어 추론을 위한 해당 모델에 대응됩니다.
2. 다중 컨텍스트 및 다중 스트림: 각 배치 모델에 다중 컨텍스트 및 다중 스트림을 사용하면 동일한 컨텍스트를 기다리는 모델의 오버헤드를 피할 수 있을 뿐만 아니라 스트림을 실현하는 멀티 스트림 동시에 자원 경쟁 문제를 더 잘 해결하기 위해 CAS가 도입되었습니다. 아래 그림과 같이 단일 스트림이 다중 스트림이 됩니다.

3. Dynamic Shape: 입력 배치가 불확실한 시나리오에서 불필요한 데이터 패딩을 처리하기 위해, 동시에 모델 수를 줄이고 비디오 메모리 등의 리소스를 줄입니다. 낭비를 줄이기 위해 Dynamic Shape를 도입하고 모델은 실제 입력 데이터를 기반으로 추론하여 데이터 패딩과 불필요한 컴퓨팅 리소스 낭비를 줄이고 궁극적으로 성능 최적화 및 처리량 향상이라는 목표를 달성합니다.
4. CUDA 그래프: 각 작업(커널 실행 등)에 최신 GPU가 소비한 시간은 최소 마이크로초 수준이며, 각 작업을 GPU에 제출하면 약간의 오버헤드도 발생합니다(마이크로초 수준 ). ). 실제 추론에서는 많은 수의 커널 연산을 수행해야 하는 경우가 많으며, 이러한 각 연산은 GPU에 별도로 제출되고 독립적으로 계산됩니다. 성능에. CUDA Graph는 전체 컴퓨팅 프로세스를 개별 작업 목록이 아닌 그래프로 정의한 다음 단일 CPU 작업이 그래프에서 여러 GPU 작업을 시작하는 방법을 제공하여 커널 제출 시작의 오버헤드를 줄임으로써 이를 수행할 수 있습니다. CUDA Graph의 핵심 아이디어는 추론 전후의 그래프를 캡처하고 추론의 필요에 따라 그래프를 업데이트함으로써 후속 추론에서 더 이상 커널을 차례로 시작할 필요가 없고 그래프만 실행하는 횟수를 줄이는 것입니다. 실행이 필요하므로 궁극적으로 커널 실행 횟수가 줄어듭니다. 아래 그림과 같이 하나의 추론으로 4개의 커널 관련 연산을 수행하는데, CUDA Graph를 사용하면 최적화 효과를 명확하게 확인할 수 있습니다.

5. 다중 레벨 PS: GPU 가속 엔진의 성능을 더 자세히 살펴보기 위해 Embedding 데이터에 대한 쿼리 작업은 다단계 PS를 통해 수행할 수 있습니다. GPU 메모리 캐시->CPU 메모리 캐시->로컬 SSD/분산 KV. 그중 핫스팟 데이터는 GPU 메모리에 캐시될 수 있으며 캐시된 데이터는 데이터 핫스팟 마이그레이션, 승격 및 제거와 같은 메커니즘을 통해 동적으로 업데이트될 수 있으며 효율적인 쿼리를 위해 GPU의 병렬 컴퓨팅 성능 및 메모리 액세스 기능을 최대한 활용합니다. . 오프라인 테스트 후 GPU 캐시의 쿼리 성능은 CPU 캐시의 쿼리 성능보다 10배 더 높습니다. GPU 캐시 누락 데이터의 경우 2레벨 캐시에 대한 데이터 액세스를 90% 이상 충족할 수 있습니다. 롱테일 요청, 분산된 KV에 액세스하여 데이터 수집을 수행해야 합니다. 구체적인 구조는 다음과 같습니다.

3.3.6 Pipeline

모델은 오프라인 교육에서 최종 온라인 로딩까지 진행됩니다. 전체 프로세스가 번거롭고 오류가 발생하기 쉬우며 모델을 범용적으로 사용할 수 없습니다. 다른 GPU 카드, 다른 TensorRT 및 CUDA 버전으로 인해 모델 변환 시 오류가 발생할 가능성이 더 높아집니다. 따라서 모델 반복의 전반적인 효율성을 향상시키기 위해 아래 그림과 같이 파이프라인에 관련 기능을 구축했습니다.

파이프라인 구성에는 오프라인 측면 모델 분할 및 변환 프로세스와 온라인 측면 모델 배포 프로세스의 두 부분이 포함됩니다.

1. 오프라인 측면: 모델 분할 노드만 제공하면 플랫폼이 자동으로 원본 TF를 변환합니다. 모델은 Embedding 하위 모델과 계산 그래프 하위 모델로 분할됩니다. Embedding 하위 모델은 분산 연산자 교체를 수행하고 분산 변환기를 통해 Embedding 가져오기는 선택한 항목을 기반으로 합니다. 하드웨어 환경(GPU 모델, TensorRT 버전, CUDA 버전 )을 사용하여 TensorRT 모델의 변환 및 컴파일 최적화를 수행하고 마지막으로 후속 모델 배포 및 출시를 위해 두 하위 모델의 변환 결과를 S3에 저장합니다. 사용자가 실행 세부 사항을 알지 못한 채 전체 프로세스가 플랫폼에 의해 자동으로 완료됩니다.
2. 온라인 테스트: 모델 배포 하드웨어 환경을 선택하기만 하면(모델 변환 환경과 일치), 플랫폼은 환경 구성에 따라 모델의 적응형 푸시 로딩을 수행하고 배포와 온라인을 완료합니다. 한 번의 클릭으로 모델 배포.

Pipeline은 구성 구축 및 원클릭 기능을 통해 모델 반복 효율성을 크게 향상시켜 알고리즘 및 엔지니어링 학생들이 업무에 더 집중할 수 있도록 돕습니다. 다음 그림은 순수 CPU 추론과 비교하여 GPU 실행에서 얻은 전반적인 이점을 보여줍니다.

4 Feature Service CodeGen Optimization

특징 추출은 기존 LR 모델이든 모델 계산의 사전 단계입니다. 점점 인기를 얻고 있는 모든 딥러닝 모델에는 특징 추출을 통한 입력이 필요합니다. 이전 블로그 ​​메이투안 테이크아웃 기능 플랫폼 구축 및 실습​​에서 모델 기능 자체 설명 MFDL을 기반으로 기능 계산 프로세스를 구성했다고 설명했으며, 온라인에서 보장하기 위해 최선을 다했습니다. 훈련 중 샘플의 추정 및 오프라인 일관성. 비즈니스가 빠르게 반복됨에 따라 모델 기능의 수가 계속해서 증가하고 있으며, 특히 다수의 개별 기능을 도입하는 대규모 모델로 인해 계산량이 두 배로 늘어납니다. 이를 위해 우리는 특징 추출 계층을 일부 최적화하고 처리량과 시간 소비 측면에서 상당한 이득을 얻었습니다.

4.1 전체 프로세스 CodeGen 최적화

DSL은 기능 처리 논리에 대한 설명입니다. 초기 기능 계산 구현에서는 각 모델에 구성된 DSL을 해석하고 실행했습니다. 실행 해석의 장점은 구현이 간단하고 일반적으로 사용되는 반복자 패턴과 같은 좋은 디자인을 통해 좋은 구현을 얻을 수 있다는 것입니다. 단점은 실행 성능이 낮고 많은 분기 점프 및 유형을 사용할 수 없다는 것입니다. 다양성을 위해 구현 수준에서는 피하세요. 실제로 모델 구성의 고정 버전의 경우 모든 모델 기능 변환 규칙이 고정되어 있으며 요청에 따라 변경되지 않습니다. 극단적인 경우에는 이 알려진 정보를 기반으로 각 모델 기능을 하드 코딩하여 최고의 성능을 얻을 수 있습니다. 분명히 모델 기능 구성은 끊임없이 변경되므로 각 모델을 수동으로 코딩하는 것은 불가능합니다. 따라서 컴파일 중에 각 구성에 대한 독점 코드 세트를 자동으로 생성하는 CodeGen의 아이디어입니다. CodeGen은 특정 기술이나 프레임워크가 아니라 추상적인 설명 언어에서 특정 실행 언어로의 변환 과정을 완성하는 아이디어이다. 실제로 업계에서는 컴퓨팅 집약적인 시나리오에서 계산을 가속화하기 위해 CodeGen을 사용하는 것이 일반적인 관행입니다. 예를 들어 Apache Spark는 CodeGen을 사용하여 SparkSql 실행 성능을 최적화합니다. 1.x의 ExpressionCodeGen에서 전체 단계 가속화를 위해 2.x에 도입된 WholeStageCodeGen에 이르기까지 매우 확실한 성능 향상이 이루어졌습니다. 기계 학습 분야에서는 TensorFlow XLA 및 TVM과 같은 일부 TF 모델 가속 프레임워크도 CodeGen 아이디어를 기반으로 하며 Tensor 노드는 통합된 중간 계층 IR로 컴파일되고 스케줄링 최적화는 결합된 IR을 기반으로 수행됩니다. 런타임 모델 계산 가속화를 달성하기 위한 로컬 환경.

Spark의 WholeStageCodeGen을 통해 학습한 우리의 목표는 전체 기능 계산 DSL을 실행 가능한 메서드로 컴파일하여 코드 실행 시 성능 손실을 줄이는 것입니다. 전체 컴파일 프로세스는 프런트엔드(FrontEnd), 옵티마이저(Optimizer) 및 백엔드(BackEnd)로 나눌 수 있습니다. 프런트 엔드는 주로 대상 DSL을 구문 분석하고 소스 코드를 AST 또는 IR로 변환하는 일을 담당합니다. 최적화 프로그램은 프런트 엔드를 기반으로 얻은 중간 코드를 최적화하여 백엔드가 최적화된 중간 코드를 변환합니다. 코드를 해당 플랫폼의 네이티브 코드로 변환합니다. 구체적인 구현은 다음과 같습니다.

1. Front-end: 각 모델은 노드 DAG 그래프에 해당하며, 각 기능을 하나씩 구문 분석하여 DSL을 계산하고, AST를 생성하고, AST 노드를 그래프에 추가합니다.
2. Optimizer: 공용 연산자 추출, 상수 폴딩 등 DAG 노드를 최적화합니다.
3. Backend: 최적화된 그래프를 바이트코드로 컴파일합니다.

최적화 이후에는 노드 DAG 그래프의 변환, 즉 백엔드 코드 구현이 최종 성능을 결정합니다. 어려움 중 하나는 기존 오픈 소스 표현 엔진을 직접 사용할 수 없는 이유이기도 합니다. 특징 계산 DSL은 순수한 계산 표현이 아닙니다. 읽기 연산자와 변환 연산자의 조합을 통해 기능 획득 및 처리 프로세스를 설명할 수 있습니다.

1. 읽기 연산자: 스토리지 시스템에서 기능을 가져오는 프로세스는 IO 유형 작업입니다. 예를 들어, 원격 KV 시스템을 쿼리합니다.
2. 변환 연산자: 로컬에서 특성을 얻은 후 변환하는 것은 계산 집약적인 작업입니다. 예를 들어 특성 값을 해시합니다.

따라서 실제 구현에서는 다양한 유형의 작업 일정을 고려하고 기계 리소스 활용도를 극대화하며 전체 시간이 소요되는 프로세스를 최적화해야 합니다. 업계 연구와 자체 실습을 결합하여 다음 세 가지 구현이 수행되었습니다.

1. 작업 유형에 따라 단계 나누기: 전체 프로세스를 획득과 계산의 두 단계로 나눕니다. 단계는 내부적으로 분할되어 병렬로 처리됩니다. 이는 초기에 사용했던 솔루션으로 구현이 간단하고 다양한 작업 유형에 따라 다양한 샤드 크기를 선택할 수 있습니다. 예를 들어 IO 유형 작업에서는 더 큰 샤드를 사용할 수 있습니다. 그러나 단점도 분명합니다. 이는 서로 다른 단계의 긴 꼬리가 중첩되는 결과를 가져오며, 각 단계의 긴 꼬리는 전체 프로세스의 시간 소모에 영향을 미칩니다.
2. 파이프라인을 기반으로 단계 분할: 서로 다른 단계의 롱테일 중첩을 줄이기 위해 먼저 데이터를 조각화하고 각 특징 읽기 조각에 대한 콜백을 추가한 다음 계산 작업을 다시 호출할 수 있습니다. IO 작업이 완료되어 전체 프로세스가 조립 라인처럼 원활하게 진행됩니다. 샤드 스케줄링을 사용하면 이전 단계에서 더 일찍 준비된 샤드가 다음 단계로 미리 들어갈 수 있으므로 대기 시간이 줄어들어 전체 요청 시간의 롱테일을 줄일 수 있습니다. 그러나 단점은 통합된 샤드 크기가 각 단계의 활용도를 완전히 향상시킬 수 없다는 것입니다. 샤드가 작을수록 IO 작업에 더 많은 네트워크 소비가 발생하고, 샤드가 클수록 컴퓨팅 작업에 소요되는 시간이 늘어납니다.
3. SEDA(단계적 이벤트 기반 아키텍처) 접근 방식 기반: 단계적 이벤트 기반 접근 방식은 대기열을 사용하여 단계 획득 및 계산 단계를 격리하며 각 단계에는 독립적인 스레드 풀과 일괄 처리 대기열이 할당됩니다. N(Batching Factor) 요소를 소비합니다. 이를 통해 각 단계에서 샤드 크기를 독립적으로 선택할 수 있으며 이벤트 중심 모델을 통해 프로세스를 원활하게 유지할 수도 있습니다. 이것이 우리가 현재 탐구하고 있는 것입니다.

CodeGen 솔루션은 완벽하지 않습니다. 동적으로 생성된 코드는 코드 가독성을 감소시키고 디버깅 비용을 증가시킵니다. 그러나 CodeGen을 적응 계층으로 사용하면 더욱 심층적인 최적화를 위한 공간이 열립니다. CodeGen 및 비동기 비차단 구현을 기반으로 온라인에서 좋은 이점을 얻었으며, 한편으로는 시간이 많이 소요되는 기능 계산을 줄이고, 다른 한편으로는 CPU 부하를 크게 줄이고 시스템 처리량을 향상시킵니다. 앞으로도 우리는 CodeGen을 계속 활용하고 하드웨어 명령(예: SIMD) 또는 이기종 컴퓨팅(예: GPU)의 조합을 탐색하는 등 백엔드 컴파일 프로세스에서 대상 최적화를 수행할 것입니다. 더 깊은 최적화.

4.2 전송 최적화

온라인 예측 서비스는 전체적으로 2계층 아키텍처입니다. 특징 추출 레이어는 모델 라우팅과 특징 계산을 담당하고, 모델 계산 레이어는 모델 계산을 담당합니다. 원래 시스템 프로세스는 특징 계산 결과를 M(예측 배치 크기) × N(샘플 너비)의 행렬로 접합한 후 직렬화하여 컴퓨팅 계층으로 전송하는 것입니다. 그 이유는 한편으로는 DNN이 아닌 많은 초기 단순 모델의 입력 형식이 라우팅 레이어를 결합한 후 변환 없이 직접 사용할 수 있기 때문입니다. , 배열 형식은 비교적 컴팩트하며 네트워크 전송 시간을 절약할 수 있습니다. 그러나 모델의 반복적인 개발로 인해 DNN 모델은 점차 주류가 되었으며 매트릭스 전송의 단점도 매우 분명해졌습니다.

1. 확장성 부족: 데이터 형식이 통일되어 있으며 숫자가 아닌 유형의 특성 값과 호환되지 않습니다.
2. 전송 성능 손실: 매트릭스 형식을 기반으로 기능을 정렬해야 합니다. 예를 들어 쿼리/사용자 차원을 각 항목에 복사하고 정렬해야 하므로 필요한 네트워크 전송 데이터의 양이 늘어납니다. 컴퓨팅 계층.

위 문제를 해결하기 위해 최적화된 프로세스는 전송 레이어 위에 변환 레이어를 추가하여 계산된 모델 특징을 Tensor, 매트릭스 또는 오프라인 사용과 같은 MDFL 구성에 따라 필요한 형식으로 변환합니다. CSV 형식 등 실제 온라인 모델의 대부분은 전송 소비를 더욱 절약하기 위해 플랫폼에서 각 Tensor 행렬을 저장하는 Tensor Sequence 형식을 설계했습니다. 그 중 r_flag는 항목 유형 기능인지 여부를 표시하는 데 사용됩니다. 길이는 항목 특성을 나타내며, 값은 M(항목 개수) × NF(특성 길이)이며, 항목 특성의 경우 M 특성 값이 플랫하게 저장됩니다. , 요청 유형 기능의 경우 직접 채워집니다. 컴팩트한 Tensor Sequence 형식을 기반으로 데이터 구조가 더욱 컴팩트해지고 네트워크를 통해 전송되는 데이터의 양이 줄어듭니다. 최적화된 전송 형식은 온라인에서도 좋은 결과를 얻었습니다. 컴퓨팅 계층을 호출하는 라우팅 계층의 요청 크기가 50% 이상 감소했으며 네트워크 전송 시간이 크게 단축되었습니다.

4.3 고차원 ID 특성 인코딩

이산 특성과 시퀀스 특성은 특성 처리 단계에서 원래 특성을 해시하여 ID 유형 특성으로 변환할 수 있습니다. 수천억 차원의 기능에 직면하여 문자열 연결 및 해싱 프로세스는 표현 공간 및 성능 측면에서 요구 사항을 충족할 수 없습니다. 업계 연구를 바탕으로 슬롯 코딩 기반의 특징 인코딩 형식을 설계하고 적용했습니다.

그 중 feature_hash는 해싱 후 원래 특징 값의 값입니다. 정수 기능은 직접 채울 수 있습니다. 정수가 아닌 기능이나 교차 기능은 먼저 해시된 다음 숫자가 44비트를 초과하면 잘립니다. 슬롯 코딩 체계가 출시된 후 온라인 특징 계산 성능이 향상되었을 뿐만 아니라 모델 효과도 크게 향상되었습니다.

5 샘플 구성

5.1 스트리밍 샘플

온라인 및 오프라인 일관성 문제를 해결하기 위해 업계에서는 일반적으로 실시간 채점에 사용되는 기능 데이터를 온라인으로 덤프합니다. 이를 기능 스냅샷이라고 합니다. 접합 및 기능 백필을 통해 간단한 오프라인 Label Construct 샘플을 사용하는 방법은 더 큰 데이터 불일치를 야기하기 때문입니다. 원래 아키텍처는 아래 그림에 나와 있습니다.

기능 규모가 커지고 반복 시나리오가 점점 더 복잡해짐에 따라 눈에 띄는 문제는 온라인 기능 추출 서비스가 큰 압박을 받고 있다는 것입니다. 전체 데이터 스트림 수집 비용이 너무 높습니다. 이 샘플 수집 방식에는 다음과 같은 문제점이 있습니다.

1. 긴 준비 시간: 현재 리소스 제약 하에서 이러한 대규모 데이터를 실행할 때 샘플 데이터를 준비하는 데 거의 T+2가 소요되며, 이는 알고리즘 모델.
2. 높은 리소스 소모: 기존의 샘플 수집 방식은 모든 요청의 특징을 계산한 후 이를 노출과 클릭으로 접합하는 방식이었습니다. 노출되지 않은 항목의 특징 계산 및 데이터 드롭다운으로 인해 저장되는 데이터의 양이 줄어듭니다. 가 커서 리소스를 많이 소모합니다.

5.1.1 일반적인 솔루션

위의 문제를 해결하기 위해 업계에는 두 가지 일반적인 솔루션이 있습니다. ①Flink 실시간 스트림 처리 ②KV 캐시 2차 처리. 구체적인 프로세스는 아래 그림에 나와 있습니다.

1. 스트리밍 스플라이싱 솔루션: 스트리밍 처리 프레임워크(Flink, Storm 등)의 저지연 스트림 처리 기능을 통해 노출/클릭 실시간 스트림을 직접 읽고 기능 스냅샷과 연결합니다. 메모리 내 스트리밍 데이터( Join) 처리, 먼저 스트리밍 훈련 샘플을 생성한 다음 이를 모델 오프라인 훈련 샘플로 전송합니다. 스트리밍 샘플과 오프라인 샘플은 각각 서로 다른 스토리지 엔진에 저장되어 다양한 유형의 모델 훈련 방법을 지원합니다. 이 솔루션의 문제점: 데이터 흐름 링크의 데이터 양이 여전히 매우 커서 많은 메시지 흐름 리소스(예: Kafka)를 차지합니다. 데이터 볼륨이 초당 수백 G인 경우 Flink 리소스 소비가 너무 큽니다. 둘째, 30분 × 60 × 100G 메모리 리소스를 창 조인해야 합니다.
2. KV 캐싱 솔루션: 특징 추출의 모든 특징 스냅샷을 KV 저장소(예: Redis)에 기록하고 N분 동안 캐시합니다. 비즈니스 시스템은 후보 대기열의 항목을 실시간 컴퓨팅에 전달합니다. 시스템을 통해 메시지 메커니즘(Flink 또는 소비자 애플리케이션)을 통해 현재 항목의 양은 이전에 요청한 항목의 양보다 훨씬 적으므로 이러한 항목 기능은 기능 스냅샷 캐시에서 제거되고 데이터는 스트리밍 훈련을 지원하기 위해 메시지 흐름을 통해 출력합니다. 이 방법은 기능이나 트래픽의 증가에 관계없이 Flink 리소스를 제어할 수 있으며 작동이 더 안정적입니다. 그러나 가장 큰 문제는 많은 양의 데이터를 캐시하려면 더 큰 메모리가 필요하다는 것입니다.

5.1.2 최적화 개선

잘못된 계산을 줄이는 관점에서 요청한 데이터가 모두 노출되지는 않습니다. 이 전략은 노출된 데이터에 대한 수요가 더 높으므로 일일 수준 처리를 스트림 처리로 전달하면 데이터 준비 시간을 크게 향상시킬 수 있습니다. 둘째, 데이터 내용부터 살펴보면, 요청 수준 변경 데이터와 일별 변경 데이터가 포함되어 있으며, 링크를 통해 두 가지 처리를 유연하게 분리할 수 있어 리소스 활용도를 크게 향상시킬 수 있습니다. :

1. 데이터 분할: 대용량 데이터 전송량 문제(피처 스냅샷 스트리밍의 가장 큰 문제)를 해결하고, 예측된 레이블과 실시간 데이터를 하나씩 일치시키고, 리플로우 중에 오프라인 데이터에 두 번 액세스할 수 있으므로 링크 트래픽 크기를 크게 줄일 수 있습니다.

• 샘플 스트림에는 컨텍스트 + 실시간 기능만 있어 읽기 데이터 스트림의 안정성이 높아집니다. 동시에 실시간 기능만 저장하면 되므로 Kafka 하드 디스크 스토리지는 10배 이상 감소했습니다.

2. 지연 소비 조인 방법: 대용량 메모리 사용량 문제를 해결합니다.

• 노출 스트림은 주류로 사용되며 HBase에 기록됩니다. 동시에 다른 스트림이 HBase의 Join에 노출될 수 있도록 RowKey가 Redis에 기록됩니다. RowKey를 통해 HBase로 전송되며, 노출, 클릭, 특성 등이 외부 메모리의 도움으로 스플라이싱이 완료되어 데이터 양이 증가함에 따라 시스템이 안정적으로 실행될 수 있도록 합니다.
• 샘플 스트림의 지연된 소비. 노출 스트림의 99% 이상을 결합하기 위해 샘플 스트림은 최소 N분 동안 창 통계를 기다립니다. 구현 방법은 윈도우를 분할하여 해당 기간의 모든 데이터를 Kafka의 디스크에 압축하고 디스크의 순차 읽기 성능을 사용하여 윈도우 기간 동안 데이터를 캐시하는 데 필요한 많은 양의 메모리를 생략합니다.

3. 피쳐링 추가 녹음 및 샘플 수집 : 레이블의 Join을 통해 여기에 추가된 피쳐링 요청 수는 온라인 샘플 수의 20% 미만으로 지연되어 읽혀지고 필터에 노출됩니다. 노출된 모델 서비스 요청(컨텍스트 + 실시간 기능)을 수행한 다음 모든 오프라인 기능을 기록하고 완전한 샘플 데이터를 구성하여 HBase에 기록합니다.

5.2 구조화된 스토리지

비즈니스 반복을 통해 기능 스냅샷의 기능 수가 점점 더 많아지고 있으며, 이로 인해 스토리지 관점에서 여러 날에 걸쳐 단일 비즈니스 시나리오에서 전체 기능 스냅샷이 하루에 수십 TB에 도달하게 됩니다. 단일 비즈니스의 특징적인 스냅샷은 이미 페타바이트 수준이며 광고 알고리즘의 저장 임계값에 곧 도달할 예정입니다. 원래 계산 프로세스를 사용하면 계산 관점에서 볼 때 저장 압력이 높습니다. 계산 엔진(Spark)의 리소스 제한(Usage Shuffle의 경우 Shuffle Write 단계의 데이터를 디스크에 씁니다. 할당된 메모리가 부족할 경우 디스크에 여러 번 쓰기 및 외부 정렬 ) 계산을 효과적으로 완료하려면 자체 데이터와 동일한 크기의 메모리와 더 많은 컴퓨팅 CU가 필요합니다. 높은 메모리를 차지합니다. 샘플 구성 과정의 핵심 흐름은 아래 그림과 같습니다.

재녹음 기능을 사용할 때 다음과 같은 문제가 있습니다.

1. 데이터 중복성: 재녹음 기능을 위한 오프라인 테이블은 일반적으로 항목 수와 함께 전체 데이터 양입니다. 샘플 구축에 사용되는 수십억 수준의 항목 수는 대략 해당 날짜의 DAU 수인 수천만 개에 달하므로 참여 시 추가로 기록되는 특징 테이블 데이터에 중복된 데이터가 있습니다. 계산.
2. Join order: 보충 기능의 계산 프로세스는 여러 개의 Join 계산이 있으므로 Join 계산의 성능은 위 그림과 같이 Join 테이블의 순서와 큰 관계가 있습니다. 왼쪽의 경우 테이블은 수십 TB 수준의 큰 테이블이므로 후속 셔플 계산 프로세스에서 많은 양의 네트워크 IO 및 디스크 IO가 생성됩니다.

느린 샘플 구성 효율성 문제를 해결하기 위해 단기적으로는 데이터 구조 관리부터 시작하겠습니다. 자세한 프로세스는 아래 그림과 같습니다.

1. 구조화됩니다. 파편. 데이터는 혼합 저장이 아닌 Context 데이터와 차원 데이터의 구조화된 저장으로 분리됩니다. 라벨 샘플의 새로운 기능을 결합하는 과정에서 대량의 중복 데이터를 전달하는 문제를 해결하고 구조화된 저장 후 오프라인 기능에 대해 뛰어난 저장 압축이 달성됩니다.
2. 고효율 여과 프리필터. Join 이전에 데이터 필터링을 진행하여 피처 계산에 필요한 데이터 양을 줄이고 네트워크 IO를 효과적으로 줄일 수 있습니다. Splicing 과정에서 Feature의 보충 기록을 위한 Hive 테이블은 일반적으로 Full Table이며, 데이터 항목의 개수는 일반적으로 월별 활동이지만, 실제 Splicing 과정에서 사용되는 데이터 항목의 개수는 대략 일일 활동량입니다. 따라서 데이터 중복성이 크므로 잘못된 데이터로 인해 추가 IO 및 계산이 발생합니다. 최적화 방법은 차원 Key를 미리 계산하고 해당 Bloom 필터를 생성하는 것입니다. Bloom 필터를 사용하여 데이터를 읽을 때 필터링하면 보충 기록 과정에서 중복 데이터 전송 및 중복 계산을 크게 줄일 수 있습니다.
3. 고성능 Join. 효율적인 전략을 사용하여 조인 시퀀스를 정렬하여 기능 재녹음 프로세스의 효율성과 리소스 사용량을 향상시킵니다. 기능 접합 프로세스 중에는 여러 테이블에 대한 조인 작업이 있으며 조인 순서도 접합 성능에 큰 영향을 미칩니다. 위 그림과 같이 스플라이싱된 왼쪽 테이블의 데이터 양이 많으면 전반적인 성능이 저하됩니다. 허프만 알고리즘의 아이디어를 활용하면 각 테이블을 노드로 간주하고 해당 데이터의 양을 가중치로 간주할 수 있습니다. 노드. 따라서 이 문제는 허프만 트리 구축으로 추상화될 수 있으며, 허프만 트리 구축 과정은 최적의 조인 순서이다.

데이터 오프라인 저장 자원이 80% 이상 절약되고, 샘플 구성 효율이 200% 이상 향상됩니다. 현재 전체 샘플 데이터도 데이터 레이크를 기반으로 구현되어 데이터 효율성을 더욱 향상시키고 있습니다.

6 데이터 준비

플랫폼은 기능, 샘플 및 모델과 같은 귀중한 콘텐츠를 대량 축적했습니다. 이러한 데이터 자산을 재사용함으로써 전략가가 더 나은 비즈니스 반복을 수행하고 더 나은 비즈니스 수익을 달성하는 데 도움이 될 수 있기를 바랍니다. . 특징 최적화는 알고리즘 직원이 모델 효과를 개선하기 위해 사용하는 모든 방법의 40%를 차지합니다. 그러나 기존 특징 마이닝 방법은 오랜 시간 소모, 낮은 마이닝 효율성, 반복적인 특징 마이닝 등의 문제를 가지고 있습니다. 기능 차원. 어떤 기능의 효과를 검증하고 사용자에게 최종 효과 지표를 추천하는 자동화된 실험 프로세스가 있다면 의심할 여지 없이 전략가가 많은 시간을 절약하는 데 도움이 될 것입니다. 전체 링크 구성이 완료되면 다양한 특징 후보 세트만 입력하면 해당 효과 지표가 출력됩니다. 이를 위해 플랫폼은 기능과 샘플의 "덧셈", "뺄셈", "곱셈" 및 "나누기"를 위한 지능형 메커니즘을 구축했습니다.

6.1 "추가" 수행

기능 추천은 모델 테스트 방법을 기반으로 하며, 다른 비즈니스 라인의 기존 모델에 기능을 재사용하고, 새로운 샘플 및 모델을 구성하고, 새 모델과 기본 모델의 오프라인 효과를 비교합니다. 새로운 기능의 이점은 관련 비즈니스 리더에게 자동으로 전달됩니다. 구체적인 기능 추천 프로세스는 아래 그림과 같습니다.

1. Feature Awareness: 기능 추천은 온라인 담벼락이나 기업간 인벤토리 방식을 통해 실행됩니다. 이러한 기능은 어느 정도 검증되었으므로 기능 추천 성공률을 보장할 수 있습니다.
2. 샘플 제작: 샘플 제작 중에 구성 파일에서 기능이 추출되며, 프로세스에서 자동으로 구성 파일에 새로운 기능을 추가한 후 새로운 샘플 데이터를 생성합니다. 새로운 기능을 얻은 후에는 이러한 기능이 의존하는 원래 기능, 차원 및 UDF 연산자를 분석하고 새로운 기능 구성 및 종속 원본 데이터를 기준 모델의 원래 구성 파일에 통합하여 새로운 기능 구성 파일을 구성합니다. 새로운 샘플을 자동으로 구성합니다. 샘플 구성 중에 기능 이름을 통해 관련 기능이 Feature Warehouse에서 추출되고, 구성된 UDF가 기능 계산을 위해 호출됩니다.
3. 모델 교육: 모델 구조와 샘플 형식 구성을 자동으로 변환한 다음 모델 교육을 수행합니다. TensorFlow를 모델 교육 프레임워크로 사용하고, tfrecord 형식을 샘플 입력으로 사용하고, 수치 클래스에 따라 새로운 기능을 분류합니다. 및 ID 클래스를 각각 A와 B의 두 그룹으로 분류합니다. ID 유형 기능은 테이블에서 조회된 다음 모델 구조를 수정하지 않고도 모델 학습을 위해 새로운 샘플을 받을 수 있습니다.
4. 새 모델 훈련 매개변수 자동 구성 : 훈련 날짜, 샘플 경로, 모델 슈퍼 매개변수 등을 포함하여 훈련 세트와 테스트 세트를 나누고 새 모델을 자동으로 훈련시킵니다.
5. 모델 평가: 평가 인터페이스를 호출하여 오프라인 지표를 얻고, 신규 모델과 기존 모델의 평가 결과를 비교하고, 단일 기능 평가 결과를 예약하고, 일부 기능을 분할한 후 단일 기능 기여가 제공됩니다. 평가 결과는 사용자에게 일률적으로 전송됩니다.

6.2 "뺄셈" 수행

기능 추천이 광고에 구현되고 특정 이점을 얻은 후 기능 강화 수준에서 몇 가지 새로운 탐색을 수행했습니다. 모델의 지속적인 최적화로 인해 기능 확장 속도가 매우 빠르고, 모델 서비스의 리소스 소비가 급격히 증가합니다. 중복되는 기능을 제거하고 모델을 "얇게 만드는" 것이 필수적입니다. 따라서 플랫폼은 엔드투엔드 기능 스크리닝 도구 세트를 구축했습니다.

1. 특성 점수: 모델의 모든 특성 점수는 WOE(Weight of Evidence, Weight of Evidence)와 같은 다양한 평가 알고리즘을 통해 제공됩니다. 기능이 높을수록 평가 정확도가 높습니다.
2. 효과 검증: 모델을 훈련한 후 점수별로 정렬하고 일괄적으로 기능을 제거합니다. 구체적으로, 특징 파괴 방법은 원본 모델과 깨진 모델의 평가 결과를 비교하는 데 사용되며, 차이가 임계값보다 큰 경우 평가 종료 및 제거할 수 있는 특징이 제공됩니다.
3. 엔드 투 엔드 솔루션: 사용자가 실험 매개변수 및 지표 임계값을 구성한 후, 삭제 가능한 특징과 특징 삭제 후 모델의 오프라인 평가 결과를 사람의 개입 없이 제공할 수 있습니다.

결국 내부 모델의 기능 중 40%가 오프라인이 된 후에도 비즈니스 지표의 하락세는 여전히 합리적인 한계 내에서 통제되었습니다.

6.3 "곱셈" 수행

더 나은 모델 효과를 얻기 위해 대형 모델, 실시간, 기능 라이브러리 등을 포함하여 광고 내에서 몇 가지 새로운 탐색이 시작되었습니다. 이러한 탐색 뒤에는 핵심 목표가 있습니다. 즉, 모델을 더욱 스마트하고 효율적으로 만들기 위해 더 많은 더 나은 데이터가 필요하다는 것입니다. 현재의 광고 상황에서 출발하여, 더 많은 유형, 더 큰 규모의 외부 데이터를 가져와 기존 사업에 적용하기 위한 샘플 데이터베이스(Data Bank) 구축을 제안합니다. 아래 그림과 같이:

우리는 다른 비즈니스 라인을 빌려 증분 샘플을 생성할 수 있는 범용 샘플 공유 플랫폼을 구축했습니다. 또한 대규모 및 소규모 비즈니스 통합을 실현하기 위해 공통 Embedding 공유 아키텍처를 구축합니다. 다음은 광고 사업 분야에서 비광고 샘플을 재사용하는 예시입니다. 구체적인 방법은 다음과 같습니다.

1. 샘플 확장: Flink 스트리밍 처리 프레임워크를 기반으로 확장성이 뛰어난 샘플 라이브러리 DataBank가 구축되었습니다. 기업 A는 실험을 위해 기업 B와 기업 C의 노출, 클릭 및 기타 라벨 데이터를 쉽게 재사용할 수 있습니다. 특히 소규모 비즈니스 라인의 경우 오프라인 보충 등록에 비해 대량의 가치 데이터가 확장되었습니다. 이 접근 방식은 온라인 및 오프라인 일관성을 보장합니다.
2. Share: 샘플이 준비된 후 매우 일반적인 응용 시나리오는 전이 학습입니다. 또한 Embedding 공유를 위한 데이터 경로도 구축됩니다( "샘플 확장" 프로세스에 크게 의존하지 않음 ). 각 비즈니스 당사자는 이 Embedding을 업데이트하고 구축할 수도 있습니다. 여러 비즈니스 라인에서 사용하기 위해 온라인에 버전 메커니즘을 내장합니다.

예를 들어 광고 내에서 비광고 샘플을 비즈니스에 재사용함으로써 샘플 수가 여러 배 증가했으며 전이 학습 알고리즘과 결합되어 오프라인 AUC가 4,000분의 1로 증가했으며 CPM은 1000분의 1로 증가했습니다. 온라인에 접속한 후 1% 증가했습니다. 또한, 각 업체에서 생성된 샘플 데이터(통합 메타데이터)를 통일적으로 관리하고, 통일된 샘플 테마 분류를 사용자에게 노출하며, 신속한 등록, 검색, 재사용 및 통합 저장을 위해 광고 샘플 테마 라이브러리도 구축하고 있습니다. 하단 레이어, 스토리지 및 컴퓨팅 리소스를 절약하고 데이터 조인을 줄이고 적시성을 향상시킵니다.

6.4 "나누기" 수행

특성 "뺄셈"을 사용하면 긍정적인 효과가 없는 일부 특성을 제거할 수 있지만 관찰을 통해 모델에는 여전히 가치가 없는 특성이 많이 있음을 알 수 있습니다. 따라서 전체 링크의 비용 기반 제약 하에서 상대적으로 입력 및 출력이 낮은 기능을 선별하고 리소스 소비를 줄일 수 있습니다. 이러한 비용 제약 하에서 해결하는 과정을 "분할"이라고 정의합니다. 전체 과정은 아래 그림과 같습니다.

오프라인 차원에서는 기능의 비용과 가치를 제공하는 기능 값 평가 시스템을 구축했습니다. 온라인 추론 중에 기능 값 정보를 사용하여 트래픽 저하 및 기능 탄력성과 같은 작업을 수행할 수 있습니다. "나누기"를 수행합니다. "주요 단계는 다음과 같습니다.

1. 문제 추상화: 각 기능의 가치 점수를 얻을 수 있으면 기능의 비용도 얻을 수 있습니다( 저장, 통신, 컴퓨팅 및 처리) 그렇다면 문제는 알려진 모델 구조와 고정 자원 비용 하에서 기능의 가치를 어떻게 최대화할 것인가입니다.
2. 비용 제약 하에서의 가치 평가: 플랫폼은 먼저 모델의 기능 세트를 기반으로 비용과 가치에 대한 통계 요약을 수행합니다. 비용에는 오프라인 비용과 온라인 비용이 포함되며 훈련된 평가를 기반으로 합니다. 모델의 기능은 종합 순위를 획득했습니다.
3. 시나리오 모델링: 다양한 리소스 조건에 따라 모델링을 위해 다양한 기능 세트를 선택할 수 있습니다. 제한된 리소스로 온라인 작업에 가장 큰 가치를 지닌 모델을 선택하세요. 또한 상대적으로 큰 기능 세트에 대해 모델링하고 트래픽 피크가 낮은 동안 활성화하여 리소스 활용도를 높이고 비즈니스에 더 큰 이점을 가져올 수 있습니다. 또 다른 애플리케이션 시나리오는 트래픽 저하입니다. 추론 서비스는 리소스 계산이 병목 현상에 도달하면 성능 저하 모델로 전환합니다.

7 요약 및 전망

위는 비즈니스 비용을 절감하고 효율성을 향상시키는 데 도움이 되는 대규모 딥 러닝 프로젝트에서 "증가" 방지 관행입니다. 앞으로도 다음과 같은 측면에서 계속 탐구하고 실천하겠습니다.

1. 전체 링크 GPU화: 추론 수준에서는 GPU 전환을 통해 보다 복잡한 비즈니스 반복을 지원하는 동시에 전체 비용도 크게 절감되며 나중에 샘플 구성 및 기능 서비스가 GPU 기반으로 전환됩니다. , 오프라인 교육 수준 향상을 공동으로 추진합니다.
2. 샘플 데이터 레이크: 스키마 진화, 패치 업데이트 및 데이터 레이크의 기타 기능을 통해 더 큰 샘플 웨어하우스를 구축하여 저비용 및 고가치 데이터를 비즈니스 측면에 노출합니다.
3. Pipeline: 알고리즘의 전체 수명주기의 반복 과정에서 디버깅 및 링크 정보의 여러 측면이 충분히 "연결"되지 않고 오프라인, 온라인 및 효과 지표의 관점이 상대적으로 단편화됩니다. 전체 링크 기반 표준화 및 관찰 가능성이 일반적인 추세이며 이는 후속 링크의 지능적이고 탄력적인 배포를 위한 기반입니다. 현재 업계에서 인기를 끌고 있는 MLOps와 클라우드 네이티브에는 많은 참고 아이디어가 있습니다.
4. 데이터와 모델의 지능적인 매칭: 위에서 언급했듯이 모델 구조가 고정되어 있다는 전제 하에 모델에 자동으로 기능이 추가되고 제외됩니다. 마찬가지로 모델 수준에서는 일부 새로운 기능이 자동으로 포함됩니다. 특정 기능 입력을 수정한다는 전제하에. 그리고 향후에도 플랫폼의 특성과 모델 시스템을 통해 사업분야에 따른 데이터와 모델의 매칭을 자동으로 완성해 나갈 예정입니다.

8

위 내용은 테이크아웃 광고를 위한 대규모 딥러닝 모델의 엔지니어링 실습의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!