Cách chạy GPT-OSS-120B trên GPU NVIDIA với tốc độ hơn 500 token mỗi giây

• GPT-OSS-120B, LLM mã nguồn mở của OpenAI, được tối ưu để đạt hiệu năng xử lý hơn 500 token mỗi giây trên môi trường GPU của NVIDIA
• Thực hiện kiểm thử song song trên nhiều khung suy luận như TensorRT-LLM, vLLM, SGLang và hỗ trợ cả kiến trúc Hopper và Blackwell
• Sửa lỗi tương thích, tích hợp định dạng phản hồi mới như Harmony và áp dụng các tối ưu hóa như định tuyến nhận biết KV cache và giải mã dự đoán dựa trên Eagle
• So sánh tensor parallelism và expert parallelism, chọn tensor parallelism để giảm độ trễ và dùng backend TensorRT-LLM MoE trên Blackwell
• Dự kiến sẽ tiếp tục tối ưu thêm trong tương lai, bao gồm cả Speculative Decoding (giải mã dự đoán) với mô hình dự thảo nhỏ

---

Tổng quan

• Khi GPT-OSS-120B, mô hình ngôn ngữ lớn mã nguồn mở mới nhất của OpenAI, được công bố, Baseten đặt mục tiêu đạt hiệu năng tốt nhất
  • Baseten là đối tác khởi chạy chính thức của OpenAI
• Dựa trên dữ liệu người dùng thực tế từ OpenRouter, Baseten đã chứng minh hiệu năng vượt trội hơn đối thủ trong môi trường dựa trên GPU NVIDIA
• Với stack suy luận linh hoạt và chuyên môn của đội ngũ kỹ sư mô hình, các bản vá tối ưu được triển khai nhanh theo từng giờ
• Chỉ trong vài giờ viết bài, nhóm đã tăng thêm 100 token mỗi giây và giữ 100% thời gian hoạt động

Nỗ lực tối ưu hiệu năng

• Thực hiện kiểm thử và benchmarking trên nhiều khung suy luận như TensorRT-LLM, vLLM, SGLang
• Đồng thời đảm bảo tương thích với kiến trúc GPU Hopper và Blackwell
• Tích hợp các thành phần chính như Baseten Flexible Inference Stack và NVIDIA Dynamo
• Áp dụng các kỹ thuật tối ưu đã được kiểm chứng như KV cache-aware routing và Speculative decoding (dựa trên Eagle)

Dưới đây là các bước quan trọng để cùng lúc đạt hiệu năng SOTA và hỗ trợ toàn bộ cửa sổ ngữ cảnh

Bước 1: Thực thi suy luận ban đầu

• Điểm khởi đầu là chạy nhanh baseline inference bằng bất kỳ cách nào
• Trên GPU, nhiều kỹ sư đồng thời thử nghiệm vLLM, SGLang, TensorRT-LLM cùng lúc
• Thành công triển khai nhanh TensorRT-LLM, khung có hiệu năng tốt nhất
• Đảm bảo hỗ trợ TensorRT-LLM trên Hopper (GPU H100 nhiều nhất) và Blackwell (B200 nhanh hơn)
• Nhờ sự linh hoạt của Baseten Inference Runtime, việc thích ứng với kiến trúc mới và thay thế công cụ trong stack diễn ra nhanh chóng

Bước 2: Sửa lỗi tương thích

• Khi xuất hiện kiến trúc mô hình mới, việc tích hợp framework thường đi kèm với các lỗi tương thích
• GPT OSS có thêm các công nghệ mới như định dạng phản hồi Harmony, nên khi tích hợp với framework hiện có đã phát sinh lỗi
• Để đồng thời giữ tốc độ và độ chính xác, nhóm đã lặp lại quy trình sửa đổi và kiểm tra, và đóng góp các sửa đổi hiệu quả trở lại mã nguồn mở
• Nhờ cộng tác của cộng đồng mã nguồn mở toàn cầu, nhiều đường đi tối ưu hóa và bản vá lỗi được thực hiện rất nhanh

Bước 3: Tối ưu cấu hình mô hình

• OpenAI công bố GPT OSS 120B hoạt động trên một H100, nhưng trên thực tế song song hóa trên 4 đến 8 GPU mang lại hiệu năng tốt hơn
• Tensor Parallelism mạnh về độ trễ (latency), còn Expert Parallelism mạnh về thông lượng (throughput) của hệ thống
  • Baseten chọn Tensor Parallelism vì mục tiêu tối ưu hóa độ trễ
• Trên Blackwell, áp dụng TensorRT-LLM MoE Backend để cải thiện hiệu năng nhân CUDA so với backend Triton trước đây
• Đã công bố cấu hình tối ưu cho môi trường Hopper và Blackwell, và trong Model API đã chọn cấu hình dựa trên Blackwell

Tối ưu hiệu năng thêm

• Mặc dù lần tối ưu đầu tiên đã đạt mức SOTA về thông lượng và độ trễ, vẫn còn nhiều dư địa cải thiện
• Cập nhật lớn tiếp theo dự kiến là triển khai Speculative Decoding
  • Cách tiếp cận này để một mô hình “draft” nhỏ và nhanh hơn tạo ra token dự đoán, rồi mô hình chính sẽ xác thực
  • Baseten khuyến nghị Eagle 3, nhưng vận hành linh hoạt hơn 10 thuật toán trong stack suy luận theo tình huống
• Speculative decoding cho phép suy luận nhiều token cùng lúc để nâng tốc độ một cách hiệu quả

[jjw951215]

Mình ước gì có ai đó tặng mình một con H100 nhỏ xinh...

[GN⁺]

Bình luận trên Hacker News

• widely-available H100 GPUs

  Khi nghe vậy, tôi đã lục tủ linh kiện ở nhà, nhưng dù tìm kĩ đến đâu vẫn tự hỏi tại sao lại không có GPU H100 giá 25.000 đô la.

  • Tôi đã tự xác nhận trên trang sản phẩm của NVIDIA rằng H100 thực sự được phân loại là một GPU. Giờ mình nghĩ cần có tên gọi dễ nhận diện hơn để tách bạch giữa “phần cứng người dùng, chủ yếu dùng cho game nhưng chỉ hạn chế suy luận LLM” và “phần cứng chuyên nghiệp cho mục đích đào tạo AI hoặc suy luận LLM cho doanh nghiệp”.
  • Tôi đã chạy mô hình 20B trên 8 card TitanX (năm 2015) bằng Ollama. Ollama phân bổ đều tổng 15GB VRAM cho 8 card, và tốc độ token còn nhanh hơn tốc độ đọc.
  • Những GPU kiểu này rất dễ thuê. Nếu không chạy GPU 24/7 liên tục trong thời gian dài thì thuê hosting rẻ hơn nhiều so với việc mua trực tiếp. Với nhu cầu cá nhân, rất ít khi cần dùng card cấp data center mới nhất, khi đó Mac Studio hay Strix Halo là đủ — dù tốc độ có phần chậm hơn.
  • Cảm ơn bình luận này, hôm nay mình thấy vui hẳn ra. Chắc chắn đây là góc nhìn từ data center, và phần cứng nhanh nhất trong tủ nhà mình có lẽ vẫn là chiếc iPhone 8 cũ.
  • Chỉ vì “không có GPU 25.000 đô tại nhà” không có nghĩa là không thể mua được phần cứng đó. Nó chỉ có nghĩa là có hàng/khả dụng, chứ chưa chắc bạn có đủ tiền để mua.

• Tôi đã dùng GPT-OSS-120B trên máy bay xuyên Đại Tây Dương với MacBook Pro (M4, 128GB RAM).
  Chỉ chạy nhanh khi cửa sổ ngữ cảnh nhỏ và tổng token thấp. Vượt quá 10.000 token thì hầu như mọi xử lý đều kéo dài và bị xếp hàng.
  MCPs, tìm kiếm web, patch URL v.v. đã trở thành rất quan trọng trong trải nghiệm dùng LLM. Nếu thiếu các tính năng này, tiện ích của LLM giảm đáng kể.
  Các công cụ lập trình CLI/TUI đã preconfigure cho môi trường offline (như opencode) không hoạt động ổn định cùng model.
  Ngoài các điểm đã được nhắc nhiều trong bình luận trước, những điểm đặc biệt của mô hình OSS cũng có:

  • Wikipedia thời xưa từng có thể lưu cục bộ rồi dùng, nên mình nghĩ sớm hay muộn sẽ có nhiều dữ liệu được expose qua MCP và AIs sẽ tìm kiếm local giống như “web search”. Khoảng 99% tìm kiếm web diễn ra trên cùng 100–1000 website. Tức là chỉ cần lưu vài GB cũng có thể bao phủ được, nên vấn đề bản quyền sẽ còn tồn tại.
  • Tò mò mọi người đang dùng Ollama, LMStudio hay llama.cpp? tweet của ggerganov
  • Tò mò mọi người đã đặt iogpu.wired_limit_mb như thế nào. Nếu mặc định thì chỉ khoảng 70% RAM, tức khoảng 90GB, có thể dùng cho GPU core. Muốn tận dụng thêm thì phải chỉnh cấu hình.
  • Mình chạy trên M2 Max. Đoạn chat ngắn đạt hơn 60 token/s, nhưng khi dài thì tụt xuống 30. Tò mò nguyên nhân của sự chậm lại là gì; có vẻ không phải do nhiệt.
  • Mình nghĩ là sự khác biệt giữa compute-bound prefill (khi băng thông/độ tính toán của CPU cao) và decode. Ngay cả với ngữ cảnh 10k, token đầu tiên vẫn chưa tới 0,5 giây.

• Nhiều kỹ sư đang song song thử vLLM, SGLang và TensorRT-LLM. Mọi người nói TensorRT-LLM nhanh nhất, nhưng thường khó cài đặt nhất, cập nhật kiến trúc mới kém, và phải compile model trực tiếp trên stack phần cứng-driver-thư viện giống production nên rất phiền. Multimodal từng gần như không thể trong một thời gian dài; thậm chí cả mô hình LLaMA multimodal nổi tiếng cũng không chạy đúng. Vẫn còn câu hỏi liệu có đáng đầu tư không; ví dụ chạy GPT-OSS-120B trên H100 bằng vLLM thì chạy ổn và ra 130–140 t/s đều đặn. Đọc tiêu đề thì tưởng sẽ được 500 t/s cho một GPU, nhưng thực tế đó là tensor parallel. Việc đóng gói riêng TRT-LLM cho gpt-oss cũng hơi đùa ghẹo. Bản thân TRT-LLM cũng đã là công cụ khá rối rồi.

  • Nếu trải nghiệm TRT-LLM, thấy còn nhiều thách thức từ khía cạnh DX. Khi làm multimodal vẫn dùng vLLM khá nhiều. Nhưng với traffic lớn, độ trễ thấp như lượng truy cập mà dịch vụ của chúng tôi phục vụ, benchmark luôn cho thấy TRT-LLM tốt hơn nên đầu tư nhiều vào tooling này.

• Việc cài GPT-OSS 20B cực kỳ dễ. Nhờ Llama, mình chạy trên Mac trong 5 phút.

  • Nếu tài nguyên CPU đủ thì chạy 120B cũng chẳng khó. Ở nhà, tải file GGUF cho server suy luận LLM trên CPU, git pull rồi build lại llama-server là xong ngay; 40 t/s có được ngay cả không chỉnh gì, 50 t/s thì chỉ cần tuning nhẹ. Tiếc là đã có rất nhiều mô hình tốt hơn 120B rồi, nên không thật sự cần chạy nữa. Việc ggerganov và đội llama.cpp giúp LLM trở nên dễ tiếp cận trong môi trường tính toán cá nhân là điều cực kỳ tuyệt vời.
  • Mọi người hay nói cài LLM khó, nhưng tại sao không để chính LLM tự cấu hình giúp mình nhỉ? Nếu còn làm không nổi việc đơn giản này thì LLM có còn ý nghĩa gì?
  • Hôm qua mình test thì gần như mọi phiên đều đưa ra thông tin sai. Tốc độ và tiện lợi tốt nhưng nếu hy sinh tính chính xác thì không còn ý nghĩa.
  • Nếu đủ bộ nhớ thì chạy 120B cũng thật dễ.

• Khi đọc, mình mới biết để model hoạt động tốt cần quá nhiều tiền xử lý và tuning. Mình từng nghĩ mặc định là chạy được ngay.

  • Theo mình, các tập đoàn lớn nên hợp tác tích cực hơn với các developer engine suy luận phổ biến trước khi phát hành LLM để hỗ trợ cả model của mình. Dù mọi thứ vẫn đang thí nghiệm, nhưng các developer đang đầu tư rất nhiều để giúp mọi người chạy LLM kể cả trên phần cứng giá rẻ.

• Trong American AI Action Plan, mục “khuyến khích AI mã nguồn mở và trọng số mở” nằm ngay sau mục “đảm bảo Frontier AI bảo vệ tự do và giá trị của Mỹ”. Có phần vô lý, nhưng đọc mô hình OSS của OpenAI lúc này khiến mình thấy rùng mình. Dù sao việc các nhà phát triển mô hình OSS nói về phần cứng cũng đáng hoan nghênh. Với đa số developer, phần cứng là rào cản gia nhập lớn nên việc họ nói chuyện về vấn đề này khiến mình mừng.

  • Mục “đảm bảo Frontier AI bảo vệ tự do và giá trị của Mỹ” cũng được nhắc tới, nên mong mọi người thông cảm vì mình còn đang gom ý kiến cho ổn. Mô hình AI luôn mang theo một worldview, và mình lại thích worldview phương Tây hơn. Có rất nhiều tiền lệ cho việc nó tạo ra xã hội tốt hơn. Ít nhất model nên được ghi lại worldview của nó và không nên âm thầm dẫn dắt cách người dùng suy nghĩ theo kiểu thao túng xã hội học.

• Có ai biết website nào nói rõ mô hình nào chạy tốt cho hệ điều hành/GPU nào không? Công thức thực nghiệm đáng tin nhất để ước tính VRAM từng có là: số tham số × (Precision/8) × 1.2 (tham khảo).

  • Tưởng thử làm calculator kiểu này nhưng thực tế có quá nhiều biến số (như traffic đồng thời), nên công thức đó dù tương đối đúng vẫn chưa đủ. Khi traffic đồng thời cao, nhân đôi để an toàn.
  • Trên Hugging Face, khi nhập thông số phần cứng/phần mềm sẽ có chức năng cho biết model có chạy được không ngay ở từng trang chi tiết (cài đặt huggingface).
  • Vì mình có internet nhanh, cách nhanh nhất là tải weight model rồi tự chạy bằng nhiều runner (llama.cpp, LM Studio, vLLM, SGLang, v.v.). Runner, implementation, phần cứng... quá nhiều biến số nên chưa thấy cái calculator nào khớp trọn với thực tế. Cách duy nhất vẫn là tự thử.
  • Cảm ơn mọi người đã chia sẻ. Nếu tính toán bị khó, liệu nên làm một DB cộng đồng để mọi người cùng thử nghiệm và chia sẻ theo runner, phần cứng, model, tham số, lượng lượng tử hóa, khả năng chạy, tokens/s... rồi cho phép lọc ngay theo tổ hợp phần cứng/runner để dùng ngay không? Sẽ rất thực dụng.

• Mình muốn nói rằng việc tìm số liệu chính xác về kích thước thật sự của GPT-OSS-120B không đơn giản. Nếu là ngôn ngữ kiểu static thì chỉ cần nhìn kích thước mảng là ra, nhưng ở đây lại muốn xem dữ liệu (không phải weight) chảy như thế nào, stream output rộng bao nhiêu. Muốn biết băng thông token output tối đa t/s là bao nhiêu trên gigabit ethernet, nên đang tìm repo GitHub gpt-oss nhưng lại không thấy rõ.

  • Tôi tò mò có ứng dụng nào xử lý logits dạng streaming cho toàn bộ token tuần tự không (vẫn sampling token theo đúng quy ước). Cũng cần tính rằng thường phải xử lý và chỉnh logits trước khi trả token để khớp cú pháp, rồi mới đưa vào bước suy luận tiếp theo.
  • Nhìn vào cấu hình model trên huggingface, thấy có tới 2.880 giá trị (sau nhân với dtype).

• GPT-OSS chạy nhanh hơn trên chip Blackwell nhờ hỗ trợ fp4. Mình đang xây engine train/inference bằng Rust và đang thêm hỗ trợ fp8, fp4 cho cudarc và candle. Đang làm để hỗ trợ các model này trong engine của Mixlayer; xem PR: cudarc PR, candle PR.

  • Mình là user RTX Pro 6000 và tò mò gpt-oss-120b có inference được không. Các PR dường như đã merge rồi, nhưng muốn biết thực tế thì có thể chạy được không?