Phục vụ mô hình ngôn ngữ lớn tốc độ cao trên PC trang bị GPU tiêu dùng

 (github.com/SJTU-IPADS)
1 điểm bởi GN⁺ 2023-12-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • PowerInfer là một engine suy luận lai CPU/GPU để phục vụ LLM cục bộ trên PC cá nhân trang bị một GPU tiêu dùng duy nhất
  • Thiết kế cốt lõi tận dụng tính cục bộ của kích hoạt trong suy luận LLM: các nơ-ron “hot” thường xuyên được kích hoạt sẽ được đưa sẵn lên GPU, còn các nơ-ron “cold” thay đổi theo từng đầu vào sẽ được tính toán trên CPU
  • Trong đánh giá, PowerInfer cho biết với một GPU RTX 4090 duy nhất, hệ thống đạt trung bình 13,20 tokens/s và tối đa 29,08 tokens/s trên nhiều LLM, bao gồm OPT-175B, thấp hơn 18% so với A100
  • So với llama.cpp, demo Falcon(ReLU)-40B-FP16 trên RTX 4090 24GB cho thấy tăng tốc 11x; trong đánh giá, mức tăng tốc tối đa là 11,69x và độ chính xác của mô hình được giữ nguyên
  • Phạm vi hỗ trợ chủ yếu là các mô hình dùng hàm kích hoạt ReLU/ReGLU/Squared ReLU; hiện có hạn chế là chưa hỗ trợ Mistral, Llama gốc, Qwen, v.v.

Vấn đề PowerInfer muốn giải quyết

  • PowerInfer là engine suy luận CPU/GPU để chạy LLM nhanh trên thiết bị cục bộ
  • Nhắm tới PC trang bị một GPU tiêu dùng duy nhất, với mục tiêu suy luận và phục vụ LLM có độ trễ thấp
  • Điểm cốt lõi trong thiết kế là việc kích hoạt nơ-ron trong suy luận LLM tuân theo phân bố luật lũy thừa
    • Một số nơ-ron hot được kích hoạt nhất quán trên nhiều đầu vào
    • Phần lớn nơ-ron cold thay đổi tùy theo đầu vào cụ thể

Cách suy luận lai CPU/GPU

  • PowerInfer nạp sẵn các nơ-ron hot lên GPU để truy cập nhanh, còn các nơ-ron cold được tính toán trên CPU
  • Cách này tập trung vào việc giảm yêu cầu bộ nhớ GPU và truyền dữ liệu CPU-GPU
  • Ngoài ra, hệ thống tích hợp bộ dự đoán thích ứng và các toán tử thưa nhận biết nơ-ron để tối ưu hóa kích hoạt nơ-ron và độ thưa trong tính toán
  • Trong suy luận lai CPU-GPU, tất cả dense activation block được tự động offload lên GPU, sau đó nếu có thể thì FFN được chia nhỏ và offload lên GPU

Đánh giá hiệu năng và demo

  • Trên một GPU RTX 4090 duy nhất, hệ thống đạt trung bình 13,20 tokens/s và tối đa 29,08 tokens/s trên nhiều LLM, bao gồm OPT-175B
  • Kết quả này được mô tả là thấp hơn 18% so với GPU A100 cấp máy chủ cao cấp nhất
  • So với llama.cpp, hệ thống nhanh hơn tối đa 11,69x trong khi vẫn giữ độ chính xác của mô hình
  • Trong demo, Falcon(ReLU)-40B-FP16 chạy trên một RTX 4090 24GB duy nhất cho thấy mức tăng tốc 11x so với llama.cpp
    • Cả PowerInfer và llama.cpp đều chạy trên cùng phần cứng và dùng hết VRAM của RTX 4090
  • Trong một đánh giá riêng với RTX 4090 24GB, mô hình ReLU FP16 và độ dài đầu vào 64, Falcon 40B đạt tăng tốc tối đa 11x, Llama 2 70B đạt tối đa 3x
  • Với RTX 2080Ti 11GB, mô hình ReLU INT4 và độ dài đầu vào 8, Falcon 40B đạt tăng tốc tối đa 8x, Llama 2 70B đạt tối đa 3x

Mô hình và nền tảng được hỗ trợ

Luồng cài đặt và chạy

  • Phụ thuộc khi build gồm CMake 3.17 trở lên, Python 3.8 trở lên và pip 19.3 trở lên
  • Bản build cho NVIDIA GPU dùng tùy chọn -DLLAMA_CUBLAS=ON
  • Bản build cho AMD GPU dựa trên ROCm/HIP, dùng -DLLAMA_HIPBLAS=ON và chỉ định AMDGPU_TARGETS
  • Cũng có thể build CPU-only
  • Lệnh suy luận cơ bản là chỉ định đường dẫn mô hình, số token đầu ra, số luồng và prompt cho file thực thi main
  • Giới hạn mức dùng GPU VRAM được chỉ định bằng tùy chọn --vram-budget
  • Serving, perplexity evaluation và batched generation của PowerInfer hỗ trợ các lệnh theo cùng cách với llama.cpp, nhưng tham số -ngl được thay bằng --vram-budget trong PowerInfer

Lượng tử hóa và tương thích

  • PowerInfer hỗ trợ tối ưu lượng tử hóa mô hình INT4 Q4_0
  • Có thể lượng tử hóa mô hình PowerInfer GGUF sang định dạng Q4_0 bằng file thực thi quantize
  • Dense inference mode được hỗ trợ hạn chế và có thể dùng theo cách tương tự llama.cpp
  • Dense inference mode không phải là chế độ tương thích cho mọi mô hình
    • ReluLLaMA và ProSparse có hàm kích hoạt đã thay đổi
    • Bamboo có kiến trúc mô hình đã thay đổi
  • PowerInfer cho biết vẫn có thể chạy với trọng số mô hình của llama.cpp để tương thích suy luận, nhưng sẽ không có cải thiện hiệu năng

Hạn chế và FAQ

  • Các mô hình hiện được hỗ trợ bị giới hạn ở những mô hình dùng hàm kích hoạt ReLU/ReGLU/Squared ReLU
  • Hiện chưa hỗ trợ Mistral, Llama gốc, Qwen, v.v.
  • Nếu xảy ra CUDA_ERROR_OUT_OF_MEMORY, có thể tạo lại chỉ mục GPU bằng --reset-gpu-index
  • Trong triển khai hiện tại, việc offload mô hình có thể không chính xác như kỳ vọng, nên có thể hạ nhẹ giá trị --vram-budget hoặc tắt offload FFN bằng --disable-gpu-index
  • PowerInfer giải thích rằng sự suy giảm chỉ số hiệu năng của các mô hình ReLU hiện tại, đặc biệt là mô hình 70B, là do chỉ fine-tune bằng 5B token, khác với khoảng 2T token cần thiết cho huấn luyện LLM thông thường

Cập nhật gần đây và kế hoạch

  • Ngày 5 tháng 1 năm 2026, PowerInfer công bố Tiiny AI Pocket Lab và cho biết có thể chạy GPT-OSS-120B int4 cục bộ ở 20 tokens/s
  • Ngày 27 tháng 7 năm 2025, PowerInfer công bố SmallThinker-21BA3B-Instruct và SmallThinker-4BA0.6B-Instruct
  • Ngày 11 tháng 6 năm 2024, PowerInfer giới thiệu framework suy luận tối ưu cho smartphone PowerInfer-2, cho biết đạt 11,68 tokens/s trên TurboSparse-Mixtral-47B
  • Cùng ngày, PowerInfer công bố Turbo Sparse, mô tả việc biến các mô hình Mistral và Mixtral thành độ thưa khoảng 90% và chỉ kích hoạt 4B tham số trong mô hình cấp Mixtral
  • Các hạng mục đã hoàn thành gồm công bố mã lõi PowerInfer, hỗ trợ Llama-2 và Falcon-40B, hỗ trợ Bamboo-7B, hỗ trợ Windows, công bố mã perplexity evaluation và hỗ trợ chia FFN online
  • Các hạng mục còn lại gồm hỗ trợ text-generation-webui, hỗ trợ Metal cho Mac, công bố mã mô hình OPT, công bố mã predictor training và hỗ trợ Multi-GPU

Bài báo và dự án nền tảng

  • Nội dung kỹ thuật chi tiết hơn được trình bày trong bài báo PowerInfer
  • PowerInfer sử dụng thư viện toán tử có thể chỉnh sửa của ggml và runtime thực thi của llama.cpp
  • THUNLP được nhắc đến trong phần hỗ trợ mô hình sparse dựa trên ReLU
  • PowerInfer cho biết dự án được truyền cảm hứng từ nghiên cứu Deja Vu

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-21
Ý kiến trên Hacker News

  • Trong phần lớn machine learning không có khái niệm nơ-ron hot/cold, nên mất một lúc mới hiểu được, và có vẻ bài báo cũng không định nghĩa trực tiếp
    Với ReLU, nếu đầu ra thường xuyên bằng 0 thì có thể xem là “cold”, nên nghe hợp lý, nhưng LLaMA gốc không dùng ReLU. Xem lại GitHub thì phương pháp này thực ra chỉ hoạt động với mô hình ReLU, và có nhóm đang “fine-tune” mô hình sang ReLU để có được tính thưa: https://huggingface.co/SparseLLM
    Vì vậy nó không áp dụng cho bất kỳ mô hình nào thường thấy trên Internet, nhưng bản thân tiến bộ này có vẻ rất lớn. Trong tương lai có thể sẽ chuyển sang sự đánh đổi giữa các mô hình lớn hơn và những hàm kích hoạt kém lý tưởng hơn; tôi cũng tò mò khi quy định của Mỹ/EU lấy FLOPs hoặc số tham số làm tiêu chí thì sẽ tính tính thưa như thế nào
    Với nghiên cứu về sau, có vẻ có thể giữ các hàm kích hoạt hiện có như SwiGLU của LLaMA, đồng thời dùng lượng tử hóa để định nghĩa vùng bão hòa thành các nơ-ron hot/cold

    • Tôi tò mò các quy định kiểu này xuất hiện khi nào và như thế nào. Việc khi phát triển còn phải để ý tới quy định về FLOPs/số tham số nghe khá kỳ lạ
    • README tuyên bố tương thích với LLaMA nhưng lại bỏ qua manh mối lớn rằng nó chỉ dành cho mô hình ReLU, đây là vấn đề khá nghiêm trọng
    • Trên https://huggingface.co/SparseLLM/ReluFalcon-40B cũng ghi “We utilize PowerInfer for inference”

  • Nếu có thể chạy Mixtral đã gỡ kiểm duyệt bằng cái này thì thật tuyệt. Trên RTX 4090 có thể sẽ lượng tử hóa được hơn 3-bit

    • Tôi thắc mắc vì sao lại bị downvote, vì LLM đã gỡ kiểm duyệt thường cho kết quả tốt hơn phiên bản bị “lobotomy” hoặc đã alignment, ít nhất là trên benchmark
    • Trong demo, họ chạy mô hình lớn hơn trên RTX 4090 VRAM 24GB. Việc triển khai kích hoạt thưa cho Mixture of Experts có thể không dễ, nhưng đây có vẻ là một hướng rất hay, có thể cho phép xử lý chỉ bằng CPU hoặc bằng GPU rẻ hơn nhiều
      Về mặt kỹ thuật Mixtral cũng đã có kích hoạt thưa do mạng nơ-ron điều khiển, nhưng như meme Inception, cần “đi sâu hơn nữa”
    • Dual GPU có thể xem là cấu hình consumer phổ thông, và hy vọng sẽ sớm được hỗ trợ. Ở 4-bit thì thậm chí còn đủ rộng rãi cho cả không gian ngữ cảnh
      Toàn bộ thứ này là một fork của llama.cpp, nên tôi kỳ vọng một ngày nào đó nó sẽ được đưa ngược lên dự án upstream
    • Trông ổn: https://www.youtube.com/watch?v=q2KpPUOsBCs

  • Nghe nói họ đang làm Mistral-7B, còn triển khai Mistral dành riêng cho GPU của tôi dùng hơn 5GB VRAM một chút: https://github.com/Const-me/Cgml
    Nó chạy khá tốt trên phần lớn GPU consumer, nhưng hiện chỉ hỗ trợ Windows

    • Trông khá thú vị. Tôi tò mò liệu nó có chạy được trên laptop Intel Core i7 không
    • Có thể thử dùng ollama. Nó dùng llmcpp và chỉ cần khoảng 4GB

  • Thật sự rất tuyệt. llama.cpp đúng là được yêu thích, nhưng cách offload sang GPU rời của nó tương đối đơn giản: xử lý prompt trên GPU và chia mô hình ở giữa
    Điều thú vị là tính thưa của kích hoạt đủ lớn để tận dụng được, còn theo góc nhìn machine learning truyền thống thì truy cập bộ nhớ thường được xem là rất ngẫu nhiên
    Hy vọng một ngày nào đó có thể offload các nơ-ron cold sang GPU tích hợp. Tôi cũng tò mò việc họ cân nhắc kernel Metal, vì tôi tưởng lợi ích hiệu năng đến từ pool bộ nhớ lai. Nếu không phải vậy thì có vẻ nó chỉ hữu ích cho các máy Mac AMD đời cũ, nhưng có thể tôi đang bỏ sót điều gì đó

    • Với Apple Silicon và Metal, có thể ý tưởng là đưa nơ-ron cold sang CPU/Accelerate, còn nơ-ron hot sang GPU để tận dụng cả hai
      Nếu đã dùng bộ nhớ hợp nhất và không có sao chép giữa GPU với CPU thì mức tăng tốc có thể nhỏ, nhưng nếu có thể tận dụng đồng thời nhiều chức năng hơn của chip thì sẽ tốt. Để tránh giảm hiệu năng do nhiệt, có lẽ chỉ nên dùng các lõi tiết kiệm điện, và Game Mode có lẽ cũng hoạt động theo kiểu đó

  • Trong triển khai này, có vẻ cần hiểu nhất định về chính mô hình để quyết định phần nào đặt trong bộ nhớ hệ thống và phần nào đặt trong bộ nhớ GPU
    Lý tưởng là có thể tính tự động được việc này hay không, hoặc liệu các mô hình trong tương lai có cung cấp giao diện để tự động hóa thuật toán bố trí kiểu này không. Nếu phải tinh chỉnh thuật toán cho từng kiến trúc mô hình thì việc bảo trì dự án này sẽ trở nên khá vất vả

    • Nhìn chung có vẻ đúng. Họ cung cấp script để kết hợp trọng số “Predictor” với mô hình gốc, nhưng trên trang đầu GitHub thì không thấy rõ cách tạo ra các trọng số đó
      Tăng tốc 10 lần thật sự ấn tượng. Nếu có thể tái hiện trên các mô hình khác, quá trình xác định nơ-ron hot/cold để tối ưu hóa inference có khả năng sẽ trở thành một phần thông thường trong phát triển mô hình

  • Phần quan trọng trong README đối với những người không trực tiếp thử nghiệm là thế này. PowerInfer đã được kiểm thử trên CPU x86-64 của Linux (AVX2), CPU x86-64 của Linux cùng GPU NVIDIA, và chip Apple M trên macOS
    Tuy nhiên họ nói chưa tối ưu cho Mac nên mức tăng hiệu năng hiện chưa lớn. Các tính năng sắp được bổ sung gồm mô hình Mistral-7B và backend inference thưa Metal cho macOS

    • Cũng đáng nhắc tới các mô hình llama2 có thể tải xuống và file convert.py

  • Phần tuyệt vời là họ đã thiết kế engine inference lai GPU-CPU bằng cách tận dụng phân bố “một số ít nơ-ron hot được kích hoạt nhất quán trên toàn bộ đầu vào, và nhiều nơ-ron cold thay đổi tùy theo đầu vào”
    Giải thích là nơ-ron hot được đưa sẵn lên GPU để truy cập nhanh, còn nơ-ron cold được tính trên CPU, nhờ đó giảm đáng kể yêu cầu bộ nhớ GPU và truyền dữ liệu CPU-GPU

  • Mọi người so sánh với llama.cpp vì đó là cách dễ nhất. Ai cũng cần biết rằng llama.cpp chậm. Nên so sánh với exllamav2 hoặc các bản triển khai được tối ưu hóa khác

    • Trong trường hợp này, vì mã đúng nghĩa là đã sửa từ llama.cpp nên so sánh với llama.cpp là hợp lý. Không chỉ ở mức dùng thư viện tính toán ma trận ggml, mà là một fork dùng nguyên main.cpp và mã llama.cpp thông thường, nên có thể so sánh trực tiếp
      https://github.com/ggerganov/llama.cpp/pull/4543 [Review] Merge PowerInfer with llama.cpp mainline #4543
      https://github.com/ggerganov/llama.cpp/discussions/4534#disc... Cũng có giải thích rằng “mức tăng tốc 11 lần hơi mang tính chọn lọc, vì mã GPU của llama.cpp cho Falcon 40B chưa được tối ưu tốt”
    • exllama không hỗ trợ ràng buộc ngữ pháp nên bị buộc phải dùng llama.cpp
      Hơn nữa, có vẻ exllama cũng có tác dụng phụ về mặt tính nhất quán: https://www.reddit.com/r/LocalLLaMA/comments/17w57eu/llm_for...
    • ExLlama không phải chỉ dành cho GPU thôi sao? Cải thiện tốc độ này là dành cho trường hợp sử dụng chia tải GPU+CPU
    • Nếu muốn gợi ý thứ gì nhanh hơn và có thể đóng gói phân phối cùng ứng dụng thì nên chọn gì, tôi cũng tò mò

  • Nếu có thể tạo tệp dự đoán độ thưa cho mô hình bất kỳ thì sẽ thật sự rất tuyệt. Hiện tại có vẻ chỉ áp dụng cho 4 mô hình mà họ đã xử lý
    Nhìn trang và mã thì có vẻ không bao gồm công cụ thực hiện bước đó. Trước mắt tôi sẽ chờ thêm, và hy vọng các tính năng này cuối cùng sẽ được merge trở lại thành tùy chọn của llama.cpp. Cái này không chỉ dùng thư viện ma trận ggml, mà dựa trên codebase llama.cpp thông thường

  • Chỉ nhìn cụm “GPU cấp tiêu dùng” thì có vẻ có thể chạy trên nhiều mẫu GPU, nhưng như các bài kiểu này thường gặp, tôi tự hỏi liệu thực tế có phải chỉ dành cho RTX 4090 không

    • Tôi không nghĩ ra điểm nào đặc biệt chỉ dành cho 4090. Thường điều quan trọng là VRAM, nên nếu cần 24GB thì 3090 cũng được, và hai card 12GB cũng là một lựa chọn
      Bản thân kỹ thuật này là một phương pháp tổng quát giúp chạy mô hình lớn hơn trên GPU nhỏ hơn, đồng thời cải thiện đáng kể hiệu năng CPU offloading. Không chỉ có ví dụ chạy mô hình lớn nhất ở fp16 trên 4090; ngay cả khi chạy cùng mô hình đó với lượng tử hóa 4-bit trên 2080Ti, cũng cho thấy mức tăng tốc khoảng 3 lần theo chuẩn LLaMA
      Vì vậy trên desktop, mô hình 33B có thể sẽ trở thành mặc định mới, và nhiều khả năng chỉ cần một chiếc 3090 hoặc 4090 là có thể chạy 70B ở tốc độ chat thời gian thực