KVSplit - Chạy context dài hơn 2–3 lần trên Apple Silicon

 (github.com/dipampaul17)
1 điểm bởi GN⁺ 2025-05-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • KVSplit là dự án nhằm chạy context dài hơn và các mô hình nặng hơn trong cùng ngân sách bộ nhớ trên Apple Silicon bằng cách áp dụng độ chính xác lượng tử hóa khác nhau cho key và value trong KV cache attention của LLM
  • Kết quả cốt lõi là cấu hình K8V4: ở mức 8K token, giảm từ 176.00MB FP16 xuống 71.50MB, tăng tốc độ xử lý token từ 54.360 tokens/sec lên 57.438 tokens/sec, với thay đổi perplexity được đưa ra là +0,86%
  • Dựa trên kết quả rằng key nhạy với lượng tử hóa hơn value, dự án tổng kết rằng K4V8, dù dùng cùng tổng số bit với K8V4, gây suy giảm chất lượng lớn hơn khoảng 7 lần so với K8V4
  • Các tính năng được cung cấp bao gồm áp dụng patch cho llama.cpp, build hỗ trợ Metal, benchmark bộ nhớ/tốc độ/perplexity, lưu kết quả CSV/JSON, công cụ trực quan hóa, và chụp mức giảm bộ nhớ dựa trên Activity Monitor
  • Cấu hình khuyến nghị là K8V4 để cân bằng giữa chất lượng và tiết kiệm bộ nhớ; nếu cần tiết kiệm bộ nhớ tối đa, có thể chọn K4V4 với mức giảm 72% và chấp nhận tổn thất chất lượng khoảng 6%

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

  • KVSplit là dự án nhằm giảm bộ nhớ KV cache khi suy luận LLM trên máy Mac Apple Silicon
  • Dự án áp dụng độ chính xác lượng tử hóa khác nhau cho key và value trong KV cache của cơ chế attention
  • Mục tiêu như sau
    • Giảm tối đa 72% mức sử dụng bộ nhớ
    • Chạy context dài hơn 2–3 lần trong cùng ngân sách bộ nhớ
    • Duy trì hoặc cải thiện tốc độ suy luận so với FP16
    • Cung cấp hỗ trợ Metal được điều chỉnh cho Apple Silicon

Kết quả benchmark chính

  • Kết quả theo từng cấu hình ở mức 8K token như sau
    • FP16: 176.00MB, 54.360 tokens/sec
    • K8V8: 93.50MB, 51.503 tokens/sec, perplexity +0,03%
    • K8V4: 71.50MB, 57.438 tokens/sec, perplexity +0,86%
    • K4V8: 71.50MB, 58.690 tokens/sec, perplexity +6,06%
    • K4V4: 49.50MB, 55.193 tokens/sec, perplexity +6,15%
  • Trong bảng tiết kiệm bộ nhớ, K8V4 được trình bày là giảm 59% ở mức 8K token, còn K4V4 là giảm 72%
  • Trong bảng hiệu năng, K8V4 cho thấy tốc độ tăng +5,7% so với FP16, K4V8 tăng +8,0%, K4V4 tăng +1,5%
  • K8V8 giảm bộ nhớ so với FP16 nhưng tốc độ thấp hơn -5,3%

Mức sử dụng bộ nhớ theo độ dài sequence

  • Context càng dài, hiệu quả tiết kiệm bộ nhớ KV cache càng lớn
  • Mức sử dụng bộ nhớ ở 8192 token như sau
    • FP16: 176.00MB
    • K8V8: 93.50MB
    • K8V4: 71.50MB
    • K4V8: 71.50MB
    • K4V4: 49.50MB
  • Ở mức 4096 token, so với 88.00MB của FP16, K8V4/K4V8 dùng 35.75MB, còn K4V4 dùng 24.75MB
  • Ở mức 128 token, các con số được đưa ra là FP16 5.50MB, K8V4/K4V8 2.23MB, K4V4 1.55MB

Tính bất đối xứng giữa key và value

  • Bộ nhớ KV cache chủ yếu bị chi phối bởi việc lưu vector key và vector value của từng token
  • Quan sát cốt lõi của dự án là key nhạy với lượng tử hóa hơn value rất nhiều
  • K8V4 dùng key 8-bit và value 4-bit, cung cấp điểm cân bằng sau
    • Suy giảm perplexity 0,86% so với FP16
    • Tiết kiệm bộ nhớ 59%
    • Tốc độ suy luận nhanh hơn FP16
  • K4V8 dùng cùng tổng số bit với K8V4, nhưng được tổng kết là có mức suy giảm chất lượng lớn hơn khoảng 7 lần so với K8V4
  • Dự án giải thích rằng nhờ tính bất đối xứng này, có thể chạy context dài hơn và mô hình lớn hơn trên consumer hardware

Cài đặt và cách tích hợp

  • Cài đặt bằng cách clone repository rồi chạy scripts/install_kvsplit.sh
git clone https://github.com/dipampaul17/KVSplit.git
cd kvsplit

chmod +x scripts/install_kvsplit.sh
./scripts/install_kvsplit.sh
  • Script cài đặt cho phép chọn cách thiết lập môi trường Python
    • Virtual Environment: tạo môi trường Python độc lập trong thư mục dự án
    • System Python: dùng bản cài đặt Python hiện có
    • Skip Python Setup: người dùng tự quản lý môi trường Python
  • Cũng có thể chọn cách tích hợp llama.cpp
    • Cách tiêu chuẩn: clone llama.cpp và áp dụng patch KV split
    • Cách Git submodule: thêm llama.cpp làm submodule cho nhà phát triển hoặc người dùng nâng cao
  • Quá trình cài đặt bao gồm thiết lập llama.cpp hỗ trợ Metal cho Apple Silicon, bật differentiated KV cache quantization, tùy chọn tải mô hình thử nghiệm, và thiết lập công cụ trực quan hóa

Ví dụ sử dụng và tùy chọn CLI

  • Có thể chạy so sánh nhanh bằng mô hình GGUF mà người dùng có
python scripts/quick_compare.py --model models/your-model.gguf
  • Các đối tượng so sánh là FP16, K8V8, K8V4, K4V8, K4V4, đồng thời hiển thị các chỉ số bộ nhớ, tốc độ và chất lượng
  • Ví dụ chạy trong README dùng --flash-attn cùng các tùy chọn lượng tử hóa KV với llama-cli
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq 8
  • Ví dụ K4V8 chỉ định riêng số bit cho key và value
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq-key 4 --kvq-val 8
  • Ví dụ context 32K được trình bày là cần khoảng 1,4GB với FP16 và khoảng 400MB với K8V4
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf \
  -c 32768 -n 4096 -t 8 --flash-attn --kvq 8 \
  -f your-long-document.txt
  • Các flag CLI chính như sau
    • -t 8: số luồng, khuyến nghị 8 trên hầu hết chip Apple Silicon
    • --flash-attn: bật attention tối ưu hóa, khuyến nghị trên Apple Silicon
    • --kvq N: thiết lập bit cho key và value
    • --kvq-key N: chỉ thiết lập bit cho key
    • --kvq-val N: chỉ thiết lập bit cho value
    • -c N: kích thước context
    • -n N: số token sẽ sinh
    • -f FILE: tệp đầu vào
    • -m MODEL: đường dẫn tệp mô hình .gguf

Công cụ benchmark và trực quan hóa

  • Benchmark đầy đủ chạy bằng scripts/benchmark_kvsplit.py
python scripts/benchmark_kvsplit.py
python scripts/benchmark_kvsplit.py --config K8V4 --seq-len 4096
  • Trực quan hóa được tạo bằng scripts/visualize_results.py
python scripts/visualize_results.py
  • Benchmark đo các mục sau
    • Memory Usage: bộ nhớ VRAM và KV cache
    • Performance: tokens/sec theo độ dài sequence
    • Quality: perplexity bằng llama-perplexity
    • Scaling: thay đổi bộ nhớ và hiệu năng theo độ dài sequence
  • Kết quả được lưu ở định dạng CSV/JSON, đồng thời tạo thống kê tóm tắt và biểu đồ trực quan hóa tự động
  • capture_memory.sh là công cụ chụp mức tiết kiệm bộ nhớ trong Activity Monitor

Tối ưu hóa và giới hạn trên Apple Silicon

  • KVSplit được tối ưu hóa cho Metal framework của Apple
  • Dự án nhấn mạnh hiệu quả bộ nhớ trên các thiết bị bị giới hạn bộ nhớ như Apple Silicon M series
  • README cho biết mức tiết kiệm bộ nhớ thực tế có thể hơi khác so với tính toán lý thuyết do 256B page alignment của llama.cpp
  • Đối tượng hỗ trợ bao gồm các chip M1, M2, M3, M4

Cấu hình khuyến nghị và lộ trình

  • Cấu hình khuyến nghị là K8V4
    • key 8-bit, value 4-bit
    • tiết kiệm bộ nhớ 59%
    • tổn thất chất lượng 0,86%
    • tốc độ suy luận +5,7% so với FP16
  • Mức tiết kiệm bộ nhớ tối đa là K4V4
    • key 4-bit và value 4-bit
    • tiết kiệm bộ nhớ 72%
    • tổn thất chất lượng khoảng 6%
    • được trình bày là phù hợp với các ứng dụng ít nhạy cảm hơn
  • Với context rất dài, K8V4 hoặc K4V4 được khuyến nghị; context càng dài thì mức tiết kiệm bộ nhớ càng tích lũy
  • Kế hoạch tương lai như sau
    • Adaptive Precision dựa trên độ quan trọng của token
    • Layer-Specific Quantization dùng độ chính xác khác nhau theo từng layer
    • Tối ưu hóa theo từng mô hình cho Mistral, Phi-3, v.v.
    • Demo web
    • Hỗ trợ iOS và iPadOS
  • Giấy phép là MIT, và dự án nhận đóng góp qua issue hoặc pull request

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-18
Các ý kiến trên Hacker News

  • Thú vị. Tôi tò mò liệu có trực giác nào giải thích vì sao lại có kết quả như vậy không. Cũng muốn biết liệu phát hiện này đến từ trực giác đó, hay được tìm ra qua thử nghiệm ngẫu nhiên
    Có vẻ bước "apply patch" trong script cài đặt vẫn còn placeholder. Thay vì bắt người dùng git clone rồi áp dụng patch, có lẽ sẽ thân thiện hơn nếu fork llama.cpp và đưa nó vào dưới dạng Git submodule
    Ngoài ra, vì thiết lập Python cục bộ của mỗi người rất khác nhau, sẽ tốt hơn nếu tách phần liên quan đến llama.cpp và phần liên quan đến Python, thay vì cố định phụ thuộc vào Homebrew Python

    • Câu hỏi về trực giác rất hay. Sự khác biệt đến từ vai trò cốt lõi mà từng thành phần đảm nhận trong attention
      Key quyết định nên chú ý tới token nào, và tạo ra pattern attention thực tế thông qua tính toán độ tương đồng. Value chỉ lưu thông tin sẽ được truyền đi sau khi attention đã được quyết định
      Nếu lượng tử hóa vector key quá mạnh tay, phép tính độ tương đồng của mọi tương tác giữa các token sẽ bị méo. Một sai số nhỏ ở key có thể khiến attention chuyển sang token hoàn toàn sai
      Value dễ chịu hơn nhiều. Sai số lượng tử hóa vector value chỉ ảnh hưởng đến nội dung thông tin của riêng token đó sau khi pattern attention đã được xác định
      Nó giống khác biệt giữa hệ thống mục lục thư viện và chính các cuốn sách. Nếu số mục lục (key) bị hỏng, bạn sẽ nhìn vào một kệ hoàn toàn sai; nhưng nếu một vài từ trong sách (value) bị nhòe, bạn vẫn đang đọc đúng cuốn sách và chỉ thỉnh thoảng có nhiễu
      Về mặt toán học, key đi vào phép tính softmax, nên sai số nhỏ sẽ được khuếch đại theo hàm mũ trong quá trình chuẩn hóa. Value chỉ đi qua phép trung bình có trọng số tuyến tính, nên sai số có xu hướng triệt tiêu lẫn nhau
      Ban đầu tôi biết đến tính bất đối xứng này qua các bài như "More for Keys, Less for Values", "KV-AdaQuant", và muốn định lượng chính xác nó có ảnh hưởng ra sao trong suy luận trên Apple Silicon. Điều gây ấn tượng là với cùng lượng bộ nhớ, chênh lệch chất lượng giữa K8V4 và K4V8 là 7 lần
      Cảm ơn cả góp ý về cài đặt; tôi dự định sửa placeholder và làm cho phụ thuộc Python linh hoạt hơn
    • Patch thực ra không được áp dụng vào llama.cpp. Lý do là phần phân tích tham số đã được chuyển sang arg.cpp từ 8 tháng trước
      Dù vậy cũng không sao, vì các tùy chọn để thiết lập lượng tử hóa K và V đã được thêm vào llama.cpp từ năm 2023
      Tôi không hiểu vì sao patch này tồn tại. Ngoài việc đổi một thiết lập vốn đã có sẵn thành tham số dòng lệnh khác để trông có vẻ mới mẻ, tôi không thấy lý do nào
      Tôi thực sự khuyên mọi người đừng chạy file install.sh trong repo mới kiểu này. Đặc biệt khi nó không cần thiết cho một việc đơn giản như áp dụng một file patch

  • Cái này khác gì so với dùng --cache-type-k và --cache-type-v?

    • Không. Trông giống một nỗ lực do LLM tạo ra để kiếm star trên GitHub
      Tôi đã ghi một số điểm kỳ lạ khác của repo trong bình luận khác
    • Tôi đoán là hơi khác. MLX/MPS không có hỗ trợ 4-bit native, và nếu tôi nhớ đúng thì có thể cũng không có 8-bit. Khi mới ra mắt, nó còn chưa hỗ trợ bf16
      Vì vậy với cách type_k/v cũ, mức thấp nhất có thể xuống trên Apple GPU có lẽ là f16/bf16 16-bit. Tuy nhiên tôi không phải chuyên gia nội bộ của llama.cpp nên cũng có thể sai

  • Tôi tò mò liệu có thể làm patch này trong MLX không. MLX đang cho tốc độ tốt hơn, nên nếu kết hợp với cách tiếp cận này thì người dùng Mac có thể trò chuyện dài với tốc độ chấp nhận được

    • Có lẽ là được, nhưng hiện tôi đang đào khá sâu vào MLX và nhận ra rằng dù đây là một framework được thiết kế tốt, độ trưởng thành của nó vẫn thấp hơn nhiều so với mức có thể lấy ngay code ví dụ mà ai đó đã benchmark sẵn là "cách tốt nhất"
      Cá nhân tôi kỳ vọng nhất, nghe khó tin nhưng là binding Haskell. Vài ngày trước có người chỉ ra rằng lazy evaluation của Haskell khá hợp với paradigm này, và cách tiếp cận gần như thuần hàm đối với compile graph cũng hữu ích. Làm machine learning trong Haskell có vẻ sẽ rất thú vị

  • Tôi tò mò liệu lượng tử hóa KV khác biệt (ví dụ K8V4) có thể áp dụng cho các model đã được chuyển sang định dạng .gguf không. Hay phải build lại model với hỗ trợ đặc biệt?
    Nếu tương thích với bất kỳ file .gguf nào thì tôi cũng muốn biết có giới hạn nào về loại model (Mistral, Phi-3, v.v.) hay thiết lập tokenizer không

    • Có thể. Một trong những ưu điểm chính của KVSplit là có thể dùng nguyên các model .gguf hiện có mà không cần tái cấu trúc hay chuyển đổi đặc biệt. Lượng tử hóa diễn ra trên KV cache lúc chạy, chứ không phải trong quá trình load hay chuyển đổi model
      Điều này khả thi vì KV cache được tạo ra trong quá trình suy luận khi xử lý token, và hoàn toàn tách biệt với trọng số model. Các flag --kvq-key và --kvq-val chỉ cho llama.cpp biết cách lưu các tensor trung gian này trong bộ nhớ
      Đã thử nghiệm thành công với Llama-3, Mistral, Phi-2/Phi-3, TinyLlama và các biến thể Qwen
      Giới hạn duy nhất là cần backend Metal của llama.cpp, và hiện tại triển khai Flash Attention của llama.cpp bỏ qua định dạng KV cache tùy chỉnh, nên phải tắt Flash Attention bằng -fa 0. Bản thân kỹ thuật này sẽ hoạt động với bất kỳ kiến trúc transformer nào dùng cơ chế attention tiêu chuẩn

  • Tôi đã có thời gian đọc mã. Nếu tôi hiểu đúng PR này thì bản vá là không cần thiết, vì chức năng này đã có trong llama.cpp từ năm 2023: https://github.com/ggml-org/llama.cpp/pull/4312
    Thay vì cung cấp một fork của llama.cpp đã áp dụng thay đổi dưới dạng commit, kho này bắt chạy script install.sh. Script này checkout nhánh master của llama.cpp mà không chỉ định revision, rồi áp dụng một bản vá ngắn. Chỉ riêng điều đó đã là một tín hiệu cảnh báo gì đó bất thường
    Trong kho có 4 file patch khác nhau, và trong script cài đặt còn có thêm một phiên bản patch nữa được nhúng bằng Heredoc. Trong script cũng có hai phiên bản mã để clone kho và thử áp dụng patch
    install.sh ghi đè một file patch bằng file patch khác qua dòng cp patch/split_kv_quant.diff patch/fixed_kv_patch.diff. Vì vậy fixed_kv_patch.diff được check-in trong kho sẽ bị ghi đè trước khi được áp dụng
    Theo tôi thấy, có vẻ ban đầu họ định dùng bản vá này: https://github.com/dipampaul17/KVSplit/blob/main/patch/split... (Sửa: xem bình luận ở cuối thì thực ra có vẻ là bản này: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... )
    Thứ bản vá này thêm vào chỉ là tham số --kvq để đặt lượng tử hóa K và V cùng lúc, trong khi ngay phía trên đã có sẵn các tham số tích hợp để đặt lượng tử hóa K và V riêng lẻ. Trong lúc chuyển qua chuyển lại các bản vá này, lẽ nào tác giả lại không nhận ra chức năng đó đã tồn tại?
    Tôi thực sự khuyên không nên chạy shell script từ những kho mới như thế này. Đặc biệt là với một script phức tạp như vậy
    Bài trên HN đã nhận hơn 200 lượt upvote và kho GitHub cũng đã có hơn 200 sao, vẫn đang tăng, nhưng nội dung có vẻ gây hiểu lầm. Một bình luận trong thread này chỉ ra vấn đề và bị gắn rất nhiều flag thực ra lại đúng. Việc tác giả vẫn tiếp tục trả lời trong thread này nhưng né câu hỏi rằng chức năng đó đã tồn tại cũng đáng lo ngại
    Sửa: Tôi đã đọc nhầm shell script. Thực ra có vẻ nó áp dụng bản vá này: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... Sau khi áp dụng patch, một cách kỳ lạ nó lại ghi đè fixed_kv_patch.diff bằng split_kv_quant.diff, nhưng sau đó không làm gì nữa. Tôi không biết đây là kết quả của vibe coding hay chỉ là chỉnh sửa mã cẩu thả, nhưng tôi muốn nhắc lại rằng không nên chạy những shell script kiểu này từ một kho lạ
    Sửa 2: Còn rối hơn nữa. Script install.sh tham chiếu URL cũ của kho llama.cpp (https://github.com/ggerganov/llama.cpp), URL này đã đổi từ lâu và hiện chỉ redirect. Các bản vá cố sửa phần phân tích tham số trong common.cpp, nhưng mã đó đã được chuyển sang arg.cpp từ 8 tháng trước (https://github.com/ggml-org/llama.cpp/commit/bfe76d4a17228bf...). Vậy script cài đặt và kho này dựa trên mã khoảng năm 2024, nhưng lại dùng một tùy chọn đã được thêm vào llama.cpp khoảng năm 2023. Rốt cuộc chuyện gì đang xảy ra?

    • Đúng vậy. Có thể tôi đã bỏ sót điều gì đó và tác giả có thể chỉ ra ở đây, nên tôi đã không nói thêm các phần đáng ngờ khác
      Có rất nhiều tín hiệu cảnh báo. Nhìn tích cực nhất thì trông giống một người đang dùng mã do LLM tạo để thổi phồng hồ sơ GitHub. Chỉ cần xem hoạt động ngày 12 tháng 5 trên hồ sơ đó là đủ
    • Cuối cùng cũng có nội dung hợp lý. Chỉ riêng việc dự án này hoạt động bằng cách áp dụng patch thay vì fork dự án gốc rồi commit thay đổi đã đủ là lý do để lo ngại
      Nhưng toàn bộ hoạt động GitHub của tác giả bài gốc đều đáng ngờ. Ngày 12 tháng 5, họ đã gửi PR hỗn tạp do LLM tạo tới nhiều dự án phổ biến, và chỉ phía JAX từ chối. Dù vậy, nhờ đó họ vẫn có thể ghim các dự án nổi tiếng lên hồ sơ như thể mình là người đóng góp
      Thật khó diễn tả bằng lời mức độ đáng ghét của chuyện này. Bất kỳ ai làm trong lĩnh vực AI cũng đang đồng lõa với ô nhiễm thông tin, và hậu quả của nó thậm chí còn chưa thể dự đoán. Internet chết và cơn lũ nội dung hỗn tạp AI mới chỉ là khởi đầu

  • Trên Apple Silicon 64GB hoặc 128GB, những thứ này có nhanh hơn hoặc tốt hơn đáng kể so với 36GB hay 48GB không?
    Tôi từng đọc rằng context lớn và model lớn vẫn chậm đến mức khó chịu ngay cả trên Apple Silicon nhanh nhất và lớn nhất có thể mua được bằng tiền
    Vì vậy tôi thắc mắc liệu thứ này có giúp tận dụng tốt hơn bộ nhớ lớn hơn không, hay trên thực tế với Apple Silicon thì các model tương đối nhỏ vẫn là câu trả lời

    • Mức tiết kiệm bộ nhớ của KVSplit tăng theo độ dài context, nên các máy Mac RAM dung lượng cao như 64GB/128GB hưởng lợi lớn hơn theo giá trị tuyệt đối. Với Mac Studio 128GB, về tiềm năng có thể xử lý cả cửa sổ context hàng trăm nghìn token
      Tuy nhiên KVSplit không thay đổi căn bản tốc độ tính toán, mà chỉ thay đổi hiệu quả bộ nhớ. Trong benchmark, K8V4 cải thiện throughput 14,5%, nhưng điều này đến từ việc cải thiện tính cục bộ bộ nhớ chứ không phải giảm khối lượng tính toán
      Lý do chính khiến model lớn trên Apple Silicon “chậm đến khó chịu” không phải là giới hạn bộ nhớ mà là giới hạn hiệu năng tính toán. Model 70B tham số sẽ chạy với tốc độ sinh token tương tự bất kể RAM khả dụng hay tối ưu KV cache
      KVSplit giúp dùng bộ nhớ khả dụng tốt hơn. Nó đặc biệt có giá trị khi nút thắt là độ dài context chứ không phải kích thước model
      Với cách dùng Apple Silicon thực tế, điểm cân bằng vẫn là gắn cửa sổ context mở rộng cho các model nhỏ hơn (7B~13B). Như vậy có thể xử lý nhiều văn bản hơn đáng kể trong khi vẫn giữ tốc độ sinh hợp lý
      Nếu workflow cần cả context khổng lồ lẫn model lớn, bạn vẫn nên cân nhắc GPU cấp server, nhưng KVSplit đẩy phạm vi có thể làm được trên phần cứng Apple xa hơn một chút

  • Đây là một công trình tuyệt vời và trông rất thú vị, nhưng để hiểu được thì cần thêm một chút giải thích ở mức cao hơn
    Ví dụ, nó có giúp chạy một model có cửa sổ context 2048 token với cửa sổ context 4~6K không? Hay giúp chạy model 128K như gemma3 với cửa sổ context từ 256K trở lên?
    Use case lý tưởng cho model local là gì?

    • Thiết lập K8V4 tiết kiệm 59% bộ nhớ, nên trên cùng phần cứng về cơ bản có thể chạy context dài hơn 2,4 lần. Model context 2048 token có thể xử lý khoảng 5000 token, còn model context 8K có thể lên tới khoảng 19,5K
      Trên thực tế, điều đó có nghĩa là bạn có thể xử lý cả một cuốn sách cùng lúc trên MacBook, phân tích codebase lớn mà không cần chia nhỏ file, hoặc giữ lịch sử hội thoại dài trong ứng dụng chat
      Mức tiết kiệm bộ nhớ tỷ lệ tuyến tính với độ dài context. Cửa sổ context càng dài thì lượng bộ nhớ tiết kiệm tuyệt đối càng lớn. Trên M4 MacBook của tôi, với context 8K, KV cache giảm từ 176MB xuống 72MB. Với context 128K, mức tiết kiệm cùng tỷ lệ sẽ giải phóng bộ nhớ ở mức gigabyte
      Tối ưu này có giá trị nhất khi bạn chạm giới hạn cửa sổ context thay vì giới hạn tham số model. Nếu lỗi thiếu bộ nhớ xảy ra do input dài chứ không phải do trọng số model lớn, KVSplit giải quyết trực tiếp nút thắt đó
    • Nó giảm mức sử dụng bộ nhớ của một model cụ thể. Dùng phần dư đó thế nào là do người dùng quyết định
      Việc tăng cửa sổ context sau khi huấn luyện không đơn giản, nên nếu không biết chính xác mình đang làm gì, tốt hơn là tìm model đã được huấn luyện với cửa sổ context lớn hơn
      Model local có nhiều mục đích như làm việc offline, quyền riêng tư/bảo mật, v.v. Tuy nhiên phần lớn thường dùng để thử nghiệm bằng cách tinh chỉnh model

  • Có chuyện kỳ lạ đang xảy ra, nên tốt nhất là đừng cài cái này hoặc chạy script kia
    Tôi đã flag bài đăng

  • Ý tưởng và thử nghiệm rất hay. Cái này có áp dụng được cho GPU không? Và có vẻ cũng tương thích với các kỹ thuật lượng tử hóa khác, có phải nên hiểu là mỗi cái có lẽ cần patch riêng không?

    • Đúng vậy. Cách tiếp cận này rất có khả năng cũng khả thi trên GPU NVIDIA/AMD. Nguyên lý cơ bản rằng key cần độ chính xác cao hơn value là độc lập với phần cứng
      Backend CUDA của llama.cpp đã hỗ trợ thiết lập kiểu cache riêng bằng các flag --cache-type-k và --cache-type-v. Bản patch cụ thể này tập trung vào tối ưu riêng cho Metal, nhưng kỹ thuật cốt lõi có thể chuyển sang nguyên vẹn
      Nó cũng tương thích với các phương pháp lượng tử hóa khác. Tối ưu KV cache này bổ sung cho lượng tử hóa trọng số model (Q4_K_M, GPTQ, AWQ, v.v.). Có thể dùng độ chính xác KV cache bất đối xứng cùng với bất kỳ định dạng trọng số model nào
      Lượng tử hóa KV cache diễn ra tại thời điểm chạy trong quá trình xử lý token và tách biệt với trọng số model, nên không xung đột với việc bản thân model đã được lượng tử hóa như thế nào. Chúng hoạt động ở các phần khác nhau của pipeline suy luận
      Phần cần thêm công việc là tích hợp với các engine suy luận chuyên biệt có xử lý KV cache tùy chỉnh như vLLM hoặc TensorRT-LLM. Mỗi engine sẽ phải triển khai riêng độ chính xác KV bất đối xứng
      Lợi ích tức thì nhất trên GPU có lẽ sẽ đến từ việc tích hợp trực tiếp nhận định này vào các triển khai FlashAttention. Trên phần cứng CUDA, giảm băng thông bộ nhớ có thể dẫn đến mức tăng tốc lớn hơn

  • Với kích thước context nhỏ mà perplexity +0,86% thì chẳng phải là khá lớn sao? Còn ở các kích thước context thực tế hơn như 64~128K thì thế nào?

    • Điểm chính có vẻ là giảm mức dùng bộ nhớ. Nó cho phép chạy context dài hơn vốn trước đây là không thể trong cùng lượng bộ nhớ giới hạn
      Hoặc cũng có thể dùng phần bộ nhớ dư cho các mục đích khác như IDE