7 puntos por GN⁺ 2026-04-23 | 4 comentarios | Compartir por WhatsApp
  • Se presentó como un modelo multimodal denso de 27 mil millones de parámetros, con soporte conjunto para los modos thinking y non-thinking y para procesamiento de imágenes y video dentro de un único checkpoint integrado
  • Su rendimiento en agentic coding supera al anterior flagship open source de la generación previa, Qwen3.5-397B-A17B, en los principales benchmarks de programación, e incluso supera modelos con hasta 15 veces más parámetros totales
  • Registró 77.2 en SWE-bench Verified, 53.5 en SWE-bench Pro, 59.3 en Terminal-Bench 2.0 y 48.2 en SkillsBench; también se publicaron métricas de razonamiento en texto y evaluaciones STEM como 87.8 en GPQA Diamond y 94.1 en AIME26
  • Gracias a su arquitectura densa, no tiene la complejidad de enrutamiento de MoE y su despliegue es más simple; además ofrece open weights, API, acceso inmediato en Qwen Studio y compatibilidad con integraciones como OpenClaw, Qwen Code y Claude Code
  • Muestra que un modelo denso bien entrenado puede superar a una generación previa mucho más grande en tareas clave para desarrolladores, y además amplía el alcance de agentic coding dentro de la familia Qwen3.6

Resumen general

  • Qwen3.6-27B se lanzó como un modelo multimodal denso de 27 mil millones de parámetros, con soporte tanto para modo multimodal thinking como non-thinking
  • En agentic coding, supera al anterior flagship open source de la generación previa, Qwen3.5-397B-A17B, a lo largo de los principales benchmarks de programación
  • Al adoptar una arquitectura densa sin la complejidad de enrutamiento de MoE, simplifica el despliegue y ofrece rendimiento de programación de primer nivel en una escala práctica y fácil de distribuir
  • Está disponible de inmediato en Qwen Studio, y también se ofrecen open weights para la comunidad y acceso vía API
  • Entre sus características clave están el agentic coding de nivel flagship, un sólido razonamiento en texto y capacidades de razonamiento multimodal

Rendimiento

  • Para Qwen3.6-27B se presentó una evaluación integral frente a modelos de referencia dense y MoE, con mejoras notables en los benchmarks de agentic coding
  • Se indica explícitamente que supera incluso a modelos con hasta 15 veces más parámetros totales
  • Las categorías evaluadas incluyen lenguaje, conocimiento, STEM y razonamiento, visión-lenguaje, comprensión de documentos, comprensión de video y visual agent
  • Lenguaje

    • Con solo 27 mil millones de parámetros, supera a Qwen3.5-397B-A17B en todos los principales benchmarks de programación
      • SWE-bench Verified 77.2 vs 76.2
      • SWE-bench Pro 53.5 vs 50.9
      • Terminal-Bench 2.0 59.3 vs 52.5
      • SkillsBench 48.2 vs 30.0
    • También aventaja con amplio margen a otros modelos densos de tamaño similar
    • En tareas de razonamiento registró 87.8 puntos en GPQA Diamond, una cifra capaz de competir con modelos de varias veces su tamaño
    • La tabla detallada incluye comparaciones entre Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B y Qwen3.6-27B
    • Principales métricas en Coding Agent
      • SWE-bench Multilingual 71.3
      • QwenWebBench 1487
      • NL2Repo 36.2
      • Claw-Eval Avg 72.4
      • Claw-Eval Pass^3 60.6
      • QwenClawBench 53.4
    • Principales métricas en Knowledge
      • MMLU-Pro 86.2
      • MMLU-Redux 93.5
      • SuperGPQA 66.0
      • C-Eval 91.4
    • Principales métricas en STEM y razonamiento
      • HLE 24.0
      • LiveCodeBench v6 83.9
      • HMMT Feb 25 93.8
      • HMMT Nov 25 90.7
      • HMMT Feb 26 84.3
      • IMOAnswerBench 80.8
      • AIME26 94.1
  • Configuración de evaluación de lenguaje

    • La serie SWE-Bench usa un agent scaffold interno junto con herramientas de bash y edición de archivos, con temp 1.0, top_p 0.95 y una ventana de contexto de 200K
      • Todos los modelos de referencia fueron evaluados en un refined benchmark que corrige algunas tareas problemáticas del conjunto público SWE-bench Pro
    • Terminal-Bench 2.0 usa el harness Harbor o Terminus-2
      • timeout de 3 horas, 32 CPU, 48 GB de RAM
      • temp 1.0, top_p 0.95, top_k 20, max_tokens 80K, ctx 256K
      • Promedio de 5 ejecuciones
    • SkillsBench evalúa 78 tareas con OpenCode
      • Se usa un subconjunto self-contained que excluye tareas dependientes de API
      • Promedio de 5 ejecuciones
    • La evaluación de otros modelos en NL2Repo usa Claude Code
      • temp 1.0, top_p 0.95, max_turns 900
    • QwenClawBench es un benchmark del agente Claw basado en distribución real de usuarios
      • temp 0.6, ctx 256K
    • QwenWebBench es un benchmark interno de generación de código frontend
      • Configuración bilingüe EN y CN
      • 7 categorías: Web Design, Web Apps, Games, SVG, Data Visualization, Animation y 3D
      • Evalúa código y alineación visual con auto-render y un judge multimodal
      • Usa el sistema de rating BT o Elo
    • AIME 26 usa por completo AIME 2026 I y II
      • Se aclara que las puntuaciones pueden diferir de la nota de Qwen 3.5
  • Visión-lenguaje

    • Qwen3.6-27B soporta tanto modo thinking como non-thinking en visión-lenguaje dentro de un único checkpoint unificado
    • Puede procesar imágenes y video junto con texto
    • Soporta tareas de razonamiento multimodal, comprensión de documentos y visual question answering
    • La tabla comparativa se presenta frente a Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B y Qwen3.6-27B
    • STEM y acertijos

      • MMMU 82.9
      • MMMU-Pro 75.8
      • MathVista mini 87.4
      • DynaMath 85.6
      • VlmsAreBlind 97.0
    • VQA general

      • RealWorldQA 84.1
      • MMStar 81.4
      • MMBench EN-DEV-v1.1 92.3
      • SimpleVQA 56.1
    • Comprensión de documentos

      • CharXiv RQ 78.4
      • CC-OCR 81.2
      • OCRBench 89.4
    • Inteligencia espacial

      • ERQA 62.5
      • CountBench 97.8
      • RefCOCO avg 92.5
      • EmbSpatialBench 84.6
      • RefSpatialBench 70.0
    • Comprensión de video

      • VideoMME(w sub.) 87.7
      • VideoMMMU 84.4
      • MLVU 86.6
      • MVBench 75.5
    • Visual Agent

      • V* 94.7
      • AndroidWorld 70.3
    • Nota

      • Los espacios en blanco (--) de la tabla significan que la puntuación aún no existe o no aplica

Uso de Qwen3.6-27B

  • Se indica que el soporte en Alibaba Cloud Model Studio estará disponible próximamente
  • Hay open weights disponibles en Hugging Face y ModelScope, con opción de self-hosting
  • También se ofrece acceso mediante la API de Alibaba Cloud Model Studio y una ruta de prueba inmediata en Qwen Studio
  • Se soporta la integración con asistentes de programación de terceros como OpenClaw, Claude Code y Qwen Code
  • Se menciona la simplificación del flujo de trabajo de desarrollo y una context-aware coding experience
  • Uso de API

    • Esta versión soporta la función preserve_thinking
    • Se describe como una función que preserva el contenido thinking generado en todos los turnos previos del mensaje, y se recomienda para agentic task
  • Alibaba Cloud Model Studio

    • Soporta chat completions y responses API compatibles con la especificación de OpenAI
    • También soporta una interfaz de API compatible con Anthropic
    • Se proporcionan ejemplos de variables de entorno según la documentación oficial
      • DASHSCOPE_API_KEY
      • DASHSCOPE_BASE_URL
      • DASHSCOPE_MODEL
    • También se indican regiones de ejemplo para Base URL
    • En el código de ejemplo se usa qwen3.6-27b como nombre de modelo por defecto
    • En extra_body se incluye enable_thinking: True
      • preserve_thinking: True aparece como comentario
    • También se incluye un ejemplo de respuesta en streaming que recopila por separado reasoning_content y answer content
    • Para más información se indica consultar el enlace de API doc
  • Coding & Agents

    • Qwen3.6-27B tiene capacidades de agentic coding y puede integrarse sin fricción con OpenClaw, Claude Code y Qwen Code
    • OpenClaw

      • OpenClaw es un AI coding agent open source y self-hosted; antes se llamaba Moltbot o Clawdbot
      • Al conectarse con Model Studio, ofrece una experiencia completa de agentic coding en la terminal
      • El script de inicio incluye Node.js 22+, ejecución del script de instalación, configuración de DASHSCOPE_API_KEY y ejecución de openclaw dashboard o openclaw tui
      • En el primer uso es necesario modificar ~/.openclaw/openclaw.json
        • Se indica explícitamente no sobrescribir el archivo completo
        • Solo deben fusionarse los campos necesarios para preservar la configuración existente
      • La configuración de ejemplo incluye el provider modelstudio y el registro del modelo qwen3.6-27b
        • api es openai-completions
        • El valor de reasoning es true
        • Los tipos de entrada son text, image
        • contextWindow es 131072
        • maxTokens es 16384
        • El modelo primary por defecto es modelstudio/qwen3.6-27b
    • Qwen Code

      • Qwen Code es un AI agent open source para terminal y una herramienta profundamente optimizada para la serie Qwen
      • El script de inicio incluye Node.js 20+, instalación de @qwen-code/qwen-code@latest y ejecución de qwen
      • Se muestran ejemplos de uso de los comandos /help y /auth dentro de la sesión
      • En el primer uso aparece un prompt de inicio de sesión, y con /auth se puede cambiar el método de autenticación
    • Claude Code

      • Las Qwen APIs también soportan el protocolo de API de Anthropic
      • Se indica que puede usarse con herramientas como Claude Code
      • El ejemplo de configuración incluye las siguientes variables de entorno
      • El comando de ejecución es claude

Cierre

  • Qwen3.6-27B demuestra que un modelo denso bien entrenado puede superar a una generación previa mucho más grande en tareas importantes para desarrolladores
  • Con una escala de 27 mil millones de parámetros, supera a Qwen3.5-397B-A17B en todos los principales benchmarks de agentic coding
  • Su estructura simplifica el despliegue y el servicio, y la familia open source Qwen3.6 ahora cubre una gama más amplia de configuraciones de modelo con la incorporación de Qwen3.6-27B

4 comentarios

 
kaydash 2026-04-23

Tendría que ser A3B para que al menos se pueda correr un poco en local jaja

 
kirinonakar 2026-04-23

Dicen que en los benchmarks sale bien, pero en uso real todavía no me parece que esté a un nivel como para usarlo como agente de programación.

 
b89kim 2026-04-26

Lo he probado y no hay grandes problemas para la codificación agéntica. Eso sí, como dices, en uso real y programación general inevitablemente rinde peor que los modelos con más parámetros. Ten en cuenta que los valores de configuración son distintos a los de 3.5 y que también se añadió el modo preserve_thinking. Con una cuantización 4bit del 27B, no hubo problema para usarlo en local.

 
GN⁺ 2026-04-23
Comentarios en Hacker News
  • Para mí, para ser un modelo local cuantizado a 16.8GB, el resultado de pelican fue realmente excelente. Lo resumí en https://simonwillison.net/2026/Apr/22/qwen36-27b/ y lo corrí en una M5 Pro con 128GB de RAM, pero la memoria real necesaria fue de unos 20GB, así que supongo que en una máquina con 32GB también debería correr sin problema. En lectura procesó 20 tokens en 0.4 segundos, o sea 54.32 tokens/s, y en generación produjo 4,444 tokens en 2 minutos 53 segundos, o sea 25.57 tokens/s. Me gustó más este resultado que el de pelican que hice hace unos días con Opus 4.7. https://simonwillison.net/2026/Apr/16/qwen-beats-opus/
    • Esto salió tan bien que hasta da la impresión de que quizá estaba en los datos de entrenamiento. Me gustaría ver más pruebas para comparar qué tanta diferencia hay
    • A veces bromeo con que en algún momento los proveedores de modelos van a empezar a optimizar para la influyente prueba de Simon de pelican riding a bicycle
    • La corbata de moño del Qwen Flamingo también se ve realmente impecable
    • Según recuerdo, casi nunca había escuchado que describieran la prueba de pelican como excellent de esta manera, pero esta vez de verdad parece merecido. Durante un tiempo la tendencia iba hacia MoE, así que también es interesante que ahora vuelva a llamar la atención un modelo dense. Me pregunto si los modelos cerrados también están yendo por una línea rápida con MoE y una línea pro con dense
    • A estas alturas uno pensaría que los LLM ya habrán entendido que el marco de una bicicleta es básicamente un rombo dividido por la mitad → ◿◸. Ojalá no esté arruinando la prueba por decirlo
  • Desde que salió Gemma 4 por Semana Santa, siento que la brecha entre los modelos para self hosting y Claude se ha reducido bastante. Claro, la diferencia sigue siendo grande, pero los modelos locales de antes eran tan poco competitivos que ahora la situación ha mejorado muchísimo. Y si Qwen 3.6 está un escalón por encima de Gemma 4, eso sí que emociona. Aun así, los modelos locales todavía a veces se desvían o fallan de formas raras, así que siempre mantengo Opus cerca. Pero incluso así, cada vez que un modelo local realmente me ayuda, siento más de cerca esa idea de que programar debería ser libre. Libre en el sentido de gratis, y libre en el sentido de libertad. Mi setup es una máquina Ubuntu aparte con una RTX 5090, y justo ahora Qwen 3.6 27B está usando 29GB de 32GB de VRAM. Corro Ollama en una instancia de podman sin root, y en el editor conecto OpenCode como servicio ACP; lo recomiendo muchísimo. ACP es Agent Client Protocol, y en mi opinión hacia allá debería ir el mundo. Y también agradezco al equipo de Qwen por haber hecho del mundo un lugar un poco mejor en un mundo lleno de Sam Altman
    • De todos los modelos que probé localmente en mi M5 MBP, Gemma4 fue el que más se sintió como Claude
    • Yo también comparto ese ideal de free y local, pero al final lo importante es la competencia sostenible. Solo con que exista presión para bajar mucho un costo de 200 dólares al mes, ya me doy por satisfecho
    • Me da curiosidad qué tanto trabajo de programación puede manejar realmente un modelo de 27B. Incluso Claude a veces se queda corto, así que me cuesta imaginar qué tan práctico sería 27B en trabajo real
    • Me pregunto cuántos tokens/s da en una RTX 5090
  • Ojalá que cada vez que anuncien un modelo también muestren en qué consumer hardware se puede correr hoy mismo, cuánto cuesta y cuántos tok/s da
    • Para correr de forma nativa en 16-bit el modelo 27B que publicaron ellos mismos, se necesita hardware considerable. Haría falta una Mac o un sistema Strix Halo con 128GB, varias GPU de consumidor con mucha memoria, o una tarjeta de estación de trabajo tipo RTX 6000. Por eso supongo que no promocionan demasiado en qué hardware de consumidor corre. La versión base que produce esos resultados no entra bien en un sistema de consumo típico. La mayoría usa versiones cuantizadas de menos bits en lugar del original. Pero la cuantización claramente tiene trade-offs, así que no es realista esperar exactamente la misma calidad que en los resultados anunciados. El Qwen3.5 27B anterior seguía siendo bastante usable hasta Q5 o Q4, dependiendo de cuánta pérdida de calidad se aceptara, y en sistemas de memoria unificada necesitaba 32GB extra de RAM, así que normalmente una Mac de 64GB era lo adecuado. También se podía con una NVIDIA 5090 de 32GB o con dos GPU de 16GB o 24GB, pero por la distribución iba más lento. Creo que hay que tomar con cautela las afirmaciones de que corre en un iPhone o en sistemas más pequeños. Con cuantizaciones extremas y varios trucos puede que logres ejecutarlo, pero muchas veces la calidad de salida ya no sirve para uso real. De vez en cuando aparecen repositorios para presumir que corre en hardware pequeño, pero muchas veces los resultados no son realmente buenos
    • A mí me dio ~5 tokens/s en una M4 con 32GB de RAM. Corrí unsloth/Qwen3.6-27B-GGUF:Q4_K_M con llama-server, y el modelo 35B-A3B daba unos 25 t/s. Para comparar, en una A100 eran unos 41 t/s y 97 t/s respectivamente. Todavía no he probado mucho el 27B, pero el 35B-A3B se descarrilaba seguido cuando el contexto pasaba de 15k~20k tokens. Para tareas básicas se puede usar con estabilidad, pero no me parece justo decir que esto ya está al nivel de los modelos frontier
    • Las combinaciones posibles de CPU/GPU para correr LLM locales son prácticamente infinitas, así que la mayoría primero elige un sistema según su presupuesto y objetivo, y luego estima el uso de VRAM viendo el tamaño del modelo y la cuantización. Si necesitas un análisis más detallado, puedes usar calculadoras de VRAM en línea, por ejemplo https://smcleod.net/vram-estimator/. Si tienes cuenta de huggingface, incluso puedes ingresar la configuración de tu sistema y ver con colores qué quant probablemente encaje. Y los t/s también dependen muchísimo de variables como el tamaño del contexto, así que con suerte solo se puede dar una estimación. Ahora mismo los LLM locales están llenos de trade-offs en todos los frentes, así que hay que seguir eligiendo qué optimizar según la tarea
    • Qwen3.5-27B corre sin problema en una tarjeta de 24GB con 4bit quant. Yo atiendo a 10 desarrolladores con dos Nvidia L4 y algunos flags de vllm, a 20~25 tok/s, y cuando hay poca carga llega a unos 40 tok/s. A los desarrolladores les parece suficiente, aunque sí pidieron más GPU para aumentar el throughput
    • A mí me da unos 30 t/s en una RTX 4090D, y usa 42GB de 48GB de VRAM. La cuantización es UD-Q6_K_XL y hay una discusión al respecto en https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/discussions/7
  • Lugares como Qwen o Minimax están publicando modelos open source que, aunque quedan un poco por debajo de OpenAI o Anthropic, muestran resultados de benchmark parecidos. Así que me pregunto cuál es exactamente la ventaja competitiva que tienen ahora OpenAI o Anthropic. Además, el precio por token de estos modelos abiertos es solo una fracción del de Anthropic Opus 4.6. https://artificialanalysis.ai/models/#pricing
    • En programación, ese último pequeño porcentaje de diferencia de calidad sí importa lo suficiente como para pagar el premium. No es lo mismo que generar spam masivo o comentarios de HN. Creo que esa es también la razón por la que la diferencia de compensación entre un ingeniero promedio y uno P99 es tan grande. Y que las empresas frontier sigan siendo competitivas aun asumiendo altos costos de I+D hoy termina siendo beneficioso a largo plazo, porque las obliga a hacer mejores productos y crear más valor añadido. En particular, creo que Anthropic está apuntando a posicionarse como un proveedor más confiable. Incluso Ali hospeda modelos frontier de pago, pero si no fueras una empresa china, ¿subirías una carga de trabajo de desarrollo de código de producción a un proveedor chino? OpenAI también genera dudas, pero al menos uno sospecha menos que te vayan a llevar secretos comerciales enteros. En Anthropic confío un poco más todavía. Por eso creo que existe ese premium. Hay demasiado precedente histórico de empresas chinas de hosting usando toda ventaja competitiva disponible y pudiendo compartirla con el gobierno o con otras empresas, así que la gente incorpora ese riesgo en el precio
    • Yo uso tanto Opus como Qwen, y en mi experiencia real la brecha entre ambos es mucho mayor de lo que sugieren los gráficos de benchmark. Si se quiere comparar con modelos hospedados, creo que hoy sería más adecuado mirar GLM. Es de los que más se acercan a los jugadores grandes, y antes lo vendían a precios muy bajos, pero últimamente ya empezaron a subirlos
    • Si estos resultados se deben a vampire attacks, entonces en cuanto los modelos cerrados aprendan a contaminar las rutas por donde les sacan las respuestas, quizá el rendimiento ya no se vea tan bien. Y cuando los usas en flujos de trabajo cotidianos, no están tan al mismo nivel. En razonamiento superficial pueden ir bien, pero en programación y tareas más difíciles la diferencia sigue siendo grande. Al menos entre los modelos abiertos que he probado, todavía no encontré ninguno que sea tan bueno como los cerrados. Si alguien tiene una buena configuración, me encantaría que la compartiera
    • En este momento, yo diría que no hay ventaja competitiva. Pero en cuanto algún ecosistema empiece a integrarse de verdad, ahí sí va a aparecer
    • El alto precio por token de Opus más bien demuestra que la gente está dispuesta a pagar por un modelo mucho mejor. Los nuevos modelos de OpenAI y Anthropic son claramente mejores que los open source; no es que los open source sean inutilizables, pero los frontier sí son mejor y probablemente lo seguirán siendo por un tiempo. Si el tiempo de un SWE vale más de 1 dólar por minuto, entonces incluso si una conversación cuesta 10 dólares, basta con que te ahorre 10 minutos para que valga la pena. Sobre todo en trabajo de código, pequeñas mejoras de calidad pueden traducirse en grandes ahorros de tiempo
  • Yo uso Qwen 3.6 35B y Gemma 4 26B en una M4 MBP, y aunque no están al nivel de Opus, sí hacen el 95% de lo que necesito, y el simple hecho de que todo esto corra completamente en local ya es impresionante
    • Me da curiosidad qué tipo de trabajo haces, y cómo conectas o usas Qwen o Gemma, o sea qué harness o enfoque empleas. En otras palabras, me gustaría entender cómo se ve tu flujo de trabajo y tu stack de software
    • Ahora ya son lo bastante útiles como para que, así como Codex se fue quitando trabajo él solo, yo también haya empezado a delegar más tareas a estos modelos locales. Y en mi M4, la versión 122B tiene mucho mejor throughput que el dense 27B, así que también tengo muchas ganas de probar esa
    • Me pregunto si usas esto con Ollama o con otra cosa
    • Me gustaría entender mejor qué significa exactamente ese 95%. Tengo dos dudas. Primero, si quieres decir que en calidad de salida está al 95% de la precisión de Opus 4.5 o 4.6. Segundo, si te refieres a que en llamadas a herramientas o tareas agentic, por ejemplo planear un viaje, rinde al 95% frente a Opus
  • Todavía no estoy muy familiarizado con los LLM locales, así que ayer pasé algo de tiempo configurando y probando algunos modelos Qwen3.6-35B-A3B. Creo que fueron mlx 4b y 8b, y gguf Q4_K_M y Q4_K_XL. En mi M4 de 64GB se veían bastante impresionantes. Pero según la tabla de TFA, este modelo nuevo parece un poco más inteligente, aunque también consume más VRAM, así que me pregunto si la diferencia clave es que sea dense. Y como 27B es más pequeño que 35B, también me hace pensar que pronto saldrán cuantizaciones que bajen todavía más el requerimiento de VRAM
    • La clave no es simplemente comparar el número de parámetros. El 35B-A3B es un modelo Mixture of Experts, así que en cada pasada solo se activan alrededor de 3B parámetros. Por eso la demanda real de cómputo escala más cerca de esos 3B que de 35B. Claro, todavía hace falta acceso de alto ancho de banda a todas las capas del modelo de 35B. En cambio este modelo sí es dense, así que en una Mac probablemente será mucho más lento. Por ejemplo, en mi M4 Pro me dio unos 9 tok/s con gguf Q6, y el 35-A3B me daba unos 70 tok/s con mlx Q4; no es una comparación totalmente justa, pero sirve como referencia. En general, estos modelos dense corren mejor en GPU dedicadas, y si tienes suficiente VRAM para mantener todo el modelo residente, la decisión se vuelve sencilla. Yo estimaría que este modelo está bien con unos 24GB VRAM o más, así que una NVIDIA 3090, 4090 o 5090 debería ir bien
  • En llama server con Q4_K_M, en 24GB sale un contexto de 91k aproximadamente, y haciendo cuentas el KV-Cache ronda unos 70MB por cada 1K de contexto. Si hubiera usado Q5, probablemente todavía habrían quedado unos 30K tokens de espacio, y la verdad eso me parece bastante impresionante
  • Yo intenté generar un pelican montando bicicleta en SVG, y el resultado fue https://codepen.io/chdskndyq11546/pen/yyaWGJx. También hice un dragón comiendo un hot dog mientras maneja un auto, y el resultado fue https://codepen.io/chdskndyq11546/pen/xbENmgK. No es perfecto, pero incluso solo con esos resultados se nota bastante lo poderosos que se han vuelto estos modelos
    • La imagen del dragón tiene problemas como un solo ojo o una cola rara, pero la del pelican me pareció casi perfecta, hasta el punto de sentir que es de las mejores que he visto
    • Esto ya se volvió un benchmark tan famoso que dan ganas de preguntarse si los modelos no estarán ya entrenados específicamente para esta prueba
  • Por mi experiencia con inferencia local hasta ahora, todavía no me ha impresionado demasiado. En una M5 Pro con 128GB de RAM, con omlx me daba unos 11 tokens/s, así que al final tardé una hora en escribir unos cientos de líneas de código que ni funcionaban. Opus y Sonnet, en cambio, resolvieron con éxito la misma tarea en cuestión de minutos en CC. El modelo 3.6 35b que corrí ayer en Ollama se veía más o menos bien. Pienso probar otros harnesses además de Claude Code, pero por ahora mi sensación es que los modelos locales siguen siendo demasiado lentos
    • Como esto es un dense model, es normal que sea lento en Mac. Si estás en Mac, te convendría probar la versión Mixture of Experts de Qwen3.6, o sea Qwen3.6-35B-A3B. En mi M4 Pro me dio alrededor de 70 tok/s. Si te va muchísimo más lento que eso, quizá por error estés usando formato GGUF. En Mac, el formato MLX específico de Apple muchas veces es más rápido
    • En mi MacBook M2 Max, con la versión MLX cuantizada a 8-bit, la velocidad de generación era de unas 7 tokens/sec
    • Sentí que OpenCode aprovecha mejor los modelos locales que Claude
  • Me pregunto qué se puede correr con 48GB de RAM en una M4 Pro