惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
博客园 - Franky
T
Tailwind CSS Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
月光博客
月光博客
人人都是产品经理
人人都是产品经理
雷峰网
雷峰网
Hugging Face - Blog
Hugging Face - Blog
有赞技术团队
有赞技术团队
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
阮一峰的网络日志
阮一峰的网络日志
C
Check Point Blog
爱范儿
爱范儿
T
The Blog of Author Tim Ferriss
aimingoo的专栏
aimingoo的专栏
Stack Overflow Blog
Stack Overflow Blog
博客园 - 聂微东
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
L
LangChain Blog
云风的 BLOG
云风的 BLOG
MyScale Blog
MyScale Blog
Microsoft Security Blog
Microsoft Security Blog
The Cloudflare Blog
博客园 - 三生石上(FineUI控件)

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
I built a site that tells you if your machine can run a H...
Muhammad Illiyin · 2026-06-16 · via DEV Community

Muhammad Illiyin

I kept seeing the same question over and over:

"Can my laptop run this model?"

Not "is this model good?"

Not "how do I fine-tune it?"

Just: can I run it without setting my machine on fire?

So I built this:

canirunaimodel.vercel.app

It checks your hardware in the browser, pulls model info from Hugging Face, estimates memory needs, and gives you a simple answer: looks good, maybe tight, or probably not happening.

That was the idea anyway.

The problem

A lot of model pages tell you parameter count, context length, quantization options, maybe a few benchmark numbers.

What they do not tell normal people is:

"Will this run on my machine?"

And that is the part most people actually need first.

If you are not deep into local AI already, the jump from "7B model" to "works on my laptop" is weirdly annoying. You end up opening five tabs, reading Reddit threads, guessing VRAM requirements, and hoping someone with similar hardware already tried it.

I wanted something faster than that.

What the site does

The flow is simple:

  1. Detect your device hardware in the browser
  2. Fetch model metadata from Hugging Face
  3. Estimate VRAM and RAM requirements
  4. Tell you whether running it locally looks realistic

So instead of reading specs like you're decoding a secret message, you get a plain answer.

That was the goal: less "AI infrastructure puzzle", more "yes/no/maybe".

Why I made it in the browser

I like tools that do one job fast.

Also, hardware detection feels better when the site can just inspect what is already there instead of making users fill out a form like:

  • GPU?
  • VRAM?
  • RAM?
  • Browser?
  • OS?
  • Did you quantize it?
  • Are you feeling lucky?

The browser already knows a surprising amount. Not everything, obviously, but enough to make a useful call.

That makes the tool feel instant, which matters a lot for something this small.

The annoying part

The hard part was not making a pretty page.

The hard part was making the answer useful without pretending to be magically exact.

Because this stuff is messy.

A model might technically run, but only if:

  • you use a smaller quantized version
  • your context length is low
  • you are patient
  • you do not mind your laptop sounding like it is about to leave Earth

So I did not want the site to act overconfident. "Yes" is easy to say. "Yes, but this is going to be tight" is more honest.

That honesty is the whole product.

What I like about it

My favorite part is that it saves people from fake optimism.

A lot of AI tools make everything sound possible. Then you try it locally and discover "possible" means "after 40 minutes of fighting memory errors."

This one tries to be more useful than exciting.

If your machine can handle it, great.

If not, I would rather tell you early.

Try it

If you like small practical AI tools, the projects page has the rest of the stuff I've been building too:
https://www.milliyin.dev/projects

If you test the site on your machine, I genuinely want to know where it gets it right and where it gets humbled.