- Tabby est un assistant de codage IA auto-hébergé proposé comme alternative open source et on-premise à GitHub Copilot, avec pour objectif un fonctionnement sans service cloud
- Le serveur met en avant une architecture autonome ne nécessitant ni SGBD ni service cloud, et il est conçu pour s’intégrer facilement à une infrastructure existante comme un Cloud IDE grâce à une interface OpenAPI
- L’environnement d’exécution prend en charge les GPU grand public, et il est possible de lancer le serveur avec une seule commande Docker en utilisant le modèle de code
StarCoder-1B et le modèle de chat Qwen2-1.5B-Instruct
- Les mises à jour récentes incluent notamment la v0.30, qui indexe les GitLab Merge Requests comme contexte, la v0.29, qui permet d’ajouter sa propre documentation via une API REST, et la v0.28, qui transforme les messages d’Answer Engine en Pages persistantes et partageables
- Des extensions IDE/éditeur, une documentation d’installation et de configuration, ainsi qu’un guide de contribution sont fournis ; il est aussi possible de compiler directement le projet avec
cargo build après avoir préparé l’environnement Rust et certaines dépendances
Rôle de Tabby et caractéristiques de base
- Tabby est un assistant de codage IA auto-hébergé, alternative open source et on-premise à GitHub Copilot
- Ses principales caractéristiques se résument en trois points
- Il est autonome, donc ne nécessite ni SGBD ni service cloud
- Il fournit une interface OpenAPI, ce qui facilite son intégration à une infrastructure existante comme un Cloud IDE
- Il prend en charge les GPU grand public
- Le projet fournit des liens vers la documentation, Slack et la roadmap
- Une démo en direct peut être ouverte sur le site web de Tabby
Changements récents
- 2025-12-12 :
vscode@0.20.0 est proposé avec l’implémentation de GitHub Issues reliées aux tâches Pochi, et la possibilité de créer des PR depuis la barre latérale avec analyse des résultats CI/Lint/Test
- 2025-07-02 : la v0.30 prend en charge l’indexation des GitLab Merge Requests comme contexte
- 2025-05-25 : des informations sont fournies pour rejoindre la file d’attente de prévisualisation privée de Agent
- 2025-05-20 : dans la v0.29, il est possible d’ajouter sa propre documentation à Tabby via l’API REST
- 2025-05-01 : la v0.28 transforme les messages d’Answer Engine en Pages persistantes et partageables
- 2025-03-31 : la v0.27 enrichit le menu
@ du panneau latéral de chat
Étendue des fonctionnalités révélée par les précédentes mises à jour
- Answer Engine a été présenté dans la v0.13.0 comme un moteur central de connaissance destiné aux équipes d’ingénierie internes, fournissant des réponses en s’intégrant aux données internes des équipes de développement
- Tabby a ajouté des fonctions d’intégration et de configuration comme GitLab SSO, GitHub/GitLab auto-hébergés, l’intégration via API HTTP et le repo-context du Code Browser
- Le flux des plugins IDE inclut des mises à jour pour VSCode/Vim/IntelliJ, un panneau latéral de chat dans VSCode, l’édition via commandes de chat, plusieurs choix pour la complétion inline et des messages de commit générés automatiquement
- La complétion de code exploite des snippets locaux pertinents comme les déclarations LSP locales et le code récemment modifié, et dans la v0.3.0 la complétion de code basée sur le RAG était activée par défaut
- Côté prise en charge des modèles, sont notamment mentionnés CodeGemma, CodeQwen, le support expérimental de Codestral et de CodeLlama 7B, ainsi que l’inférence Metal sur Apple M1/M2
Démarrage et exemple d’exécution
- Le guide de démarrage est disponible dans Getting Started
- La façon la plus simple de lancer le serveur consiste à utiliser une commande Docker
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
- Des options supplémentaires incluent des réglages comme le type d’inférence et le parallélisme, consultables sur une page de documentation dédiée
Contribution et compilation
- Le guide complet de contribution se trouve dans CONTRIBUTING.md
- Le code source se clone avec ses sous-modules
git clone --recurse-submodules https://github.com/TabbyML/tabby
cd tabby
- Si le dépôt a déjà été cloné, la commande
git submodule update --recursive --init permet de récupérer tous les sous-modules
- Les prérequis avant compilation sont les suivants
- Configuration de l’environnement Rust
- macOS :
brew install protobuf
- Ubuntu/Debian :
apt install protobuf-compiler libopenblas-dev
- Outils utiles sur Ubuntu :
apt install make sqlite3 graphviz
- Une fois la préparation terminée, il est possible de compiler Tabby avec
cargo build
- Le flux de contribution se poursuit par la soumission d’une Pull Request après les modifications
1 commentaires
Avis de Hacker News
La démo de complétion de la fonction
findMaxElementsur la page d’accueil semble bien illustrer ce qui nous attend, voire peut-être déjà l’état actuelLes 6 lignes de Python proposées pour cette fonction peuvent simplement être remplacées par
return max(arr); ça fonctionne, mais c’est clairement du code de niveau juniorCe code affreux fait peur en soi, mais ce qui m’inquiète davantage, c’est que les personnes qui l’autocomplètent aveuglément risquent de cesser de progresser
On peut gagner des story points, mais je me demande si l’on devient vraiment meilleur développeur pour autant
Or, pour comprendre ces 20 %, il faut aussi comprendre les 80 % traités par le LLM ; donc, comme le LLM ne peut pas aller jusqu’au déploiement à votre place, je ne suis pas très inquiet
Comme langage machine → assembleur → C → Python → LLM (langage naturel), cela revient à compiler les prompts humains en un code intermédiaire comme Python
Les premières versions de CPython n’étaient sûrement pas parfaites non plus, et les ingénieurs devaient être inquiets. Avec un peu de chance, ce nouveau « compilateur » deviendra lui aussi de mieux en mieux, et plus efficace, mais il ne sera pas parfait
Malgré tout, on pourrait finir par payer un coût comparable à celui que l’on accepte déjà en ne manipulant plus directement l’assembleur
Maintenant qu’il y a l’IA, on demande qu’elle les fasse à notre place, et au final on ne sait plus rien et on ne sait plus rien faire
Je ne pensais pas que notre projet se retrouverait en une de HN un dimanche
Tabby a beaucoup évolué depuis son lancement il y a deux ans https://www.tabbyml.com et c’est désormais une plateforme IA pour développeurs complète, avec complétion de code et chat sur la base de code
Pour les usages en équipe et en entreprise, elle prend aussi en charge le SSO, le contrôle d’accès et l’authentification des utilisateurs https://demo.tabbyml.com/search/how-to-add-an-embedding-api-...
Les utilisateurs qui l’ont adoptée ont constaté que Tabby est la seule plateforme proposant un onboarding entièrement en libre-service dans un mode de déploiement on-premise ; ses performances sont aussi comparables aux autres options du marché, donc si vous êtes curieux, je vous recommande de l’essayer
https://www.reddit.com/r/LocalLLaMA/s/lznmkWJhAZ
https://www.linkedin.com/posts/kelvinmu_last-week-i-introduc...
Je ne connais pas bien l’IA locale, mais j’aimerais essayer ; je me demande à quel niveau se situe « run tabby in 1 minute » https://github.com/TabbyML/tabby#run-tabby-in-1-minute par rapport, par exemple, à 4o-mini dans la version gratuite de ChatGPT
J’aimerais savoir si, en exécutant la commande Docker ci-dessous sur un MacBook Pro de milieu de gamme, on obtient une IA comparable en vitesse et en capacités, ou si ce n’est pas encore à ce 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-InstructJe vois qu’il existe une page d’instructions séparée pour MacBook, avec plus de contexte https://tabby.tabbyml.com/docs/quick-start/installation/appl...
Il y est indiqué : « Les capacités de calcul des M1/M2 sont limitées ; cela peut suffire pour un usage personnel, mais si vous avez besoin d’une instance partagée pour une équipe, envisagez un hébergement Docker basé sur CUDA ou ROCm »
Les très petits modèles comme les 1,5B sont assez bêtes et ne sont pas bons pour générer du code de manière conversationnelle, mais même des modèles de 3B ou moins peuvent assez bien faire des suggestions de complétion par tabulation
Il existe aussi des modèles « open » plus grands que l’on peut exécuter en local, et les modèles dans la plage 32B–70B peuvent être bien meilleurs que gpt-4o-mini sur presque tous les aspects, y compris l’écriture de code. Par exemple,
llama3.3-70b-instructetqwen2.5-coder-32b-instructsont plutôt correctsSi vous manquez vraiment de RAM,
qwen2.5-coder-7b-instructoucodegemma-7b-itpeuvent aussi convenir pour des tâches simplesDire « MacBook Pro de milieu de gamme » ne suffit pas : la quantité de RAM est importante. En règle générale, il faut environ 1 Go de RAM par milliard de paramètres
Avec une quantification agressive, cela peut descendre à 500 Mo ; un modèle non quantifié tourne plutôt autour de 2 Go, mais la quantification 8 bits demande généralement environ 1 Go et reste globalement correcte
Le « bouton de bascule de télémétrie IDE / extension » ne peut pas être désactivé dans la Community Edition. Je me demande ce que contiennent ces données de télémétrie à distance.
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...
J’utilise Continue.dev et ollama pour un usage similaire, et c’est toujours une bonne nouvelle de voir davantage d’outils dans ce domaine
Cela dit, comme d’habitude, pour faire tourner un modèle vraiment bon, par exemple Qwen2.5-coder 32B, il faut du matériel assez puissant
Les exemples sont tous du code qu’on s’attendrait normalement à trouver dans une bibliothèque, et la qualité de certains est aussi discutable
Les LLM sont-ils en train de devenir des bots de spam pour les bases de code ?
D’après « comment exploiter plusieurs GPU NVIDIA », Tabby ne prend en charge qu’un seul GPU ; pour utiliser plusieurs GPU, il faut lancer plusieurs instances de Tabby, puis définir
CUDA_VISIBLE_DEVICESpour CUDA etHIP_VISIBLE_DEVICESpour ROCmJe me demande donc si l’inférence avec 2 GPU reliés par NVLink n’est pas prise en charge, ou si c’est un cas différent parce que NVLink permet de traiter deux GPU comme un seul
Voir l’exemple sur https://tabby.tabbyml.com/docs/references/models-http-api/vl...
Super projet. J’aime particulièrement l’idée de ne pas avoir à envoyer ses données à une grande entreprise ni à faire confiance à ses conditions d’utilisation
L’efficacité d’un assistant de codage est directement proportionnelle à la longueur de contexte, or les modèles ouverts qu’on peut faire tourner sur un ordinateur personnel sont en général beaucoup plus petits
Ce serait bien d’avoir des données quantifiant son utilité sur des bases de code plus complexes
Je me demande quel est le matériel recommandé. Faut-il un GPU ? Est-ce que ça pourrait tourner correctement sur un vieux Ryzen APU (Zen 3 et graphismes Vega 7) ?
La présence ou non d’un GPU intégré ne change pas grand-chose, et si on l’exécute uniquement sur CPU, le modèle sera tout aussi très lent
Si les Mac s’en sortent à peu près correctement avec les LLM, c’est parce que la bande passante mémoire de l’Apple Silicon est inhabituellement élevée, mais elle reste loin de la vitesse des GPU haut de gamme dotés de VRAM très rapide
Pour un tout petit modèle utilisé pour l’autocomplétion par tabulation, un ancien CPU AMD devrait probablement faire l’affaire
Très chouette. Je suis particulièrement content de voir qu’il existe un client Eclipse https://github.com/TabbyML/tabby/tree/3bd73a8c59a1c21312e812...
Cela dit, il a fallu un peu fouiller pour trouver des informations sur le client Eclipse. Il n’était ni dans le README principal, ni dans la liste des extensions IDE de la documentation
Je ne sais pas s’il s’agit d’un simple oubli ou s’il n’est pas encore prêt à être « officiellement présenté »