Die Vision
Was Kuno ist, warum lokal statt Cloud sinnvoll ist, und wie eine Mini-Organisation aus spezialisierten Agenten besser funktioniert als ein einziges riesiges Modell.
Kuno ist kein weiterer Cloud-Chatbot mit einem Webinterface. Kuno läuft auf Hardware, die dir gehört, hört dir zu, antwortet mit einer Stimme - und koordiniert dabei still im Hintergrund ein Team kleiner, spezialisierter KI-Modelle. Dieses Kapitel erklärt die Idee dahinter, bevor du auch nur ein einziges Kabel ansteckst.
Vor diesem Kapitel: Du weißt, dass du etwas mit lokalen KI-Modellen bauen möchtest, aber die Architektur ist noch unklar. Am Ende: Du verstehst, was Kuno ist, warum Lokalität die richtige Entscheidung ist, und wie eine Mini-Organisation aus Spezialisten einem Monolithen überlegen ist.
Was ist Kuno?
Kuno ist ein sprachgesteuerter Heim-Assistent - aber nicht die Sorte, die du in eine Steckdose steckst und vergisst. Er wohnt auf vier Geräten, jedes mit einer eigenen Rolle. Du stellst ihm eine Frage, er denkt nach, koordiniert intern, und antwortet dir durch einen kleinen Roboter mit Mikrofon und Lautsprecher. Dabei verlässt keine einzige Anfrage dein lokales Netzwerk.
Der Name "Kuno" ist bewusst gewählt: kein Akronym, kein Produkt-Brand, sondern einfach ein Name - weil ein System, das mit dir spricht, einen Namen verdient.
Technisch gesehen ist Kuno ein Multi-Agenten-System. Im Kern läuft ein großes Sprachmodell (Nemotron-3-Nano-30B) als sogenannter Concierge: er nimmt deine Eingabe entgegen, entscheidet, welcher Spezialist gefragt werden soll, und fasst das Ergebnis zusammen. Die Spezialisten sind kleinere 4B-Modelle, die jeweils eine einzige Aufgabe beherrschen - Recherche, Code, Klassifizierung, proaktive Benachrichtigung.
Der wichtigste Unterschied zu kommerziellen Lösungen: Kuno hat keinen Subscription-Preis, keinen Privacy-Fallout, und keine Rate-Limits. Er läuft, solange du ihn anlässt.
Warum lokal?
Vor zwei Jahren war "lokal" gleichbedeutend mit "langsam und unbrauchbar". Das hat sich grundlegend geändert. Modelle wie Nemotron-3-Nano-30B oder Qwen-2.5-Coder-7B erreichen auf moderner Hardware Cloud-Niveau - bei einem Bruchteil der laufenden Kosten.
Privacy ist der offensichtlichste Grund. Alles, was du einem Cloud-Modell sagst, verlässt dein Netzwerk. Gespräche über Gesundheit, Finanzen, Pläne - der Anbieter loggt mit, trainiert eventuell damit, unterliegt fremder Jurisdiktion. Lokal heißt: die Daten bleiben auf deiner Hardware.
Latenz ist der zweite Grund. Ein API-Roundtrip zu einem US-Server kostet 300-800 ms, bevor die erste Token kommt. Ein lokales Modell auf dem DGX Spark antwortet in unter 100 ms. Bei einem Voice-System, das du täglich benutzt, ist der Unterschied spürbar.
Souveränität ist der dritte Grund. Cloud-APIs ändern ihre Preise, stellen Modelle ein, ändern ihr Policy-Framework. Dein lokales Modell läuft morgen genauso wie heute. Du entscheidest, welche Modellversion du verwendest - und wann du upgrast.
Kosten sind geringer als du denkst. Der DGX Spark kostet einmalig ~4.000 €. Für eine einzige GPU-intensiv verwendete Cloud-API-Lizenz zahlst du leicht 100-200 € im Monat. Die Amortisation ist in unter zwei Jahren erreicht, wenn du das System täglich nutzt.
Das Ziel von Kuno ist nicht, Cloud-Dienste grundsätzlich abzulehnen. Manche Aufgaben (Web-Suche, externe APIs) erfordern naturgemäß Netzwerkzugriff. Aber die Inferenz - das Nachdenken - findet lokal statt.
Die Mini-Organisation
Warum nicht einfach ein einziges, möglichst großes Modell? Das ist die naheliegende Frage, und die Antwort ist: weil spezialisierte Teams robuster sind als Einzelkämpfer.
Ein Generalisten-Modell muss gleichzeitig gut im Verstehen von Sprache, im Recherchieren, im Schreiben von Code, im Zusammenfassen und im Planen sein. Das führt zu Kompromissen. Ein Modell, das ausschließlich auf Code-Completion trainiert wurde, ist für diese Aufgabe schlicht besser als ein Generalist gleicher Größe.
Kuno bildet deshalb eine Mini-Organisation - fünf Rollen, koordiniert durch den Concierge:
┌────────────────────┐
│ Du (Sprache) │
└──────────┬─────────┘
↓
┌────────────────────┐
│ Concierge (30B) │ ← wertet Intent aus, routet
└──┬───┬───┬─────────┘
↓ ↓ ↓
Auxiliary Research Code
(4B) (4B) (4B)
↓ ↓ ↓
Notifier (proaktiv)
Concierge ist das Gehirn. Er versteht deine Anfrage, wählt den richtigen Spezialisten und fasst zusammen. Er läuft auf dem Nemotron-3-Nano-30B-Modell, gehostet auf dem DGX Spark, gesteuert vom Mac Mini.
Auxiliary klassifiziert Eingaben schnell, wenn der Concierge sich nicht sicher ist. Kleines Modell, niedrige Latenz.
Research kann Dokumente durchsuchen, lokale Wissensdatenbanken befragen oder - wenn konfiguriert - externe Quellen konsultieren.
Code schreibt, erklärt und debuggt Code. Läuft auf einem spezialisierten Code-Modell (z.B. Qwen-2.5-Coder).
Notifier ist der einzige Agent, der proaktiv handelt: Er beobachtet Ereignisse und spricht dich an, wenn etwas Relevantes passiert - ohne dass du fragst.
Diese Struktur macht das System wartbar. Wenn du ein besseres Code-Modell ausprobieren willst, tauschst du einen einzigen Spezialisten aus, ohne die anderen anzufassen. Wenn der Research-Agent langsam ist, kannst du ihn isoliert debuggen.
Im nächsten Kapitel siehst du den Hardware-Stack im Detail: welche vier Geräte Kuno ausmachen, was jedes kostet, und warum die Aufgabenteilung so aussieht, wie sie aussieht.