SourceBridge: Ferramenta de código aberto para análise de base de código usando LLMs locais

SourceBridge é um projeto de código aberto que usa LLMs locais para construir uma compreensão estruturada de bases de código. Você o aponta para um repositório Git e ele indexa a base de código em um grafo de símbolos contendo arquivos, funções, classes e dependências. A ferramenta então usa seu LLM para construir uma árvore de compreensão hierárquica, começando de segmentos de código individuais e subindo através de arquivos, pacotes e o repositório completo.

O que ele gera

• Resumos rápidos: resumos de múltiplos níveis fundamentados no código real
• Passeios pelo código: walkthroughs ordenados arquitetonicamente com referências específicas a arquivos/funções
• Caminhos de aprendizado: material de integração estruturado pedagogicamente
• Histórias de fluxo de trabalho: rastreamentos de fluxo de dados através do sistema
• Busca semântica contra o grafo do repositório

Suporte a modelos locais

O suporte a modelos locais foi uma prioridade desde o primeiro dia. Atualmente, os backends suportados incluem:

• Ollama — backend local principal, contra o qual o desenvolvedor testa diariamente
• llama.cpp — suporte direto a llama-server, ligeiramente mais rápido que Ollama nos testes
• vLLM — para servidores GPU
• LM Studio — incluindo decodificação especulativa
• SGLang — para configurações multi-GPU

Todos os backends funcionam via API compatível com OpenAI, então qualquer coisa que fale esse protocolo funciona. Provedores de nuvem (Anthropic, OpenAI, Gemini, OpenRouter) também são suportados para quando você quer maior qualidade em tarefas específicas.

Desempenho do modelo

O desenvolvedor tem executado principalmente no Qwen 3.5 35B-A3B (MoE, apenas 3B parâmetros ativos) via llama.cpp em um Mac Studio. Na quantização Q4_K_XL, ele roda a aproximadamente 50 tokens/segundo e produz resumos rápidos e passeios pelo código sólidos. Para repositórios maiores, Qwen 3.5 122B-A10B via Ollama foi testado — ele mostra melhor seguimento de instruções, mas precisa de cerca de 76GB de RAM.

Para tarefas de compreensão (resumir código, construir a árvore de compreensão), modelos da classe 32B fazem um trabalho razoável. A diferença de qualidade entre modelos locais e de nuvem é perceptível, mas não é um impeditivo para a maioria dos casos de uso. Modelos de nuvem ainda claramente vencem na geração de relatórios onde você precisa que o LLM siga instruções de formatação complexas sem entrar em loop.

O modo de pensamento nos modelos Qwen 3.5 está desabilitado por padrão — ele desperdiça tokens em cadeias de raciocínio que não melhoram a saída de compreensão. Isso é configurável via variável de ambiente se você quiser experimentar.

Arquitetura

• Servidor API Go (indexação, autenticação, fila de jobs, armazenamento de grafo)
• Trabalhador Python gRPC (chamadas LLM, pipeline de compreensão, geração de artefatos)
• Interface web Next.js (progresso em tempo real, visualizador markdown)
• SurrealDB (dados de grafo, artefatos de conhecimento, estado de jobs)
• Todos os três componentes são Dockerizados, rodam com docker compose up

O trabalhador lida com enfileiramento, novas tentativas, backoff e cancelamento — então, se seu modelo local for lento ou travar no meio da geração, o sistema se recupera graciosamente em vez de perder o trabalho.

Começando

git clone https://github.com/sourcebridge-ai/sourcebridge.git
cd sourcebridge
# Edite config.toml — aponte llm.provider para sua instância Ollama/llama.cpp
docker compose up

Seu código nunca sai da sua máquina. A inferência do LLM permanece local. Há telemetria anônima opcional (apenas contagem de instalações, desabilite com DO_NOT_TRACK=1).

O desenvolvedor está buscando feedback de pessoas executando modelos locais sobre o que funciona e o que não funciona, especialmente em relação a quais modelos produzem a melhor saída de compreensão, se modelos MoE valem a troca de RAM versus modelos densos, e quaisquer problemas com backends específicos.