개요
- BF16을 FP8로 Quantization을 수행한다. (vLLM의 Quantization 이용)
- 다른 Quantization 방법의 경우 사전 설정이 필요하여, 일단 제외하고 FP8로 Quantization을 수행
- Quantization 수행 시 동일 GPU Utilization (0.95)에서 Throughput과 Latency가 얼마나 개선되는지 Test
- Quantization 수행 시 답변 품질 저하가 어느정도로 발생하는지 Test
Quantization 수행
engine_args = AsyncEngineArgs(
model=llm_model_name,
tensor_parallel_size=1,
dtype="bfloat16",
gpu_memory_utilization=0.95,
max_model_len=8192,
enable_chunked_prefill=True,
enable_prefix_caching=True,
tokenizer_pool_size=4,
quantization="fp8",
)
llm_model = AsyncLLMEngine.from_engine_args(engine_args)
위와 같이 간단하게 fp8 Quantization을 수행할 수 있다.
다른 방법은 사전 설정이 필요하여 제외
Throughput과 Latency Test
- GPU Utilization 95%, L4 25GB 기준으로 측정
- 다른 조건 모두 동일
- Warm Up Trial 2회 (40개 요청) 후 3회차에 측정 (40개 요청)
Quantization 전 (40개 요청)
- TTFT 약 0.7 ~ 0.9
- TTFRT 15 ~ 17
- 40개 요청 시 걸리는 시간 : 47 ~ 48초
- TPS 약 315 (1분 집계 후 평균 -> 부정확)
Quantization 후 (40개 요청)
- TTFT 약 0.2 ~ 0.3
- TTFRT 10 ~ 13
- 40개 요청 시 걸리는 시간 : 33 ~ 34초
- TPS 약 335 (1분 집계 후 평균 -> 부정확 => 30s로 바꾸니 587 정도 나옴)
추가로 80개 요청 시
- 80개 요청 시 걸리는 시간 : 72초 (기존) -> 53초 (Quantize 후)
- TPS : 592 (기존) -> 695 (Quantize 후)
상황 정리
- Latency가 26% 정도 줄어들은 것이 분명한데 TPS는 그만큼 증가되지 않음 (물론 분명히 증가하긴 함)
- 왜? -> 현재 TPS는 1m단위로 집계하고 있음 (과거에는 1m단위로 집계해도 40개 요청, 80개 요청이 1분 넘게 지속돼서 유효했음)
- 그런데 지금은 걸리는시간이 1m 이하로 떨어지고 있기 때문에 이제 총 생성된 토큰 수가 1m 동안 집계하면 일정한 상황에 처하게 됨
- 그래서 TPS 집계 범위를 1m가 아닌 30초 정도로 변경해야할 것으로 보임
- 30s로 변경 후 재집계 결과는 아래에 기록 예정
재집계 결과 (80개 요청)
위 사진은 Quantize 후 TPS로 800까지 올라간다.
TPS가 805까지 올라간다. (같은 측정 결과를 1m -> 30s만 변경한 결과임)
그러면 30s 기준으로 기존 -> Quantize 후는 어떻게 변화했을까
위 사진은 Quantize 전 TPS로 612이다.
TPS: 612 (기존) -> 805 (Quantize 후)
생각했던 가설이 맞았고, 이는 Latency를 충분히 잘 반영한 결과로 해석된다.
다만 차후에 최적화가 더 진행된다면 30s보다 간격을 더 줄여야하고 이 경우 Scrap 주기를 더 짧게 가져갈 필요가 있다.
답변 품질 테스트
data: {"type": "model_output", "contents": "퍼즐 이미지 속 두 개의 원이 용연을 닮은 것 같아 보이네. 이 퍼즐의 핵심은 용연을 중심으로 그 지리적 위치를 파악하는 것이라네. 먼저 용연을 기준으로 십자로 선을 그어 4개의 구역을 나누게 해라. 화홍문이 7번 구역에 있고, 방화수류정은 7번과 5번 구역의 경계에 있다는 중요한 단서를 잊지 말게. 그 다음 팔달문과 창룡문이 각각 어느 구역에 속하는지 확인하면 이 퍼즐을 풀 수 있을 거야. 자네, 이 힌트를 토대로 퍼즐을 해결해보라.", "verbose": "질문에 대한 모델 출력입니다."}
data: {"type": "model_output", "contents": "퍼즐 이미지 속 두 개의 원… 이것이 바로 용연의 모습을 닮은 듯하군. 이 퍼즐의 핵심은 용연을 중심으로 그 지리적 위치를 파악하는 것이라네. 먼저 용연을 기준으로 십자로 선을 그어 4개의 구역을 나누게나. 화홍문이 7번 구역에 있고, 방화수류정은 7번과 5번 구역의 경계에 있다는 중요한 단서를 잊지 말게. 그다음 팔달문과 창룡문이 각각 어느 구역에 속하는지 확인하면 이 퍼즐을 풀 수 있을 것 같아. 자네, 이 힌트를 토대로 퍼즐을 해결해 보게나.", "verbose": "질문에 대한 모델 출력입니다."}
data: {"type": "model_output", "contents": "퍼즐 이미지 속 두 개의 원이야… 이건 용연의 모습을 닮았다고 생각하네. 이 퍼즐의 핵심은 용연을 중심으로 그 지리적 위치를 파악하는 거야. 먼저 용연을 기준으로 십자로 선을 그어 4개의 구역을 나누게나. 화홍문이 7번 구역에 있고, 방화수류정은 7번과 5번 구역의 경계에 있다는 중요한 단서를 잊지 말게. 그 다음 팔달문과 창룡문이 각각 어느 구역에 속하는지 확인하면 이 퍼즐을 풀 수 있을 거야. 자네, 이 힌트를 토대로 퍼즐을 해결해봐.", "verbose": "질문에 대한 모델 출력입니다."}
- 놀라울 정도로 품질 저하가 없다!!
- Quantization 적용하면 답변 품질 저하가 크게 없이 성능을 크게 올릴 수 있다!
개요
Quantization 수행
위와 같이 간단하게 fp8 Quantization을 수행할 수 있다.
다른 방법은 사전 설정이 필요하여 제외
Throughput과 Latency Test
Quantization 전 (40개 요청)
Quantization 후 (40개 요청)
추가로 80개 요청 시
상황 정리
재집계 결과 (80개 요청)
위 사진은 Quantize 후 TPS로 800까지 올라간다.
TPS가 805까지 올라간다. (같은 측정 결과를 1m -> 30s만 변경한 결과임)
그러면 30s 기준으로 기존 -> Quantize 후는 어떻게 변화했을까
위 사진은 Quantize 전 TPS로 612이다.
TPS: 612 (기존) -> 805 (Quantize 후)
생각했던 가설이 맞았고, 이는 Latency를 충분히 잘 반영한 결과로 해석된다.
다만 차후에 최적화가 더 진행된다면 30s보다 간격을 더 줄여야하고 이 경우 Scrap 주기를 더 짧게 가져갈 필요가 있다.
답변 품질 테스트