- Tabby ist ein selbst gehosteter KI-Coding-Assistent, der als Open-Source- und On-Premises-Alternative zu GitHub Copilot angeboten wird und auf einen Betrieb ohne Cloud-Dienste abzielt
- Der Server setzt auf eine in sich geschlossene Konfiguration, die weder DBMS noch Cloud-Dienste benötigt, und ist mit einer OpenAPI-Schnittstelle so konzipiert, dass er sich leicht in bestehende Infrastruktur wie Cloud-IDEs integrieren lässt
- Als Laufzeitumgebung werden Consumer-GPUs unterstützt; mit einem einzigen Docker-Befehl lässt sich ein Server mit dem Code-Modell
StarCoder-1B und dem Chat-Modell Qwen2-1.5B-Instruct starten
- Zu den jüngsten Updates gehören v0.30, das GitLab Merge Requests als Kontext indexiert, v0.29, das eigene Dokumente per REST API hinzufügt, sowie v0.28, das Answer-Engine-Nachrichten in teilbare Pages umwandelt
- Dokumentation zu IDE-/Editor-Erweiterungen, Installation und Konfiguration sowie ein Contribution Guide werden bereitgestellt; mit vorbereiteter Rust-Umgebung und einigen Abhängigkeiten lässt sich Tabby per
cargo build selbst bauen
Rolle und Grundfunktionen von Tabby
- Tabby ist ein selbst gehosteter KI-Coding-Assistent und eine Open-Source- sowie On-Premises-Alternative zu GitHub Copilot
- Die wichtigsten Merkmale lassen sich in drei Punkte zusammenfassen
- In sich geschlossen, daher sind weder DBMS noch Cloud-Dienste erforderlich
- Stellt eine OpenAPI-Schnittstelle bereit und lässt sich dadurch einfach in bestehende Infrastruktur wie Cloud-IDEs integrieren
- Unterstützt Consumer-GPUs
- Das Projekt stellt Links zur Dokumentation, zu Slack und zur Roadmap bereit
- Eine Live-Demo kann auf der Tabby-Website geöffnet werden
Jüngste Änderungen
- 2025-12-12:
vscode@0.20.0 wird bereitgestellt; damit lassen sich GitHub-Issues mit Pochi-Tasks verknüpfen und umsetzen, außerdem können in der Sidebar PRs erstellt werden, inklusive Analyse von CI-/Lint-/Test-Ergebnissen
- 2025-07-02: v0.30 unterstützt das Indexieren von GitLab Merge Requests als Kontext
- 2025-05-25: Hinweise zur Teilnahme an der Warteliste für die private Preview des Agent werden bereitgestellt
- 2025-05-20: In v0.29 können eigene Dokumente über eine REST API zu Tabby hinzugefügt werden
- 2025-05-01: v0.28 wandelt Answer-Engine-Nachrichten in dauerhafte und teilbare Pages um
- 2025-03-31: v0.27 bietet ein umfangreicheres
@-Menü im Chat-Seitenpanel
Funktionsumfang aus früheren Updates
- Die Answer Engine wurde in v0.13.0 als zentrale Knowledge Engine für interne Engineering-Teams eingeführt und liefert Antworten durch Integration mit internen Daten des Entwicklungsteams
- Tabby hat Integrations- und Konfigurationsfunktionen wie GitLab SSO, selbst gehostetes GitHub/GitLab, HTTP-API-Integration und Repo-Kontext im Code Browser ergänzt
- Der IDE-Plugin-Workflow umfasst Updates für VSCode/Vim/IntelliJ, ein VSCode-Chat-Seitenpanel, Bearbeitung über Chat-Befehle, mehrere Auswahlmöglichkeiten bei Inline-Completion sowie automatisch generierte Commit-Nachrichten
- Code-Completion nutzt lokal relevante Snippets wie lokale LSP-Deklarationen und kürzlich geänderten Code; in v0.3.0 wurde RAG-basierte Code-Completion standardmäßig aktiviert
- Bei der Modellunterstützung werden unter anderem CodeGemma, CodeQwen, Codestral, experimentelle Unterstützung für CodeLlama 7B sowie Apple-M1/M2-Metal-Inferenz erwähnt
Einstieg und Ausführungsbeispiel
- Die Einstiegdokumentation ist unter Getting Started verfügbar
- Der einfachste Weg, den Server zu starten, ist die Nutzung eines Docker-Befehls
docker run -it \
--gpus all -p 8080:8080 -v $HOME/.tabby:/data \
tabbyml/tabby \
serve --model StarCoder-1B --device cuda --chat-model Qwen2-1.5B-Instruct
- Zusätzliche Optionen umfassen Einstellungen wie Inferenztyp und Parallelität und sind auf einer separaten Dokumentationsseite zu finden
Mitwirken und Build
- Der vollständige Contribution Guide steht in CONTRIBUTING.md
- Der Quellcode wird zusammen mit den Submodulen geklont
git clone --recurse-submodules https://github.com/TabbyML/tabby
cd tabby
- Wenn das Repository bereits geklont wurde, lassen sich mit
git submodule update --recursive --init alle Submodule abrufen
- Vor dem Build sind folgende Vorbereitungen nötig
- Rust-Umgebung einrichten
- macOS:
brew install protobuf
- Ubuntu/Debian:
apt install protobuf-compiler libopenblas-dev
- Nützliche Tools für Ubuntu:
apt install make sqlite3 graphviz
- Nach Abschluss der Vorbereitungen kann Tabby mit
cargo build gebaut werden
- Der Contribution-Workflow führt nach den Änderungen zur Einreichung eines Pull Requests
1 Kommentare
Meinungen auf Hacker News
Die Demo auf der Homepage, in der die Funktion
findMaxElementvervollständigt wird, wirkt wie ein gutes Beispiel dafür, wohin die Reise geht – oder vielleicht schon dafür, wo wir heute stehen.Die vorgeschlagenen sechs Zeilen Python für diese Funktion lassen sich einfach durch
return max(arr)ersetzen; sie funktionieren zwar, sind aber komplett Code auf Junior-Niveau.Dieser schreckliche Code an sich ist schon beunruhigend, aber noch mehr Sorge macht mir, dass Menschen, die so etwas blind per Autovervollständigung übernehmen, in ihrer Weiterentwicklung stehen bleiben könnten.
Man kann damit vielleicht Story Points sammeln, aber ob man dadurch als Entwickler tatsächlich besser wird, ist fraglich.
Um diese 20 % zu verstehen, muss man aber auch die 80 % verstehen, die das LLM übernommen hat. Deshalb mache ich mir keine großen Sorgen, solange das LLM nicht auch das Deployment komplett ersetzt.
So wie Maschinencode → Assembly → C → Python → LLM (natürliche Sprache): Die Prompts von Menschen werden gewissermaßen in Zwischencode wie Python kompiliert.
Die frühen Versionen von CPython waren sicher auch nicht perfekt, und Ingenieure dürften sich unwohl gefühlt haben. Mit etwas Glück wird auch dieser neue „Compiler“ immer besser und effizienter, aber perfekt wird er nicht sein.
Trotzdem könnte man am Ende ähnliche Kosten in Kauf nehmen wie jene, die man bereits dafür zahlt, dass Menschen nicht mehr direkt mit Assembly arbeiten.
Jetzt gibt es KI, und man fragt sie, ob sie es für einen erledigt; am Ende weiß man nichts mehr und kann auch nichts mehr selbst.
Ich hätte nicht erwartet, dass unser Projekt an einem Sonntag auf die HN-Startseite kommt.
Tabby hat sich seit der Veröffentlichung vor zwei Jahren stark weiterentwickelt https://www.tabbyml.com und ist inzwischen eine umfassende KI-Entwicklerplattform mit Code-Vervollständigung und Codebase-Chat.
Für Team- und Enterprise-Einsatz unterstützt es außerdem SSO, Zugriffskontrolle und Nutzerauthentifizierung https://demo.tabbyml.com/search/how-to-add-an-embedding-api-...
Nutzer, die Tabby eingeführt haben, stellten fest, dass es bei On-Premises-Bereitstellung die einzige Plattform mit vollständig Self-Service-Onboarding ist. Die Performance kann zudem mit anderen Optionen am Markt mithalten; wer neugierig ist, sollte es ausprobieren.
https://www.reddit.com/r/LocalLLaMA/s/lznmkWJhAZ
https://www.linkedin.com/posts/kelvinmu_last-week-i-introduc...
Als jemand, der sich mit lokaler KI nicht gut auskennt, sie aber gern ausprobieren würde, frage ich mich, wie „run tabby in 1 minute“ https://github.com/TabbyML/tabby#run-tabby-in-1-minute im Vergleich etwa zum kostenlosen 4o-mini von ChatGPT abschneidet.
Wenn man auf einem mittelklassigen MacBook Pro den folgenden Docker-Befehl ausführt, bekommt man dann eine KI mit ähnlicher Geschwindigkeit und ähnlichen Fähigkeiten, oder ist das noch nicht auf diesem Niveau?
docker run -it --gpus all -p 8080:8080 -v $HOME/.tabby:/data tabbyml/tabby serve --model StarCoder-1B --device cuda --chat-model Qwen2-1.5B-InstructOffenbar gibt es eine eigene Anleitungsseite für MacBooks mit etwas mehr Kontext https://tabby.tabbyml.com/docs/quick-start/installation/appl...
Dort steht: „Die Rechenleistung von M1/M2 ist begrenzt und kann für die persönliche Nutzung ausreichen; wenn man jedoch eine gemeinsam genutzte Instanz für ein Team benötigt, sollte man Docker-Hosting auf Basis von CUDA oder ROCm in Betracht ziehen.“
Sehr kleine Modelle wie 1.5B sind ziemlich dumm und eignen sich nicht gut für interaktive Codegenerierung, aber auch Modelle unter 3B können Tab-Completion-Vorschläge recht gut machen.
Es gibt auch größere „offene“ Modelle, die man lokal betreiben kann; Modelle im Bereich 32B bis 70B können in fast jeder Hinsicht, einschließlich Code-Schreiben, deutlich besser sein als gpt-4o-mini. Zum Beispiel sind
llama3.3-70b-instructundqwen2.5-coder-32b-instructziemlich ordentlich.Wenn wirklich wenig RAM vorhanden ist, können
qwen2.5-coder-7b-instructodercodegemma-7b-itfür einfache Aufgaben ebenfalls brauchbar sein.„Mittelklassiges MacBook Pro“ reicht als Beschreibung nicht aus; entscheidend ist, wie viel RAM vorhanden ist. Als Faustregel braucht man etwa 1 GB RAM pro 1B Parameter.
Bei starker Quantisierung sind es etwa 500 MB, bei nicht quantisierten Modellen etwa 2 GB; 8-Bit-Quantisierung liegt aber normalerweise bei rund 1 GB und ist im Allgemeinen in Ordnung.
Der „IDE-/Extension-Telemetrie-Toggle“ lässt sich in der Community Edition nicht abschalten. Ich frage mich, was in diesen Telemetriedaten enthalten ist.
struct HealthState {model: String,chat_model: Option,device: String,arch: String,cpu_info: String,cpu_count: usize,cuda_devices: Vec,version: Version,webserver: Option,}https://tabby.tabbyml.com/docs/administration/usage-collecti...
Ich nutze für ähnliche Zwecke Continue.dev und ollama, und es ist immer erfreulich, wenn es in diesem Bereich mehr Tools gibt.
Allerdings braucht man, wie üblich, ziemlich leistungsfähige Hardware, wenn man tatsächlich ein gutes Modell wie Qwen2.5-coder 32B betreiben will.
Die Beispiele sind allesamt Code, den man eigentlich eher in einer Bibliothek erwarten würde, und bei manchen Codebeispielen ist auch die Qualität fragwürdig.
Wird ein LLM zum Spam-Bot für Codebasen?
Laut „Wie man mehrere NVIDIA-GPUs nutzt“ unterstützt Tabby nur eine einzelne GPU; wenn man mehrere GPUs verwenden will, soll man mehrere Tabby-Instanzen starten und für CUDA
CUDA_VISIBLE_DEVICES, für ROCmHIP_VISIBLE_DEVICESsetzen.Dann frage ich mich, ob die Nutzung von zwei per NVLink verbundenen GPUs für Inferenz nicht unterstützt wird – oder ob das eine andere Situation ist, weil NVLink zwei GPUs wie eine behandelt.
Ein Beispiel findet sich unter https://tabby.tabbyml.com/docs/references/models-http-api/vl....
Tolles Projekt. Besonders gefällt mir die Idee, keine Daten an große Unternehmen schicken und deren AGB vertrauen zu müssen.
Die Wirksamkeit eines Coding-Assistenten ist direkt proportional zur Kontextlänge, aber offene Modelle, die auf einem privaten Rechner laufen können, sind meist deutlich kleiner.
Es wäre gut, Daten zu haben, die quantifizieren, wie nützlich das bei komplexeren Codebasen ist.
Mich interessiert die empfohlene Hardware. Braucht man eine GPU? Könnte es auf einer alten Ryzen-APU (Zen 3 und Vega-7-Grafik) noch brauchbar laufen?
Ob integrierte Grafik vorhanden ist oder nicht, macht keinen großen Unterschied; wenn man nur die CPU nutzt, läuft das Modell genauso sehr langsam.
Der Grund, warum Macs für LLMs einigermaßen brauchbar sind, ist die ungewöhnlich hohe Speicherbandbreite von Apple Silicon, aber an die Geschwindigkeit hochwertiger GPUs mit sehr schnellem VRAM kommen sie bei Weitem nicht heran.
Für ein sehr kleines Modell zur Tab-Vervollständigung dürfte auch eine alte AMD-CPU wahrscheinlich ganz ordentlich ausreichen.
Sehr cool. Besonders freut mich, dass es einen Eclipse-Client gibt: https://github.com/TabbyML/tabby/tree/3bd73a8c59a1c21312e812...
Allerdings musste ich etwas suchen, um Informationen zum Eclipse-Client zu finden. Er stand weder im Haupt-README noch in der Liste der IDE-Erweiterungen in der Dokumentation.
Ich weiß nicht, ob das nur ein Versehen ist oder ob er noch nicht „richtig veröffentlicht“ werden soll.