- Tổng hợp trong một kho lưu trữ cấu hình phần cứng, thiết lập switch PCIe và cấu hình chạy Docker để vận hành LLM đẳng cấp hàng đầu cùng chuyển đổi giọng nói-thành-văn bản ngay trên máy cục bộ
- Mức ngân sách khoảng $2k nhắm tới cấu hình 2× RTX 3090 để có 48GB VRAM, chạy Qwen3.6-27B và STT cục bộ dựa trên
whisper-large-v3
- Mức ngân sách khoảng $40k giả định cấu hình 4× RTX PRO 6000 Blackwell Workstation để có 384GB VRAM và đạt mức thông minh mô hình khá gần Claude Opus
- Hệ thống thực tế 4× RTX 6000 Pro kết hợp thân máy dựa trên EPYC/DDR4 hàng cũ với switch PCIe Gen4 c-payne, để xử lý giao tiếp P2P giữa các GPU ngay trong fabric của switch thay vì qua CPU root complex
- Sau khi tinh chỉnh cả BIOS, GRUB, ACS và giới hạn điện năng, P2P đạt 27.5GB/s một chiều, 50.4GB/s hai chiều và độ trễ 0.37–0.45µs, chạm line-rate Gen4
Các mức ngân sách để chạy LLM cục bộ
- Cấu hình này hướng tới người dùng muốn chạy các mô hình đẳng cấp hàng đầu và chuyển đổi giọng nói-thành-văn bản ngay trên máy cục bộ
- Kho lưu trữ bao gồm phần cứng đang dùng, lý do mua, mẹo cấu hình, cách chạy STT cục bộ và cấu hình chạy mô hình dựa trên container Docker
- Có ghi chú rằng ngoại trừ bảng trong README, phần nội dung còn lại không do AI viết
-
Cấu hình khoảng $2k
- Đề xuất cấu hình 2× RTX 3090 để đạt tổng cộng 48GB VRAM
- Với cấu hình này có thể chạy Qwen3.6-27B
- STT cục bộ dùng whisper-large-v3, và dùng bộ khung
stt đa nền tảng để truy cập
./runners/stt có cấu hình STT sẵn sàng chạy, giả định chỉ có khoảng 11GB VRAM trên GPU Nvidia- STT cục bộ được xem như một công cụ thuận tiện hơn so với dịch vụ hosted
-
Cấu hình khoảng $40k
- Giả định cấu hình 4× RTX 6000 Pro để đạt tổng cộng 384GB VRAM
- Ở tầm giá này, được mô tả là đã đạt tới mức thông minh mô hình khá gần Claude Opus
- Tính đến 2026-07, mô hình tốt nhất hiện tại cho 4× RTX6kPRO được nêu là
GLM-5.2-Int8Mix-NVFP4-REAP-594B
- Cấu hình chạy nằm tại
runners/GLM-5.2-594B
- Một hướng tiếp cận khác cũng được nhắc tới là nối cụm 4× DGX Spark để có 512GB VRAM, rồi để Qwen3.7-27B xử lý nhanh các tác vụ lặp bằng một “bộ não lớn” nhưng chậm
Phần cứng thực tế cho 4× RTX 6000 Pro
- Hệ thống thực tế được xây dựng xoay quanh 4× RTX PRO 6000 Blackwell Workstation
- Mỗi GPU có 96GB, tổng cộng 384GB VRAM, với giá khoảng $46,000
- Thân máy tận dụng EPYC đời cũ và linh kiện DDR4 mua trên eBay để giảm chi phí hệ thống cơ bản và dồn ngân sách cho VRAM
- Tính đến tháng 7 năm 2026, hệ thống dựa trên PCIe5/DDR5 rất đắt, nên chọn switch PCIe Gen4 và thân máy dùng DDR4
-
BOM hệ thống cơ bản
- Hệ thống cơ bản chủ yếu gồm các linh kiện EPYC đời cũ mua trên eBay
- Các linh kiện chính và giá như sau
- Bo mạch chủ ASRock Rack ROMED8-2T: $715
- CPU AMD EPYC Milan 7313P 16 nhân 3.0GHz: $504
- 8× 16GB Crucial DDR4 ECC RDIMM, tổng 128GB RAM: $642
- 2× PSU Super Flower 1700W: $750
- Switch PCIe c-payne Microchip Switchtec PM40100 Gen4: khoảng $1,330
- NVMe khởi động 4TB: $291
- 2× NVMe 8TB để chứa trọng số mô hình: $1,200
- Tổng hệ thống cơ bản là $5,587
-
Switch PCIe Gen4
- Dùng switch PCIe4 của c-payne để xử lý giao tiếp giữa các GPU gần như trực tiếp
- Ở bước allreduce của tensor parallelism, dữ liệu giữa các GPU di chuyển trong fabric của switch mà không đi qua PCI root complex
- BOM phụ cho switch là khoảng €1,220, tương đương khoảng $1,330 USD
- Switch PCIe Gen4 5× x16 dựa trên Microchip Switchtec PM40100
- SlimSAS PCIe Gen4 Host Adapter x16
- 2 cáp SlimSAS SFF-8654 8i
- Tự làm enclosure bằng gỗ cho GPU và switch PCI, mất khoảng một ngày
- Quạt tích hợp trên switch PCI quá ồn và có vẻ vô dụng nên đã tháo khỏi bo mạch
Lưu trữ trọng số mô hình và cách chạy
- Toàn bộ trọng số mô hình được lưu cục bộ trên filesystem ZFS được nhân bản trên hai ổ 8TB
- Filesystem được mount tại
~/storage
- Mô hình cần chạy được tải về cục bộ trước bằng lệnh sau
hf download <model-name> --local-dir ~/storage/<model-name>
- Mỗi mô hình đặt
docker-compose.yml trong thư mục riêng và chạy trong container Docker riêng của nó
- Cấu hình chạy nằm tại
./runners/
- Mỗi container mount
~/storage/models ở chế độ chỉ đọc để đọc trọng số đã cache
- Khi mô hình được phục vụ tại
http://clank.j.co:5000, có thể truy cập từ opencode được host trong VM trên máy khác
- Máy chủ DNS nội bộ ánh xạ
clank.j.co tới máy LLM, nhưng cũng có thể dùng dạng http://<llm-machine-ip>:5000
Bộ khung agent và cấu hình công cụ
- Trong một VM riêng, tác giả dùng ứng dụng tạo một phiên tmux cho mỗi thư mục trong cây
~/src, và chạy một instance opencode trong mỗi phiên
- Mỗi instance
opencode dùng http://clank.j.co:5000, tức HTTP API của máy suy luận, làm backend
- Yếu tố cốt lõi để tận dụng tốt mô hình nguồn mở được xem là cấu hình công cụ
- Phần tóm tắt
skills/ bao gồm các công cụ sau
- camofox, khóa API kagi.com, duyệt web và tìm kiếm qua searXNG
- Giao tiếp và thông báo qua bot Telegram
- Một instance Gitea cục bộ riêng tư để cộng tác mã nguồn
- Có thể dùng agent để cùng làm việc tương tác trong phiên, hoặc giao việc cho nó xử lý issue trên Gitea và tạo PR
- Công việc này chạy trong VM sandbox, và giao tiếp với host chỉ diễn ra qua mount filesystem dùng chung
Switch PCIe và thiết lập đa GPU
-
Thiết lập BIOS
- Trên bo mạch chủ ROMED8-2T, tác giả điều chỉnh thiết lập BIOS để tốc độ switch PCI không bị hạ xuống
AMD PCIE Link Width được đặt thành x16 cho khe cắm switch- Thiết lập chia nhánh x8/x8 trước đó khiến khe bị tách và liên kết upstream chỉ train ở Gen4 x8
- Cần cắm cả hai cáp SlimSAS 8i, mỗi cáp phụ trách x8
- PCIe Link Speed được ép ở Gen4
- Khi thiết bị Blackwell Gen5 tự thương lượng qua switch Gen4, quá trình train có thể thất bại và rơi xuống Gen1
- ASPM được đặt thành Disabled
- ASPM L1 sẽ hạ liên kết nhàn rỗi xuống 2.5GT/s
- Đây là nguyên nhân khiến trong
lspci trông như bị hạ xuống Gen1, nhưng dưới tải thì vẫn chạy Gen4
- Re-Size BAR được đặt thành Enabled
- Điều này cần thiết để lộ toàn bộ BAR VRAM 96GB và cho GPU P2P
- SR-IOV được đặt thành Disabled
- Đây là cấu hình để tránh overhead IOMMU và tránh cản trở P2P trong môi trường suy luận bare metal
- Preferred IO để Auto
- Có thể cải thiện độ trễ một chút nếu chỉ định thủ công bus
81 của switch c-payne, nhưng đó là tối ưu hóa chứ không phải sửa lỗi, và số bus có thể đổi sau khi chỉnh BIOS
-
Redriver và cáp
- Theo khuyến nghị của c-payne, tác giả dùng c-payne tool để hạ redriver gain xuống
lvl 3
- Mức gain phụ thuộc vào chiều dài cáp của đầu nối SAS
- Do đặt quá ít cáp từ c-payne, tác giả mua cáp SAS trông tương tự trên Amazon, nhưng khác biệt nhỏ đã gây sự cố nên phải đặt lại
Kernel, ACS và giới hạn điện năng
-
GRUB và NVIDIA UVM
- Đặt các tham số kernel sau trong
/etc/default/grub
GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
- Nếu không có
iommu=off, NCCL sẽ bị treo khi P2P đa GPU
- Để sửa P2P của NVIDIA UVM, áp dụng cấu hình sau
echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u
-
Vô hiệu hóa ACS
- Nếu ACS được bật mặc định, lưu lượng P2P sẽ không ở lại trong fabric của switch mà đi qua root port của CPU
- Khi đó hiệu quả của switch PCIe sẽ biến mất
- Vì
pcie_acs_override cần kernel đã vá, tác giả vô hiệu hóa ACS lúc runtime bằng setpci
- Khi khởi động, một dịch vụ systemd oneshot sẽ chạy
/usr/local/bin/disable-acs.sh
- Cách xác minh như sau
- Trong
lspci -vvv | grep ACSCtl, tất cả phải hiển thị dấu trừ
- Trong
nvidia-smi topo -m, bốn GPU phải hiện là PIX chứ không phải PHB/NODE
- Có thể dễ dàng đo băng thông và độ trễ P2P bằng
./tools/measure-gpu-speed.sh
-
Giới hạn điện năng GPU
- Để tránh phải lắp mạch 220V, hệ thống chạy trên một mạch 110V duy nhất nhưng có giới hạn điện năng GPU
- Dùng systemd để áp dụng persistence mode và giới hạn điện năng khi khởi động
sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
- Giới hạn điện năng GPU là 350W mỗi GPU, trong khi mặc định là 600W
- 4×350W tương đương tải GPU 1,400W, phù hợp với ngân sách PSU
- Ở giai đoạn chỉ có một PSU 1700W trước khi chuyển sang mạch 240V, GPU được chạy khoảng 260W
- 4×260W = 1,040W GPU
- Cộng thêm khoảng 280W cho hệ thống là tổng khoảng 1,320W
- Có thể xác minh bằng
nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv
Kết quả đo và tài liệu tham khảo
- Hướng upstream về CPU là Gen4 x16, khoảng 30GB/s
- P2P qua switch đạt 27.5GB/s một chiều, 50.4GB/s hai chiều
- Độ trễ là 0.37–0.45µs, ở mức line-rate Gen4
- Nếu ASPM được bật ở đâu đó,
lspci có thể hiển thị liên kết GPU downstream ở trạng thái nhàn rỗi là 2.5GT/s (downgraded)
- Hiển thị này chỉ mang tính bề ngoài; khi có tải, liên kết sẽ train lại lên Gen4
-
Resources
- local-inference-lab/rtx6kpro: kho lưu trữ được cập nhật thường xuyên về cách tận dụng 4, 6, 8 card RTX 6000 Pro
- c-payne: switch PCI độc lập được dùng trong cấu hình này
- RTX6kPRO Discord: máy chủ Discord thảo luận benchmark RTX6kPRO và thử nghiệm mô hình mới
1 bình luận
Ý kiến trên Hacker News
Tôi đã dùng khá nhiều LLM cục bộ và cũng chi quá tay cho phần cứng, nhưng cần hạ kỳ vọng và đọc kỹ các điều kiện chi tiết
Bản dựng lớn trong bài viết bắt đầu với ngân sách 40.000 USD, nhưng vì bao gồm 4 GPU giá 12.000 USD mỗi chiếc, nên thực tế gần với 50.000–55.000 USD hơn
Cấu hình cục bộ thường dựa vào các kỹ thuật như lượng tử hóa hoặc REAP để khớp mô hình với phần cứng. Có nhiều tuyên bố rằng lượng tử hóa 4-bit là không mất mát, nhưng đó là điều rút ra từ đo lường độ phân kỳ KL trên một corpus nhỏ; khi dùng cho các tác vụ lập trình với ngữ cảnh dài thì chất lượng giảm rõ rệt. Ngay cả trong các tác vụ không phải lập trình như phân tích dataset, cũng có thể đo được khá rõ khác biệt chất lượng giữa lượng tử hóa 4-bit, 8-bit, và đôi khi cả bản gốc 16-bit
Bài này cũng khuyên dùng mô hình REAP, nghĩa là ai đó đã cắt bỏ một số trọng số để làm mô hình nhỏ hơn. Ý tưởng là loại bỏ các trọng số kém hữu ích hơn cho một số tác vụ nhất định, nhưng chất lượng đầu ra tổng thể lại giảm tiếp
Cái bẫy là khi mọi người nói “chạy GLM-5.2 cục bộ”, nhìn benchmark thì có vẻ rất ấn tượng, nhưng thực ra họ không chạy GLM-5.2, mà chạy một mô hình phái sinh đã bỏ phần lớn bit và loại bỏ một số expert. Với các tác vụ rất nhỏ hoặc chat, khác biệt giữa mô hình lượng tử hóa/REAP và bản gốc không dễ thấy, nhưng trong các tác vụ dài hạn nơi các lỗi nhỏ tích lũy, khác biệt đó trở nên rất khó chịu
Rồi vì đã chi 50.000 USD rồi, bạn dễ rơi vào con dốc trơn kiểu: để tăng chất lượng thêm một chút và khiến khoản đầu tư đáng giá hơn, chỉ cần mua thêm một hai GPU giá 12.000 USD nữa
Với tác vụ lập trình, cần chia phiên thành nhiều lượt gọi. Tôi đã làm https://github.com/aka-rider/orqestra, nhưng với môi trường chạy công cụ hiện nay thì gần như ở đâu cũng có thể tự làm điều tương tự
Điểm mấu chốt là tách riêng phiên dùng để đọc code và gọi công cụ, vốn tiêu tốn ngữ cảnh, rồi tạo một báo cáo Markdown kiểu “code và tài liệu liên quan ở đây, bằng chứng là thế này” để giảm ảo giác. Phiên lập kế hoạch để riêng; vì mô hình nhỏ hay bỏ qua chi tiết nên cho critic và architect trao đổi qua lại 1–3 lần, rồi cũng cho worker và validator trao đổi qua lại vì cùng lý do
Qwen3.6 có thể ở chế độ chỉ đọc để tìm các bug phức tạp trong nhiều giờ và thường tìm ra. Bản sửa nó đề xuất có thể sẽ hơi hacky, nhưng Sonnet cũng vậy
Qwen3.6 có thể viết code một cách máy móc theo kế hoạch do Opus tạo ra. Sau đó cần prompt kiểu “hãy tự review thay đổi của bạn. Có bug không? Đối chiếu với kế hoạch ban đầu xem có thiếu gì không? Có vi phạm CLAUDE.md không?”. Nhưng việc này cũng phải làm y như vậy với Sonnet
Tôi cũng dùng LLM cục bộ để lập chỉ mục lại knowledge base. Khi xử lý ticket, chỉ cần để lại ghi chú thô như “một panel duy nhất để render lỗi, chuyển toàn bộ thông báo lỗi” là nó có thể trả lại một bản đặc tả hoàn thiện khoảng 90%, có mục tiêu và ngữ cảnh kèm theo
Nó thật sự tốt cho các tác vụ nhỏ, nhưng khi tôi giao tác vụ lớn đầu tiên, nó quên mất môi trường chạy agent là gì và bắt đầu dùng sai định dạng gọi công cụ. Nó đang chạy trên Pi, nhưng lại tin rằng mình đang chạy trong Claude và cố gọi các công cụ Claude không tồn tại
Nó không tự viết được cả ứng dụng, nhưng đã giúp tôi xử lý một vấn đề mạng phiền phức trong tailnet mà tôi không có thời gian hay động lực tự tìm hiểu, và tôi thường dùng nó cho những việc đơn giản nhưng chi phí điều tra cao nên trước đây không làm. Nó không phải Opus, nhưng hữu ích, và tôi không phải lo liệu mình có tận dụng được giá trị tương xứng với phí thuê bao hay chi phí API hay không
Những công cụ nhỏ như xử lý ngôn ngữ tự nhiên, tổng hợp giọng nói, xử lý ảnh, kỹ thuật âm thanh, xử lý tín hiệu, plugin diffusion cho Krita rất phù hợp với cấu hình cục bộ. Vài ngày trước tôi cũng có viết ngắn về chuyện này[1]
[1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...
Việc nói rằng “với khoảng 40.000 USD thì trí tuệ của mô hình sẽ lên một bậc, khá gần với Claude Opus” tương đương với chi phí dùng Claude Opus 4.8 hoặc Codex GPT 5.5 trong 16,8 năm, nếu tính theo mức 200 USD/tháng
Tôi thực sự thích chạy mô hình cục bộ, nhưng nó vẫn đắt đến phi lý, chất lượng thấp hơn, và nếu có backdoor thì còn có thể nguy hiểm. Thật lòng mong là không phải như vậy
Tuy vậy, tôi nghi ngờ liệu thiết bị cục bộ có thực sự xử lý được khối lượng sử dụng API trị giá 4.000 USD/tháng hay không. Vì thiết bị cục bộ khó chạy song song prompt hiệu quả như nhiều trung tâm dữ liệu của Anthropic
Các công ty như OpenAI và Anthropic vẫn đang bán gói dịch vụ với mức giá được trợ cấp bằng vốn đầu tư mạo hiểm, và nguồn vốn đó rồi sẽ muốn có lợi nhuận
Tôi đã dùng 1 tỷ token trong tháng đầu với OEM spark; nếu tính theo Opus thì lượng đó hơn 1.000 USD. Do mẫu hình token khác nhau nên đây không phải so sánh công bằng, nhưng sau đó nhờ các cải tiến của vLLM, chủ yếu là MTP, tốc độ cũng tăng 2–3 lần. DiffusionGemma nhanh hơn Gemma thường khoảng 4 lần
Bạn cũng đâu sở hữu đường truyền cáp quang, vậy tại sao lại muốn sở hữu thêm một tài sản khấu hao nhanh, đắt đỏ và phiền phức?
Thuê GPU cloud cho phép bạn tham gia vào văn hóa sở hữu, kiểm soát dữ liệu, kiểm soát giá và văn hóa hacking mà không cần dựng một cỗ máy Frankenstein khổng lồ cho sở thích. Cỗ máy đó đắt, bị chưng cất đến mức trên thực tế kém hữu dụng hơn, và bảo trì cũng rất đau đầu
Dù nói “40.000 USD là gần Opus”, nhưng nếu GLM 5.2 là “gần Opus” thì để suy luận thoải mái cần ít nhất 8xH200, tức là gần 400.000 USD hơn là 40.000 USD
Bài viết đề xuất dùng một mô hình đã chỉnh sửa: “GLM-5.2, khoảng 594B tham số, được cắt tỉa bằng REAP để loại bỏ khoảng 22% expert và lượng tử hóa bằng Int8-mix NVFP4”
Tôi tò mò nó sẽ hoạt động ra sao trong thực tế ngoài benchmark. Qwen3.6 cũng thường rơi vào vòng lặp khi suy luận ở lượng tử hóa 6-bit, còn ở đây thậm chí đã loại bỏ một phần expert. Đôi khi một mô hình nhỏ hơn ở 8-bit hoặc 16-bit có thể thông minh hơn một mô hình lớn bị ‘cắt thùy não’. Có vẻ mọi người đồng thuận rằng với coding thì tốt nhất không nên xuống dưới 8-bit
Ngoài ra cũng không rõ khi nhét mô hình đã bị ‘cắt thùy não’ vào 4 chiếc RTX 6000 thì còn lại bao nhiêu context khả dụng. Dưới 100k thường gần như khó dùng, vì hay phải nén trước khi gom đủ context cần thiết. Kiểm tra trong repository thì context là 240k
Muốn biết là hoàn toàn không chạy được, hay chậm đến mức không dùng nổi. Tôi muốn kiểm chứng build và khái niệm của một mô hình gần tuyến đầu ở local, rồi sau 18–24 tháng nữa khi giá GPU giảm mạnh thì bổ sung phần còn lại
Liệu như vậy có thể chạy đồng thời hàng trăm prompt không?
Nó có trong llamacpp. Người tạo ra heretic cũng đã tạo các chiến lược chống lặp và đa dạng hóa ở mức hiện đại
Không có nhu cầu thực tế phải chạy 8x H200, trừ khi bạn đơn giản là muốn làm vậy. Ngoại lệ là khi cần thường xuyên phục vụ nhiều người dùng hoặc agent đồng thời
Cũng có lựa chọn trung gian. Nếu có 128GB VRAM, hiện đã có nhiều lựa chọn đạt dung lượng đó nhờ kiến trúc bộ nhớ hợp nhất, và có thể chạy DeepSeek V4 flash ở tốc độ tốt thông qua DwarfStar
Tôi sẽ không bỏ tiền ra mua, nhưng với nhiều người thì mức này có vẻ là điểm thỏa hiệp phù hợp
Tuy nhiên phải dùng Pi. claude code có quá nhiều context bootstrap nên mọi thứ chậm hơn nhiều
“Với 2 chiếc RTX 3090, tổng cộng có 48GB VRAM thì có thể chạy Qwen3.6-27B, và đó là một mô hình tuyệt vời”, nhưng với 3.000 USD thì có thể mua M5 MacBook Pro có 48GB bộ nhớ dùng chung, mà lại không phải một cái thùng máy khổng lồ
Hoặc cũng đáng cân nhắc dùng số tiền đó cho các nhà cung cấp hosting đám mây. Ít nhất ở một mức nào đó, thậm chí có thể rẻ hơn nhiều. Dĩ nhiên, việc có thể chạy mô hình cục bộ vẫn là một điều rất hay
Nhưng chỉ sau khi dùng thử những thứ khá tốt như Gemma 4 31B và Qwen 3.6 27B, tôi mới nhận ra chúng hữu ích đến mức nào
Bạn sẽ thôi lo rằng mình đang chia sẻ thông tin nhạy cảm, thôi lo hết token, và cũng thôi lo về tính sẵn sàng của AI từ xa. LLM cục bộ rất có giá trị
Hai chiếc 3090 có tổng băng thông bộ nhớ 1,87 TB/s, mỗi chiếc 0,936 TB/s, trong khi M5 MacBook Pro chỉ có 0,3 TB/s. Chip Max tối đa 0,63 TB/s, nhưng cấu hình đó là một cỗ máy 10.000 USD
Vì vậy Qwen 27B chạy đủ nhanh cho công việc thực tế trên hai chiếc 3090, nhưng trên MacBook Pro thì chậm đến khó chịu. Ngoài ra, khi chạy mô hình lớn trên MacBook Pro, UI bị khựng và bàn phím nóng lên. Để hai chiếc 3090 dưới tầng hầm rồi truy cập từ MacBook thì tốt hơn nhiều
Không chỉ tốc độ sinh token, mà cả thời gian tới token đầu tiên, tức thời gian xử lý prompt, cũng khác. Phần cứng M5 tự thân rất tuyệt, nhưng GPU vẫn nhanh hơn nhiều
Chạy mô hình trên GPU box còn có lợi thế là có thể dùng laptop trên đùi mà không biến nó thành một cái đĩa nóng
Vì vậy cả prefill bị giới hạn bởi FLOPS lẫn decode bị giới hạn bởi băng thông đều sẽ chậm
Tuần này tôi vừa dựng LLM cục bộ, nên xin góp thêm trải nghiệm của mình. Tôi chọn một card 32GB tên Arc B70 của Intel; rẻ hơn 3090 và có nhiều RAM hơn, nhưng bus bộ nhớ chậm hơn
Tôi chọn nó vì các mô hình tôi muốn dùng hơi lớn để nhét vừa thoải mái trong 24GB, và tôi cũng cần thêm chỗ để chạy vài mô hình nhỏ cho tự động hoàn thành và nhận dạng giọng nói. Ngoài ra tôi đã có sẵn một server giá rẻ, còn nếu dùng dual GPU thì phải thay bo mạch chủ, bộ nguồn, và có lẽ cả case
Việc cấu hình khá rắc rối. Dòng Intel cần một gói driver gọi là “level zero” để hỗ trợ SYCL, đại khái giống CUDA phiên bản Intel, và làm cho nó chạy đúng khá khó. Tôi chạy llama.cpp trong container Docker, và cũng phải xử lý kha khá để container nhìn thấy card. Cũng cần kernel trong vài tháng gần đây
Khi đã chạy được rồi thì kết quả rất ấn tượng so với khoản đầu tư 1.000 USD. Chạy Qwen 3.6 35B với lượng tử hóa q4 dùng khoảng 3/4 RAM và đạt khoảng 88 token/giây. Nếu muốn một mô hình kích thước vừa phải với chi phí thấp, đây là một cách
B70 có bus 256-bit ở 2375MHz, 608 GB/s, còn 3090 có bus 384-bit ở 2438MHz, 936 GB/s. Không phải nó chậm hơn, mà là có ít kênh hơn, tức là bề rộng hẹp hơn
qwen3.6-27b có thể chạy biến thể q4 trên một chiếc 3090 với ngữ cảnh tổng cộng khoảng 250K
Nó đủ nhanh để không gây bực bội, nên mức tăng tốc khi dùng hai chiếc 3090 không đáng với tôi. Cũng có lựa chọn chạy q6 trên hai chiếc với tốc độ bằng một nửa và ngữ cảnh nhỏ hơn, nhưng dù sao cũng không cạnh tranh được với các mô hình hàng đầu hiện nay, nên nếu chưa có sẵn hai chiếc 3090 thì ở mức giá hiện tại, tôi nghĩ một chiếc là khoản đầu tư tốt nhất. Nếu có môi trường chạy được cấu hình tốt, như vậy đã đủ để làm rất nhiều việc
Theo kinh nghiệm của tôi, ở độ chính xác đó thì độ chính xác hồi tưởng trong ngữ cảnh dài giảm mạnh. Để KV cache ở q8 và làm việc với ngữ cảnh 120k thì tốt hơn
Liên quan đến chuyện này, tôi tò mò hệ thống cách ly tốt nhất có thể dùng ngay bây giờ là gì. Không rõ có cần đi tới mức VM dày hoàn chỉnh hay thứ gì đó giống Firecracker là đủ
Mỗi lựa chọn khả dĩ đều có những cạm bẫy tinh vi rất dễ tự bắn vào chân, và có vẻ rất dễ rơi vào tình trạng thực tế là chẳng có bảo mật gì. VM được dùng vì có thể thực sự tin rằng bảo mật là nguyên tắc nền tảng của công nghệ này, chứ không phải kiểu “dùng 20 flag này rồi nheo mắt lại thì sẽ ổn”
Trước tiên cần mô hình hóa vector tấn công.
rm -rfcó thể chặn bằng hạn chế ghi, còncurl malware.sh | shthì hạn chế thực thi trong các thư mục có thể ghi là được (seatbelt/SELinux). Chỉ riêng việc hạn chế ghi vào các thư mục nhạy cảm có khả năng vô hiệu hóa đáng kể phần lớn mã độcRò rỉ thông tin xác thực thì xử lý bằng cách dọn dẹp biến môi trường, cấm đọc .ssh, .aws, v.v., và không đặt LLM gần hệ thống vận hành
Tôi đã làm một tiện ích nhỏ cho MacOS https://github.com/aka-rider/leash, nhưng cũng có thể làm bằng bash script
Nếu muốn thứ nhẹ, có thể dùng kiểu bubblewrap[1], hoặc dùng microVM như libkrun[2]; nếu muốn cả bộ công cụ liên quan thì có thể đi tới Docker đầy đủ
[1] https://github.com/containers/bubblewrap
[2] https://github.com/libkrun/libkrun
Tôi đồng cảm với sự bất định rằng làm sao thực sự biết mọi thứ đã được khóa chặt
Cá nhân tôi nghĩ VM hoặc microVM là hướng đúng. Khác với container, chúng được thiết kế như những ranh giới bảo mật thực sự. Ngay cả khi so với bubblewrap, bạn có thể đưa cho agent toàn bộ filesystem và chạy ở chế độ YOLO, trong khi với bubblewrap phải bootstrap từng công cụ phát triển để dùng được, mount an toàn các thư mục cấu hình, cache gói, v.v., mà vẫn có khả năng liên tục gặp lỗi quyền. Mức cách ly cũng yếu hơn nhiều
Hỗ trợ môi trường thực thi còn hạn chế, nhưng tôi thấy cách chạy tiến trình môi trường thực thi trên host rồi ủy quyền toàn bộ lời gọi công cụ và tương tác filesystem cho VM là khá hợp lý. Như vậy có thể giữ dữ liệu phiên và khóa xác thực trên máy chính để chúng tuyệt đối không đi vào ngữ cảnh. Đổi lại, bản thân môi trường thực thi trở thành một phần của ranh giới bảo mật, đó là điểm đánh đổi
Cách chuyển dữ liệu vào/ra VM cũng là vấn đề về khả dụng. Tôi đang dùng script đẩy local git repository vào VM rồi lấy lại như một remote, như vậy VM không thể khởi tạo kết nối tới host và cũng không cần có thông tin xác thực git. Nhưng với người muốn agent push thẳng lên GitHub thì có thể là quá tốn công
Các lựa chọn về VM mà tôi đã thử hoặc đã thấy là qemu + libvirt, crun-vm, họ libkrun. qemu + libvirt mất công căn chỉnh nhưng đã được kiểm chứng rất kỹ và có khả năng cấu hình cao. crun-vm là một PoC về lớp tích hợp cấp cao giữa podman và qemu, có vẻ đã bị bỏ, nhưng thú vị vì xoay quanh công cụ hiện có và tiêu chuẩn. libkrun là một người chơi mới hơn và có các wrapper như microsandbox, smolvm, krunvm. Tất cả đều xét trên Linux
Cảm giác phải cố đến mức này để dùng LLM thật kỳ lạ. Đặc biệt là theo đuổi tối tân theo kiểu này thì càng vậy
Ngày mai những thứ như Claude biến mất thì tôi cũng chẳng chớp mắt
Tôi không hiểu vì sao người ta lại đổi nếp nhăn não của mình lấy quyền truy cập vào cỗ máy tạo slop. Nếu cần ví dụ tương tự hay, có lẽ giống như đưa cho một thợ mộc lành nghề một cái máy nhả ra đồ nội thất có chất lượng thấp hơn Ikea một hai bậc. Nó có làm được việc không? Phần lớn là có. Người thợ mộc có tận hưởng quá trình đó không? Không
Theo kinh nghiệm của tôi, khi chạy các mô hình bị lượng tử hóa nặng như q4 hoặc đã bị biến đổi ở mức nào đó, tôi chưa từng cảm thấy “wow, thật tuyệt vời”. Trái lại, sau vài lần prompt là tôi cho vào thùng rác
Tôi có RTX 6000 PRO 96GB, và thứ có thể chạy thoải mái là cỡ Qwen 3.6 27B hoặc MoE, Gemma 4 31B. Khi chạy mô hình ở độ chính xác đầy đủ và độ dài ngữ cảnh tối đa thì giới hạn là đến đó
Chúng có hiệu năng tốt và có thể dùng cho nhiều mục đích như lập trình, nghiên cứu trên internet, v.v. Nếu tính ra bạn có vẻ sẽ chi hơn 2.400 đô la mỗi năm cho Anthropic thì mua loại card như vậy có thể hợp lý, nhưng phải chấp nhận chất lượng giảm. Dù sao thì cũng còn chưa chắc 5 năm nữa con người có còn đang lập trình hay không