4 pontos por GN⁺ 2025-01-13 | 1 comentários | Compartilhar no WhatsApp
  • O Tabby é um assistente de programação com IA auto-hospedado, oferecido como uma alternativa open source e on-premises ao GitHub Copilot, com foco em um fluxo de operação sem serviços em nuvem
  • O servidor aposta em uma configuração autocontida que não exige DBMS nem serviços em nuvem, e foi projetado com uma interface OpenAPI para facilitar a integração com infraestruturas existentes, como Cloud IDEs
  • O ambiente de execução oferece suporte a GPUs de nível consumidor, e o servidor pode ser iniciado com um único comando Docker usando o modelo de código StarCoder-1B e o modelo de chat Qwen2-1.5B-Instruct
  • Entre as atualizações recentes estão a v0.30, que indexa Merge Requests do GitLab como contexto, a v0.29, que adiciona documentos próprios via REST API, e a v0.28, que transforma mensagens do Answer Engine em Pages compartilháveis
  • Estão disponíveis extensões para IDE/Editor, documentação de instalação e configuração, além de um guia de contribuição; com um ambiente Rust e algumas dependências preparados, também é possível compilar diretamente com cargo build

Papel do Tabby e características básicas

  • Tabby é um assistente de programação com IA auto-hospedado, uma alternativa open source e on-premises ao GitHub Copilot
  • Suas principais características podem ser resumidas em três pontos
    • É autocontido, portanto não requer DBMS nem serviços em nuvem
    • Fornece uma interface OpenAPI, facilitando a integração com infraestruturas existentes, como Cloud IDEs
    • Oferece suporte a GPUs de nível consumidor
  • O projeto fornece links para documentação, Slack e roadmap
  • Uma demonstração ao vivo pode ser aberta no site do Tabby

Mudanças recentes

  • 2025-12-12: foi disponibilizado o vscode@0.20.0, que implementa recursos ao conectar issues do GitHub a tarefas do Pochi e permite criar PRs pela barra lateral junto com a análise de resultados de CI/Lint/Test
  • 2025-07-02: a v0.30 passou a oferecer suporte para indexar Merge Requests do GitLab como contexto
  • 2025-05-25: foi publicado um convite para entrar na fila de prévia privada do Agent
  • 2025-05-20: na v0.29, tornou-se possível adicionar documentos próprios ao Tabby via REST API
  • 2025-05-01: a v0.28 transforma mensagens do Answer Engine em Pages persistentes e compartilháveis
  • 2025-03-31: a v0.27 passou a oferecer um menu @ mais rico no painel lateral de chat

Escopo de funcionalidades revelado por atualizações anteriores

  • O Answer Engine foi apresentado na v0.13.0 como um mecanismo central de conhecimento para equipes internas de engenharia, fornecendo respostas ao se integrar aos dados internos da equipe de desenvolvimento
  • O Tabby vem adicionando recursos de integração e configuração, como GitLab SSO, GitHub/GitLab auto-hospedados, integração via HTTP API e repo-context no Code Browser
  • O fluxo de plugins de IDE inclui atualizações para VSCode/Vim/IntelliJ, painel lateral de chat no VSCode, edição por comandos de chat, múltiplas opções de conclusão inline e mensagens de commit geradas automaticamente
  • A conclusão de código aproveita snippets locais relevantes, como declarações LSP locais e código modificado recentemente; na v0.3.0, a conclusão de código baseada em RAG foi ativada por padrão
  • Em termos de suporte a modelos, são mencionados CodeGemma, CodeQwen, Codestral, suporte experimental ao CodeLlama 7B e suporte a inferência Metal no Apple M1/M2

Como começar e exemplo de execução

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
  • As opções adicionais incluem configurações como tipo de inferência e paralelismo, que podem ser consultadas em uma página de documentação separada

Contribuição e build

  • O guia completo de contribuição está em CONTRIBUTING.md
  • Clone o código-fonte junto com os submódulos
git clone --recurse-submodules https://github.com/TabbyML/tabby
cd tabby
  • Se você já clonou o repositório, pode baixar todos os submódulos com o comando git submodule update --recursive --init
  • Antes do build, é preciso preparar o seguinte
    • Configurar o ambiente Rust
    • macOS: brew install protobuf
    • Ubuntu/Debian: apt install protobuf-compiler libopenblas-dev
    • Ferramentas úteis no Ubuntu: apt install make sqlite3 graphviz
  • Depois que tudo estiver pronto, é possível compilar o Tabby com cargo build
  • O fluxo de contribuição segue com o envio de um Pull Request após as alterações

1 comentários

 
GN⁺ 2025-01-13
Opiniões no Hacker News
  • A demo de completar a função findMaxElement na página inicial parece um exemplo que mostra bem o que vem por aí — talvez até o estado atual
    As 6 linhas de Python sugeridas para essa função poderiam ser simplesmente substituídas por return max(arr); funciona, mas é código totalmente de nível júnior
    Esse código horrível por si só já assusta, mas me preocupa ainda mais que pessoas que autocompletam isso cegamente parem de evoluir tecnicamente
    Dá para ganhar story points, mas fica a dúvida se a pessoa realmente melhorou como desenvolvedora

    • Acho que isso é um problema que vai se autocorrigir. Código dessa qualidade não pode ir para produção e, no fim, para passar nos testes, é preciso entender os últimos 20%~30% de detalhes que o LLM não consegue resolver
      Mas, para entender esses 20%, você também precisa entender os 80% que o LLM tratou; então não me preocupo tanto, já que o LLM não vai fazer o deploy por você
    • Por outro lado, isso também pode virar a próxima camada de abstração
      Como linguagem de máquina → assembly → C → Python → LLM (linguagem natural), seria como compilar prompts humanos para um código intermediário, tipo Python
      As primeiras versões do CPython provavelmente também não eram perfeitas, e os engenheiros devem ter ficado inseguros. Com sorte, esse novo “compilador” também vai ficar cada vez melhor e mais eficiente, mas não será perfeito
      Ainda assim, talvez a gente passe a pagar um custo parecido com o que já paga por não lidar diretamente com assembly
    • Um hábito subestimado ao aceitar sugestões do Cursor é quase sempre perguntar em seguida: “existe um jeito melhor?
    • Antigamente, a gente sabia alguma coisa. Depois que o Google surgiu, a gente simplesmente pesquisava, mas ainda conseguia fazer por conta própria
      Agora, com a IA, passamos a pedir que ela faça por nós e, no fim, não sabemos nada e não conseguimos fazer nada
    • Acho que esse exemplo mostra mais o julgamento da empresa ao escolher esse código para a demo da página inicial
  • Eu não esperava que nosso projeto fosse parar na primeira página do HN em um domingo
    O Tabby evoluiu bastante desde o lançamento há 2 anos https://www.tabbyml.com e agora se tornou uma plataforma de IA para desenvolvedores abrangente, com completamento de código e chat com a base de código
    Para uso em equipes/empresas, também oferece SSO, controle de acesso e autenticação de usuários https://demo.tabbyml.com/search/how-to-add-an-embedding-api-...
    Usuários que o adotaram descobriram que o Tabby é a única plataforma que oferece onboarding self-service completo no modelo on-premises, e o desempenho também é comparável ao de outras opções do mercado; se tiver curiosidade, recomendo testar
    https://www.reddit.com/r/LocalLLaMA/s/lznmkWJhAZ
    https://www.linkedin.com/posts/kelvinmu_last-week-i-introduc...

    • Fico curioso se existe um plugin para MSVC
    • Ele é compatível apenas com Nvidia e Apple? Gostaria de saber se também funciona em GPU AMD
  • Do ponto de vista de alguém que não entende muito de IA local, mas quer experimentar, fico curioso para saber em que nível o “run tabby in 1 minute” https://github.com/TabbyML/tabby#run-tabby-in-1-minute fica em comparação, por exemplo, com o 4o-mini gratuito do ChatGPT
    Quero saber se, ao executar o comando Docker abaixo em um MacBook Pro de configuração intermediária, dá para usar uma IA parecida em velocidade e capacidade, ou se ainda não chega a esse ponto
    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
    Pelo que vi, há uma página de instruções específica para MacBook, com mais contexto https://tabby.tabbyml.com/docs/quick-start/installation/appl...
    Ela diz: “A capacidade computacional do M1/M2 é limitada; pode ser suficiente para uso pessoal, mas, se você precisar de uma instância compartilhada para uma equipe, considere hospedagem Docker baseada em CUDA ou ROCm”

    • gpt-4o-mini talvez não seja a melhor referência para avaliar o que um bom LLM consegue fazer com código: https://aider.chat/docs/leaderboards/#aider-polyglot-benchma...
      Modelos muito pequenos, como 1.5B, são bem burros e não são bons para gerar código de forma conversacional, mas modelos abaixo de 3B ainda podem se sair bem em sugestões de autocompletar com Tab
      Também há modelos “abertos” maiores que podem rodar localmente, e modelos na faixa de 32B~70B podem ser muito melhores que o gpt-4o-mini em quase tudo, inclusive escrever código. Por exemplo, llama3.3-70b-instruct e qwen2.5-coder-32b-instruct são bem bons
      Se você tiver pouca RAM mesmo, qwen2.5-coder-7b-instruct ou codegemma-7b-it também podem servir para tarefas simples
      Só dizer “MacBook Pro de configuração intermediária” não basta; o que importa é quanta RAM ele tem. Como regra prática, é preciso cerca de 1 GB de RAM para cada 1B de parâmetros
      Com quantização forte, pode ser 500 MB; modelos sem quantização ficam perto de 2 GB, mas quantização de 8 bits geralmente fica em torno de 1 GB e costuma ser aceitável
    • Como pergunta adicional, modelos open source tendem a ser menos “inteligentes” que modelos fechados; fico curioso se há planos de compensar isso oferecendo contexto melhor, por exemplo consultando a documentação técnica relacionada e colocando-a no contexto
  • O “toggle de telemetria do IDE / extensão” não pode ser desativado na Community Edition. Fico curioso sobre o que entra nesses dados de telemetria remota

    • As informações de estado coletadas têm, em linhas gerais, a estrutura abaixo
      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...
  • Uso Continue.dev e ollama para um propósito parecido, e é sempre bem-vindo ver mais ferramentas surgindo nessa área
    Só que, como de costume, para rodar um modelo realmente bom, por exemplo o Qwen2.5-coder 32B, é preciso hardware bastante potente

  • Os exemplos são todos códigos que originalmente eu esperaria encontrar em uma biblioteca, e a qualidade de alguns deles também é duvidosa
    Será que o LLM vai virar um bot de spam para codebases?

  • Segundo “como usar várias GPUs NVIDIA”, o Tabby só oferece suporte a uma única GPU e, para usar várias GPUs, é preciso subir várias instâncias do Tabby e configurar CUDA_VISIBLE_DEVICES para CUDA ou HIP_VISIBLE_DEVICES para ROCm
    Então fico na dúvida se usar 2 GPUs conectadas por NVLink para inferência não é suportado, ou se é uma situação diferente porque o NVLink trata as duas GPUs como se fossem uma só

  • Projeto excelente. Gosto especialmente da ideia de não precisar enviar dados para uma grande empresa e confiar nos termos de uso dela
    A eficácia de um assistente de programação é diretamente proporcional ao tamanho do contexto, e os modelos abertos que dá para rodar em um computador pessoal costumam ser bem menores
    Seria bom ter algum material quantificando o quão útil ele é em codebases mais complexas

    • Torço para que assistentes de programação 100% locais se popularizem, mas, por enquanto, a recomendação de “funciona melhor em GPUs de mais de US$ 10 mil” é um obstáculo; no fim, não sobra opção além de usar as grandes empresas
  • Fico curioso sobre o hardware recomendado. Precisa de GPU? Será que roda de forma aceitável em uma Ryzen APU antiga (Zen 3 com gráficos Vega 7)?

    • O gargalo típico de LLMs auto-hospedados é a largura de banda de memória
      Ter ou não gráficos integrados não faz grande diferença e, rodando só na CPU, o modelo vai executar muito devagar do mesmo jeito
      O motivo de Macs serem razoáveis para LLMs é que a largura de banda de memória do Apple Silicon é excepcionalmente alta, mas ainda fica bem atrás da velocidade de uma GPU avançada com VRAM muito rápida
      Para um modelo bem pequeno usado em autocompletar por tab, uma CPU AMD antiga provavelmente dá conta de forma aceitável
    • Um exemplo de configuração local com uma 3090 pode ser visto em https://www.reddit.com/r/LocalLLaMA/s/lznmkWJhAZ
  • Muito legal. Fiquei especialmente feliz por haver um cliente para Eclipse https://github.com/TabbyML/tabby/tree/3bd73a8c59a1c21312e812...
    Mas tive que fuçar um pouco para encontrar informações sobre o cliente Eclipse. Não estava nem no README principal nem na lista de extensões de IDE da documentação
    Não sei se foi uma simples omissão ou se ainda não está pronto para ser “lançado oficialmente”