Qwen3.6 35B-A3B resol en local un crawler LTE que Gemma 4 no va poder completar

Qwen3.6 35B-A3B aconsegueix executar en local una tasca de programació inversa que havia fet fracassar Qwen3.5 i Gemma 4: descarregar el JavaScript d’un portal de mòdem LTE, reconstruir-ne el procés d’autenticació i escriure un programa que consulta la intensitat del senyal en temps real.

Protorikis converteix aquest projecte personal en un benchmark d’agents de codi. El resultat és notable perquè no es resol amb una funció aïllada, sinó connectant informació dispersa en milers de línies minificades i utilitzant eines de terminal durant hores. També és una sola prova, amb intervenció humana i una configuració concreta; no demostra que Qwen3.6 sigui millor que tots els rivals en qualsevol tasca.

El repte que separa una demo d’un agent útil

L’autor utilitza tres exercicis per triar un model local. El primer és una aplicació que vigila la velocitat d’internet i actua com a filtre bàsic. El segon reprodueix el foc de Doom dels anys noranta en una terminal, amb gràfics ANSI i un algorisme delicat. Gemma 4 havia resolt aquest segon exercici amb facilitat.

El tercer sembla més modest: consultar les dades d’un mòdem mòbil. En realitat, el portal no ofereix una API documentada i amaga l’autenticació i les peticions dins de fitxers JavaScript grans, minificats i plens de codi auxiliar. El model ha d’identificar els recursos, entendre el login i localitzar les crides que retornen mètriques de ràdio.

Aquest tipus de feina castiga dues debilitats habituals dels LLM: perdre detalls quan el context creix i inventar connexions plausibles entre fragments que no s’han llegit bé.

Què és Qwen3.6 35B-A3B

La variant provada és un model obert de 35.000 milions de paràmetres totals que n’activa aproximadament 3.000 milions per token. Aquesta arquitectura Mixture of Experts reparteix el treball entre 256 experts i en selecciona un subconjunt per a cada pas. La fitxa oficial combina capes Gated DeltaNet d’atenció lineal amb capes d’atenció convencional.

Qwen declara una finestra nativa de 262.144 tokens, ampliable experimentalment fins a prop d’un milió. També recomana conservar almenys 128K en tasques complexes. L’autor configura precisament 128K, quantització Q4 per als pesos i Q8 per a la memòria KV, de manera que el model càpiga als 36 GB de memòria del seu MacBook amb M3 Max.

Els pesos oficials tenen llicència Apache 2.0 i funcionen amb Transformers, llama.cpp, MLX, vLLM i SGLang. La prova utilitza una versió comunitària per a LM Studio perquè havia rendit lleugerament millor en els experiments previs de memòria.

Primer obstacle: les eines no funcionen

El pla inicial consisteix a demanar a l’agent que detecti i descarregui tots els fitxers JavaScript del portal. Protorikis intenta treballar amb Z Agent, però Qwen no aconsegueix utilitzar-ne les eines i ni tan sols executa correctament curl. Canvia, per tant, a OpenCode.

Aquest incident és important: el rendiment d’un agent no depèn només del model. El format de crida d’eines, l’agent que l’envolta, la distribució dels pesos, la plantilla de conversa i els permisos de terminal poden decidir si una tasca arrenca o queda bloquejada.

Amb OpenCode, Qwen troba i descarrega els recursos. També comença a llegir-los massa aviat. Un únic service.js és tan gran que amenaça d’omplir tot el context amb codi poc llegible.

Preparar el codi abans de raonar

L’autor intervé i obre una sessió nova amb un objectiu més concret: passar els dinou fitxers minificats per JS Beautify. Qwen executa l’ordre correctament. Aquest pas no canvia la lògica, però introdueix salts de línia i sagnat perquè tant la persona com el model puguin navegar per funcions i blocs.

La decisió il·lustra una bona pràctica amb repositoris grans: reduir soroll abans de demanar una solució. En lloc d’abocar tots els fitxers al prompt, l’agent busca paraules clau i llegeix només intervals rellevants. A uns 42.000 tokens de context, el vídeo mesura prop de 300 tokens per segon durant la càrrega del prompt i 30 durant la generació.

Qwen descobreix després que falten fitxers, com login.js. Protorikis interromp l’execució, li ordena descarregar-los i embellir-los i deixa que continuï. La nova informació porta la sessió al límit i activa la compactació del context.

El login funciona després de gairebé tres hores

Després de la compactació, l’autor recorda al model els fitxers pendents. Qwen ja havia escrit una primera versió del crawler, encara fallida, i continua reconstruint la seqüència d’autenticació. Al cap de dues hores i cinquanta-cinc minuts anuncia que el login funciona.

L’èxit no és un resultat d’un sol prompt. Hi ha sessions separades, instruccions correctives, una interrupció humana, compactació i proves iteratives. Això no en resta valor: descriu millor com es treballa realment amb un agent. La capacitat rellevant és recuperar-se d’errors i acumular una solució verificable, no encertar a la primera.

De l’autenticació a les mètriques de ràdio

L’endemà, el model torna a carregar la memòria KV i rep una nova petició: trobar les crides que retornen la qualitat del senyal. Qwen navega pel codi, aplica coneixement sobre bandes mòbils i afegeix la consulta al programa.

El projecte queda complet després de tres hores i cinquanta-tres minuts repartits en dos dies. El crawler inicia sessió, extreu les mètriques de ràdio i les registra. L’autor entra manualment al portal i comprova que els valors fluctuen i coincideixen. Després demana una neteja del codi i un README que preservi les particularitats descobertes.

Aquesta verificació contra la interfície real és el punt fort del benchmark. No avalua si el codi «sembla correcte», sinó si es connecta al dispositiu i retorna les mateixes dades.

Rendiment local i coll d’ampolla

La combinació d’experts esparsos i atenció híbrida permet una velocitat de generació considerable per a un model de 35B en un portàtil. Quan el context és petit, el vídeo mostra uns 40 tokens per segon; amb més informació, baixa cap als 30.

El problema principal és el prefill: el temps necessari per processar tot l’historial abans del primer token. Quan la sessió creix o el servidor es reinicia, reconstruir la memòria KV es fa lent. El model pot generar ràpid una vegada preparat, però l’espera inicial empitjora amb desenes de milers de tokens.

La compactació ajuda a continuar, encara que pot eliminar detalls. Escriure resultats intermedis al disc, fer commits, mantenir un README i dividir el problema en sessions redueix la dependència d’una memòria perfecta.

Qwen3.6 iguala Claude Sonnet?

En una prova anterior, Claude Sonnet havia necessitat aproximadament mig dia per resoldre el mateix projecte. Qwen3.6 hi dedica gairebé quatre hores i produeix una implementació que l’autor prefereix perquè és més simple. Aquesta observació permet dir que, en aquest cas i amb aquest operador, el model local arriba a un resultat comparable.

No és una comparació controlada: no es garanteixen prompts, eines, versions, intents ni criteris idèntics. Tampoc hi ha un conjunt de problemes prou ampli per calcular una taxa d’èxit. El títol «iguala Sonnet» descriu el desenllaç del projecte, no una equivalència general de capacitats.

La conclusió útil és més concreta. Qwen3.6 35B-A3B pot mantenir prou context, usar una terminal i fer programació inversa d’un servei real en maquinari de consum. El benchmark també mostra que un bon resultat encara depèn de preparar els fitxers, vigilar el context, canviar d’eina quan cal i comprovar cada dada contra el sistema original.