Dos clientes Rust para Gemma 4: endpoint HTTP directo o servidor MCP
Un desarrollador publica dos CLI en Rust que lanzan la misma pregunta a un Gemma 4 E2B autoalojado, una por HTTP compatible con OpenAI y otra a través de un servidor MCP.
Un desarrollador ha publicado dos clientes de línea de comandos escritos en Rust que hacen la misma pregunta a un Gemma 4 E2B autoalojado por dos caminos distintos. El primero, gemma-rust, llama directamente al endpoint HTTP compatible con OpenAI. El segundo, gemma-rust-mcp, es un cliente MCP: levanta el servidor MCP del propio entorno y consulta a través de sus herramientas.
La respuesta es la misma en ambos casos. Lo que cambia es lo que ve el cliente. El primero imprime la respuesta cruda del endpoint, campo por campo. El segundo recibe lo que el servidor decida reportar, que aquí es markdown en lugar de JSON.
La misma llamada, una capa más arriba
Por debajo, la ruta MCP acaba haciendo la misma petición HTTP. La diferencia es que sale desde un proceso Python que el cliente Rust ha lanzado, no desde el propio binario. El autor lo plantea así: un cliente MCP como Claude Code nunca toca el endpoint, llama a herramientas. Escribir un cliente en Rust —ni Claude Code ni el SDK de Python con el que se construyeron los servidores— es la forma más rápida de comprobar qué devuelven esos servidores de verdad.
Los dos binarios se prueban contra dos despliegues muy distintos del mismo modelo. En local, llama.cpp con llama-server sobre una GTX 1650 Ti de 4 GiB y sin autenticación. En la nube, vLLM sobre una NVIDIA L4 en Cloud Run, detrás de IAM de Google Cloud. Ninguno de los dos clientes arranca, para ni despliega nada: eso lo hacen los entornos.
Qué hace falta para reproducirlo
El listón de Rust es bajo: 1.98.1 en el ejemplo. Los mínimos reales salen de las dependencias: reqwest 0.13.5 y clap 4.6.6 piden 1.85, y rmcp 3.3.0 pide 1.88. Ambas crates son edition 2024.
En el lado del servidor, el artículo compila llama.cpp en el commit 95ef7fc con CUDA y CMAKE_CUDA_ARCHITECTURES=75, que es la arquitectura Turing. El checkpoint es el GGUF cuantizado q4_0 de Gemma 4 E2B: un archivo de 3.349.516.256 bytes (unos 3,1 GiB) que, según la medición del propio autor, cabe en una tarjeta de 4 GiB porque buena parte del fichero no llega a salir del host. El servidor se levanta en el puerto 8080 con -ngl 99 -c 8192, y el health check devuelve {"status":"ok"}.
Los dos CLI son demos y su salida está pensada para que alguien la lea, así que no esconden nada detrás de un flag --verbose: cada ejecución imprime el objetivo, el health check, la petición, la respuesta, el razonamiento del modelo, el recuento de tokens, la latencia y lo que el servidor diga de sí mismo.
Que MCP se esté consolidando como la vía por la que los agentes hablan con los modelos hace que la comparación tenga recorrido. Si toca depurar un agente que no responde como debería, saber qué capa está devolviendo markdown en vez de JSON ahorra bastante tiempo.