TurboFieldfare - Engine mã nguồn mở chạy Gemma 4 26B trên mọi máy Mac dòng M với 2GB RAM

 (github.com/drumih)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • TurboFieldfare chạy Gemma 4 26B-A4B với khoảng 2GB bộ nhớ mà không đưa toàn bộ mô hình 14.3GB vào bộ nhớ, cho phép suy luận cục bộ ngay cả trên máy Mac Apple Silicon 8GB
  • Sau khi chỉ giữ thường trú lõi dùng chung 1.35GB và FP16 KV cache, nó stream trọng số chuyên gia MoE cần thiết cho từng token từ SSD, đồng thời giới hạn I/O bằng LFU cache 16 slot và pread song song
  • Gemma 4 26B-A4B kích hoạt khoảng 3.88B tham số cho mỗi token; tốc độ giải mã đo được là 5.1~6.3 tok/s trên MacBook Air M2 8GB và 31~35 tok/s trên M5 Pro 24GB
  • Đây là runtime chuyên dụng được triển khai bằng Swift 6.2 và Metal 4, cung cấp ứng dụng Mac native, CLI, công cụ cài đặt và máy chủ tương thích OpenAI thử nghiệm trên cùng thư mục mô hình .gturbo
  • Phạm vi hiện tại giới hạn ở suy luận chỉ văn bản trên máy Mac Apple Silicon chạy macOS 26 trở lên và có tối thiểu 8GB RAM; không hỗ trợ hình ảnh, giọng nói, video, cũng như xác thực máy chủ từ xa và TLS

Cấu trúc thực thi giảm bộ nhớ

  • TurboFieldfare không nạp toàn bộ instruction-tuned Gemma 4 26B-A4B vào bộ nhớ
    • Lõi dùng chung 1.35GB và FP16 KV cache được giữ trong bộ nhớ
    • Chỉ các routed expert cần thiết cho từng token được đọc từ SSD vào buffer mà Metal có thể truy cập
    • Mô hình chỉ văn bản sau khi cài đặt có dung lượng khoảng 14.3GB, nhưng bộ nhớ mà trọng số và 4K KV cache sử dụng chỉ khoảng 2GB
  • Trong tổng số 26B tham số, mô hình kích hoạt khoảng 3.88B tham số cho mỗi token
  • Trọng số dùng MLX affine 4-bit dựa trên group 64; router là 8-bit, còn shared expert và routed expert là 4-bit
  • Đây không phải cấu hình bọc MLX hay llama.cpp, mà là runtime chuyên dụng Swift·Metal được tạo riêng cho Gemma 4 26B-A4B

Quy trình tạo token

  • Ở mỗi lớp Transformer, Metal tính attention và router bằng các trọng số thường trú
  • CPU đối chiếu 8 expert ID đứng đầu do router chọn với LFU cache 16 slot theo từng lớp
    • Cache miss được lấp đầy bằng số lượng giới hạn các lệnh gọi pread song song
    • Trong khi SSD đang đọc, Metal tính nhánh shared-expert thường trú
    • Khi đọc xong, shared output và routed output được kết hợp
  • Prefill prompt dùng các chunk tối đa 128 token để expert đã được nạp một lần có thể xử lý nhiều hàng
  • Ở giai đoạn sinh, vòng lặp routed layer được lặp lại theo từng token
  • KV cache dùng bộ nhớ vòng giới hạn cho 25 sliding-window layer và bộ nhớ tuyến tính cho 5 full-attention layer
  • Attention khi giải mã là exact split-K/V, tách riêng các đường K và V đã được chuẩn hóa

Cài đặt và định dạng mô hình

  • Nếu chọn Download ở lần chạy đầu tiên, khoảng 15GB sẽ được tải xuống từ một Hugging Face revision cố định bằng range request
  • Trình cài đặt không tạo toàn bộ checkpoint gốc trong file tạm hay bộ nhớ
    • Nó nhận các dải byte cần thiết rồi repack trực tiếp sang layout .gturbo
    • Không chuẩn bị riêng toàn bộ shard hay tensor, nên lượng bộ nhớ tạm thời được giới hạn
    • Bản cài đặt hoàn chỉnh phải vượt qua kiểm tra manifest và hash file mới có thể sử dụng
  • Sau khi cài xong, mô hình chiếm khoảng 14.3GB dung lượng lưu trữ, và bản thân quá trình cài đặt không load mô hình vào bộ nhớ
  • Runtime chỉ chấp nhận thư mục .gturbo hoàn chỉnh có manifest.json cuối cùng
  • Hỗ trợ tiếp tục tải xuống bị gián đoạn, xóa trạng thái tải xuống một phần và xác minh cài đặt mà không load mô hình

Môi trường chạy và hiệu năng

  • Môi trường yêu cầu là máy Mac Apple Silicon, macOS 26, Metal 4, Xcode 26, Swift 6.2 trở lên
  • Gói này chỉ dành cho arm64 và không hỗ trợ các phiên bản macOS và Metal cũ hơn
  • Thiết bị được xác minh là MacBook Air M2 8GB; cần dung lượng lưu trữ trống để cài mô hình và kết nối Internet cho lần tải đầu tiên
  • Hiệu năng giải mã đo được như sau
    • MacBook Air M2 8GB: 5.1~6.3 tok/s
    • M5 Pro 24GB: 31~35 tok/s
  • Thông lượng thay đổi theo độ dài prompt, độ dài sinh, trạng thái page cache và phần cứng, nên các số đo là mốc tham chiếu chứ không phải giới hạn trên của hiệu năng
  • Trước khi chạy mô hình, nên đóng các ứng dụng dùng nhiều bộ nhớ và kiểm tra bộ nhớ trống bằng memory_pressure -Q
  • Ứng dụng, decode service, CLI, máy chủ, test hoặc tiến trình mô hình cục bộ khác chỉ nên chạy một cái tại một thời điểm

Sản phẩm cung cấp và cách sử dụng

  • Gói Swift cung cấp sáu sản phẩm
    • TurboFieldfare: thư viện Swift gồm runtime và kernel Metal
    • TurboFieldfareMac: ứng dụng Mac native để cài đặt và sinh văn bản
    • TurboFieldfareDecodeService: tiến trình cục bộ dùng một lần sở hữu mô hình và Metal mà ứng dụng Mac sử dụng
    • TurboFieldfareCLI: instruction chat và raw completion trên dòng lệnh
    • TurboFieldfareServer: máy chủ Chat Completions tương thích OpenAI trên loopback
    • TurboFieldfareRepack: công cụ cài đặt streaming và xác minh cài đặt
  • Trong ứng dụng Mac, sau khi tải mô hình, chọn Load Model rồi nhập prompt để sinh văn bản
    • Có thể xem tiến trình, tốc độ giải mã và lượng bộ nhớ sử dụng trên thanh trạng thái
    • Có thể điều chỉnh sampling, context length, expert-cache slot và các tùy chọn runtime
  • Instruction chat của CLI nhận mảng thông điệp JSON và chuyển đổi sang cùng định dạng với ứng dụng Mac
    • Giá trị mặc định của giới hạn phản hồi --max-new là 1,024 token
    • Ứng dụng Mac có thể sinh cho đến khi context window đã chọn đầy
  • --prompt được dùng cho raw completion không áp dụng định dạng chat và cho các so sánh có thể tái lập
  • Văn bản sinh ra được gửi ra standard output, thống kê thời gian gửi ra standard error; có thể tắt xuất thống kê bằng --quiet

Prompt và phạm vi hỗ trợ

  • Ứng dụng Mac xử lý input như instruction và tự động áp dụng định dạng chat của Gemma
  • Thiết lập sampling mặc định là temperature 0.2, Top-K 64, Top-P 0.95
    • Nếu đặt temperature thành 0, nó dùng greedy output có tính quyết định
    • Mô hình có thể lặp lại hoặc trả lời sai, nên cần kiểm tra các kết quả quan trọng
  • Ứng dụng và CLI hỗ trợ thông điệp người dùng, thông điệp mô hình và system guidance tùy chọn, nhưng không phơi bày hoặc thực thi công cụ
  • Hiện tại, input/output của mô hình chỉ là văn bản; không hỗ trợ hình ảnh, âm thanh, video
  • CLI cung cấp --max-context, --temperature, --top-k, --top-p, --repetition-penalty, --seed và chuỗi --stop có thể lặp lại

Máy chủ cục bộ tương thích OpenAI

  • Máy chủ thử nghiệm chạy tại 127.0.0.1:8080/v1 và hỗ trợ Chat Completions, streaming, khai báo công cụ hàm và tái sử dụng prompt prefix đơn lẻ
  • Máy chủ trả về tool call do mô hình tạo, nhưng việc phê duyệt và thực thi mọi lời gọi công cụ thuộc trách nhiệm của client
  • Vì không có xác thực từ xa và TLS, máy chủ phải chỉ được giữ trên loopback
  • Ứng dụng Mac, CLI và máy chủ dùng cùng thư mục .gturbo, nhưng tại một thời điểm chỉ một sản phẩm sở hữu mô hình được chạy

Phạm vi triển khai và nhật ký thử nghiệm

  • Các kernel Metal tùy chỉnh xử lý GEMV lượng tử hóa, attention, MoE, normalization, RoPE, sampling và production fusion
  • Runtime triển khai streaming routed-expert dựa trên SSD, expert cache giới hạn, prefill một prompt theo chunk và sinh theo từng token
  • 103 kết quả đo trải dài trên kernel, caching, I/O, prefill và decode được quản lý như nhật ký thử nghiệm
  • Tài liệu thử nghiệm bao gồm các tối ưu hóa có tác động lớn, những ý tưởng thất bại và các kết quả ban đầu bị đảo ngược sau khi xác minh mạnh hơn
  • Công việc tương lai gồm phát triển ứng dụng iPhone·iPad, đo tốc độ suy luận và bộ nhớ trên di động, benchmark trên Mac mini M4 16GB và các máy Mac Apple Silicon 8GB khác

Giấy phép và điều kiện mô hình

  • Mã nguồn và tài liệu được phân phối theo Apache License 2.0
  • Trọng số mô hình không nằm trong kho lưu trữ; trình cài đặt tải riêng từ checkpoint Hugging Face cố định
  • Các điều kiện phân phối gốc vẫn tiếp tục áp dụng cho trọng số
  • TurboFieldfare là dự án nghiên cứu độc lập, không liên kết với Google và không được Google tài trợ hay phê duyệt

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Tôi luôn thắc mắc vì sao cứ phải nhồi toàn bộ mô hình vào bộ nhớ, như thể còn cần biết cả Vua Charles là ai. Theo tôi, kỹ thuật chia nhỏ tệp lớn để đọc hiệu quả với ít bộ nhớ đã được thiết lập từ lâu
    Có vẻ trong giới AI tiên tiến, người ta rất giỏi làm mô hình nhưng lại có xu hướng đẩy bài toán mở rộng quy mô và tính thực dụng sang cho đội hạ tầng. Nếu kiến thức thực sự dùng đến chưa tới 10%, thì chỉ cần tinh chỉnh và tối ưu hóa cũng có thể giảm mạnh chi phí

    • Giữ toàn bộ mô hình trong bộ nhớ nhanh hơn rất nhiều so với việc hoán đổi với đĩa
    • Về cơ bản thì bạn vừa mô tả kiến trúc Mixture of Experts (MoE). Nếu các lớp chuyên gia đủ nhỏ và SSD đủ nhanh thì có thể chỉ nạp khi cần
      LLM dạng dense thường cho chất lượng tốt hơn, nhưng nếu đẩy các lớp ra bộ nhớ ngoài thì sẽ chậm hơn MoE rất nhiều

  • Dạo này khi tải một dự án không rõ nguồn gốc, phải tự chạy kiểu kiểm tra bảo mật như thế này. Tôi đã bảo nó bỏ qua các chỉ thị agent và các tệp Markdown trong repo, rồi kiểm tra mã nguồn Swift/Metal, script build, cấu hình CI và các dependency; kết quả là không tìm thấy mã độc, backdoor, đánh cắp thông tin xác thực hay endpoint mạng bị ẩn, nhưng rủi ro về biên dịch, chuỗi cung ứng và runtime vẫn còn
    Nếu ai có prompt tốt hơn thì cứ chia sẻ, và chi phí chạy bằng Composer 2.5 của Cursor là dưới 0,20 USD

  • Nếu dùng macOS 15 trên M1 MacBook Air, chỉ cần xóa hai dòng sau hoặc bọc chúng bằng if #available(macOS 26.0, *) là biên dịch được: opts.languageVersion = .version4_0
    Theo chú thích, bạn sẽ mất phần tăng tốc attention 11,24 lần giúp prefill nhanh hơn 2,4 lần, nhưng trên M1 Air GPU 8 nhân vẫn đạt 5~6 token/giây

    • Thông tin hữu ích đấy. Sau này có thể tôi sẽ thử hạ phiên bản hỗ trợ tối thiểu
      Mức cải thiện prefill 2,4 lần chỉ hoạt động trên dòng GPU apple10, còn M1 nếu tôi nhớ không nhầm là apple7

  • Tôi tò mò dự án này so với mmap thông thường ra sao. llama.cpp cũng có thể chạy mô hình 26B với 2GB RAM nếu bật mmap và tắt repacking
    Khác biệt cốt lõi có vẻ là họ đồng bộ việc đọc SSD với tác vụ suy luận để giảm độ trễ tối đa, còn hệ điều hành thì không xét đến ngữ cảnh thực thi đó

    • Bản đầu tiên có dùng mmap. Trên M2 8GB, đọc một expert 3,36MB ở trạng thái cold, mmap mất 10ms còn pread mất 2,8ms; toàn bộ mô phỏng đạt lần lượt 0,50 token/giây và 4 token/giây
      Với mmap, hệ điều hành chỉ phản ứng sau khi mô hình chạm vào page, nên nó không biết expert nào đã được chọn và khi nào có thể chồng việc đọc lên tác vụ GPU. Các trọng số chung vẫn dùng mmap để giữ đơn giản; llama.cpp có lẽ cũng chạy được dưới 2GB, nhưng tôi nghĩ sẽ chậm hơn
    • Nếu muốn biết tốc độ thực tế thì tôi muốn so trực tiếp với SSD offloading của llama.cpp

  • Câu “các kết quả đo được là đường cơ sở chứ không phải trần hiệu năng” nghe rất giống văn phong của Claude

    • Kiểu diễn đạt này lan quá rộng đến mức tôi còn lo mình đọc văn Claude mãi rồi sẽ nhiễm luôn thói quen đó
    • “Tôi đã thử nghiệm hơn 100 lần và đa số thất bại, nhưng một vài lần đã đưa tôi đến đây” cũng trông như cùng một dấu vết
    • Ban đầu có lẽ đây là kiểu diễn đạt của ChatGPT, nhưng tôi cũng không định quy chụp là chưng cất từ công ty phương Tây nào đó. Có khi các blog công thức nấu ăn sau 2022 đã lọt vào dữ liệu huấn luyện quanh bản 4.6~4.8
    • Tôi nghĩ đã đến lúc ngừng kiểu phán đoán này. Nó chẳng khác gì một dạng cảnh sát ngữ pháp mới và cũng không mang thêm giá trị gì
      Nếu tác giả chỉ dùng LLM để gọt câu chữ mà không thêm nội dung vô ích thì cũng không sao. Nếu bản thân bài viết là thứ được tạo ra vô dụng thì cứ downvote thôi

  • Việc đạt 12 token/giây và phản hồi gần như tức thì trên M1 Max Mac Studio với SSD nhanh hơn là rất ấn tượng. Điều đó cho thấy khả năng chạy mô hình lớn trực tiếp từ SSD thay vì từ bộ nhớ

    • Tiếc là ở đây tốc độ đọc SSD lại là nút thắt lớn nhất

  • Dạo này có nhiều engine streaming từ SSD, nhưng hiếm dự án nào thử những tính năng khó hơn. Các mô hình chủ chốt đều có MTP head cho speculative decoding, nên có thể tận dụng nó để đọc trước trọng số expert từ SSD
    Nếu chuẩn bị sẵn trọng số trước khi GPU cần đến, chi phí cache miss trong VRAM có thể giảm mạnh; nếu hiệu quả được chứng minh, các mô hình tương lai có thể có một head chuyên để gọi trước expert và tính đến điều đó ngay từ giai đoạn huấn luyện

    • Trong streaming từ SSD, GPU gần như luôn phải đợi SSD mang đúng expert đến, nên phía SSD thực tế hầu như không có thời gian để đọc trước. Nếu đọc nhầm expert dự đoán thì còn phản tác dụng; vì vậy trong môi trường batch nhỏ thông thường, MTP hiện tại cũng không giúp được nhiều
    • Trên thực tế việc này khó hơn tưởng tượng. Mỗi lớp có một tập expert khác nhau, và một router nhỏ sẽ nhìn vào trạng thái đầu ra của expert ở các lớp dưới để quyết định expert cần dùng
      Với token nháp do MTP tạo ra, bạn có thể dự đoán expert của lớp đầu tiên, nhưng để biết lớp thứ 10 thì phải chạy các lớp 1~9 và đọc các expert tương ứng trước. Vì thế, thay vì bộ sinh token tiếp theo, cần một cơ chế được huấn luyện để dự đoán kích hoạt expert của mọi lớp cùng lúc

  • Dự án chạy DiffusionGemma cũng gần như đã sẵn sàng, và hai dự án có thể kết hợp với nhau rất hợp. Trên M3 36GB đạt khoảng 20 token/giây, và khả năng cao là hai bên còn có thể dùng chung các kernel nhanh hơn
    Mã hiện ở https://github.com/mmastrac/diffgemma nhưng vẫn chưa ở trạng thái có thể phát hành

    • Gần đây tôi có xem qua, nhưng đi đến kết luận rằng chạy mô hình diffusion cục bộ không mang lại nhiều lợi ích thực tế: https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...
      Tôi muốn nghe suy nghĩ của bạn về chuyện đó
    • Diffusion Gemma xuất hiện khi dự án đã đi được nửa chặng, và tôi đã nghiêm túc cân nhắc chuyển hướng, nhưng cuối cùng vẫn quyết định hoàn thiện hướng hiện tại. Hai dự án rất hợp nhau, và bạn cứ thoải mái dùng phần mã cần thiết hoặc liên hệ qua LinkedIn ở cuối README

  • Tôi thắc mắc vì sao lại có chênh lệch lớn như vậy giữa 5~6 token/giây trên MacBook Air M2 8GB và 31~35 token/giây trên MacBook Pro M5. Có vẻ hiệu năng SSD khó mà chênh đến mức đó, nhưng với cách này tôi đã đoán SSD sẽ là nút thắt cổ chai chi phối

    • Mức cải thiện hiệu năng SSD của M5 là rất đáng kể ngay cả khi so với thế hệ trước. Trong Blackmagic Disk Speed Test, MacBook Pro M5 đạt tối đa 6.323MB/s, còn MacBook Pro M4 đạt 2.031MB/s, chênh hơn 3 lần
      https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
    • Cũng rất có thể M5 có nhiều bộ nhớ hơn nên hệ điều hành đã cache sẵn phần lớn tệp. M2 chịu áp lực bộ nhớ lớn hơn nên có lẽ sẽ cache ít hơn các kết quả đọc từ SSD
      Nếu tổng cộng chỉ được dùng 2GB, tính cả cache của hệ điều hành, thì tốc độ suy luận có thể còn thấp hơn
    • Phụ thuộc khá nhiều vào cache hệ thống và pread. Dù tiến trình dưới 2GB, máy Mac M5 vẫn có thể cache một phần và phần cứng bản thân nó cũng nhanh hơn nhiều
      Mỗi token đọc mất 83ms trên M2 và 12ms trên M5 Pro, còn tổng thời gian lần lượt là 163ms và 30ms. Đây là kết quả của cả việc đọc lẫn xử lý GPU đều nhanh hơn
    • Do đã cũ thế hệ nên ngay cả so Pro với Pro thì SSD cũng chậm hơn nhiều, và trong cùng một thế hệ, SSD cùng băng thông bộ nhớ của Air có thể cũng thấp hơn Pro
    • MacBook Pro M5 có 24GB RAM nên cũng có thể giữ nhiều ngữ cảnh hơn trong bộ nhớ

  • Về sau, tôi hy vọng với những hệ thống có 30~60GB bộ nhớ và SSD rất nhanh, kỹ thuật kiểu này có thể chạy được cả các mô hình cực lớn