Dois Clientes Rust para Gemma 4: Chamando o Endpoint vs. Chamando o Servidor MCP

Este artigo fornece um guia passo a passo para dois pequenos CLIs em Rust que fazem a mesma pergunta a um Gemma 4 E2B auto-hospedado. O primeiro chama diretamente o endpoint HTTP compatível com OpenAI do modelo. O segundo é um cliente MCP: ele inicia o próprio servidor MCP do equipamento e pergunta através de suas ferramentas.

https://github.com/xbill9/gemma-rust

https://github.com/xbill9/gemma-rust-mcp

O que este projeto está tentando fazer?

Ambos os CLIs são demonstrações, e sua saída é lida por um público. Portanto, nenhum deles esconde nada atrás de uma flag --verbose: cada execução imprime o alvo, a verificação de saúde, a solicitação, a resposta, o raciocínio do modelo, contagens de tokens, latência e o que quer que o servidor diga sobre si mesmo.

Eles são executados contra duas implantações muito diferentes do mesmo modelo com o mesmo código:

• local: llama-server do llama.cpp em um laptop com GPU de 2021, uma GTX 1650 Ti com 4 GiB, sem autenticação
• Cloud Run: vLLM em um NVIDIA L4, atrás do Google Cloud IAM

A parte interessante é o que muda quando a mesma pergunta passa pelo MCP em vez de HTTP. Não é a resposta.

Por que dois clientes?

Porque eles respondem a duas perguntas diferentes.

gemma-rust mostra o que o modelo disse. Uma chamada HTTP, a resposta bruta no estilo OpenAI, cada campo impresso.

gemma-rust-mcp mostra o que um agente vê. Um cliente MCP como Claude Code nunca toca no endpoint. Ele chama ferramentas e recebe de volta o que essas ferramentas escolhem relatar. Escrever um segundo cliente em Rust — um que não é Claude Code e não é o SDK Python com o qual os servidores foram construídos — é a maneira mais rápida de descobrir o que esses servidores realmente retornam.

Nenhum deles inicia, para ou implanta nada. Os equipamentos fazem isso.

Como tudo isso se encaixa?

  gemma-rust ─────── HTTP (reqwest) ───────────────────────┐
                                                           ├──▶  llama-server   GTX 1650 Ti, local
                                                           │     vLLM           NVIDIA L4, Cloud Run
  gemma-rust-mcp ─── MCP over stdio (rmcp) ──▶ server.py ──┘
                                               (Python, o próprio do equipamento)

O caminho MCP faz a mesma chamada HTTP no final. Ele apenas a faz de dentro de um processo Python que o cliente Rust lançou e devolve markdown em vez de JSON.

Onde eu começo?

A estratégia para construir os dois clientes é uma abordagem incremental passo a passo.

Primeiro, um servidor de modelo é levantado localmente e verificado com curl. Em seguida, o cliente HTTP é construído e validado contra ele, incluindo as duas maneiras que o Gemma 4 retorna uma resposta vazia de um servidor saudável. O mesmo binário é então apontado para o Cloud Run.

Depois, o servidor MCP Python do equipamento é instalado, o cliente MCP é construído e a mesma pergunta passa pelos mesmos dois servidores novamente — que é de onde vem a comparação.

Neste ponto você deve ter…

• Uma máquina Linux com uma GPU NVIDIA, um driver funcionando e o toolkit CUDA (nvcc) — este é um GTX 1650 Ti, CUDA 13.3
• git, cmake, um compilador C++ e curl
• Python 3 — para o servidor MCP do equipamento, não para os clientes Rust
• Uma conta Hugging Face que aceitou a licença do Gemma, e o CLI hf
• Opcional: o Google Cloud SDK e um serviço Gemma 4 Cloud Run, para a parte em nuvem. Este artigo implanta um.

Passo 1 — Instalar Rust

Use rustup:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.cargo/env
rustc --version

rustc 1.98.1 (48a229cea 2026-09-01)

Qualquer versão recente funciona. Os limites vêm das próprias rust-version das dependências:

Ambos os crates são da edição 2024.

Passo 2 — Construir llama.cpp com CUDA

llama-server é o servidor de modelo local. Construa-o a partir do código-fonte, no commit que o equipamento executa:

git clone https://github.com/ggml-org/llama.cpp ~/llama.cpp
cd ~/llama.cpp
git checkout 95ef7fc
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=75 -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j --target llama-server
ls build/bin/llama-server

build/bin/llama-server

75 é Turing, que é o que uma GTX 1650 Ti é. Defina a capacidade de computação da sua própria placa lá, ou deixe a flag de fora e deixe o CMake detectá-la.

Passo 3 — Baixar o Checkpoint do Gemma 4

O equipamento serve o QAT q4_0 GGUF do Gemma 4 E2B do Google:

hf auth login
hf download google/gemma-4-E2B-it-qat-q4_0-gguf --local-dir ~/models/gemma-4-E2B-it-qat-q4_0
ls -l ~/models/gemma-4-E2B-it-qat-q4_0/

-rw-rw-r-- 1 xbill xbill 3349516256 Sep  3 13:19 gemma-4-E2B_q4_0-it.gguf

Ele se ajusta a uma placa de 4 GiB porque a maior parte do arquivo nunca deixa o host — o artigo anterior mede isso.

Passo 4 — Iniciar o Servidor de Modelo

Execute-o em primeiro plano; Ctrl-C é a desmontagem completa:

~/llama.cpp/build/bin/llama-server \
  -m ~/models/gemma-4-E2B-it-qat-q4_0/gemma-4-E2B_q4_0-it.gguf \
  --host 127.0.0.1 --port 8080 -ngl 99 -c 8192

De um segundo terminal:

curl -s http://127.0.0.1:8080/health

{"status":"ok"}