Execute a pré-visualização do Ripple-65B localmente: RAM, VRAM e configuração do agente de programação

O Ripple-65B Preview pode ser executado localmente, mas um bom ponto de partida é uma máquina com memória suficiente para um pacote do Ollama de cerca de 39–46 GB mais o ambiente de execução, a cache e o sistema operativo. Uma placa gráfica de 24 GB não consegue alojar todo esse pacote na VRAM. Uma máquina com 64 GB de memória unificada poderá servir para um teste com contexto curto, dependendo da etiqueta escolhida e da pressão real sobre a memória. Um conjunto de memória maior dá a um agente de programação mais espaço para manter disponíveis os ficheiros, os resultados dos testes e o histórico da conversa.

A Ricursive Intelligence lançou este modelo denso de 65B ao abrigo da licença Apache 2.0 e disponibiliza pesos BF16 e NVFP4. O Ollama adicionou o Ripple Preview na versão v0.40.16. Este guia começa pela escolha da máquina e do ambiente de execução, e depois mostra como testar uma carga de trabalho de programação real. Os escalões de memória abaixo são estimativas de planeamento. Os resultados publicados dos testes de desempenho são identificados separadamente.

O que distingue o Ripple de um agente de programação com um nome semelhante?

Ripple é o modelo. Pode sugerir alterações e chamadas de ferramentas, enquanto um ambiente de programação controla os ficheiros e comandos a que pode realmente aceder. Executar o modelo na mesma rede que um repositório não lhe dá acesso ao Git. É o ambiente de programação que decide como montar a área de trabalho, executar testes e pedir aprovação. Esta distinção é importante ao comparar uma sessão de chat no Ollama com um teste de desempenho no terminal.

O cartão oficial do modelo descreve um Transformer denso de 65B, treinado de raiz, com 80 camadas e suporte para até 1 048 576 tokens. A arquitetura densa utiliza o modelo completo em cada token gerado. A largura de banda da memória e a precisão efetiva dos pesos são importantes, mesmo quando o ponto de controlo cabe na memória. A Ricursive indica uma pontuação de 80.52 no Terminal-Bench 2.1, na sua própria configuração de teste. Um executor, uma quantização ou um ambiente de teste diferente podem alterar o resultado. Consulte o relatório de lançamento para obter informações sobre os testes de desempenho e a arquitetura.

Quanta RAM ou VRAM deve reservar no orçamento?

Com dois bytes por parâmetro, 65 mil milhões de parâmetros implicam cerca de 130 GB de armazenamento para os pesos BF16, antes da sobrecarga do runtime. Este cálculo usa GB decimais, não uma alocação medida. Do mesmo modo, multiplicar por quatro bits dá um limite inferior aproximado para os pesos compactados, sem incluir escalas, tensores mantidos com maior precisão nem metadados do pacote. Use o tamanho do artefacto concreto para estimar a transferência e a telemetria do runtime para calcular os recursos necessários na máquina.

Uma versão NVIDIA NVFP4 e uma etiqueta do Ollama são artefactos diferentes. Consulte o cartão oficial NVFP4 antes de escolher esse formato e confirme a arquitetura da GPU e a stack de disponibilização a que se destina. Um sistema com várias GPU também precisa de um runtime que suporte explicitamente a divisão deste checkpoint. Somar as capacidades anunciadas de duas GPU não basta para concluir que um modelo cabe na memória ou funciona de forma eficiente.

Que runtime local deve escolher?

A opção mais simples é a listagem do modelo no Ollama, juntamente com a versão v0.40.16 ou uma versão posterior compatível. Consulte a listagem para verificar a etiqueta atual, o tamanho do pacote e as notas relativas à plataforma antes de transferir. Para um teste simples, execute:

ollama run ripple-preview
ollama ps

O primeiro comando transfere o modelo, se necessário, e inicia uma sessão. O segundo permite ver a distribuição e o contexto carregado. Em Apple Silicon, a versão inclui um caminho MLX específico para o Ripple. Se quiser reproduzir os resultados do programador com NVIDIA, siga as instruções atuais do cartão do modelo e registe toda a configuração de disponibilização. Os resultados entre formatos só são comparáveis depois de ter em conta os diferentes kernels, precisões e descodificação especulativa.

Deixe espaço para o armazenamento do modelo, um download temporário, a sua cópia de trabalho e os artefactos de teste. Em máquinas que também executam tarefas de armazenamento ou cópias de segurança, verifique a unidade onde está efetivamente guardada a cache do runner. Um SSD quase cheio pode interromper um primeiro download, mesmo que o tamanho nominal do modelo pareça aceitável.

O que significa um contexto de um milhão de tokens numa máquina local?

Esse é o contexto máximo suportado pelo checkpoint, não uma definição inicial útil. Um agente de programação pode enviar centenas de ficheiros, resultados da shell e a conversa anterior para o modelo. Esse input aumenta a alocação de cache e o tempo até à geração do primeiro token. Os prefixos longos também tornam o ciclo de feedback mais lento se o harness enviar repetidamente registos antigos.

Comece com um input deliberadamente pequeno e uma só tarefa. Mantenha um snapshot fixo do repositório e registe a memória máxima após o carregamento e novamente no fim do prompt mais longo. Depois, aumente o contexto um passo de cada vez. Observe a memória residente efetiva ou a pressão sobre a memória unificada e verifique se há uso contínuo de swap. Elimine registos de teste desnecessários antes de aumentar o contexto. As compensações descritas neste guia de implementação local do Qwen3.8-27B são uma boa referência para um modelo mais leve.

Como se testa uma sessão de programação real?

Crie uma cópia de trabalho descartável e escolha uma tarefa delimitada: explicar um teste que falha, identificar os ficheiros envolvidos e propor um patch. Use apenas dados sintéticos ou dados de repositórios aprovados. Forneça ao harness uma lista dos ficheiros que pode ler e uma pequena lista de comandos de teste permitidos localmente. Reveja o diff e execute os testes de forma independente antes de confiar no resultado. Este guia do Git worktree explica como manter as experiências separadas da cópia de trabalho principal.

Registe o tempo até à primeira resposta útil, a velocidade de geração após o prefill, a memória máxima e se a alteração sugerida passa no teste. Inclua na comparação qualquer tentativa falhada ou truncada. Se um modelo passar cinco minutos a gerar um patch plausível, mas inutilizável, um valor máximo de tokens por segundo ocultará o problema. Outra tarefa útil é rever um pequeno diff sem editar ficheiros. Isso permite perceber se a mesma máquina também é valiosa para tarefas de revisão de menor risco.

Quando é que vale a pena usar um modelo local de 65B num computador maior?

Use o Ripple quando tiver recursos suficientes para o executar e uma carga de trabalho que beneficie do seu comportamento em tarefas de programação. Num computador de secretária com recursos limitados, um checkpoint mais pequeno que caiba na memória do acelerador poderá proporcionar uma melhor experiência no dia a dia. As execuções longas requerem uma abordagem própria, diferente das perguntas rápidas: a largura de banda, a memória de troca e o tráfego de armazenamento em segundo plano acumulam-se ao longo de uma sessão do agente.

Se um NAS armazenar as cópias do seu repositório e os resultados, mantenha esses serviços de armazenamento independentes do orçamento de recursos de computação do modelo. Monte apenas os dados de entrada necessários para a tarefa e guarde os dados produzidos num diretório de experiências. Para uma referência de comparação mais abrangente, consulte o que determina os requisitos de memória do Kimi K3 em execução local.

Perguntas frequentes

O Ripple precisa de uma GPU NVIDIA?

Não é necessária uma única marca de GPU para todas as opções de execução local. O Ollama tem uma opção MLX para Apple Silicon. As instruções de precisão e aceleração orientadas para NVIDIA aplicam-se à pilha NVIDIA compatível especificada pelo programador do modelo.

Uma RTX 4090 consegue alojar o modelo completo?

O pacote do Ollama descrito acima excede um limite de 24 GB de VRAM antes mesmo dos recursos adicionais necessários durante a inferência. A transferência de tarefas para a CPU é uma configuração à parte, com um perfil de desempenho diferente.

O tamanho da transferência corresponde ao consumo máximo de memória?

Não. O ambiente de execução, o alocador, os processos das ferramentas, a cache de atenção e o sistema operativo afetam todos o consumo máximo. O tamanho da transferência é um ponto de partida útil para planear o espaço em disco.

O contexto máximo anunciado é a configuração inicial adequada?

Comece com o contexto mais curto que permita concluir a tarefa e, depois, meça o tempo de prefill e o consumo de memória à medida que o aumenta. O suporte para o contexto completo não garante um débito prático em execução local.

O Terminal-Bench permite estimar o desempenho no meu próprio repositório?

Use-o para compreender a avaliação do programador e, depois, teste a sua própria carga de trabalho com um conjunto de testes, limites e ambiente de execução fixos. O benchmark apresentado não garante os mesmos resultados localmente.

Conclusão

Comece com uma etiqueta exata do Ollama ou com um formato NVIDIA suportado pelo programador, deixe margem para além do ficheiro dos pesos e teste uma tarefa limitada. O Ripple-65B Preview alarga a escolha de modelos de programação locais. O seu valor no seu hardware depende de conseguir concluir trabalho útil dentro dos limites de memória e latência.