v100-stack

Stack de inferência local para NVIDIA Tesla V100 (Volta, sm_70), com binários pré-compilados. Volta foi descontinuada em 2026 — CUDA 13 removeu o suporte, PyTorch 2.11 tirou os cubins, Triton 3.3 dropou a arquitetura. Este repo fixa cada peça no último ponto em que ainda funciona, e publica o resultado compilado para você não precisar refazer isso depois de formatar a máquina.

Todos os números aqui foram medidos, não estimados. Hardware de referência: 2× Tesla V100-SXM2-16GB com NVLink NV6, Xeon E5-2696 v3, Debian 13.

git clone https://github.com/neto007/v100-stack && cd v100-stack
sudo ./scripts/00-driver.sh        # driver R580 (último ramo com Volta)
sudo ./scripts/01-cuda.sh          # CUDA 12.9.1 + patch do glibc 2.41
sudo ./scripts/02-tuning.sh        # clocks travados, NCCL sobre NVLink
./scripts/03-python.sh             # Python 3.12 + torch 2.10 cu129
sudo ./scripts/install-release.sh  # baixa os binários já compilados
sudo ./scripts/setup-services.sh   # instala as units e o comando v100ctl
./scripts/verify.sh                # confere tudo contra os valores de referência

Nada sobe no boot. Você controla o que usar:

v100ctl status        # serviços e VRAM das duas placas
v100ctl llm   start --web   # LLM  : API 8090 | WebUI 8091
v100ctl audio start --web   # áudio: API 8080 (balanceada) | WebUI 8088
v100ctl stop                # derruba tudo

Layout, orçamento de VRAM e configuração: docs/operacao.md.

Depois de um sudo ./scripts/00-driver.sh pode ser preciso reiniciar. Se as GPUs não voltarem com um reboot quente, faça power-cycle completo — veja troubleshooting.

Compatibilidade de glibc. Os binários do CI são compilados em Ubuntu 24.04 (glibc 2.39) de propósito: rodam em alvos com glibc igual ou mais novo. Se a release tiver sido publicada por build/release-local.sh a partir de um Debian 13, ela exige glibc ≥ 2.41. Verifique com ldd --version.

Hardware — banda HBM2 823,5 GB/s (91,5% do pico), NVLink P2P 145,2 GB/s, fp16 97,7 TFLOP/s (78% do pico teórico de 125).

LLM, Qwen3.8 27B Q4_K_M em duas placas:

1,95× só por configuração. Detalhes e a varredura completa em docs/benchmarks.md.

Áudio, dois servidores balanceados (um por placa): 2,04× de vazão (1,53 → 3,13 req/s), distribuição 10/10. Veja docs/audio-servers.md.

Documento vira podcast — uma aba na WebUI do audio.cpp que orquestra llama-server (roteiro, turno a turno via tool calling) e o OmniVoice (vozes ancoradas por clone) inteiramente no navegador, sem serviço novo. Patch em patches/audiocpp-podcast-tab.patch, aplicado automaticamente pelo build. Veja docs/podcast.md. Trocar o modelo de voz por um fine-tune (ex. pt-BR) exige converter safetensors → GGUF próprio do projeto — processo documentado em docs/models.md.

Medimos e elas são falsas neste hardware. O raciocínio está em docs/playbook.md.

1. "Desligue o ECC para ganhar VRAM e banda." Ganho zero em SXM2-16GB — memória idêntica e banda dentro do ruído. A doc que promete ganho descreve a V100 PCIe. Deixe ligado.
2. "Tensor-parallel não ajuda em stream único." Ajuda: +74,8% em prompt processing, +45,8% em geração. A afirmação original vem de um setup Windows sem NCCL nativo.
3. "Speculative decoding é net-negativo em V100." Verdade para o vLLM, falso para o llama.cpp: +42,5%. Meça por engine, não por arquitetura de GPU.

source scripts/common.sh
bash build/build-llamacpp.sh      # ~10 min em 36 threads
bash build/build-audiocpp.sh      # ~25 min em 36 threads
bash build/build-flashattn.sh     # ~9 min

O CI roda exatamente esses mesmos scripts. Para empacotar e publicar o que você compilou localmente:

./build/release-local.sh v0.1.0

MIT. Os projetos compilados (llama.cpp, audio.cpp, flash-attention-v100) mantêm suas licenças originais.