Chạy Kimi K3 ở 0.50 tok/s với 29GB RAM

 (github.com/sqliteai)
1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • WASTE là một engine suy luận viết bằng C, chuyển mô hình open-weight Kimi K3 đầy đủ với 2,78 nghìn tỷ tham số thành container 982GiB không cắt giảm để chạy trên laptop phổ thông
  • Chỉ giữ trunk thường trú của mô hình trong bộ nhớ, còn khoảng 4% trọng số expert được kích hoạt theo từng token sẽ được đọc từ NVMe, và phần RAM còn lại được dùng làm cache expert có kích thước giới hạn
  • Kimi K3 có thể mở với tối thiểu 29,05GB RAM ở ngữ cảnh 4K, nhưng cấu hình thực dụng là ngân sách 46GB trên MacBook Pro 64GB, nơi đạt 0.45~0.62 tok/s
  • Chồng lấp việc đọc expert với tính toán để cải thiện khoảng 1,6 lần, và chạy router của tầng kế tiếp sớm hơn một residual để nâng tỷ lệ cache hit từ 14% lên 38% mà không thay đổi tổng lượng đọc hay logits
  • Có thể chạy mô hình cực lớn cục bộ mà không cần kết nối Internet, không tốn chi phí theo token và không truyền dữ liệu ra ngoài, nhưng cần NVMe nội bộ và khoảng 1TB dung lượng lưu trữ; nếu ngân sách RAM vượt 52GB thì có thể chậm đi mạnh do paging của hệ điều hành

Mục tiêu và hình thức triển khai của WASTE

  • WASTE(Weight-Aware Streaming Tensor Engine) là một engine suy luận C có thể nhúng, không có phụ thuộc runtime bên ngoài
    • Chỉ dùng libwaste.a và file thực thi waste, không cần BLAS, CUDA, ONNX hay Python ngoài libc và pthreads
    • Python chỉ được dùng cho chuyển đổi mô hình và kiểm chứng tham chiếu PyTorch, không nằm trong đường suy luận
    • API công khai gồm 26 hàm, hỗ trợ mở mô hình, đặt giới hạn RAM, sinh đầu ra, lưu session và thoát
  • Đối tượng kiểm chứng hiện tại là toàn bộ mô hình Kimi K3 2.78T
    • Bản gốc công khai là 1.42TB, container sau chuyển đổi là 982GiB
    • Không phải bản chưng cất, cắt tỉa hay thu nhỏ
    • Kimi-Linear 48B cũng dùng cùng engine và định dạng, với container 19GiB, tối thiểu 1.87GB RAM và đạt 10.7 tok/s
  • Tên dự án xuất phát từ mục tiêu giảm tình trạng những mô hình có thể chạy trên phần cứng để bàn lại bị đưa lên trung tâm dữ liệu đám mây, nơi tiêu tốn cả chi phí token lẫn điện năng

Kiến trúc streaming từ đĩa

  • Với kiến trúc Mixture of Experts, K3 chỉ kích hoạt khoảng 4% mô hình cho mỗi token, nên không cần giữ thường trú các trọng số không hoạt động trong RAM mà chỉ cần bố trí để truy cập khi cần
  • Container .waste gồm manifest JSON, trunk thường trú và các bank expert theo từng tầng
    • Mỗi bản ghi expert được căn chỉnh 4KiB
    • Các ma trận gate·up·down được đặt liền kề để một expert được đọc bằng đúng một lần pread
    • Page cache được bỏ qua bằng F_NOCACHE trên macOS, O_DIRECT trên Linux và FILE_FLAG_NO_BUFFERING trên Windows
  • Nếu không bỏ qua page cache, các container thử nghiệm nhỏ hơn RAM có thể bị hệ điều hành cache, tạo ra tỷ lệ hit không thể tái hiện với mô hình 982GiB
  • Khi đọc bản ghi, luôn kiểm tra magic, ID expert và phạm vi offset để tránh việc bank bị cắt hoặc ghép sai trả về trọng số sai
    • Kiểm tra crc32 của payload được bật bằng --verify
    • Chi phí kiểm chứng khoảng 5% trên Kimi-Linear và khoảng 1% trên K3, mặc định là tắt
    • Khuyến nghị kiểm chứng một lần với container đã sao chép, tải xuống hoặc đặt trên ổ đĩa không đáng tin cậy
    • Trunk và codebook không có checksum

Đọc trước và dự đoán router

  • Khi router của một tầng quyết định 16 ID expert, mỗi lần đọc sẽ được gửi như một luồng riêng, và việc tính toán tiêu thụ dữ liệu ngay khi dữ liệu đến
    • Việc chồng lấp giữa đọc và tính toán cải thiện khoảng 1,6 lần trên K3
    • Khối lượng công việc và thống kê cache giữ nguyên trước và sau khi bật tính năng
  • Trước khi hidden state thực tế của tầng kế tiếp được tạo ra, router kế tiếp đang thường trú sẽ được chạy bằng hidden state hiện tại để nạp trước 6 expert
    • Dự đoán sớm một residual đạt độ chính xác 92% ở rank 1 và 81% ở top 6
    • Router thực tế vẫn quyết định expert cuối cùng nên đầu ra được giữ nguyên chính xác
    • Tỷ lệ demand hit tăng từ 14% lên 38%, và tổng số byte đọc không thay đổi
    • Có thể tắt bằng WASTE_LOOKAHEAD=0
  • Phần triển khai áp dụng kỹ thuật tương tự cho prefill đã bị loại bỏ
    • Tầng decode chiếm 16 slot cache nhưng tầng chunk chiếm khoảng 550 slot
    • Các bản ghi đọc trước bị đẩy ra trước khi được dùng, làm lượng đọc tăng 6,9% và thời gian không giảm

Lượng tử hóa và độ chính xác

  • Trọng số expert được lưu bằng lượng tử hóa vector phần dư 3 tầng với codebook 256 phần tử cho vector 8 chiều, dùng 3,00 bit mỗi trọng số
    • Không phục hồi toàn bộ ma trận mà tạo bảng tích vô hướng từng phần, rồi xử lý mỗi hàng bằng 3 lần tra bảng và 2 phép cộng
  • Trunk giữ ở 4 bit và 8 bit
    • Vì mô hình chỉ được huấn luyện nhận biết lượng tử hóa trên expert, trunk 3 bit làm đầu ra sụp đổ
    • Dự đoán cache đúng nhưng throughput cũng không cải thiện nên đã bị loại bỏ
  • Mọi tầng đều được so sánh với triển khai tham chiếu PyTorch
    • Sai khác logits cuối cùng là 3.6e-06
    • Vision tower so với tham chiếu riêng là 2.3e-06
    • Chuyển đổi latent KV cache giữ logits giống nhau ở mức 1.2e-05

Ngân sách RAM và vùng hiệu năng hẹp

  • K3 dùng 16 expert trên mỗi token qua 92 tầng, tạo ra working set 17.0GB cho mỗi token
    • Nếu cache nhỏ hơn kích thước này, expert được lưu từ một token sẽ bị đẩy ra trước token kế tiếp và tỷ lệ hit sẽ về 0%
  • Kết quả đo trên hệ thống 64GB cho thấy cấp thêm RAM không phải lúc nào cũng nhanh hơn
    • Ngân sách 32GB · cache 3.32GB: hit rate 0%, 0.50 tok/s
    • Ngân sách 46GB · cache 17.32GB: hit rate cũ 17%, 0.53~0.55 tok/s
    • Ngân sách 52GB · cache 23.32GB: 0.04~0.15 tok/s, không tái hiện ổn định
    • Ngân sách 58GB · cache 29.32GB: 0.02~0.03 tok/s
  • Router lookahead nâng hit rate ở mức 46GB từ khoảng 14% lên 38%, nhưng sự sụp đổ từ 52GB trở lên không phải do cache miss mà do paging của hệ điều hành
    • Ở 58GB, dù hit rate cao hơn nhưng vẫn chậm hơn khoảng 20 lần so với 46GB
    • Sau khi đẩy hệ thống vào trạng thái paging với ngân sách lớn, ngay cả phép đo 46GB cũng có thể rơi xuống 0.02 tok/s
  • Ngân sách mặc định được chọn thấp hơn 7/8 RAM vật lý, giảm theo đơn vị working set của token
    • Trên MacBook Pro 64GB, hệ thống dùng 46.24GB và phân 17.56GB cho cache expert
    • Nếu ngân sách chỉ định thấp hơn mức tối thiểu, chương trình sẽ từ chối khởi động thay vì tiếp tục với swapping
    • Trên hệ thống 128GB, có thể dùng toàn bộ ngân sách khuyến nghị tương ứng trunk cộng 3 lần working set

Hiệu năng K3 và yêu cầu phần cứng

  • Hệ thống đo là MacBook Pro M5 Pro 64GB với SSD nội bộ
    • RAM tối thiểu cho ngữ cảnh 4K: 29.05GB
    • 32K: 30.54GB, 128K: 35.63GB, 1M: 83.21GB
    • Trunk thường trú: 27.28GB
    • Tải mô hình: 20 giây
    • decode: 0.45~0.62 tok/s với ngân sách mặc định
    • prefill: chunked 0.47 tok/s, tuần tự 0.29 tok/s
  • Có thể mở mô hình với tối thiểu 29.05GB, nhưng hệ thống 32GB có thể bị paging nặng nên 64GB mới là cấu hình khuyến nghị thực tế
  • Mỗi token đọc 17.0GB expert ở trạng thái cold, và với lookahead đạt 38% hit rate thì đọc 10.5GB
  • SSD nội bộ đo được 12.78GB/s, còn hộp USB ngoài là 0.94GB/s
    • Vì một token đọc 17GB expert, cùng xử lý đó sẽ mất khoảng 13 giây trên thiết bị lưu trữ ngoài
    • Bản tải gốc có thể đặt trên ổ ngoài, nhưng container đã chuyển đổi phải đặt trên NVMe nội bộ
  • Cần 982GiB cho container chuyển đổi và 1.42TB để staging shard gốc; dung lượng staging có thể giải phóng sau khi chuyển đổi

Attention và xử lý đa phương thức

  • Attention của K3 kết hợp Kimi Delta Attention và gated multi-head latent attention theo tỷ lệ 3:1
    • KDA duy trì recurrent state kích thước cố định thay vì KV cache tăng dần
    • MLA cache latent rộng 512 mà không mở rộng key/value theo từng head
  • Hấp thụ kv_b_proj vào query và output giúp giảm cache ngữ cảnh 4K từ 11.25GB xuống 0.21GB
    • Giảm 53 lần so với trước
    • Ở 128K, bố cục mở rộng cần 360GB, còn bố cục latent cần 7.2GB
  • Đường đa phương thức hỗ trợ ViT 401M tham số, 27 tầng, patch 14
    • Mã hóa ảnh 1024 patch mất 15.7 giây
    • Ảnh 896×896 chiếm 256 vị trí chuỗi ở cấu hình mặc định
    • Embedding ảnh cũng đi qua 92 tầng MoE nên phần lớn chi phí giống text prefill hơn là vision tower
    • Nếu giảm một nửa max_patches trong vision.json thì số vị trí prompt cũng giảm một nửa
  • Hỗ trợ PNG, JPEG, GIF, BMP, TGA, PSD và có thể dùng ảnh trong run, chat, eval
    • Vị trí ảnh đã mã hóa trong hội thoại được giữ trong attention state nên không cần mã hóa lại ở lượt sau
    • Vision tower chỉ được tải khi có ảnh, dùng 434MB trọng số và 1.12GB bộ nhớ đặt trước tổng cộng

Chuyển đổi, chạy và server

  • Việc build chỉ cần trình biên dịch C11 và make
    • make check vượt qua 23 bài kiểm tra và bỏ qua 11 bài bằng container tổng hợp mà không cần mô hình thật
    • Nếu có hai container thật, toàn bộ bộ kiểm tra là 36 bài
  • Chuyển đổi K3 dùng nguyên vẹn 96 shard safetensors từ moonshotai/Kimi-K3 đã công khai
    • Mất khoảng 4,7 giờ trên M5 Pro với 3 tiến trình
    • Encoder PyTorch thuần mất 23,7 giờ
    • Có thể tiếp tục theo từng tầng, nên nếu bị gián đoạn chỉ cần xử lý lại tầng đang chạy dở
    • Trình tải xuống hỗ trợ nối lại file từng phần, exponential backoff và jitter, kiểm tra Content-Length, và ghi trạng thái shard đã hoàn tất
  • CLI cung cấp run, chat, eval, plan... và với --json sẽ xuất kết quả của eval, tokenize, plan, info, bench ở dạng máy đọc được
  • serve/ là HTTP server tương thích OpenAI gọi C API công khai qua ctypes
    • Cung cấp /v1/chat/completions, /v1/completions, /v1/models, /health
    • Hỗ trợ streaming, định nghĩa/kết quả công cụ, typed call arguments, schema phản hồi JSON, tool_choice, kênh think, thinking_effort, và ảnh
    • Trình render prompt đã port encoding_k3.py của bản phát hành K3, và nếu có thư mục trọng số thì sẽ so sánh 38 cuộc hội thoại theo từng segment

Nền tảng và các giới hạn hiện tại

  • macOS arm64, Linux arm64, Linux x86_64 đều đạt 23 pass · 11 skip trên cùng bộ kiểm tra không phụ thuộc mô hình, đồng thời vượt qua sanitizer và 400 lượt fuzz
  • Windows x86_64 được cross-compile bằng MinGW-w64 để kiểm tra container tổng hợp, CLI và forward pass, nhưng chưa chạy với container mô hình thật
    • Không hỗ trợ MSVC và Windows ARM64
    • Việc bỏ qua page cache trên Windows mới chỉ được xác nhận trên filesystem CI, chưa được kiểm chứng với tải thực tế của container lớn hơn RAM
  • SIMD trên x86 chọn AVX-512 hoặc AVX2 theo CPUID, nhưng đường AVX-512 vẫn chưa được chạy trên CPU thực sự hỗ trợ
  • Backend Metal cho độ chính xác đúng nhưng chậm hơn CPU 22% do kiểu tác vụ có hàng trăm phép matvec phụ thuộc nhỏ, nên bị tắt mặc định
  • API hiện chưa cố định, và việc tự động chuyển đổi chat format hiện chỉ hỗ trợ K3
    • Kimi-Linear không đoán template mà chạy ở chế độ raw
  • Sẽ không đưa vào phân bổ bit không đồng đều theo từng expert
    • Giá trị của bit thứ ba chỉ chênh tối đa 1,15 lần giữa các expert trong cùng tầng và 1,01 lần giữa các tầng, nên tối ưu phân bổ không đem lại lợi ích
    • Phân bổ theo tần suất routing có giảm dung lượng lưu trữ nhưng hầu như không giảm được I/O vốn là nút thắt
  • Giấy phép là Apache 2.0

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Các ý kiến trên Hacker News

  • Thật sự rất ấn tượng. Đây không phải là một dự án nhằm thực dụng hơn các nhà cung cấp cloud ngay lúc này, mà là dự án cho thấy ranh giới của khả năng
    Khi cải thiện hiệu quả mô hình đi cùng với nâng cao hiệu năng thiết bị cục bộ, một ngày nào đó các mô hình local chất lượng cao cũng có thể vận hành kinh tế

  • 0,5 token mỗi giây thì tôi nghĩ không hữu ích cả với các tác vụ dài. Thà bỏ tiền mua 2 chiếc 16GB 4060 Ti và áp dụng tensor parallelism
    Có lẽ 20 năm nữa nó sẽ hợp với một robot chậm kiểu cyberpunk chạy bằng năng lượng mặt trời, vừa cắt cỏ hoặc lau vỉa hè; hoặc một robot trong vườn chỉ vừa đủ theo kịp tốc độ sinh trưởng của cây bonsai để tỉa cành

    • Hiện giờ gần như không dùng được, nhưng tôi vui vì những dự án như thế này phải tiếp tục được cải thiện thì cuối cùng mới đạt tới phiên bản thực dụng

  • Nói rằng trả tiền token và để nhà cung cấp suy luận trả tiền điện là lãng phí, tôi không thấy khác gì chuyện mua dưa chuột thì nông dân trả tiền nước và phân bón. Hy vọng đó là kiểu lập luận mà LLM gán ghép sau này
    Bản thân ý tưởng thì thú vị và tôi muốn thử với các mô hình nhỏ hơn. Nếu vừa tạo 0,5 token mỗi giây vừa đọc vài GB mỗi giây từ SSD, thì với laptop phổ thông vẫn quá lớn, nhưng khi nhắm tới mô hình 250~500GiB thì có khi lại thực dụng hơn

    • Tự trồng cà chua thì sẽ có cà chua miễn phí. Dù không đủ làm BLT, nhưng vì không phải hàng siêu thị nên coi như đã cứu thế giới được một chút /s

  • Giả sử dùng liên tục 42W và tiền điện là 20 cent/kWh, thì sẽ vào khoảng 5 đô la cho mỗi 1 triệu token, chưa tính các chi phí khác như phần cứng

    • Một tháng có khoảng 2,6 triệu giây, và với 0,5 token/giây thì tạo được 1,3 triệu token mỗi tháng. Nếu tính cả chi phí phụ trợ, lấy chi phí vận hành thiết bị hằng tháng làm chi phí trên mỗi 1 triệu token cũng xấp xỉ đúng
    • Tôi tò mò phép tính sẽ thay đổi thế nào nếu có điện mặt trời

  • llama.cpp chuẩn cũng có thể mmap GGUF, nên phần không vừa bộ nhớ sẽ nằm lại trên đĩa, còn kernel page cache sẽ giữ phần trunk thường trú là phần hay được dùng. Tôi tự hỏi lợi ích của việc tự triển khai là gì

    • Vài ngày trước, ở một dự án tương tự cũng có câu hỏi y như vậy; họ nói ban đầu đã thử mmap, rồi tự triển khai và nhanh hơn 10 lần
      Cũng giống lý do các database engine tự triển khai cache của mình. Kernel paging là cơ chế tổng quát, dựa trên yêu cầu, nhưng nếu biết pattern truy cập thực tế thì có thể đọc trước dữ liệu cần thiết và pipeline hóa
    • Ở quy mô này, nếu dùng SSD làm swap thì chỉ trong vài tháng rất dễ dùng hết độ bền ghi tích lũy. Tôi muốn xem tổng lượng ghi tích lũy và thống kê hao mòn trong SMART khi chạy lâu hơn một bài thử ngắn
      Nếu là mô hình vừa hết trong RAM, chạy llama-server với --no-mmap thì tốt hơn. Tất nhiên, để nạp toàn bộ Kimi K3 và ngữ cảnh 1 triệu token thì cần server 2TB

  • README tạo cảm giác rất mạnh là do LLM viết, nên tôi tò mò codebase có phải cũng do LLM viết không

    • Tôi không muốn chê bai hời hợt, nhưng tài liệu tự mâu thuẫn về việc liệu mô hình có thật sự chạy ở độ chính xác gốc hay không. Tuyên bố lượng tử hóa 3-bit có thể thú vị, nhưng K3 ở độ chính xác gốc chỉ riêng tham số dense đã khoảng 115GB, các expert thưa được kích hoạt trên mỗi token khoảng 25GB, lại còn thêm KV cache, nên tuyên bố 2 giây mỗi token trên 29GB RAM thật khó hiểu
    • Tôi đã tự viết rất nhiều phần mềm và cũng tạo ra ngôn ngữ lập trình: https://github.com/marcobambini/gravity
      Giờ tôi dùng kỹ năng của mình để điều phối LLM và agent, nhờ đó viết code tốt hơn nhanh hơn rất nhiều. Lập trình viên phải chọn một trong hai con đường: thích nghi với công nghệ mới hoặc bị đào thải
    • Tôi chỉ mong các tác giả ít nhất cũng tự đọc qua README do LLM tạo ra. LLM thiếu hiểu biết về góc nhìn của độc giả, nên giả định rằng độc giả bên ngoài cũng biết toàn bộ bối cảnh dự án và quá trình ra quyết định
      Những quyết định nội bộ quan trọng với người dùng nhưng không liên quan với độc giả nhìn vào sản phẩm hoàn chỉnh, cùng các thuật ngữ khó hiểu kiểu Claude, vẫn được đưa nguyên vào. Tôi thừa nhận mình dùng LLM thường xuyên và nó rất hữu ích cho việc viết code phức tạp, nhưng chất lượng bản nháp văn bản thì tệ
    • Trong danh sách contributor có claude, nên không cần đoán nữa. Nếu giao cho Claude cả việc commit thì khả năng họ tự review code cũng có vẻ thấp
    • README mang đậm văn phong đặc trưng của Claude nhất. Giống như nhận ra cách viết của từng người, giờ tôi có cảm giác kiểu văn ngắn, ngắt quãng và chỉ quá chú trọng nhịp điệu mà Claude mặc định tạo ra cũng đã thành một nhóm riêng trong đầu

  • Nếu công nghệ tiến bộ đến mức có thể chọn chính xác mô hình phù hợp với tác vụ, giá trị có thể tăng lên. Có thể tưởng tượng một tương lai trong quá trình tự động khám phá chỉ chạy mô hình lớn khoảng 30 phút mỗi ngày, thời gian còn lại dùng mô hình nhỏ

    • Tôi không nghĩ tương lai đó sẽ đến. Ngay cả một mục trong backlog cũng phải làm xong mới biết mất bao lâu; nếu chưa thực sự thực hiện thì không có cách nào biết trước độ phức tạp của tác vụ