Tại sao hầu hết các công cụ tính toán VRAM (bộ nhớ truy cập ngẫu nhiên video) của mô hình ngôn ngữ lớn (LLM) lại không chính xác đối với các mô hình hiện đại (và một bản sửa lỗi mã nguồn mở theo giấy phép MIT).

🔗 Dùng thử — miễn phí, không cần đăng ký: fitllm.run ⭐ Mã nguồn mở (MIT, một tệp): github.com/click6067-ship-it/fitllm-engine Hầu hết các công cụ tính toán "tôi có thể chạy LLM này không?" ước tính bộ nhớ đệm KV bằng công thức sách giáo khoa: KV ≈ 2 × lớp × kv_heads × head_dim × ngữ cảnh × byte Công thức này giả định mỗi lớp giữ một bộ nhớ đệm KV toàn ngữ cảnh với một hình dạng đầu. Điều này đúng với Llama-1/2 — nhưng sai với hầu hết các mô hình năm 2025–2026: Gemma 4 là sự xen kẽ cửa sổ trượt 5:1:toàn cục — hầu hết các lớp chỉ giữ 1024 token cuối cùng, và các lớp toàn cục sử dụng hình dạng đầu khác. KV tỷ lệ với token. MoE giữ mọi chuyên gia thường trú ngay cả khi chỉ một vài chuyên gia được kích hoạt trên mỗi token. Vì vậy, con số đơn giản đã tính quá mức thuật ngữ bộ nhớ đệm KV — khoảng 4 lần trên Qwen 3.6, khoảng 11 lần trên Gemma 4 31B ở ngữ cảnh dài — đủ để thay đổi từ "không vừa" thành "vừa". (Một lỗi phổ biến thứ hai: áp dụng lượng tử hóa trọng số GGUF cho bộ nhớ đệm KV — llama.cpp giữ KV ở f16 theo mặc định; bit trọng số ≠ bit KV.) FitLLM đọc trực tiếp tệp config.json chính thức của từng mô hình và mô hình hóa các lớp cửa sổ trượt / tuyến tính / toàn cục / MoE một cách riêng biệt — nó tái tạo bộ nhớ đệm KV toàn ngữ cảnh 20,78 GiB đã công bố của Gemma 4 31B. Nó bao gồm Apple Silicon và NVIDIA RTX, và bạn có thể dán bất kỳ ID mô hình Hugging Face nào. Đây là một công cụ ước tính, không phải là sự thật tuyệt đối (đặc biệt là tok/s bị giới hạn bởi băng thông). Toàn bộ công cụ tính toán là một tệp MIT dễ đọc, vì vậy bạn có thể kiểm tra toán học, phân nhánh nó hoặc gửi yêu cầu sửa lỗi: 👉 https://github.com/click6067-ship-it/fitllm-engine Dùng thử: https://fitllm.run