- Gemma 4 26B-A4B có thể chạy ở tốc độ mức đọc nhờ tối ưu hóa
ik_llama.cpp trên máy chủ không GPU dùng một Intel Xeon E5-2620 v4 đời 2016, DDR3 128GB
- Trong decoder pass của LLM, nút thắt là băng thông bộ nhớ chứ không phải phép tính; CPU phần lớn phải chờ mang trọng số tiếp theo từ RAM vào cache
- Các tùy chọn như
--spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack giúp giảm nghẽn trên môi trường DDR3 bằng giải mã suy đoán MTP, định tuyến MoE và bố trí bộ nhớ thân thiện với cache
- Theo log, tổng nhu cầu bộ nhớ là 82,355MiB; với toàn bộ ngữ cảnh 262K, KV cache khoảng 56GB còn lớn hơn phần trọng số khoảng 25GB
- Các công cụ hộp đen như
ollama thiếu hỗ trợ model cần thiết và thiếu các nút tinh chỉnh chi tiết; với phần cứng cũ, cần hiểu sâu về engine suy luận và cấu trúc bộ nhớ mới có thể khai thác hiệu năng
Môi trường chạy và nút thắt chính
- Máy chủ thử nghiệm là phần cứng tái sử dụng, cấu hình gồm Intel Xeon E5-2620 v4 @ 2.10GHz, 8 lõi 16 luồng, AVX2, 20MiB L3 cache, 2MiB L2, 128GB DDR3, không có GPU
- CPU này không hỗ trợ AVX-512, AVX-VNNI, BF16 và cũng không có GPU tích hợp
- Trong suy luận LLM, decoder pass tạo token từng cái một chủ yếu bị ràng buộc bởi băng thông bộ nhớ chứ không phải lượng tính toán
- Để tính token tiếp theo, phải liên tục chuyển các trọng số chứa tri thức đã học của model từ RAM vào cache và lõi CPU; bộ xử lý thường mất nhiều thời gian chờ dữ liệu hơn là làm phép nhân ma trận
- “Bức tường bộ nhớ (memory wall)” này không chỉ là vấn đề của Xeon mà còn là rào cản hiệu năng quan trọng ngay cả với phần cứng cao cấp như H100
Các nút điều khiển chạy cần thiết thay vì công cụ hộp đen
- Nếu chỉ chạy
llama-cli trong môi trường DDR3 không GPU thì sẽ rất chậm, và do nhiều tối ưu hóa được thiết kế cho trường hợp dùng GPU phổ biến nên vẫn còn nhiều dư địa cải thiện
ollama có thể không hỗ trợ model cần thiết, đồng thời không phơi bày đủ thiết lập chi tiết để thực sự đẩy hiệu năng lên cao- Việc chạy thực tế chỉ khả thi khi kết hợp nhiều cờ mà
ik_llama.cpp cung cấp
- Nhóm cờ cốt lõi như sau
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune
-sm graph -smgs -sas -mea 256 --split-mode-f32
-t 8 --parallel 8
--cpu-moe --merge-up-gate-experts
--flash-attn on --mla-use 3
--mlock --run-time-repack --no-kv-offload
Giải mã suy đoán và tối ưu hóa MoE
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune dùng verifier 26B cùng với một MTP drafter nhỏ đã được tạo từ trước--draft-max 3 nghĩa là tối đa 3 token cho mỗi draft, --draft-p-min 0.0 là chấp nhận mọi xác suất, còn --spec-autotune điều chỉnh độ dài chuỗi theo khối lượng công việc- Khi tạo chuỗi suy luận dài, dù người dùng chỉ thấy câu trả lời cuối cùng khá ngắn, mỗi token suy nghĩ ẩn vẫn đòi hỏi một decoder pass đầy đủ
- Trên CPU, chi phí stream trọng số của verifier vào cache là rất lớn, trong khi các lớp hoạt động của drafter nhỏ lại vừa khít với L3 cache, nên lợi ích của giải mã suy đoán càng rõ rệt
- Gemma 4 26B-A4B có cấu trúc MoE, trong đó mỗi token kích hoạt 8 chuyên gia trên tổng 128 chuyên gia; trong khoảng 25.2B tham số tổng, số tham số thực sự hoạt động là khoảng 3.8B
--cpu-moe điều chỉnh định tuyến cho phù hợp với hệ phân cấp cache của CPU, giúp giảm cache thrashing do liên tục nhảy giữa 128 chuyên gia, xóa cache rồi lại phải nạp từ DDR3--merge-up-gate-experts hợp nhất up projection và gate projection bên trong chuyên gia thành một phép nhân ma trận duy nhất; trong log có thể xác nhận bằng fused_up_gate = 1-t 8 là thiết lập khớp với 8 lõi vật lý; với workload nghẽn bộ nhớ, dùng cả 16 luồng SMT có thể làm tăng chi phí lập lịch hơn là tăng thông lượng
Khóa bộ nhớ, tái sắp xếp và chia đồ thị
--run-time-repack tái cấu trúc ma trận trọng số ngay trước khi suy luận để khớp với layout cache của CPU; trong log hiện Repacked 265 tensors- Thiết lập này chấp nhận tốn vài giây lúc khởi động để sắp xếp lại các bảng số trong RAM sang dạng CPU đọc hiệu quả hơn, từ đó tận dụng tối đa băng thông bộ nhớ khi sinh văn bản thực tế
--mlock khóa model trong RAM để hệ điều hành không thể swap nó ra đĩa- Nếu giới hạn memlock của kernel không đủ, sẽ xuất hiện cảnh báo
failed to mlock 27628376064-byte buffer và Try increasing RLIMIT_MEMLOCK; đây không phải vấn đề của bản thân LLM mà là do thiết lập ulimit mặc định
--no-kv-offload bỏ qua việc thử chuyển KV cache sang GPU trong môi trường không có GPU, và giữ nó trong RAM hệ thống-sm graph thử chia đồ thị tính toán theo chiều dọc để nhiều thiết bị xử lý hoặc vùng nhớ có thể đồng thời tính các phần khác nhau của cùng một lớp- Trong lần chạy này, log báo
Split mode 'graph' is not supported for Gemma4 external MTP, nên hệ thống hạ an toàn xuống kiểu chia theo lớp
-sas chỉ định chia workload giữa các socket CPU vật lý hoặc các nút NUMA, còn --split-mode-f32 buộc dùng độ chính xác số thực dấu chấm động 32 bit tại điểm trung gian nơi các phần được ghép lại sau khi chia
Attention, mức dùng bộ nhớ và kết luận
- ikawrakow đã viết kernel tùy biến để xử lý Flash Attention trên CPU, cho phép xử lý ngữ cảnh nặng mà không cần GPU
--flash-attn on hợp nhất attention softmax và phép nhân ma trận để không phải ghi toàn bộ ma trận attention N×N xuống RAM, mà tính và tiêu thụ theo từng khối nhỏ ngay trong cache--mla-use 3 kích hoạt Multi-Head Latent Attention để nén Key và Value của KV cache thành biểu diễn latent nhỏ hơn- Trong log có
flash_attn = 1, fused_moe = 1, fused_up_gate = 1, cho thấy các tối ưu hóa này thực sự đã được áp dụng
- Theo log bộ nhớ, tổng toàn bộ các lớp là 81,607.46MiB, và bộ nhớ cần cho tensor model cùng cache là 82,355MiB
- Với toàn bộ ngữ cảnh 262K, phần trọng số khoảng 25GB còn KV cache khoảng 56GB, nghĩa là KV cache lớn hơn cả model
- Thiết lập này nạp một MoE 25B tham số và thực hiện giải mã suy đoán bằng MTP drafter, từ đó sinh văn bản ở tốc độ mức đọc trên máy chủ đời 2016 dùng Xeon, DDR3 và không có GPU
- Kết luận là nút thắt của việc chạy cục bộ AI open-weights hiện đại không chỉ nằm ở silicon, mà còn ở việc hiểu cách engine suy luận vận hành và cấu trúc bộ nhớ; với đúng fork, lượng tử hóa được hiệu chỉnh và hiểu biết về kiến trúc bộ nhớ, ngay cả máy chủ cũ cũng có thể chạy được
2 bình luận
Ý kiến trên Hacker News
Tôi viết bài này vì bực bội khi thiếu cách chạy mô hình Gemma 4 Drafter mới và các công cụ phổ biến lại che giấu những điểm tinh chỉnh hiệu năng
Cuối cùng tôi đã thành công chạy mô hình 26B MoE mới nhất ở tốc độ đọc trên một máy chủ tái sử dụng cũ không có GPU, chỉ với một Xeon E5-2620 v4 và 128GB RAM DDR3
Tôi cũng có liên kết mô hình lượng tử hóa ở cuối bài, nhưng nó sẽ không chạy nếu không dùng fork ik_llama-cpp mà tôi đã nhắc tới, và muốn biết chi tiết thì phải xem bài khác
Tôi không phải kỹ sư machine learning, máy chủ này cũng đang bận làm cache Nix, nhưng nếu có câu hỏi thì tôi sẽ cố trả lời trong khả năng
Trong lúc một luồng đang chờ DDR3 thì luồng khác có thể chạy
Ngoài ra tôi cũng không hiểu rõ phần mô tả
--cpu-moe. Một expert có khoảng 4.0GiB tham số, mà nếu L3 cache chỉ có 20MiB thì ngay cả khi tối ưu thứ tự expert cũng có vẻ không thể cache tham số một cách đáng kểNhư những người khác đã nói, chỉ một số mẫu Intel Xeon E5-2xxx v4 hỗ trợ DDR3, và theo tài liệu của Intel thì E5-2620 v4 không phải một trong số đó
Cấu hình dual Xeon và 128GB DDR3, CPU là 2 × Xeon E5-2697 v2 tổng cộng 24 core/48 thread nên số core tốt hơn, nhưng khác biệt thực tế có thể không lớn
Thiết bị này đang chỉ bám bụi, nhưng nếu là Gemma ở tốc độ đọc thì khá đáng mong đợi
Hãy tìm “chia farming” trên Amazon, nhưng bỏ qua chia seeds
Giờ thì cùng cấu hình đó đã đắt hơn khoảng 2,5 lần, nhưng vẫn rẻ hơn nhiều so với máy DDR5 thế hệ hiện tại
https://www.amazon.com/dp/B095TRGCSX
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, online CPU 0-31, 128GB RAMTôi muốn biết liệu có 8 khe DIMM thì băng thông bộ nhớ thực tế có tốt hơn không. Hiện giờ cỗ máy tội nghiệp này chỉ dùng để xem YouTube
Vẫn chưa tới mức đó, nhưng điểm kết thúc rõ ràng khi bong bóng hiện tại vỡ là các mô hình mở chạy trên phần cứng và thiết bị cục bộ sẽ trở nên “đủ tốt” cho hầu hết nhu cầu
Khi đó, những gì đang diễn ra trong ngành công nghệ hiện nay có thể sụp đổ hoàn toàn
Khi thực sự bí thì tôi sẽ gọi Claude API, nhưng có lẽ 80% nhu cầu có thể xử lý bằng mô hình cục bộ ngu hơn một chút
Ngôn ngữ và kỹ thuật lập trình không thay đổi quá nhiều nên tôi hy vọng dùng được ít nhất 5 năm, rồi khi có tối ưu để nhét mô hình thông minh hơn vào cùng lượng VRAM thì lúc đó nâng cấp
Tôi thích hướng đi này
Nếu đoán lý do họ chưa làm, có thể là vì các phòng thí nghiệm AI hiện đang bán mô hình với mức lỗ rất lớn, nên với Amazon, kiểu điện toán biên lợi nhuận thấp này kém hấp dẫn hơn các sản phẩm biên lợi nhuận cao khác
Có lẽ để trạng thái hiện tại sụp đổ thì cũng chưa cần đến mức chạy cục bộ. Chỉ cần đường băng tiền miễn phí của các phòng thí nghiệm AI kết thúc và họ buộc phải bán với giá cao hơn chi phí vận hành thực tế, thì bất kỳ ai có năng lực tính toán cũng sẽ có động lực cung cấp dịch vụ mô hình mở rẻ hơn với mức giá phổ thông
Ai rồi cũng sẽ có mô hình và khả năng tự chạy nó, nên tình trạng thiếu GPU lại có lợi cho họ
Hy vọng của họ phụ thuộc vào việc doanh nghiệp lớn và vừa/nhỏ chuyển toàn bộ quy trình làm việc lên cloud, rồi nhân viên thi nhau dùng càng nhiều token càng tốt
Mô hình “đủ tốt” cộng thêm quyền riêng tư và tiết kiệm chi phí dài hạn là rất hấp dẫn
Trớ trêu là môi trường thực thi đa dụng cho coding agent càng tốt thì hào lũy của các dịch vụ như Claude càng thu hẹp. Thật khó tin là chỉ trong vài tháng, một số mô hình mở đã bắt kịp các mô hình tuyến đầu nhanh đến vậy
Bài viết hay và cũng rất ấn tượng về mặt kỹ thuật. Tôi đồng ý rằng cần hiểu build pipeline và có thể chạy cục bộ
Tuy nhiên, xét theo giá điện thì có thể không kinh tế. Máy chủ cũ kém hiệu quả năng lượng, và tôi từng nghĩ máy chủ Xeon đời cũ sẽ ngốn khoảng 200W khi tải, trong khi cùng mô hình đó trên OpenRouter có giá 0,1/0,3 USD mỗi triệu token, 76 token/giây, context 262k
Hơn nữa, mấy máy chủ kiểu này còn ồn. Dù vậy, có vẻ ước tính 200W của tôi là quá cao; mấy máy chủ Xeon cũ tôi từng dùng đúng là ăn điện nhưng tôi không nhớ chính xác model nào
Máy chủ thường ồn, nhưng điều đó cũng phụ thuộc cấu hình. Có khá nhiều dịch vụ hosting giá rẻ dùng các chip kiểu này, và hiệu quả điện năng tốt hơn bạn nghĩ
Chạy cấu hình tương tự trong case 4U với quạt 120mm chậm thì ổn
Thật mừng khi thấy người khác cũng nhận ra điều này. Tôi đang chạy Gemma 26B-A4B Q4 trên một container với Xeon đời 2012 và RAM 16~24GB, đạt khoảng 8~12 token/giây
Không thể so với ngữ cảnh lớn hay chạy bằng GPU, và bộ giải mã hình ảnh của
llama.cppcũng chậm hơn GPU rất nhiều, nhưng với các tác vụ tự động hóa nhỏ hoặc câu hỏi kiến thức phổ thông thì vẫn ổn. Nó đủ nhanh để vừa đọc vừa theo dõi nên cảm giác chờ đợi cũng đỡ hơnCấu hình là bản build
llama.cppbật OpenBLAS và OpenMP,OPENBLAS_NUM_THREADS=4,OMP_NUM_THREADS=4,unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL, cacheq8_0, ngữ cảnh 8192 và các thiết lập tương tựTùy CPU mà nên tìm các tối ưu như AVX2, và tôi có thử MTP một chút nhưng không thấy cải thiện hiệu năng. Cũng có thể chỉnh kích thước batch cache/ngữ cảnh hoặc hạ xuống Q2, và tốt nhất là tránh cấp phát quá nhiều luồng. Tôi khuyên nên bắt đầu từ mặc định hoặc
llama-benchTrong lúc thử nghiệm tôi chạy
gemma4:e4b-it-q4_K_M, thứ này nằm gọn hoàn toàn trong 11GB VRAM, và đạt hơn 50 token/giây. Mẫu nhỏ cỡ đó không hữu ích lắm cho lập trình, nhưng có thể hợp cho mục đích khácTôi muốn làm kiểu Wake-on-Use để dùng như ChatGPT cá nhân. Có lẽ có thể đặt một Pi làm proxy rồi gọi script Wake-on-LAN, và biết đâu sau này sẽ thành một dự án cuối tuần thú vị
LLM luôn bật của tôi là dense
Gemma4:31b, thậm chí còn không nạp nổi một nửa lên chiếc 2060 12GB, rất chậm nhưng chất lượng tốt, và vì dùng cho xử lý hàng đợi tự động nên tôi không phải ngồi nhìn đầu ra. Tôi còn một chiếc 2060 nữa, nhưng cắm cả hai vào thì PC không POST đượcTôi đã cân nhắc Mac Studio Pro một thời gian, rồi cuối cùng lại đi theo hướng này. Tôi dựng một máy HP Z620 headless với 192GB RAM ECC, dual Xeon E5-2680 v2, Optane AIC, hai card P102-100 VRAM 10GB, một SSD khởi động tối thiểu cài Debian 12.6, và một phiên bản CUDA cũ cố định để hỗ trợ card Pascal
Tôi dùng AMT/meshcommander từ xa dưới tầng hầm, chạy
llama.cppcùng frontend rồi truy cập qua mạng nội bộ. Tôi đang nghịch Talkie, Qwen 3.6 27b, medgemma, và nếu chọn lượng tử hóa phù hợp thì hiệu năng GGUF nhìn chung khá ổnTổng chi phí dưới 500 đô, nhưng tôi mua máy chủ này trên eBay từ năm ngoái nên bây giờ có thể đã khác
Về sau, nếu LLM tam phân thực sự nở rộ, tôi hy vọng phần cứng cũ này sẽ có thể lưu trữ các mô hình mật độ cao nhưng đầy kiến thức. Kể cả lớn hơn RAM GPU và tràn sang Optane cũng không sao, vì kiến thức sự thật phổ quát quan trọng hơn tốc độ
Kế hoạch cuối cùng là cấu hình xong rồi cất nó vào thùng rác Faraday dưới tầng hầm, để khi thế giới sụp đổ thì nó còn làm một nhà tiên tri phục vụ “tái thiết văn minh”. Tất nhiên trong tình huống đó điện mới là vấn đề, nhưng nếu phần cứng này rẻ đến vậy và AI hiện đại lại thực dụng trong nhiều khoảnh khắc như thế, thì cũng đáng thử
Điều thú vị nhất trong tiến bộ AI không phải AGI hay mẫu mới nhất từ một kỳ lân AI nào đó, mà là có thể chạy được gì cục bộ
6 năm trước người ta có thể chạy các mô hình vui vui nhưng gần như vô dụng trên PC gaming cấu hình mạnh, còn bây giờ một chiếc laptop M5 có thể chạy thứ tốt hơn gấp 100 lần
Nếu thị trường phản ứng với tình trạng thiếu bộ nhớ và Apple silicon tiếp tục tiến bộ với cùng tốc độ, thì những gì có thể chạy cục bộ sau 6 năm nữa sẽ rất thú vị hoặc đáng sợ
Tôi cũng không biết điều đó có ý nghĩa gì với định giá của các công ty AI. Trước đây tôi từng hỏi một nhân viên của một công ty như vậy câu tương tự tại một sự kiện, và anh ta không trả lời mà bỏ đi lấy cocktail
Kinh doanh AI thâm dụng vốn như các nhà máy kiểu cũ. Datacenter rất đắt, mô hình ngốn điện, và phần cứng nội bộ phải thay mỗi 3~4 năm
Các mô hình nhỏ hơn, chuyên biệt hơn đang gặm dần biên lợi nhuận từ phía dưới. Các tác vụ như phiên âm, giọng nói, nhận diện hình ảnh không cần mô hình khổng lồ
Không có lý do gì để kỳ vọng biên lợi nhuận cao như phần mềm truyền thống, và phần lớn lợi nhuận từ AI sẽ chảy về phía người tiêu dùng. Dù vậy, một vài tập đoàn khổng lồ như Microsoft, Google, Amazon, Meta có thể nhắm tới lợi thế chi phí nhờ kinh tế quy mô
Không cần loại đầu bảng như 5080, chỉ với một GPU gaming khá ổn là bạn đã có thể chạy các mô hình cục bộ tốt hơn mức tiên tiến nhất vào đầu năm 2025
Có thể bạn sẽ phải đổi mô hình tùy theo tác vụ muốn làm, và các siêu mô hình bao trùm mọi thứ vẫn còn là lãnh địa của datacenter
Nhưng phần lớn mọi người có công việc toàn thời gian và hai con thì không có thời gian lẫn năng lượng để vá lỗi và bảo trì. Hệ thống ngày càng phức tạp và bug cũng nhiều hơn. Đó là sự đánh đổi lâu đời giữa tự do và tiện lợi
Phần lớn người dùng không biết LLM là gì hay chạy thế nào. Nhiều người dùng LLM chỉ dùng thứ nơi làm việc cung cấp mặc định, và cả những người rành hơn một chút cũng có vẻ sẵn sàng trả phí thuê bao cho OpenAI hay Anthropic
Sẽ có một nhóm nhỏ nhưng tận tâm gồm những người dùng mô hình trọng số mở thích LLM cục bộ, còn số còn lại nhiều khả năng vẫn sẽ tiêu thụ từ các nhà cung cấp lớn. Nó có thể giống bức tranh lựa chọn hệ điều hành ngày nay, với thiểu số người dùng Linux và đa số dùng Windows, macOS, Chrome
Các game 5~6 năm tuổi rẻ hơn rất nhiều và chạy được trên phần cứng bình thường. Nhưng ngành này không đứng yên trong 5 năm, nên phần mềm mới đòi hỏi phần cứng tốt hơn vẫn liên tục xuất hiện
Kết quả mà tác giả bài gốc nêu trong phần bình luận là khoảng 12 token/giây
Đây là một nỗ lực ấn tượng hơn nhiều so với mức tôi nghĩ phần cứng này có thể làm được, nhưng vẫn còn thiếu khá xa so với mức cần thiết cho các phiên tương tác hội thoại thật sự thỏa đáng
Nhiều khi rẻ hơn 100~500 lần so với các mô hình tối tân, và số token/giây cũng có thể nhanh hơn 2~5 lần
Nếu dùng cho tác vụ nền thì hoàn toàn ổn
Nó có hoạt động, nhưng không phải mức thông lượng để dùng cho công việc nghiêm túc
E5-2620 v4 rất tuyệt. Tôi đã dùng nó 10 năm rồi, và từng định nâng cấp nhưng nhìn giá hiện tại thì dừng lại
Tôi gắn 64GB DDR4 với RX 9060 XT 16GB và game vẫn chạy nhanh. Trong DOOM The Dark Ages thì CPU có thể hơi nghẽn cổ chai một chút, nhưng vẫn 60fps nên không thành vấn đề
Chạy LLM nhẹ trên GPU dĩ nhiên là lựa chọn hợp lý, và việc nó vẫn có thể chạy ổn trên CPU nếu tinh chỉnh tốt cũng rất hay
Một tháng trước tôi mua 2667 v4 với giá 30 đô và có vẻ mức tăng hiệu năng sẽ khá đáng kể, nhưng đến giờ vẫn chưa thật sự cần. Nếu muốn đẩy theo hướng LLM như trong bài thì có lẽ tôi sẽ nâng cấp, vì 2667 xử lý được RAM nhanh hơn một chút
Tôi vẫn khá ngạc nhiên trước những gì còn có thể tìm được ở thị trường đồ cũ
Tôi không ngờ giá RAM và GPU lại tăng mạnh như vậy, nhưng tình cờ lại mua đúng lúc. Tôi cũng từng nghĩ đến chuyện săn một con 3080 khoảng 300 đô trên eBay rồi bán 1080 Ti đi, nhưng ngoài chuyện đó ra thì đây là một bản nâng cấp tuyệt vời
Nó ngốn điện như Coca Cola, nhưng với vai trò workstation thì chạy rất tốt, nên tôi định ép nó làm việc cho đến khi hỏng
Trước đây tôi cứ nghĩ hư hại do nhiệt sẽ giết CPU sau khoảng 5~7 năm, nên tôi tự hỏi có phải đó là một giả định sai hay không. Cũng có thể CPU ngày nay mạnh và bền hơn trước rất nhiều
Gần đây có một bài tương tự liên quan đến tối ưu hóa Xeon đời cũ
“High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
https://news.ycombinator.com/item?id=47320244
Có vẻ bất ngờ là Itanium cũng khá hợp để chạy LLM: https://medium.com/@tglozar/running-llama-inference-on-intel...
Nghĩ kỹ thì cũng hợp lý
Nội dung khá thú vị. Tôi có một hệ thống Xeon đời cũ, chắc phải thử xem sao.