Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Você provavelmente já passou pela experiência de ver a tela travar após copiar um comando de instalação de modelo do YouTube para o terminal. O motivo pelo qual LLMs locais travam em MacBooks antigos com 8GB ou 16GB de RAM, ou em notebooks de entrada, não é a falta de núcleos de processamento. A verdadeira causa é que o runtime tenta ler dados que ultrapassam os limites quando a largura de banda da memória é extremamente estreita. Ajustando a largura de banda do dispositivo e modificando apenas o tamanho do contexto, é possível executar um modelo de assistência de código e utilizá-lo sem problemas mesmo em aparelhos mais antigos.
O macOS e o Ubuntu mais recentes impedem a instalação indiscriminada de pacotes no Python do sistema. Assim que você executa pip install, ele exibe o erro PEP 668 (error: externally-managed-environment) e é interrompido. Se você for preguiçoso e adicionar a flag para forçar a desativação da proteção do sistema (--break-system-packages), as ferramentas básicas do SO acabarão corrompidas e você precisará reinstalá-lo. Utilize o pipx, que suporta isolamento em ambiente virtual independente, para instalar a ferramenta de diagnóstico.
Implante a ferramenta de diagnóstico de código aberto llmfit, desenvolvida por Alex Jones, de forma isolada para extrair as especificações do seu hardware.
`bash
brew install pipx
pipx ensurepath
pipx install llmfit
mkdir -p ~/local-ai-workspace/{configs,logs,scripts}
llmfit --json system > ~/local-ai-workspace/logs/system_specs.json
`
Ao concluir este processo no terminal, a capacidade de RAM do dispositivo e as informações do barramento de memória são organizadas no arquivo system_specs.json em 1 minuto, sem mexer nas bibliotecas do sistema.
O processo de geração de texto por um modelo de linguagem local é uma tarefa sequencial em que o próximo caractere é gerado analisando os tokens anteriores. A cada etapa, dezenas de bilhões de pesos do modelo precisam ser lidos inteiramente do barramento de memória. Em outras palavras, a velocidade percebida não é determinada pelo clock da GPU, mas sim pelo valor da largura de banda da memória.
O desempenho de tokens por segundo (TPS) é calculado com a fórmula abaixo:
TPS approx rac{ ext{Memory Bandwidth (GB/s)}}{ ext{Model Weights Size (GB)} + ext{KV Cache per Step (GB)}} imes etaO valor na fórmula representa a eficiência de largura de banda efetiva (MBU) do runtime e geralmente fica em torno de 0.65.
Se você carregar totalmente um modelo 7B quantizado de 4 bits (cerca de 4,5 GB) em uma memória de desktop DDR4 comum com largura de banda de 45 GB/s, a velocidade de processamento ficará estagnada em . O texto aparecerá quebrado caractere por caractere, o que é frustrante para uso profissional como assistente. Por outro lado, ao carregá-lo em um modelo RTX 4060 de 8 GB com largura de banda de 288 GB/s ou na memória unificada da série M com largura de banda superior a 100 GB/s, a taxa chega a 35 a 40 tokens por segundo, superando facilmente a velocidade de digitação em tempo real.
Depois de verificar as especificações do seu aparelho, dividimos os modelos a serem utilizados em exatamente dois:
Qwen2.5-Coder-7B-Instruct (Q4_K_M) com 4,7 GB de tamanho. Ele atinge mais de 35 TPS em um MacBook com memória unificada de 16 GB ou em uma placa de vídeo dedicada com VRAM de 8 GB.Llama-3.2-3B-Instruct (Q4_K_M) com 2,0 GB de tamanho. Mesmo no ambiente DDR4 de notebooks de baixo consumo, ele consome menos RAM e entrega consistentemente cerca de 15 TPS.Mesmo após conseguir carregar o modelo com sucesso, o processo é encerrado silenciosamente após algumas interações. O código Exit Code 137 exibido no terminal significa que o kernel de gerenciamento de memória do sistema operacional (Linux OOM-Killer ou macOS JetSam) encerrou o processo à força (SIGKILL) devido à falta de RAM.
Ao usar uma GPU dedicada, ocorre um problema ainda mais incômodo chamado Fallback de CPU Silencioso (Silent CPU Fallback). Quando o limite da VRAM é ultrapassado, o processo não é encerrado, mas parte das camadas de computação é deslocada para a RAM do sistema, que é extremamente lenta. Nesse momento, a utilização da queda de GPU despenca e o desempenho cai para cerca de 1 token por segundo.
O culpado é o cache KV (Key-Value), que consome mais RAM à medida que a conversa se alonga. Com base na arquitetura do Llama-3, se o contexto for mantido aberto até 32.768 (32K) tokens, serão adicionados mais 4,0 GB apenas de memória de cache, além dos 4,5 GB dos pesos. Em dispositivos de 8GB, isso inevitavelmente causará falhas. Limitar esse comprimento a 4.096 (4K) tokens reduz a capacidade do cache para 512 MB, permitindo que o sistema funcione mesmo em ambientes de 8GB sem travamentos.
Este é o procedimento para verificar o estado atual e fixar o limite.
Primeiro, digite ollama ps no terminal. Se o item PROCESSOR exibir uma divisão como 30%/70% CPU/GPU em vez de 100% GPU, significa que a VRAM já foi excedida e os dados foram deslocados para a RAM lenta.
Crie um arquivo de configuração para fixar o tamanho do contexto. Abra ~/local-ai-workspace/configs/Modelfile.coder e adicione o seguinte conteúdo:
`dockerfile
FROM qwen2.5-coder:7b
PARAMETER num_ctx 4096
PARAMETER temperature 0.2
`
Faça o build do modelo personalizado no terminal:
`bashollama create custom-coder:7b -f ~/local-ai-workspace/configs/Modelfile.coder
`
Após a conclusão do build, digite sudo purge no terminal no macOS para limpar o cache de disco, e no Windows utilize wsl --shutdown para encerrar instâncias ociosas do WSL, garantindo pelo menos 2 GB ou mais de RAM livre disponível.
Para garantir que o código-fonte da empresa ou projetos pessoais não vazem para o exterior, vincule o endpoint de atendimento do modelo apenas ao loopback local (127.0.0.1).
Crie o arquivo ~/local-ai-workspace/scripts/serve_secure.sh e insira o seguinte código:
`bash
#!/bin/bash
export OLLAMA_HOST="127.0.0.1:11434"
export OLLAMA_ORIGINS="http://127.0.0.1:*,http://localhost:*"
ollama serve > ~/local-ai-workspace/logs/ollama_runtime.log 2>&1 &
`
Após executar o script, digite lsof -i :11434 | grep LISTEN no terminal para verificar se o endereço de escuta aparece como 127.0.0.1:11434. Se aparecer 0.0.0.0:11434, que pode ser acessado externamente, o processo deve ser encerrado imediatamente.
A integração é feita utilizando o plugin Continue.dev do VS Code. Abra o arquivo de configuração (~/.continue/config.json) para separar o modelo de chat do modelo de preenchimento automático.
`json
{
"models": [
{
"title": "Local Qwen2.5-Coder (Chat)",
"provider": "ollama",
"model": "custom-coder:7b",
"apiBase": "http://127.0.0.1:11434"
},
{
"title": "Local Llama3.2 (Summary)",
"provider": "ollama",
"model": "llama3.2:3b",
"apiBase": "http://127.0.0.1:11434"
}
],
"tabAutocompleteModel": {
"title": "Local Autocomplete",
"provider": "ollama",
"model": "qwen2.5-coder:1.5b",
"apiBase": "http://127.0.0.1:11434"
},
"allowAnonymousTelemetry": false
}
`
Atribua o modelo 7B (cujo contexto foi limitado agora há pouco) para perguntas e respostas, e especifique o modelo ultraleve de 1 GB qwen2.5-coder:1.5b para o preenchimento automático por tabulação. O atraso no preenchimento automático desaparecerá.
A validação é realizada com a internet desconectada. Desative o Wi-Fi para ficar offline, abra o terminal e envie uma consulta diretamente:
`bash
curl -s -X POST http://127.0.0.1:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "teste de rede isolada local",
"stream": false
}' | grep "response"
`
Se uma resposta JSON normal for retornada com a conexão bloqueada, a configuração do ambiente de desenvolvimento que roda com segurança apenas dentro dos recursos do seu notebook, sem dependência de nuvem externa, estará concluída.