HeadlinesBriefing favicon HeadlinesBriefing.com

El harness de codificación aprovecha el punto de referencia del rendimiento del modelo local

Hacker News •
×

Si alguna vez has considerado reemplazar las llamadas a la API que realiza tu harness de codificación por un modelo local, probablemente hayas terminado decepcionado. Ejecutaste un rápido llama-bench y pensaste que ibas a ver X tokens/segundo. Lo que ese punto de referencia no te dice es cómo se siente realmente usar estos harnesses.

La experiencia de desarrollo es extremadamente variable. Puede que hayas estado sentado allí durante minutos sin ver ninguna respuesta. Tal vez estabas progresando y a mitad de camino comenzó a estancarse. '¿Quién es este prefill, que me está tomando todo mi tiempo?' No es tu culpa: la mayoría de los harnesses de codificación no fueron construidos pensando en un modelo local.

Se puede esperar un cierto nivel de herramienta incorrecta para el problema. Por favor, añade sal: He estado experimentando con chad, un harness de codificación optimizado específicamente para Qwen 3.8 27B en Apple silicon. Física de portátiles La mayoría de los harnesses conspiran contra localhost de tres maneras.

Grandes prompts del sistema y esquemas de herramientas. Supongamos que tu portátil lee a 90 tokens por segundo y escribe alrededor de 10. Estos representan las partes de prefill y generación de cada bucle en tu harness de codificación.

A estas velocidades, cada 1.000 tokens de lectura de un prompt se traducen en ~11 segundos mirando el cursor antes de que el modelo comience a escribir. Antes de que tu LLM haga cualquier trabajo, leerá todo el prompt del sistema junto con cualquier esquema de herramienta cargado. En el harness pi, esta combinación fue de 2.008 tokens para Qwen 3.8 27B, pero 18.046 para Opencode.

No notarás mucha diferencia cuando tengas una GPU de centro de datos con tasas de prefill que promedian 10k+ tokens/segundo. Esto se reduce a 0,2 frente a 1,8 segundos. ¿En tu portátil? Esa es la diferencia entre 22 y 226 segundos, medido. ¡Inaguantable! Ventanas de contexto más pequeñas. Después de que tu LLM termina el prompt del sistema, tienes una ventana de contexto finita restante en la memoria para hacer trabajo.

Es más pequeña de lo que piensas, y tu harness acaba de gastar parte de ella. Cuánto contexto tienes depende de cuánto memoria empiezas con respecto a lo grande que son los pesos del modelo. Hay muchas variables aquí, pero 32.000 tokens es una suposición razonable de cuánto espacio te quedará con un modelo razonablemente bueno en un portátil razonablemente bueno. ¿Cuánto de ese presupuesto de 32.000 tokens queda para el harness pi? 94% - parece manejable. ¿Opencode? Con 18.046 tokens ya fuera, solo queda el 44% de tu contexto para hacer trabajo real.

Un hábito de solicitudes secundarias. En el patrón tradicional de cliente local/servidor remoto, el harness puede hacer tantas solicitudes secundarias a los servidores del centro de datos como quiera. Tu portátil es tanto el cliente como el servidor.

En el mejor de los casos, esas solicitudes secundarias hacen que el modelo local se ponga en cola y espere. En el peor de los casos, causan repetidos prefill largos. En más de 24 tareas, Opencode disparó 33 de ellas, crush 51 y dsh 24 (títulos y resúmenes de sesiones), casi todas superponiendo un turno de agente.

El modelo estaba 'ocupado' el 125% y el 114% del tiempo de pared para Opencode y Crush: dos solicitudes en vuelo en una sola GPU. Resultados del Harness Puse 9 harnesses a través de una serie de 8 ejercicios de Exercism, cada uno en su propio modo de aprobación automática, con un prompt idéntico de una sola oración. Cada tarea aprovechó el mismo M4 Mac Book Pro (24GB, mac OS 26.6.2) con una cuantificación de 3 bits del modelo Qwen 3.8 27B servido a través de llama.cpp (build 10470).

El mismo servidor llama-server fue compartido por cada harness y un proxy común impuso el mismo régimen de muestreo recomendado para Qwen (temperatura=1.0, top_k=20, top_p=0.95, min_p=0.05). Cada sesión tuvo el mismo caché unificado de 32.768 servido a través de cuatro ranuras. Cada número reportado a continuación es el propio recuento de llama-server leído a través del proxy, nunca un auto-reporte del harness, excepto las dos filas marcadas * (chad en su motor MLX interno, donde no hay servidor para observar, por lo que provienen del propio rastreo de prefill de chad con las mismas definiciones).