CanIRun.ai — Máy tính của tôi có thể chạy mô hình AI không?

 (canirun.ai)
40 điểm bởi GN⁺ 2026-03-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một công cụ nền web giúp kiểm tra những mô hình AI nào máy cục bộ thực sự có thể chạy được
  • Sử dụng WebGPU API của trình duyệt để ước tính hiệu năng phần cứng, nên kết quả có thể khác với thông số thực tế
  • Hiển thị theo từng mô hình các thông tin như yêu cầu bộ nhớ, tốc độ xử lý token, độ dài ngữ cảnh, xếp hạng chạy được (S~F)
  • Bao gồm các mô hình nguồn mở và thương mại chủ chốt như Qwen, Llama, Gemma, Mistral, DeepSeek, GPT-OSS
  • Giúp nhanh chóng đánh giá khả năng chạy AI cục bộ, nên có thể dùng như chỉ số tham khảo hữu ích cho nhà phát triển và nhà nghiên cứu

Tổng quan dịch vụ

  • CanIRun.ai là một website cho phép khám phá các mô hình AI có thể chạy trong môi trường cục bộ
    • Khi mở trang bằng trình duyệt của mình, người dùng có thể xem danh sách các mô hình có thể chạy dựa trên hiệu năng hệ thống
    • Kết quả được ước tính thông qua WebGPU API và có thể có khác biệt so với hiệu năng phần cứng thực tế
  • Mỗi mô hình được phân loại theo xếp hạng hiệu năng (S~F), giúp nhận biết trực quan khả năng chạy và mức độ hiệu quả

Hệ thống xếp hạng mô hình

  • Xếp hạng được chia thành S, A, B, C, D, F, trong đó S nghĩa là chạy mượt nhất
    • Ví dụ: theo tiêu chuẩn NVIDIA GeForce RTX 4070 12GB
    • Qwen 3.5 9B, Llama 3.1 8B được hiển thị là S(90/100) nên có thể chạy mượt
    • Phi-4 14B là A(70/100), tức là “hoạt động tốt”
    • GPT-OSS 20B, Mistral Small 3.1 24B là D(34~39/100), tức “gần như không thể chạy”
    • Ngoài ra, Gemma 3 27B, Qwen 3 32B và phần lớn các mô hình từ 27B trở lên được hiển thị là F(0/100), tức “quá nặng”

Nguồn dữ liệu và nền tảng công nghệ

  • Dữ liệu mô hình được thu thập từ llama.cpp, Ollama, LM Studio
  • Trong trang của từng mô hình có hiển thị chi tiết các thông tin như mức sử dụng bộ nhớ, độ dài ngữ cảnh, tốc độ token, loại kiến trúc (Dense/MoE)

Ý nghĩa ứng dụng

  • Cung cấp tài liệu tham khảo thực tế cho nhà phát triển, nhà nghiên cứu, người dùng nguồn mở muốn trực tiếp chạy mô hình AI trong môi trường cục bộ
  • Hỗ trợ xây dựng chiến lược chọn mô hình và triển khai phù hợp bằng cách so sánh kích thước mô hình và hiệu suất theo năng lực GPU
  • Hoạt động trên nền trình duyệt nên có ưu điểm là có thể thử ngay mà không cần cài đặt

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-03-14
Ý kiến từ Hacker News

  • Trong 2 năm qua tôi đã dành rất nhiều thời gian để thử nghiệm mô hình cục bộ
    Các mô hình nhỏ, ví dụ như qwen3.5:9b, rất phù hợp cho việc dùng công cụ cục bộ, trích xuất thông tin hoặc ứng dụng nhúng
    Với tác vụ lập trình, các công cụ đám mây như Google Antigravity, gemini-cli hoặc Anthropic Claude hiệu quả hơn
    Tôi đã thử hơn 100 giờ với việc thiết lập Emacs và Claude Code chạy cục bộ, nhưng không khuyến nghị cho người dùng phổ thông
    Thay vào đó, tôi nghĩ điểm ngọt ngào nhất là sử dụng tốt các mô hình nhúng cục bộ nhỏ nhưng thực dụng

    • Tôi rất khuyến nghị qwen3.5:9b
      Mô hình này tuy nhỏ nhưng có khả năng suy luận đa phương thức rất tốt, và hệ thống suy nghĩ nội bộ (CoT) khá ổn định
      Đặc biệt, cấu trúc đánh đổi mới giữa VRAM và kích thước ngữ cảnh rất ấn tượng — có thể xử lý 100K token với 1.5GB VRAM, nên ngay cả RTX 3060 cũng có thể xử lý hội thoại dài hoặc tài liệu dài
    • Tôi đã thử qwen3.5 cho công cụ cục bộ nhưng kết quả không tốt
      Con bot Discord vốn hoạt động ổn với GPT-OSS-120B lại gặp vấn đề trên Qwen: nó chỉ giả vờ gọi công cụ chứ không thực thi
      Cuối cùng tôi tách riêng: ảnh thì xử lý bằng Qwen, còn hội thoại thông thường thì dùng GPT
    • Tôi đã dùng qwen3.5 9b và thấy tỷ lệ hallucination khá cao
      Khi duyệt repo mã cục bộ, 30~50% kết quả bịa ra tên file hoặc tên hàm sai
      Kiểm tra lại bằng KimiK2 thì phần lớn đều sai. Mô hình nhỏ thì tốt thật, nhưng cần cẩn trọng về độ tin cậy
    • Tôi tò mò không biết mọi người tích hợp mô hình nhỏ vào workflow thực tế như thế nào
      Tôi đang thử nghiệm với ollama trên M4 MacBook Pro (128GB RAM), nhưng vẫn chưa tìm được luồng làm việc thật sự ưng ý
    • Tôi muốn biết liệu cách kết hợp lập kế hoạch bằng mô hình lớn và viết mã bằng mô hình cục bộ nhỏ có ổn không
      Tôi muốn giảm phụ thuộc vào Claude Code hay Codex

  • Có vẻ trang này đang ước tính hiệu năng dựa trên băng thông bộ nhớ và kích thước của mô hình
    Nhưng với mô hình MoE (như GPT-OSS-20B), không phải mọi tham số đều được dùng ở mỗi token, nên trên cùng phần cứng nó có thể sinh token nhanh hơn
    GPT-OSS-20B có 3.6B tham số hoạt động, nên tốc độ tương đương mô hình dense 3~4B, nhưng VRAM vẫn cần đủ cho toàn bộ mô hình 20B
    Về mặt năng lực, nó được đánh giá ở mức xấp xỉ mô hình dense 8.5B

    • Thực tế, trên laptop Strix Halo của tôi, hiệu năng của các mô hình thử nghiệm tốt hơn dự đoán rất nhiều
      Với mô hình MoE thì cần tính băng thông bộ nhớ dựa trên chỉ các tham số đang hoạt động
    • Có vẻ cách tính này dựa trên toàn bộ kích thước ngữ cảnh
      Nhưng trong sử dụng thực tế, nhiều khi chỉ cần ngữ cảnh nhỏ hơn là đủ
      llama-fit-params của llama.cpp rất hữu ích trong trường hợp này
    • Tài liệu cũng giải thích điểm này khá rõ
      Với mô hình MoE như Mixtral 8x7B, chỉ khoảng 12.9B trong tổng số 46.7B là được kích hoạt
      Tức là có thể vừa đạt chất lượng của mô hình lớn vừa có tốc độ của mô hình nhỏ, nhưng toàn bộ mô hình vẫn phải nằm trong bộ nhớ
      Tài liệu canirun.ai
    • Tuy vậy vẫn có một chút không chính xác
      Tốc độ sinh token thì tương tự, nhưng tốc độ prefill của MoE lớn chậm hơn
      Ngoài ra, nếu dùng speculative decoding, mô hình dense nhỏ có thể tăng tốc tới 3 lần, còn mô hình MoE thì gần như không được lợi gì

  • Những nỗ lực như TFA hay llmfit là đáng hoan nghênh, nhưng điều khiến tôi khó chịu là rất khó tìm được mô hình nào cho chất lượng tốt nhất trên phần cứng của mình
    Ví dụ, Qwen 3.5 27B Q6 @ 100k context chạy rất tốt, nhưng danh sách gợi ý lại ưu tiên Qwen 2.5 cũ hơn
    Với tôi chỉ cần trên 50 tok/s là đủ, nên sẽ rất hay nếu có thể sắp xếp theo chất lượng

    • Câu hỏi này quá rộng
      Ví dụ: “mô hình mở chất lượng cao cho lập trình, với 8GB VRAM, 32GB RAM, t/s ≥ 30, context ≥ 32K” thì là Qwen2.5-Coder-7B-Instruct
      “với 24GB VRAM, 32GB RAM để nghiên cứu web” thì là Qwen3-30B-A3B-Instruct-2507
      “với 40GB VRAM, 128GB RAM để làm embedding cho RAG” thì là Qwen3-Embedding-8B
      Tức là cần có khuyến nghị mô hình cụ thể theo phần cứng
    • Tôi tò mò về hiệu quả chi phí của chạy cục bộ ($/Mtok)
      Nếu không tính tiền điện thì gần như miễn phí, nhưng tốc độ và chất lượng lại kém hơn
      Không biết có phải mọi người thích chạy cục bộ đơn giản vì quyền riêng tư dữ liệu không
    • Vấn đề này thực sự rất khó, và tôi cũng đã nghiên cứu hơn 1 năm rồi
      Khi phải đồng thời cân nhắc nhiều thiết bị và mô hình để tối ưu chất lượng và phân bổ tài nguyên, độ phức tạp tăng bùng nổ
      Cuối cùng hiện tại tôi đành thỏa hiệp bằng cách đơn giản chọn mô hình quant lớn nhất
    • LLM rốt cuộc chỉ là máy tính chuyên dụng
      Không giống máy tính bình thường là phải chính xác, ở đây mục tiêu của người làm mô hình và người dùng khác nhau nên rất khó dự đoán kết quả mong muốn

  • Cái này trông đơn giản như phiên bản web của llmfit
    Liên kết GitHub của llmfit

    • Đúng vậy. Nhưng llmfit hữu ích hơn nhiều vì nó tự động phát hiện tài nguyên hệ thống
    • Cảm ơn vì đã chia sẻ liên kết. Thực sự hữu ích hơn website rất nhiều
      Trên chiếc M2 Max MBP (96GB RAM) của tôi, nó cũng cho thấy phần lớn LLM cục bộ đều chạy được
      Tôi khá ngạc nhiên vì có quá nhiều mô hình có thể chạy cục bộ hơn tôi nghĩ

  • Tôi khuyến nghị stack Rust+Wasm như một lựa chọn nhẹ hơn Docker hay Python
    Dự án LlamaEdge

  • Nó nhận diện đúng RTX 6000 Pro Max-Q (96GB VRAM) của tôi, nhưng trong UI lại hiển thị là 4GB
    Ngoài ra nó không tính đến mô hình lượng tử hóa, chỉ hiện các mô hình độ phân giải đầy đủ
    Cần được cải thiện

  • Danh sách GPU di động còn thiếu và nó cũng không hiểu các chiến lược như chia sẻ bộ nhớ CPU hay offload KV cache
    Hệ thống của tôi bị hiện là Arc 750 (2GB RAM dùng chung), nhưng thực tế là RTX1000 Ada (6GB GDDR6)
    Qwen3 Coder Next, Devstral Small, Qwen3.5 4B đều chạy khá tốt gần như thời gian thực
    Các mô hình lớn hơn thì chậm, nhưng không gặp vấn đề thiếu token

  • Ý tưởng rất hay
    Nhưng tôi đang dùng M3 Ultra (256GB RAM) mà tùy chọn chỉ có đến 192GB
    Sẽ tốt hơn nếu có thể chọn mô hình và so sánh hiệu năng theo từng bộ xử lý nữa

    • Đáng tiếc là Apple đã ngừng mẫu 512GiB

  • Đây là lần đầu tôi biết trình duyệt tự động cung cấp thông tin phần cứng cho website

    • Thực ra nó không hoàn toàn chính xác
      Website nhận tôi là iPhone 19 Pro, nhưng thực tế tôi đang dùng iPhone SE thế hệ 1
    • Trên Librewolf mới nhất, nó yêu cầu quyền truy cập WebGL
      Có vẻ nó phát hiện phần cứng bằng cách đó
    • Loại thông tin này thường được dùng cho fingerprinting trình duyệt
      Các trình duyệt ưu tiên quyền riêng tư sẽ cung cấp dữ liệu ngẫu nhiên
    • Tôi nghĩ chuyện các hãng hàng không định giá khác nhau theo hệ điều hành cũng là nhờ kiểu này

  • Thật lạ khi trông như không có khác biệt hiệu năng nào giữa chip M4 và M5
    Dung lượng bộ nhớ cũng có vẻ không ảnh hưởng đến hiệu năng mô hình lớn
    Nhìn chung nó có vẻ dựa trên ước tính chứ không phải dữ liệu thực, nên cần có nhãn “ESTIMATE” rõ ràng

    • Trong các bài thử nghiệm ban đầu, M5 Max thực sự cho thấy hiệu năng được cải thiện
      Tham khảo: video về Apple M5 Max