CanIRun.ai — Kann ich AI-Modelle auf meinem Computer ausführen?

 (canirun.ai)
40 Punkte von GN⁺ 2026-03-14 | 1 Kommentare | Auf WhatsApp teilen
  • Ein webbasiertes Tool, mit dem sich prüfen lässt, welche AI-Modelle eine lokale Maschine tatsächlich ausführen kann
  • Nutzt die WebGPU API des Browsers, um die Hardwareleistung abzuschätzen; die Ergebnisse können von den tatsächlichen Spezifikationen abweichen
  • Zeigt je Modell Speicherbedarf, Token-Verarbeitungsgeschwindigkeit, Kontextlänge, Ausführungsbewertung (S~F) usw. an
  • Enthält wichtige Open-Source- und kommerzielle Modelle wie Qwen, Llama, Gemma, Mistral, DeepSeek, GPT-OSS
  • Ermöglicht eine schnelle Einschätzung der lokalen AI-Ausführbarkeit und ist damit ein nützlicher Referenzwert für Entwickler und Forschende

Service-Überblick

  • CanIRun.ai ist eine Website, auf der sich AI-Modelle erkunden lassen, die in einer lokalen Umgebung ausgeführt werden können
    • Öffnen Nutzer die Website im Browser, sehen sie auf Basis der Systemleistung eine Liste der ausführbaren Modelle
    • Die Ergebnisse werden über die WebGPU API geschätzt und können von der tatsächlichen Hardwareleistung abweichen
  • Jedes Modell wird nach einer Leistungsbewertung (S~F) klassifiziert, sodass sich Ausführbarkeit und Effizienz intuitiv erfassen lassen

Modell-Bewertungssystem

  • Die Bewertungen sind in S, A, B, C, D, F unterteilt, wobei S die flüssigste Ausführung bedeutet
    • Beispiel: auf Basis einer NVIDIA GeForce RTX 4070 12GB
    • Qwen 3.5 9B, Llama 3.1 8B usw. werden als S (90/100) angezeigt und lassen sich flüssig ausführen
    • Phi-4 14B wird als A (70/100) angezeigt und „läuft gut“
    • GPT-OSS 20B, Mistral Small 3.1 24B usw. sind mit D (34~39/100) als „praktisch nicht ausführbar“ eingestuft
    • Darüber hinaus werden die meisten Modelle ab 27B wie Gemma 3 27B und Qwen 3 32B mit F (0/100) als „zu schwergewichtig“ angezeigt

Datenquellen und technische Grundlage

  • Die Modelldaten stammen aus llama.cpp, Ollama und LM Studio
  • Auf jeder Modellseite werden Speicherauslastung, Kontextlänge, Token-Geschwindigkeit, Architekturtyp (Dense/MoE) usw. detailliert angezeigt

Bedeutung in der Praxis

  • Bietet Entwicklern, Forschenden und Open-Source-Nutzern, die AI-Modelle direkt lokal ausführen möchten, eine praktische Referenz
  • Hilft beim Vergleich von Modellgröße und Effizienz im Verhältnis zur GPU-Leistung und unterstützt so die Auswahl geeigneter Modelle und Deployment-Strategien
  • Läuft browserbasiert und kann daher ohne Installation sofort getestet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-14
Hacker-News-Kommentare

  • In den letzten zwei Jahren habe ich enorm viel Zeit in Experimente mit lokalen Modellen gesteckt
    Kleine Modelle, zum Beispiel qwen3.5:9b, waren sehr gut für lokale Tools, Informationsextraktion und eingebettete Anwendungen geeignet
    Fürs Programmieren waren Cloud-basierte Tools wie Google Antigravity, gemini-cli oder Anthropic Claude effizienter
    Ich habe Emacs und Claude Code lokal eingerichtet und damit über 100 Stunden experimentiert, würde das normalen Nutzern aber nicht empfehlen
    Stattdessen halte ich den Sweet Spot für kleine, praktische lokale Embedded-Modelle, die man gut beherrscht

    • Ich kann qwen3.5:9b sehr empfehlen
      Das Modell ist klein, hat aber hervorragende multimodale Reasoning-Fähigkeiten, und sein internes Denkschema (CoT) ist stabil
      Besonders beeindruckend ist die neue Trade-off-Struktur zwischen VRAM und Kontextgröße — 100K Token lassen sich mit 1,5 GB VRAM verarbeiten, sodass auch auf einer RTX 3060 lange Gespräche oder Dokumente möglich sind
    • Ich habe qwen3.5 für lokale Tools ausprobiert, aber die Ergebnisse waren nicht besonders gut
      Bei einem Discord-Chatbot, der mit GPT-OSS-120B gut funktionierte, gab es bei Qwen das Problem, dass Tool-Aufrufe nur imitiert, aber nicht ausgeführt wurden
      Am Ende habe ich die Verarbeitung aufgeteilt: Bilder mit Qwen, normale Konversationen mit GPT
    • Ich habe qwen3.5 9b ausprobiert, aber die Halluzinationsrate war hoch
      Beim Durchsuchen lokaler Code-Repositories waren 30–50 % der Ergebnisse falsch und erfanden Dateinamen oder Funktionsnamen
      Nachprüfung mit KimiK2 zeigte, dass das meiste davon falsch war. Kleine Modelle sind gut, aber bei der Zuverlässigkeit ist Vorsicht geboten
    • Ich frage mich, wie andere kleine Modelle in reale Workflows integrieren
      Ich experimentiere auf einem M4 MacBook Pro (128 GB RAM) mit ollama, habe aber noch keinen zufriedenstellenden Ablauf gefunden
    • Ich frage mich, ob eine Kombination aus einem großen Modell für die Planung und einem kleinen lokalen Modell für das Schreiben von Code sinnvoll ist
      Ich würde meine Abhängigkeit von Claude Code oder Codex gern verringern

  • Diese Website scheint die Leistung eines Modells anhand von Speicherbandbreite und Modellgröße zu schätzen
    Bei MoE-Modellen (GPT-OSS-20B usw.) werden jedoch nicht bei jedem Token alle Parameter verwendet, weshalb auf derselben Hardware eine schnellere Tokengenerierung möglich ist
    GPT-OSS-20B hat 3,6B aktive Parameter und erreicht daher eine ähnliche Geschwindigkeit wie ein dichtes 3–4B-Modell, benötigt beim VRAM aber die Größe des gesamten 20B-Modells
    In Bezug auf Intelligenz wird es ungefähr auf dem Niveau eines dichten 8,5B-Modells eingeordnet

    • Tatsächlich war die Leistung der Modelle, die ich auf meinem Strix-Halo-Laptop getestet habe, viel besser als vorhergesagt
      Bei MoE-Modellen sollte man die Speicherbandbreite nur anhand der aktiven Parameter berechnen
    • Diese Berechnung scheint von der vollen Kontextgröße auszugehen
      In der Praxis reicht aber oft ein kleinerer Kontext aus
      llama-fit-params in llama.cpp ist in solchen Fällen nützlich
    • Das wird in der Dokumentation auch klar erklärt
      Bei MoE-Modellen wie Mixtral 8x7B sind von 46,7B nur etwa 12,9B aktiv
      Man bekommt also die Qualität eines großen Modells und die Geschwindigkeit eines kleineren Modells zugleich, aber das Gesamtmodell muss weiterhin komplett im Speicher liegen
      canirun.ai-Dokumentation
    • Es gibt allerdings eine kleine Ungenauigkeit
      Die Geschwindigkeit der Tokengenerierung ist ähnlich, aber die Prefill-Geschwindigkeit ist bei großen MoE-Modellen langsamer
      Außerdem kann man mit speculative decoding bei kleinen dichten Modellen bis zu 3x Geschwindigkeitsgewinn erreichen, während MoE-Modelle davon fast nicht profitieren

  • Ansätze wie TFA oder llmfit sind gut, aber es frustriert mich, dass es schwer ist herauszufinden, welches Modell auf meiner Hardware die beste Qualität liefert
    Zum Beispiel läuft Qwen 3.5 27B Q6 @ 100k Kontext gut, aber in der Empfehlungsliste wird zuerst das ältere Qwen 2.5 genannt
    Mir reichen über 50 tok/s, daher wäre es gut, nach Qualität sortieren zu können

    • Die Frage ist zu allgemein
      Zum Beispiel: „Open Model hoher Qualität fürs Coding bei 8 GB VRAM, 32 GB RAM, t/s ≥ 30, Kontext ≥ 32K“ → Qwen2.5-Coder-7B-Instruct
      „Für Web-Recherche bei 24 GB VRAM, 32 GB RAM“ → Qwen3-30B-A3B-Instruct-2507
      „Für RAG-Embeddings bei 40 GB VRAM, 128 GB RAM“ → Qwen3-Embedding-8B
      Es braucht also konkrete Modellempehlungen je nach Hardware
    • Mich würde die Kosteneffizienz lokaler Ausführung ($/Mtok) interessieren
      Abgesehen vom Strom ist es fast kostenlos, aber Geschwindigkeit und Qualität sind schwächer
      Vielleicht bevorzugen Leute lokal ja einfach wegen Datenschutz?
    • Das ist wirklich schwierig, und ich beschäftige mich auch schon seit über einem Jahr damit
      Wenn man gleichzeitig mehrere Geräte und Modelle berücksichtigen und Qualität und Ressourcenverteilung optimieren will, explodiert die Komplexität schnell
      Im Moment habe ich mich damit arrangiert, einfach das größte quantisierte Modell zu wählen
    • LLMs sind letztlich nur spezialisierte Taschenrechner
      Sie müssen nicht wie normale Taschenrechner exakt sein, und weil die Ziele der Modellhersteller und Nutzer unterschiedlich sind, ist es schwer vorherzusagen, welches Ergebnis man bekommt

  • Das sieht einfach nach der Web-Version von llmfit aus
    llmfit GitHub-Link

    • Stimmt. Aber llmfit ist viel nützlicher, weil es Systemressourcen automatisch erkennt
    • Danke für den Link. Tatsächlich ist das deutlich nützlicher als die Website
      Sogar auf meinem M2 Max MBP (96 GB RAM) wird angezeigt, dass die meisten lokalen LLMs gut laufen
      Ich war überrascht, wie viele lokal ausführbare Modelle es doch gibt

  • Als leichtere Alternative zu Docker oder Python empfehle ich einen Rust+Wasm-Stack
    LlamaEdge-Projekt

  • Meine RTX 6000 Pro Max-Q (96 GB VRAM) wurde zwar korrekt erkannt, aber in der UI als 4 GB angezeigt
    Außerdem werden nur Modelle in voller Auflösung gezeigt, quantisierte Modelle werden nicht berücksichtigt
    Das sollte verbessert werden

  • Die Liste mobiler GPUs ist unzureichend, und Strategien wie gemeinsam genutzter CPU-Speicher oder KV-Cache-Offloading werden offenbar nicht verstanden
    Mein System wird als Arc 750 (2 GB Shared RAM) angezeigt, tatsächlich ist es aber eine RTX1000 Ada (6 GB GDDR6)
    Qwen3 Coder Next, Devstral Small, Qwen3.5 4B usw. laufen fast in Echtzeit gut
    Größere Modelle sind langsamer, aber Token-Knappheit gibt es nicht

  • Tolle Idee
    Ich nutze allerdings ein M3 Ultra (256 GB RAM), und als Option gibt es nur bis 192 GB
    Es wäre auch gut, wenn man ein Modell auswählen und die Leistung nach Prozessor vergleichen könnte

    • Leider hat Apple das 512-GiB-Modell eingestellt

  • Ich habe gerade zum ersten Mal gemerkt, dass mein Browser Hardwareinformationen automatisch an Websites weitergibt

    • In Wirklichkeit ist das nicht vollständig präzise
      Die Website erkennt mich als iPhone 19 Pro, tatsächlich habe ich aber ein iPhone SE der 1. Generation
    • Bei aktuellem Librewolf wird um WebGL-Zugriff gebeten
      Vermutlich wird damit die Hardware erkannt
    • Solche Informationen werden oft für Browser-Fingerprinting verwendet
      Datenschutzorientierte Browser liefern zufällige Informationen zurück
    • Ich vermute, dass Fluggesellschaften auf diese Weise auch je nach OS unterschiedliche Preise festlegen

  • Es wirkt seltsam, dass es zwischen M4- und M5-Chips gar keinen Leistungsunterschied zu geben scheint
    Auch die Speichergröße scheint die Leistung bei großen Modellen nicht zu beeinflussen
    Insgesamt wirkt es eher wie eine schätzungsbasierte Darstellung statt echter Messdaten, daher wäre ein Hinweis „ESTIMATE“ sinnvoll