Skip to main content

Lokale KI statt teurer APIs: Ein ausführlicher Artikel zum Video

Die Preise für KI-Dienste in der Cloud sind für viele Entwickler inzwischen ein echtes Ärgernis. Monatliche Abos werden eingeschränkt, nutzbare Kontingente sinken, und wer ernsthaft mit KI arbeiten will, landet oft zwangsläufig bei API-Abrechnung nach Verbrauch. Genau an diesem Punkt setzt das Video an: Es zeigt, wie man sich eine lokale KI-Umgebung auf dem eigenen Rechner einrichtet – privat, offline-fähig, schnell und vielseitig einsetzbar.

Dabei geht es ausdrücklich nicht nur um einen simplen Chatbot. Gezeigt wird ein vollständiges Setup für:

  • lokales Chatten mit Modellen
  • Autocomplete in VS Code
  • agentisches Coding in VS Code
  • Nutzung lokaler Modelle über terminalbasierte Tools

Der große Mehrwert des Videos liegt darin, dass nicht nur Klick-für-Klick-Anweisungen gegeben werden, sondern die technischen Grundlagen sauber erklärt werden. Wer die Konzepte verstanden hat, kann sich auch in Zukunft bei neuen Modellen, neuen Tools und neuer Hardware selbst helfen.

https://youtu.be/UngVdAsQEiU

1. Warum lokale KI überhaupt sinnvoll ist

Die Ausgangsthese des Videos ist klar: Cloud-KI ist bequem, aber auf Dauer teuer, eingeschränkt und nicht privat. Lokale KI verspricht dagegen mehrere Vorteile:

  • keine laufenden API-Kosten
  • volle Datenhoheit, da Code und Eingaben auf dem eigenen Rechner bleiben
  • Offline-Nutzung
  • anpassbare Performance, je nach eigener Hardware
  • freie Wahl des Modells statt Bindung an einen Anbieter

Natürlich gibt es auch Nachteile. Lokale Modelle sind oft kleiner und im Durchschnitt schwächer als die größten Cloud-Modelle. Außerdem hängt die Geschwindigkeit stark von der eigenen Hardware ab. Dennoch zeigt das Video, dass lokale KI gerade für viele Coding-Workflows bereits heute erstaunlich brauchbar ist.

2. Die Grundlagen: Wie ein KI-Modell lokal läuft

Bevor konkrete Tools eingerichtet werden, erklärt das Video die wichtigsten technischen Bausteine. Das ist entscheidend, denn nur so versteht man später, warum ein Modell schnell oder langsam ist.

2.1 Parameter: Wie groß ein Modell ist

Fast jedes Sprachmodell wird über seine Anzahl an Parametern beschrieben. Im Video werden Beispiele wie 1B, 27B, 128B oder sogar 862B genannt. Das „B“ steht für Milliarden.

Die Grundregel lautet:

  • mehr Parameter = meist bessere Fähigkeiten
  • mehr Parameter = mehr Speicherbedarf
  • mehr Parameter = schwieriger lokal auszuführen

Ein Modell mit hunderten Milliarden Parametern ist auf normaler Consumer-Hardware praktisch nicht lokal nutzbar. Deshalb muss man für ein lokales Setup fast immer auf kleinere oder speziell komprimierte Varianten zurückgreifen.

2.2 Kontextfenster: Wie viel Information gleichzeitig verarbeitet werden kann

Neben den Parametern ist das Kontextfenster zentral. Es beschreibt, wie viel Text, Code oder sonstige Information das Modell gleichzeitig „im Kopf behalten“ kann.

Ein größeres Kontextfenster ist nützlich für:

  • große Codebasen
  • lange Unterhaltungen
  • agentische Aufgaben mit vielen Dateien
  • längere Bearbeitungsketten

Aber: Ein großes Kontextfenster kostet zusätzlich Speicher. Das heißt, auch wenn das Basismodell in den Grafikspeicher passt, kann ein zu groß eingestellter Kontext dazu führen, dass das Setup plötzlich deutlich langsamer wird.

3. GPU, VRAM und Arbeitsspeicher: Der eigentliche Flaschenhals

Der vielleicht wichtigste Teil des Videos ist die Erklärung, wo ein Modell überhaupt geladen wird.

3.1 VRAM ist der wichtigste Wert

Lokale Modelle laufen hauptsächlich auf der GPU, also der Grafikkarte. Relevant ist hier vor allem der VRAM (Video RAM), also der dedizierte Speicher der Grafikkarte.

Wenn ein Modell geladen wird, versucht das System, möglichst viel davon direkt in den VRAM zu packen. Das ist der schnellste Pfad.

Beispiel:

  • Hat eine GPU 16 GB VRAM, dann sollte das Modell inklusive Kontext möglichst in diese 16 GB passen.

3.2 Was passiert, wenn das Modell zu groß ist?

Wenn das Modell mehr Speicher braucht, als der VRAM bietet, passiert Folgendes:

  1. Der VRAM wird vollständig gefüllt.
  2. Der Rest wird in den normalen Arbeitsspeicher (RAM) ausgelagert.

Das funktioniert grundsätzlich, hat aber einen großen Nachteil:
Sobald Teile des Modells im normalen RAM liegen, sinkt die Geschwindigkeit drastisch.

Das ist einer der wichtigsten praktischen Punkte des Videos. Der Unterschied ist nicht nur ein bisschen spürbar, sondern kann enorm sein.

3.3 Mac vs. Windows/Linux mit dedizierter GPU

Das Video weist außerdem auf einen Unterschied zwischen Plattformen hin:

  • Macs mit Unified Memory teilen sich den Speicher zwischen CPU und GPU.
  • Windows-/Linux-Rechner mit dedizierter GPU haben getrennten GPU-Speicher und normalen RAM.

Unified Memory kann vorteilhaft sein, weil insgesamt mehr Speicher flexibel verfügbar ist. Dedizierter VRAM ist dafür oft performanter. Für das lokale KI-Setup zählt aber in beiden Fällen vor allem:
Wie viel nutzbarer Speicher steht real zur Verfügung?

4. Einstieg mit LM Studio

Als zentrales Werkzeug empfiehlt das Video LM Studio. Das ist eine Desktop-Anwendung, die das lokale Herunterladen, Laden und Bereitstellen von Modellen stark vereinfacht.

Warum LM Studio laut Video so gut für den Einstieg geeignet ist:

  • gute Benutzeroberfläche
  • einfache Modellsuche
  • Anzeige von Speicherbedarf
  • direkte Konfiguration von Ladeparametern
  • lokaler API-Server mit OpenAI-kompatiblen Endpunkten

Gerade für Einsteiger ist das wichtig, weil man nicht sofort mit Kommandozeilen-Tools und komplexen Inferenzservern kämpfen muss.

5. Modelle finden: LM Studio und Hugging Face

5.1 Direkte Suche in LM Studio

In LM Studio kann man Modelle direkt suchen, etwa nach Qwen. Das Tool zeigt dann:

  • Modellnamen
  • Parameterzahl
  • geschätzten Speicherbedarf
  • teilweise Fähigkeiten wie Vision, Tool Use und Reasoning

So lässt sich schnell einschätzen, ob ein Modell überhaupt zur eigenen Hardware passt.

5.2 Hugging Face als größere Modellbibliothek

Wenn LM Studio nicht alles anbietet, verweist das Video auf Hugging Face. Dort lassen sich Modelle nach Popularität, Parametern und Features durchsuchen.

Besonders hilfreich ist dort:

  • nach „trending“ sortieren
  • auf reasoning-fähige Modelle achten
  • Quantisierungen gezielt auswählen

6. Quantisierung: Der Schlüssel für lokale Nutzbarkeit

Ein zentraler Begriff des Videos ist die Quantisierung.

6.1 Was Quantisierung bedeutet

Vereinfacht gesagt wird ein Modell dabei so komprimiert, dass seine Gewichte mit weniger Genauigkeit gespeichert werden. Dadurch wird es deutlich kleiner.

Typische Stufen sind:

  • Q8
  • Q6
  • Q4
  • teils auch Q3 oder Q2

6.2 Der praktische Effekt

Je stärker quantisiert wird:

  • desto kleiner wird das Modell
  • desto leichter passt es in den VRAM
  • desto schneller läuft es lokal
  • aber desto eher verliert es etwas Qualität

Im Video wird Q4 als guter Startpunkt empfohlen. Das gilt heute tatsächlich oft als sinnvoller Mittelweg aus Qualität und Ressourcenbedarf.

6.3 Wichtige Konsequenz

Quantisierung ist für lokale KI praktisch unverzichtbar. Die meisten interessanten Modelle wären in ihrer ursprünglichen Form viel zu groß für Consumer-Hardware.

7. Welche Fähigkeiten ein Modell haben sollte

Das Video betont, dass man nicht nur auf Größe achten darf, sondern auch auf die Fähigkeiten des Modells. In LM Studio werden oft Eigenschaften angezeigt wie:

  • Vision: Bilder verarbeiten
  • Tool Use: Werkzeuge und Funktionen aufrufen
  • Reasoning: längeres, expliziteres Nachdenken

Gerade für Coding-Agenten ist Tool Use sehr wichtig.
Reasoning kann bei komplexeren Aufgaben ebenfalls hilfreich sein, kostet aber meist zusätzliche Zeit und oft auch mehr Ressourcen.

Für verschiedene Aufgaben empfiehlt sich deshalb nicht unbedingt ein einziges Modell für alles, sondern eher eine Aufteilung:

  • kleines, schnelles Modell für Autocomplete
  • größeres, intelligenteres Modell für Chat und Agenten

Diese Trennung ist einer der praktisch wichtigsten Tipps des Videos.

8. Modelle laden und konfigurieren

Ist ein Modell heruntergeladen, muss es in LM Studio geladen werden. Dabei zeigt das Video, dass man unbedingt die erweiterten Ladeparameter aktivieren sollte.

8.1 GPU Offload

Wenn das Modell vollständig in den VRAM passt, sollte der GPU Offload maximal gesetzt werden. Damit wird das Modell vollständig auf die GPU geladen, was maximale Geschwindigkeit bringt.

8.2 Kontextlänge

Die Kontextlänge sollte bewusst gesetzt werden. Wer nur chatten will, braucht nicht zwangsläufig extrem viel Kontext. Wer mit einem Agenten auf einer größeren Codebasis arbeitet, braucht deutlich mehr.

Der entscheidende Punkt:

  • mehr Kontext = mehr Speicherverbrauch
  • zu viel Kontext = Spillover in den RAM = starke Verlangsamung

9. Der große Performance-Unterschied: Alles im VRAM vs. Auslagerung in RAM

Das Video demonstriert die Geschwindigkeit sehr anschaulich.

Fall 1: Modell passt komplett in den VRAM

  • Antwortgeschwindigkeit: etwa 124 Tokens pro Sekunde

Fall 2: Modell plus Kontext passt nicht mehr komplett hinein

  • Teile landen im normalen RAM
  • Antwortgeschwindigkeit: etwa 24 Tokens pro Sekunde

Das ist ungefähr ein sechsfacher Geschwindigkeitsverlust.

Diese Demonstration ist einer der wichtigsten Punkte des gesamten Videos. Sie zeigt sehr klar, warum die Modellwahl, Quantisierung und Kontextgröße nicht bloß technische Nebensachen sind, sondern direkten Einfluss auf die Alltagstauglichkeit haben.

10. MoE-Modelle: Mehr Leistung auf begrenzter Hardware

Ein besonders interessanter Teil des Videos behandelt MoE-Modelle („Mixture of Experts“).

10.1 Was MoE bedeutet

Bei MoE-Modellen sind zwar sehr viele Parameter vorhanden, aber pro Anfrage werden nur bestimmte Teile aktiv genutzt. Deshalb spricht man oft von:

  • Gesamtgröße des Modells
  • Zahl der aktiven Parameter

Ein Modell kann zum Beispiel 35 Milliarden Parameter haben, aber nur 3 Milliarden davon pro Schritt aktiv nutzen.

10.2 Warum das nützlich ist

MoE-Modelle sind für lokale Setups spannend, weil man einen Teil der Gewichte auf CPU bzw. RAM auslagern kann, während die besonders relevanten Teile auf der GPU bleiben.

In LM Studio gibt es dafür einen Parameter wie:
„number of layers for which to force MOE weights onto the CPU“

10.3 Praktischer Nutzen

Das Video zeigt, dass ein großes Modell mit dieser Methode noch mit brauchbarer Geschwindigkeit laufen kann. Ohne die MoE-spezifische Verteilung würde das gleiche Setup fast unbenutzbar langsam werden.

Das ist ein sehr wichtiger Hintergrundaspekt:

  • Nicht jedes große Modell ist lokal völlig ausgeschlossen.
  • Mit der richtigen Architektur und Konfiguration lässt sich erstaunlich viel aus begrenzter Hardware herausholen.

11. Mehrere Modelle gleichzeitig laden

Für ein realistisches Entwickler-Setup reicht oft ein einzelnes Modell nicht. Das Video zeigt deshalb, wie man in LM Studio mehrere Modelle gleichzeitig lädt:

  • ein kleines Modell für Autocomplete
  • ein größeres Modell für Chat/Agenten

Das ist sinnvoll, weil die Anforderungen unterschiedlich sind:

Autocomplete

  • muss extrem schnell reagieren
  • darf klein sein
  • braucht keine maximale Intelligenz

Agenten/Chat

  • dürfen langsamer sein
  • profitieren von größerem Kontext
  • brauchen Tool Use und idealerweise Reasoning

Diese Arbeitsteilung erhöht die Nutzbarkeit des Setups enorm.

12. LM Studio als lokaler API-Server

Ein weiterer Kernpunkt: LM Studio dient nicht nur als Chat-App, sondern auch als lokaler Server, der OpenAI-kompatible API-Endpunkte bereitstellt.

Das ist deshalb so wichtig, weil viele Tools bereits mit OpenAI-kompatiblen APIs umgehen können. Wenn LM Studio lokal denselben Stil von Endpunkten anbietet, kann man zahlreiche Anwendungen daran anschließen, ohne viel Speziallogik.

Das bedeutet praktisch:

  • Viele Tools lassen sich einfach auf http://localhost:.../v1 umbiegen.
  • Ein echter API-Key ist lokal oft gar nicht nötig.
  • Man kann lokale Modelle in bestehende Workflows integrieren.

13. VS Code und Continue: Lokales Autocomplete

Für die IDE-Integration verwendet das Video zunächst die Erweiterung Continue.

13.1 Warum Continue?

Continue unterstützt:

  • Chat
  • Agentenmodus
  • Autocomplete
  • lokale Modellanbieter wie LM Studio

Gerade Autocomplete ist hier ein entscheidender Punkt, denn nicht alle VS-Code-KI-Erweiterungen erlauben dafür lokale Modelle.

13.2 Wichtige Einstellungen

Das Video empfiehlt, insbesondere zwei Dinge anzupassen:

  • Autocomplete Timeout erhöhen, z. B. auf 1000 ms
  • Debounce anpassen, also die Verzögerung nach dem Tippen

Der Hintergrund: Auch wenn das Modell lokal läuft, gibt es eine gewisse Latenz durch Anfrage, Verarbeitung und Rückgabe. Wenn der Timeout zu kurz ist, erscheint der Vorschlag nicht.

13.3 Das passende Modell für Autocomplete

Für Autocomplete sollte ein kleines Modell verwendet werden, etwa ein kleiner Coder-Ableger. Denn:

  • Autocomplete muss sich sofort anfühlen
  • ein zu großes Modell macht das Tippen zäh
  • leicht geringere Qualität ist hier akzeptabel

Das Video zeigt dafür ein Modell um ungefähr 1 GB Größe.

13.4 Konfiguration

In Continue wird das Modell über eine YAML-Konfiguration eingebunden. Relevante Punkte sind:

  • frei wählbarer Anzeigename
  • Provider = LM Studio
  • exakter Modellname aus LM Studio
  • API-Base = lokaler LM-Studio-Endpunkt mit /v1
  • Rolle = autocomplete

Dadurch weiß Continue, welches Modell als Autocomplete-Modell fungieren soll.

14. Agentisches Coding mit Continue

Neben Autocomplete zeigt das Video auch den Chat- und Agentenmodus in Continue.

14.1 Tool-Rechte richtig setzen

Wichtig ist hier die Konfiguration der Tools. Viele Aktionen sollten auf automatic gestellt werden, etwa:

  • Dateien lesen
  • Dateien erstellen
  • Dateien bearbeiten

Andere Dinge sollte man bewusst absichern, etwa:

  • Terminal-Kommandos nur nach Rückfrage
  • URL-Fetches nur nach Nachfrage

Das ist ein wichtiger praktischer Punkt:
Ein Agent ist nur dann nützlich, wenn er genügend Rechte hat, um wirklich zu arbeiten. Gleichzeitig sollte man riskante Operationen nicht unkontrolliert freigeben.

14.2 Modellfähigkeiten deklarieren

Für das Agentenmodell muss man in Continue u. a. angeben:

  • ob es Tool Use unterstützt
  • ob es Bildinput verarbeiten kann

Damit der Agent korrekt arbeitet, muss die Konfiguration also nicht nur auf die API zeigen, sondern auch die tatsächlichen Fähigkeiten des Modells widerspiegeln.

14.3 Praktische Demonstration

Im Video wird gezeigt, wie der Agent eine Datei test.ts erzeugt und darin console.log("test") bzw. sinngemäß einen Testinhalt schreibt. Das verdeutlicht: Das lokale Modell ist nicht nur ein Gesprächspartner, sondern kann tatsächlich in Projekten arbeiten.

15. GitHub Copilot mit lokalem Modell

Als zweite VS-Code-Variante zeigt das Video die Einbindung in GitHub Copilot, genauer über die Insider- bzw. Betaversion von VS Code.

15.1 Idee dahinter

Copilot kann inzwischen auch OpenAI-kompatible Modelle einbinden. Dadurch lässt sich LM Studio dort als lokaler Anbieter registrieren.

Konfiguriert werden:

  • Name des Anbieters
  • API-URL
  • ein beliebiger API-Key
  • die Liste der Modelle
  • Tool Calling / Vision / Tokenlimits

15.2 Wichtiger Hinweis

Das Video nennt aber auch einen Nachteil:
Diese Copilot-Integration scheint weiterhin eine Internetverbindung zu benötigen, da VS Code bzw. Copilot selbst noch mit GitHub kommuniziert.

Das heißt:

  • Das Modell selbst kann lokal laufen.
  • Die Benutzererfahrung ist angenehm.
  • Aber es ist nicht vollständig offline.

Das ist ein sehr relevanter Punkt, gerade wenn Datenschutz und völlige Unabhängigkeit wichtig sind.

16. Terminalbasierte Agenten mit „Pi“

Wer vollständig lokal und flexibler arbeiten will, bekommt im Video noch eine dritte Variante: ein terminalbasiertes Tool namens Pi.

16.1 Warum ein Terminal-Agent sinnvoll sein kann

Terminalagenten haben einige Vorteile:

  • direkter Zugriff auf Projekte
  • oft sehr effizienter Workflow
  • gute Integration in CLI-basierte Entwicklergewohnheiten
  • vollständiger unabhängig von IDE-Spezifika

16.2 Konfiguration

Auch hier ist das Grundprinzip wieder dasselbe:

  • Provider = LM Studio
  • Base URL = lokaler Endpunkt mit /v1
  • API-Typ = OpenAI-kompatibel
  • Modell-ID = exakt aus LM Studio
  • Kontextfenster übernehmen
  • Reasoning-Flag setzen, falls passend
  • Bildinput aktivieren, wenn unterstützt

Das Schöne daran: Genau das ist die eigentliche Lehre des Videos.
Wenn man einmal das Grundprinzip verstanden hat – lokaler OpenAI-kompatibler Endpoint, Modellname, Kontextgröße, Fähigkeiten –, dann wird die Einrichtung in jedem Tool im Grunde nur eine Frage der jeweiligen Konfigurationssyntax.

17. Praxisvergleich: Lokales Modell vs. Claude Sonnet

Das Video bleibt nicht bei Theorie und Setup stehen, sondern vergleicht lokale Modelle auch mit Cloud-Modellen anhand praktischer Beispiele.

17.1 Sudoku-App aus einem Prompt

Ein lokales Qwen-Modell erzeugte eine komplette Sudoku-App mit:

  • Schwierigkeitsgraden
  • Pencil Marks
  • Fehlerprüfung
  • Lösungsanzeige
  • Hinweisen

Dauer:

  • ungefähr 9 Minuten

Dasselbe Prompt wurde auch mit einem Claude-Sonnet-Modell ausgeführt.

Ergebnis:

  • ebenfalls etwa 9 Minuten
  • qualitativ ähnlich
  • mit leichten Unterschieden in der konkreten Umsetzung

Das zeigt: Bei generativen Aufgaben kann ein lokales Modell durchaus mithalten, zumindest wenn man Zeit akzeptiert und die Anforderungen nicht extrem sind.

17.2 Bugfix in einer größeren Codebasis

Spannender wird der Unterschied bei einer echten Fehlerbehebung in einer größeren Anwendung.

Aufgabe:

  • Bug in einem Videoeditor beheben

Ergebnis:

  • Claude Sonnet: ca. 45 Sekunden
  • lokales Qwen-Modell: ca. 2,5 Minuten

Beide kamen laut Video zur praktisch identischen Lösung.
Der Unterschied lag vor allem in der Zeit, die das lokale Modell brauchte, um die Codebasis zu lesen und zu verarbeiten.

Das ist eine sehr ehrliche und wichtige Einordnung:

  • Lokale Modelle sind machbar und oft erstaunlich gut.
  • Große Cloud-Modelle sind bei komplexen Analysen oft noch schneller.
  • Der Vorteil lokal liegt eher bei Kostenkontrolle, Datenschutz und Unabhängigkeit.

18. Was man aus dem Video wirklich mitnehmen sollte

Der größte Wert des Videos liegt nicht in einzelnen Modellnamen oder Toolversionen, sondern in den allgemeinen Prinzipien.

Die wichtigsten Lehren sind:

1. VRAM ist der zentrale Engpass

Nicht die CPU-Leistung, sondern vor allem der verfügbare Grafikspeicher bestimmt, welche Modelle praktikabel laufen.

2. Das Modell muss zur Aufgabe passen

Nicht jedes Modell ist für alles ideal.
Autocomplete braucht etwas anderes als ein Coding-Agent.

3. Quantisierung ist entscheidend

Ohne Quantisierung sind viele Modelle lokal unbrauchbar.

4. Kontext kostet viel Speicher

Ein zu großes Kontextfenster kann ein eigentlich brauchbares Setup ruinieren.

5. Spillover in normalen RAM macht alles langsam

Sobald ein Modell nicht mehr komplett oder überwiegend im VRAM liegt, bricht die Geschwindigkeit stark ein.

6. MoE-Modelle können ein cleverer Mittelweg sein

Gerade bei begrenzter Hardware sind sie ein interessanter Hebel.

7. OpenAI-kompatible APIs sind der Integrationsschlüssel

Sobald LM Studio als lokaler API-Server läuft, lassen sich viele Tools relativ ähnlich anbinden.

19. Für wen sich ein solches Setup lohnt

Ein lokales KI-Setup lohnt sich besonders für:

  • Entwickler mit sensiblem oder proprietärem Code
  • Nutzer mit hohem API-Verbrauch
  • Menschen, die unabhängig von Cloud-Abos arbeiten wollen
  • alle, die gern an ihrem Workflow feilen und Technik verstehen möchten
  • Entwickler, die oft offline oder mit lokalem Datenschutzanspruch arbeiten

Weniger geeignet ist es für Nutzer, die:

  • maximalen Komfort ohne Setup wollen
  • keinerlei Hardware-Ressourcen frei haben
  • immer das absolut stärkste Modell mit bestmöglicher Qualität erwarten

20. Fazit

Das Video ist im Kern eine sehr gelungene Einführung in die Welt der lokalen KI für Entwickler. Es verbindet praktische Anleitung mit technischem Verständnis und bleibt dabei erstaunlich konkret. Statt nur ein bestimmtes Tool oder ein bestimmtes Modell zu hypen, vermittelt es ein belastbares mentales Modell dafür, wie lokale Inferenz auf echter Hardware funktioniert.

Besonders stark ist dabei:

  • die klare Erklärung von VRAM, RAM, Kontext und Quantisierung
  • die realistische Demonstration von Performance-Unterschieden
  • der praktische Einsatz in LM Studio, Continue, Copilot und Pi
  • der Vergleich zwischen lokalem Modell und Cloud-KI

Die wichtigste Botschaft lautet letztlich:
Lokale KI ist kein magischer Ersatz für alle Cloud-Modelle, aber sie ist längst mehr als ein Experiment. Wer seine Hardware und die zugrunde liegenden Konzepte versteht, kann sich schon heute eine erstaunlich leistungsfähige, private und kostengünstige KI-Umgebung für den Entwicklungsalltag aufbauen.

Back to top