GPT OSS trên Google Cloud C4 mang lại cải thiện 70% TCO trên GPT OSS với Intel và Hugging Face

Google Cloud C4 mang lại cải thiện 70% TCO trên GPT OSS với Intel và Hugging Face

  • 6 min read
GPT OSS trên Google Cloud C4 mang lại cải thiện 70% TCO trên GPT OSS với Intel và Hugging Face
Google Cloud C4 mang lại cải thiện 70% TCO trên GPT OSS với Intel và Hugging Face

Google Cloud C4 Mang Lại Cải Thiện 70% TCO trên GPT OSS với Intel và Hugging Face

Intel và Hugging Face đã hợp tác để chứng minh giá trị thực tế của việc nâng cấp lên Máy ảo (VM) C4 mới nhất của Google chạy trên bộ xử lý Intel® Xeon® 6 (tên mã Granite Rapids (GNR)). Chúng tôi đặc biệt muốn đánh giá hiệu suất cải thiện trong khả năng tạo văn bản của Mô hình ngôn ngữ lớn (LLM) OpenAI GPT OSS.

Kết quả đã có và rất ấn tượng, cho thấy sự cải thiện 1.7x về Tổng chi phí sở hữu (TCO) so với các phiên bản VM Google C3 thế hệ trước. Phiên bản VM Google Cloud C4 mang lại thêm:

  • Thông lượng TPOT/vCPU/đô la cao hơn từ 1.4x đến 1.7x
  • Giá mỗi giờ thấp hơn so với VM C3

Giới thiệu

GPT OSS là tên gọi chung cho mô hình Mixture of Experts (MoE) mã nguồn mở được phát hành bởi OpenAI. Mô hình MoE là một kiến trúc mạng nơ-ron sâu sử dụng các mạng con “chuyên gia” chuyên dụng và một “mạng cổng” để quyết định sử dụng chuyên gia nào cho một đầu vào nhất định. Các mô hình MoE cho phép bạn mở rộng dung lượng mô hình của mình một cách hiệu quả mà không cần mở rộng tuyến tính chi phí tính toán. Chúng cũng cho phép chuyên môn hóa, nơi các “chuyên gia” khác nhau học các kỹ năng khác nhau, cho phép chúng thích ứng với các phân phối dữ liệu đa dạng.

Ngay cả với các tham số rất lớn, chỉ một tập hợp con nhỏ các chuyên gia được kích hoạt trên mỗi mã thông báo, làm cho suy luận CPU khả thi.

Intel và Hugging Face đã hợp tác để hợp nhất một tối ưu hóa thực thi chuyên gia (PR #40304) để loại bỏ tính toán dư thừa, nơi mọi chuyên gia xử lý tất cả các mã thông báo cho trình biến áp. Tối ưu hóa này chỉ đạo mỗi chuyên gia chỉ chạy trên các mã thông báo mà nó được định tuyến đến, loại bỏ lãng phí FLOP và cải thiện mức sử dụng.

Phạm vi & Phần cứng Đánh giá

Chúng tôi đã đánh giá GPT OSS trong một khối lượng công việc tạo có kiểm soát, có thể lặp lại để cô lập các khác biệt về kiến trúc (GCP C4 VM trên bộ xử lý Intel Xeon 6 (GNR) so với GCP C3 VM trên bộ xử lý Intel Xeon thế hệ thứ 4 (SPR)) và hiệu quả thực thi MoE. Trọng tâm là giải mã trạng thái ổn định (độ trễ trên mỗi mã thông báo) và thông lượng được chuẩn hóa từ đầu đến cuối với kích thước lô tăng lên trong khi vẫn giữ độ dài chuỗi cố định. Tất cả các lần chạy đều sử dụng bộ nhớ cache KV tĩnh và chú ý SDPA để xác định.

Tóm tắt Cấu hình

  • Mô hình: unsloth/gpt-oss-120b-BF16
  • Độ chính xác: bfloat16
  • Tác vụ: Tạo văn bản
  • Độ dài đầu vào: 1024 mã thông báo (được đệm bên trái)
  • Độ dài đầu ra: 1024 mã thông báo
  • Kích thước lô: 1, 2, 4, 8, 16, 32, 64
  • Tính năng đã bật:
    • Bộ nhớ cache KV tĩnh
    • Phần phụ trợ chú ý SDPA
  • Số liệu được báo cáo:
    • Thông lượng (Tổng số mã thông báo được tạo trên mỗi giây được tổng hợp trên lô)

Phần cứng Đang Thử nghiệm

Tạo Phiên bản

C3

Truy cập Google Cloud Console và nhấp vào tạo VM trong dự án của bạn. Thực hiện theo các bước bên dưới để tạo một phiên bản 176 vCPU.

C4

Truy cập Google Cloud Console và nhấp vào tạo VM trong dự án của bạn. Thực hiện theo các bước dưới đây để tạo một phiên bản 144 vCPU.

Thiết lập môi trường

Đăng nhập vào phiên bản bằng SSH và sau đó cài đặt docker. Thực hiện theo các bước bên dưới để thiết lập môi trường một cách dễ dàng. Để có thể tái tạo, chúng tôi liệt kê các phiên bản và cam kết mà chúng tôi đang sử dụng trong các lệnh.

Chúng ta đang ở trong container ngay bây giờ, hãy thực hiện các bước sau.

Quy trình Đánh giá

Đối với mỗi kích thước lô, chúng tôi

Chạy numactl -l python benchmark.py cho các mã sau.

python import os import time import torch from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer

INPUT_TOKENS = 1024 OUTPUT_TOKENS = 1024

def get_inputs(tokenizer, batch_size): dataset = load_dataset(“ola13/small-the_pile”, split=“train”) tokenizer.padding_side = “left” selected_texts = [] for sample in dataset: input_ids = tokenizer(sample[“text”], return_tensors=“pt”).input_ids if len(selected_texts) == 0 and input_ids.shape[-1] >= INPUT_TOKENS: selected_texts.append(sample[“text”]) elif len(selected_texts) > 0: selected_texts.append(sample[“text”]) if len(selected_texts) == batch_size: break

return tokenizer(selected_texts, max_length=INPUT_TOKENS, padding="max_length", truncation=True, return_tensors="pt")

def run_generate(model, inputs, generation_config): inputs[“generation_config”] = generation_config model.generate(**inputs) # warm up pre = time.time() model.generate(**inputs) latency = (time.time() - pre) return latency

def benchmark(model, tokenizer, batch_size, generation_config): inputs = get_inputs(tokenizer, batch_size) generation_config.max_new_tokens = 1 generation_config.min_new_tokens = 1 prefill_latency = run_generate(model, inputs, generation_config) generation_config.max_new_tokens = OUTPUT_TOKENS generation_config.min_new_tokens = OUTPUT_TOKENS total_latency = run_generate(model, inputs, generation_config) decoding_latency = (total_latency - prefill_latency) / (OUTPUT_TOKENS - 1) throughput = OUTPUT_TOKENS * batch_size / total_latency

return prefill_latency, decoding_latency, throughput

if name == “main”: model_id = “unsloth/gpt-oss-120b-BF16” tokenizer = AutoTokenizer.from_pretrained(model_id) model_kwargs = {“dtype”: torch.bfloat16} model = AutoModelForCausalLM.from_pretrained(model_id, **model_kwargs) model.config._attn_implementation=“sdpa” generation_config = model.generation_config generation_config.do_sample = False generation_config.cache_implementation=“static”

for batch_size in [1, 2, 4, 8, 16, 32, 64]:
    print(f"---------- Run generation with batch size = {batch_size} ----------", flush=True)
    prefill_latency, decoding_latency, throughput = benchmark(model, tokenizer, batch_size, generation_config)
    print(f"throughput = {throughput}", flush=True)

Kết quả

Thông lượng Chuẩn hóa trên mỗi vCPU

Trên các kích thước lô lên đến 64, C4 chạy bằng bộ xử lý Intel Xeon 6 luôn vượt trội hơn C3 với thông lượng trên mỗi vCPU cao hơn từ 1.4x đến 1.7×. Công thức là:

$\text{normalized_throughput_per_vCPU}

\frac{\text{throughput_C4} / \text{vCPUs_C4}} {\text{throughput_C3} / \text{vCPUs_C3}}$

Chi phí & TCO

Ở kích thước lô 64, C4 cung cấp thông lượng trên mỗi vCPU cao hơn 1.7× so với C3; với mức giá gần ngang bằng trên mỗi vCPU (chi phí hàng giờ tỷ lệ tuyến tính với số lượng vCPU), điều này mang lại lợi thế TCO 1.7× (C3 sẽ yêu cầu chi tiêu gấp 1.7× cho cùng một khối lượng mã thông báo được tạo).

Tỷ lệ thông lượng trên mỗi vCPU: $\frac{\text{throughput_C4} / \text{vCPUs_C4}}{\text{throughput_C3} / \text{vCPUs_C3}} = 1.7 \Rightarrow \frac{\text{TCO_C3}}{\text{TCO_C4}} \approx 1.7$

Kết luận

VM Google Cloud C4 được hỗ trợ bởi bộ xử lý Intel Xeon 6 (GNR) cung cấp cả hiệu suất tăng ấn tượng và hiệu quả chi phí tốt hơn cho suy luận MoE lớn so với VM Google Cloud C3 thế hệ trước (được hỗ trợ bởi bộ xử lý Intel Xeon thế hệ thứ 4). Đối với suy luận GPT OSS MoE, chúng tôi quan sát thấy thông lượng cao hơn, độ trễ thấp hơn và chi phí giảm. Những kết quả này nhấn mạnh rằng nhờ các tối ưu hóa khung mục tiêu từ Intel và Hugging Face, các mô hình MoE lớn có thể được phục vụ hiệu quả trên CPU đa năng thế hệ tiếp theo.

Recommended for You

Giới thiệu RTEB- Một tiêu chuẩn mới để đánh giá khả năng truy xuất thông tin

Giới thiệu RTEB- Một tiêu chuẩn mới để đánh giá khả năng truy xuất thông tin

Không có mô tả ngắn gọn

OCR SOTA trên thiết bị với Core ML và dots.ocr

OCR SOTA trên thiết bị với Core ML và dots.ocr