Exploring Deep Learning Acceleration Technology Embedded in LLMs
•
0 likes•71 views
Lab's research presentation I am a doctoral student at Seoul National University of Science and Technology and am currently the head of the Applying LLMs to Various Industry (AL2VI) Lab.
Recommended
More Related Content
Similar to Exploring Deep Learning Acceleration Technology Embedded in LLMs
Similar to Exploring Deep Learning Acceleration Technology Embedded in LLMs (20)
More from Tae Young Lee
More from Tae Young Lee (20)
Exploring Deep Learning Acceleration Technology Embedded in LLMs
- 1. Exploring Deep Learning Acceleration Technology Embedded in LLMs Tae Young Lee
- 6. TensorRT (GPU기반 배포기술) DeepSpeed 장착 (메모리 최적화) Fused Kernel 장착 (고성능 CUDA 연산) Megatron LM 장착 (모델 병렬처리) 다량의 데이터 처리 메커니즘 (빅데이터 처리) 4 2 3 1
- 8. TensorRT 딥러닝 모델을 최적화하여 NVIDIA GPU 상에서 추론속도를 수배~수십배 향상시켜주는 모델 최적화 엔진. TensorRT는 Optimizer와 Runtime Engine으로 구성되어 있다. Optimizer란 NVIDIA GPU 연산에 적합한 최적화 기법으로 딥러닝 모델을 최적화해 주는 Method Runtime Engine이란 다양한 GPU에서 모델 연산을 수행하는 것 딥러닝 가속화 기법 . Quantization 및 Precision Calibration . Graph Optimization . Kernel Auto tuning . Dynamic Tensor Memory 및 Multi-Stream execution
- 9. Quantization & Precision Calibration 낮은 Precision의 Network일수록 당연하게 FP16, INT8 datatype까지의 reduced Precision기술을 지원 낮은 Precision의 Network일수록 당연하게 data의 크기 및 weight의 bit수가 작기 때문에 빠르고 효율적인 연산이 가능 weight를 표현하는 bit수가 작아질수록 DRAM에서 GPU가 읽어와야 할 데이터의 크기는 줄어듦. 이러한 Data Movement가 줄어들면 energy consumption이 줄어들 수 있고 실제 연산시간도 줄일 수 있다. Graph Optimization 여러단계로 설정되어 있는 Layer들을 Layer Fusion과 Tensor Fusion을 통해 ‘동시에' 연산하여 속도를 향상 시킴 Layer Fusion은 Vertical Fusion과 Horizontal Fusion 그리고 Tensor Fusion을 통해 Model Graph를 단순화 시키고 모델의 Layer개수가 크게 감소 https://opac.tistory.com/6
- 10. Kernel Auto-tunning TensorRT는 사용하는 플랫폼별로 엔진을 따로 생성해야 함 예를 들면, Jetson AGX Xavier보드에서 생성한 엔진은 NX Xavier보드에서는 실행이 불가하다. TensorRT는 각기 다른 플랫폼에서 engine의 개수, 아키텍처, 메모리 등 최적의 kernel을 찾아서 선택적으로 엔진을 생성해 줌 Dynamic Tensor Memory & Multi-stream execution 자체적인 Memory Management 시스템으로 footprint를 줄여 데이터의 Reuse기회를 늘려줄 수 있는 Dynamic Tensor Memory기능이 있다. CUDA Stream 기술을 활용해서 여러개의 input stream을 스케쥴링을 통해 최적의 병렬처리 효율을 만들어 낼 수 있다. 이를 Multi-stream execution기술이라고 한다. https://opac.tistory.com/6
- 12. Fused Kernel Kernel Fusion이라는 기법을 활용하여 분산된 연산을 효율적으로 합하여 하나의 연산으로 처리하는 기법. GPU는 Kernel 단위로 연산이 이루어지게 된다. 예를 들면 우리가 두개의 Tensor를 서로 MatMul 후에 Add하는 연산을 수행할 때, Matmul Kernel, Add Kernel 이렇게 두개의 커널을 실행 이 때 두 개의 커널을 실행하는 대신 두개의 커널을 MatmulAdd라는 하나의 커널로 합쳐 실행하는 것을 Kernel Fusion이라고 함 Matmul Kernel의 결과를 메모리에 저장하고Add Kernel이 다시 메모리에 저장된 결과를 불러와 연산에 사용해야 하는 overhead가 발생하는데, kernel 내에서 sharedmemory나 register를 공유해 이러한 overhead를 제거할 수 있다. Kernel Fusion은 주어진 연산 그래프가 있을 때 잘 알려진 패턴이 보이면 이를 Fused된 Kernel로 교체하여 성능 최적화를 만들어낸다. https://tech.scatterlab.co.kr/serving-architecture-3/
- 14. DeepSpeed Microsoft에서 개발한 딥러닝 최적화 라이브러리(PyTorch와 호환 가능)로, MT-NLG 및 BLOOM과 같은 여러 LLM을 학습하는 데 사용 메모리 최적화(ZeRO 기법, Gradient CheckPoint), 파이프라인 병렬처리 등 분산 학습을 위한 다양한 최적화 기법을 지원 https://dl.acm.org/doi/10.1145/3394486.3406703 Megatron-LM + Kernel Fusion 기반의 모델병렬화 기능 지원 이 도구는 주로 Kernel Fusion을 통한 속도개선에 방점이 있음 1 2
- 15. DeepSpeed’s Problem Lack of Scalability : 속도는 빠르지만 지원하는 모델이 너무 적다. Sequence to Sequence Model은 병렬화가 불가능 Deployment : DeepSpeed-inference는 웹서버에 배포 불가 Memory-Inefficiency : DeepSpeed-inference는 메모리 비효율적임, GPU와 CPU 메모리 모든 영역에서 비효율적인 방식으로 병렬처리가 이루어짐 Lack of Simplicity : Faster Transformer는 사용법이 너무 복잡함
- 16. ZeRO-Infinity ZeRO-Infinity는 이기종 메모리 시스템을 활용하여 3D parallelism보다 50배 더 증가한 NVIDIA DGX-2 노드당 1T 모델을 지원한다. 다음은 모델 사이즈를 스케일링하기 위한 ZeRO-Infinity에 적용된 기술이다. Infinity Offload Engine ZeRO-Infinity는 모든 model states를 분할하여 메모리 중복성을 제거하는 ZeRO-3을 기반으로 모든 분할 model states를 CPU 또는 NVMe 스토리지로 offloading한다. Activation을 위한 CPU offload Model states 외에 Activation 메모리를 CPU 메모리로 offload할 수 있다. 10 T 모델의 activation checkpoint(0.76 TB)는 DGX-2의 1.5TB CPU 메모리에 모두 들어갈 수 있는 크기이다. Working 메모리를 위한 Memory-centric tiling ZeRO-Infinity는 ZeRO-3의 데이터 fetch와 release 패턴을 활용하여 큰 연산자를 순차적으로 실행할 수 있는 작은 tile로 분할하여 working 메모리의 요구사항을 줄인다. 예를들어 ZeRO-Infinity는 OP(OPerator)를 원래 OP의 파라미터 tile로 구성된 수학적으로 동등한 더 작은 선형 OP 시퀀스로 나타내고 그것들을 순차적으로 실행한다. ZeRO-3와 결합하면 tile 수에 비례하여 working 메모리가 줄어든다. 따라서 ZeRO-Infinity는 model parallelism에 의존하지 임의 크기의 OP를 지원할 수 있다. https://moon-walker.medium.com/%EB%A6%AC%EB%B7%B0-zero-infinity-breaking-the-gpu-memory-wall-for-extreme-scale-deep-learning-eeca3c035da5 1
- 17. Training Deep Nets with Sublinear Memory Cost Gradient Checkpoint Gradient를 노드마다저장하는대신, 그래프를분석하여저장되지않아도 되는 Gradient를 삭제 기본 아이디어 필요한 노드에만조약돌(pebbles, 메모리)을 놓고 중간 결과 계산 값이 더 필요하지않으면 노드에서조약돌을제거하고향후 계산에 사용 Memory Requirement 메모리 전략을 사용할 수도 있지만, 계산 복잡도가증가하므로권장하지 않음 전략으로중간 결과를 체크포인트로지정하여저장하면계산 복잡도가 이기에 권장 전략으로사용 속도는 약 10~20% 정도 느려지지만, Transformer 같은 대용량 모델 학습에 필요한 메모리를크게 줄일 수 있으며, 긴 sequence의 RNN에 대해서도효과적 계산 그래프 적용을 위해 Dynamic programming 및 트리 분해 기법 적용 https://medium.com/tensorflow/fitting-larger-networks-into-memory-583e3c758ff9 https://arxiv.org/pdf/1604.06174.pdf (2016) 2
- 20. Model Parallelism Inter-layer Model Parallelism Inter-layer Model Parallelism의 문제점 - 인공신경망의 특성상 동시에 하나의 GPU만 작동
- 21. Model Parallelism Inter-layer Model Parallelism 문제의 개선 방향 - Pipeline Model Parallelism (GPipe) : inter-layer 모델 병렬화를 개선, 입력 배치를 더 작은 단위로 쪼개서 파이프라이닝 함 미니배치 → 마이크로배치로분해 마이크로배치가많을수록 GPU유휴시간이 줄어든다. 파이프라이닝을수행하여 GPU가 가능한 최대로 일하도록 함 즉 GPU가 쉬는 시간 Bubble을 최소로 만듦→학습이 빨라짐
- 22. Pipeline Model Parallelism (PipeDream) 1F1B 방식을 채택하여 버블을 극도로 줄인다. - Pipeline Flush 없이 수시로 업데이트 발생 대신 메모리 효율 역시 극도로 떨어짐 → 치명적 단점 여러 버전의 체크포인트를 메모리에 유지시켜야 하는데 이는 병렬화의 취지에 반한다.
- 23. Model Parallelism Pipeline Model Parallelism (PipeDream-2BW, Two buffered weight) - Gradient Accumulation을 활용하여 Gradient Syncronization 이슈를 완화 - 이전 버전에 비해 적은 수의 체크포인트 버전 (2개)만으로도 운용이 가능 Pipeline Model Parallelism (PipeDream-Flush) - 1F1B+Pipeline Flush, 플러시를 다시 살렸기 때문에 버블의 크기는 GPipe와 비슷 - Activation을 오랫동안 유지할 필요가 없기 때문에 GPipe보다 메모리 효율적
- 24. Pipeline Model Parallelism (PipeDream-Flush) - GPipe : Backward 시작까지 모든 Activation을 가지고 있어야 한다. - 1F1B : 해당 마이크로 배치의 Backward가 끝나고나서 Activation Memory 삭제 Activation Memory란? Model Parallelism
- 25. Parallelformer
- 26. Model Parallelism Tensor Model Parallelism - Column Parallel - Input Tensor는 복사하고, Weight Tensor는 수직방향으로 분할하여 내적 후 Concatenation 수행 Tensor Model Parallelism - Row Parallel - Input Tensor는 수직방향, Weight Tensor는 수평방향으로 분할하여 내적 후 Addition 수행
- 27. Model Parallelism Tensor Model Parallelism - MLP Layer - Column-Row 순서대로 2개의 Linear Layer를 연결한다. - 이를 통해 All-Gather와 Scatter 통신 생략 가능 (이는 Column-Row 순으로 연결시에만 가능)
- 28. Megatron-LM Contribution ● 단순하고 효율적으로 모델 병렬화를 구현: 기존에 pytorch 트랜스포머 구현체에서 몇가지 부분들을 수정해서 쉽게 적용가능. ● 모델과 데이터 병렬 테크닉에 대해 깊이 있게 분석: 512GPU를 통해 76% 확장 효율성을 검증. ● BERT와 같은 모델에서 layer normalization의 배치가 모델의 증가에 따라 정확도에 미치는 영향을 보임 ● 모델사이즈 증가에 따른 모델의 성능향상 확인 ● 몇몇 태스크들에서 SOTA를 달성 ● 학습과 평가 파이프라인 코드를 오픈소스로 공개: https://github.com/NVIDIA/Megatron-LM
- 29. Data and Model Parallelism in Deep Learning Data Parallelism : 미니 배치를 여러 워커에 분산시키는 것 Model Parallelism : 모델의 메모리 사용과 계산 부분을 여러 워커에 분산 시키는 것 미니배치를 적절하게 증가시켜서 워커들에게 적절하게 나누어 주는 방법은 트레이닝 데이터의 증가에 따라 거의 선형적으로 증가하는 것을 볼 수 있다. 하지만 큰 배치 학습이 최적화 과정에서 문제를 보일수 있다 : 모델의 정확도를 낮추거나 모델이 수렴하는데 더 많은 시간을 필요로 하게 된다. 이러한 점 때문에 학습 시 처리량 증가의 이점이 상쇄됨 또 다른 연구에서는 Data parallelism과 activation checkpointing을 결합한 방법을 사용 메모리 사용량을 줄이기 위해 activation을 저장하지 않고 backward 과정에서 다시 계산하는 방법을 사용 하지만 이런 방법들도 문제가 있었으며 다른 솔루션에서는 메모리가 차지하는 공간을 줄이기 위해 파라미터를 공유하는 (Parameter Sharing)을 사용. 그러나 이 또한 모델의 전체 크기에 제한된다는 단점 존재 Megatron-LM에서는 여러 가속기들에 모델을 여러개로 나누는 model parallelism을 사용한다. 이 방법을 통해 메모리를 보다 효율적으로 사용하고 마이크로 배치의 크기와 상관없이 병렬화를 적용할 수 있다.
- 30. Model parallelism의 2가지 패러다임 model parallelism에는 layer-wise pipeline parallelism과 텐서 계산을 분산해서 하는 방법이 있다. Pipeline model parallelism 파이프라인 모델 병렬화는 연산들의 그룹이 다른 디바이스로 전달되기 전에 수행된다. 하지만 이러한 방법들도 일관적이지 않은 문제가 있다. GPipe에서는 synchronous gradient decent을 사용해서 일관적이지 않은 이슈를 극복했다. 통신과 계산연산들의 효율적인 파이프라인을 다루기 위해서는 추가적인 로직이 필요하며 파이프라인 버블로부터 효율성이 줄어들고, 옵티마이저의 변경으로 인해 정확도에 영향을 줄 수도 있다. Distributed tensor computation Distributed tensor computation의 경우 여러 디바이스를 통해서 계산을 가속시키거나 모델 크기를 증가하기 위해 tensor 연산을 분할하는 방법은 수직적이며 보다 일반적인 접근 방법이다. 이전에는 FlexFlow, Mesh-Tensorflow와 같은 방법들이 있었으며, Megatron-LM에서는 Mesh-Tensorflow의 아이디어를 이용해서 기존의 Pytorch Transformer 구현체에 몇가지 수정을 통해 모델 병렬화를 구현할 수 있다.
- 31. 1 2 3 4
- 32. 1 3 2 4
- 33. 1 3 2 4
- 34. 1 3 2 4
- 36. Data Parallelism Data Parallelism : 데이터를 여러 GPU로 분할 / 모델은 모든 GPU에 복제 초기 Data Parallelism (torch.nn.DataParallel) - 싱글 프로세스 / 멀티 쓰레드 - 멀티 노드에서 사용할 수 없음. (1대의 컴퓨터 안에서만 사용 가능)
- 37. 초기 Data Parallelism Forward Pass Backward Pass & Optimization
- 38. 초기 Data Parallelism의 문제 Forward Pass - 멀티 쓰레드는 Python에서 효율적이지 않으며 노드간 통신 불가능 - 한 디바이스의 모델만 업데이트 되기 때문에 매 스텝마다 모델의 복제가 일어나야 함 Backward Pass & Optimization
- 39. 초기 Data Parallelism의 문제와 업데이트 방향 초기 Data Parallelism (torch.nn.DataParallel)의 문제점 - 멀티 쓰레드는 Python에서 효율적이지 않으며 노드간 통신이 불가능 함 → 멀티 프로세스로 개발하면 해결 됨 - 한 디바이스의 모델만 업데이트 되기 때문에 매 스텝마다 모델의 복제가 일어나야 함 → 모든 디바이스에서 계산된 Gradient들의 평균을 계산해서 모든 디바이스의 모델을 업데이트 하면 됨 2017년 Ring All-Reduce의 등장으로 모든 디바이스에서의 업데이트가 이전에 비해 수월해짐 - 이를 채용한 대표적인 라이브러리로 Horovod가 등장하여 인기를 끔 - 이후에 TensorFlow, PyTorch에 구현되었으며 우리에게 익숙한 DDP(DistributedDataParallel)라는 이름으로 불리게 됨 - 실제 NCCL 구현에서는 Reduce-Scatter + All-Gather와 Equivalent 함. (with Pipelining)
- 40. DDP (torch.nn.parallel.DistributedDataParallel) 실제로는 뒤쪽 레이어의 Gradient부터 차례대로 All-reduce하여 통신과 Backward를 중첩해서 수행함 이렇게 Computation과 Communication을 오버랩 하는 것은 이 분야에서 흔하게 사용하는 테크닉
- 41. Data Parallelism 여러대의 gpu에 데이터를 분석하여 시간을 단축하는 방법 weight parameter를 업데이트할 때마다 여러 gpu가 학습한 결과를 종합한 후 다시 나누는 synchronization(all-reduce) 필요 Model Parallelism 모델 사이즈가 너무 커서 하나의 gpu메모리에 다 들어가지 않는 경우 여러 gpu에 모델 파라미터를 나누어 연산 일반적으로 tensor parallelism과 pipeline parallelism으로 나누어짐 Model & Data Parallelism
- 42. Tensor & Pipeline Parallelism Tensor Parallelism 커다란 행렬을 여러 gpu로 나누어 연산한 후 그 결과값을 concat하는 방식 Pipeline Parallelism 여러 gpu가 활성화되지 않는 bubble 존재 마이크로배치들/weight를 계속해서 올리는 과정에서 higher memory bandwidth를 요구함
- 43. Pathway 인프라 https://arxiv.org/pdf/2203.12533.pdf PaLM에서는 pipeline을 사용하지 않으면서 540B나 되는 큰 모델을 6144개의 칩으로 확장시키기 위해 다음의 전략 사용 첫째, 각 TPU v4 Pod은 full copy of the model parameters를 가진다. 이때, 각 weight tensor는 12-way model parallelism을 통해 3072개의 chip에 나누어져 있고, 마찬가지로 데이터도 256-way fully sharded data parallelism을 통해 분산되어 있다. 둘째, 각 pod 단위에서 two-way data parallelism을 적용하기 위해, client-server architecture를 이용한다. component A는 각 pod의 forward+backward computation결과 component B는 optimizer update정보를 담고 있으며 cross-pod gradient transfer가 존재한다. The Pathways program은 처음에 각 pod으로 하여금 component A를 연산하게 하고, 각 결과를 pod끼리 공유하게 한다. 마지막으로 component B를 연산한다. Pathways system은 여러 대의 accelerator chip를 활용하여 모델을 훈련시킬 수 있는 특징들을 가진다.
- 44. Pathways system은 여러 대의 accelerator chips를 활용하여 모델을 훈련시킬 수 있는 특징들을 가진다. 1. aysnchronous gang-scheduling를 각 pod scheduler에 적용, 즉, 여러 대의 프로세스가 소통하면서 동시에 작동하도록 함으로써, latency를 줄임 2. shared-dataflow execution model을 사용하기 때문에 data transfer 시간을 줄임 Training Efficiency 연구자들은 성능을 평가하기 위해 MFU(model FLOPs utilization)라는 새로운 지표를 소개한다. 이는 관측된 throughput, 즉, 일초당 처리할 수 있는 토큰의 수와 이론적 최대 throughput과의 비율이다. 다시 말해, 기대되는 최대 throughtput과 현실 사이의 비교라고 할 수 있다. https://velog.io/@tobigs-nlp/PaLM-Scaling-Language-Modeling-with-Pathways-2
- 45. Multi-gate Mixture of Experts MMoE는 Shared-Bottom multi-task DNN구조(그림 a참고)를 기반으로, 모든 태스크에서 하나의 Bottom Network를 공유하는 대신, Expert Network 그룹을 통해 Task를 공유한다. 이때 각각의 Expert는 Feed-Forward Network로 구성되어 있다.(그림 c참고). https://dl.acm.org/doi/pdf/10.1145/3219819.3220007 (2018)
- 46. Rematerialization 이후 재사용될 가능성이 있는 값을 메모리에 store - load하는 대신, 값을 일단 버리고 나중에 다시 필요할 때 재계산 하는 것 다시 사용할 값이라면 저장을 해 두었다가 나중에 다시 불러와 사용을 하여 추가적인 CPU 연산을 하지 않도록 하는 것이 직관적이지만, 어떤 경우엔 필요한 값을 나중에 다시 계산하는 것이 효율적일 때가 있다. (예컨대 Compiler가 머신코드를 생성할 때 register spilling이 있는 상황에서는 값을 다시 계산해서 사용하는 것이 효율적) 컴파일러의 경우 register resident dependency가 있는 몇몇 예외적인 값들에 한해서만 rematerialization이 효율적이지만, Checkmate와 같은 딥러닝 메모리 최적화 상황에서는 전체 operation subgraph를 재계산하에 사용할 수 있다. GPU memory에서 RAM으로 spilling이 발생하는 cost가 매우 크기 때문이다. https://yunmorning.tistory.com/20 https://arxiv.org/abs/2006.09616 (2020)
- 47. 최대 24배 빠른 vLLM의 비밀 파헤치기 vLLM은 PagedAttention 기법을 활용하여 문장 생성 속도를 비약적으로 높인 방법론 이뿐만 아니라 실제 서빙을 위해 많은 요소들이 포함되어 있다. 예를 들어 멀티 클러스터 환경에서 안정적인 서빙을 하기 위한 Ray Cluster를 사용하거나 큰 모델과 데이터를 병렬로 처리할 수 있도록 Megatron LM의 Parallelism을 차용하고 있습니다. Ray Cluster나 Megatron LM은 앞에서 살펴보았다. vLLM의 핵심 기술은 PagedAttention과 Continuous Batching 기법입니다. https://tech.scatterlab.co.kr/vllm-implementation-details/
- 48. Key/Value Caching LLM 은 주어진 Context 뒤에 한토큰 한토큰을 이어서 생성하는 방식으로 추론을 진행 이때 Auto Regressive 모델에서의 Self-Attention 특성상 앞 부분의 Context 의 Key, Value 값은 토큰이 새로 생성되더라도 변하지 않음 이를 활용하여 앞 부분에 연산해 둔 Key, Value 를 토큰 생성이 끝날때 까지 Caching 하여 중복된 연산을 막는 기법 새로운 토큰에 대해 생성을 완료하고, 해당 토큰에 대한 Key, Value 값이 계산 되면 기존 Key/Value Cache 에 새로운 Key/Value 값을 concat 하여 다시 저장함 https://tech.scatterlab.co.kr/serving-architecture-3/
- 49. PagedAttention은 운영 체제에서 흔한 가상 메모리와 페이지 단위의 기술에서 영감을 받은 어텐션 알고리즘 🔹 KV 캐시는 각각 일정 수의 토큰에 대한 키와 값이 담긴 블록으로 나뉘어 있다. 🔹 블록은 연속되지 않은 메모리 공간에 저장되어 있다 PagedAttention
- 50. Continuous Batching Dynamic Batching ( = Continuous Batching) 여러 개의 입력을 한 개의 Batch로 묶어 최대한 Tensor Core Utilization을 높이는 방법이 필요하고 이를 위한 기법임 다만 Batch의 크기를 무한이 늘린다고 계속 Utilization이 늘어나는 것이 아니고, GPU의 사용률이 이미 충분히 높아진 시점 부터는 Latency가 증가하게 된다. Selective Batching Dynamic Batching에서 Context의 길이가 10인 입력과 길이가 256인 입력이 동시에 하나의 Batch로 묶이게 되는 상황처럼 Batch내의 길이가 매우 다양한 경우엔 가장 짧거나 가장 긴 입력 시퀀스에 맞게 padding 또는 attention mask를 적용해야 하기 때문에 연산의 비효율 발생(이를 해결하기 위한 방법) 현재 처리중인 모든 시퀀스들을 하나의 Batching으로 만드는 것이 아닌, 선택적으로 필요로 하는 시퀀스끼리 묶어 Batching을 함으로서 연산의 비효율성을 최소화 함. 또한 Batch 내에서 Early Stopping된 Sequence가 발생한 경우 선택적이로 해당 Sequence를 반환함으로서최소한의 연산이 이뤄질 수 있도록 구현 https://tech.scatterlab.co.kr/serving-architecture-3/
- 51. 분산 처리를 위한 Worker PagedAttention의 Block을 관리 KV 캐시 등을 관리하는 컴포넌트 매 요청 시 Scheduler를 통하여 요청된 프롬프트들의 생성 순서를 변경
- 52. TensorRT-LLM TensorRT-LLM은 최신 NVIDIA Tensor Core GPU에서 추론 성능을 가속화하고 최적화하는 오픈 소스 라이브러리입니다. 개발자들은 이를 사용하여 새로운 LLM(대규모 언어 모델)을 실험할 수 있으며, C++ 또는 CUDA에 대한 심층적인 지식이 없어도 현저히 향상된 성능과 빠른 사용자 정의 능력을 누릴 수 있습니다. TensorRT-LLM은 TensorRT의 딥 러닝 컴파일러, FasterTransformer의 최적화된 커널, 전/후 처리 및 다중 GPU/다중 노드 통신을 간단한 오픈 소스 Python API로 감싸 LLM을 정의, 최적화 및 실행할 수 있습니다. 이는 프로덕션에서 LLM에 대한 추론을 위한 것입니다. ● 딥 러닝 컴파일러: LLM을 GPU에서 효율적으로 실행할 수 있도록 최적화된 컴파일된 그래프를 생성합니다. ● 최적화된 커널: LLM의 주요 연산을 최적화된 커널로 구현하여 성능을 향상시킵니다. ● 사전/후처리: LLM의 입력 및 출력을 조정하여 성능과 정확도를 개선합니다. ● 멀티 GPU/멀티 노드 통신: 여러 GPU 또는 노드에서 LLM을 병렬로 실행하여 성능을 더욱 향상시킵니다. TensorRT LLM은 다음과 같은 LLM에 사용할 수 있습니다. - Transformer: LLM의 가장 일반적인 아키텍처 - GPT-3: OpenAI에서 개발한 대규모 언어 모델 - LaMDA: Google AI에서 개발한 대규모 언어 모델 - RoBERTa: Facebook AI에서 개발한 대규모 언어 모델
- 53. Thank you