2 puntos por GN⁺ 10 일 전 | 1 comentarios | Compartir por WhatsApp
  • Como sucesor de Qwen3.6-Plus, mejora frente a la versión anterior en codificación agéntica, además de ofrecer un conocimiento del mundo más sólido y mejor desempeño en seguimiento de instrucciones
  • Registró la puntuación más alta en 6 benchmarks principales de codificación, confirmando una gran mejora en el rendimiento como agente de código
  • Compatible con la función preserve_thinking, que en tareas agénticas utiliza un método para conservar en los mensajes el proceso de pensamiento de los turnos anteriores
  • En benchmarks de conocimiento del mundo, mejoró con SuperGPQA +2.3 y QwenChineseBench +5.3, entre otros; y en seguimiento de instrucciones registró +2.8 en ToolcallFormatIFBench
  • Se puede probar de forma interactiva en Qwen Studio y estará disponible mediante la API de Alibaba Cloud Model Studio con el nombre qwen3.6-max-preview

Mejoras principales

  • Gran mejora en capacidad de codificación agéntica frente a Qwen3.6-Plus: SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
  • Refuerzo del conocimiento del mundo (world knowledge): SuperGPQA +2.3, QwenChineseBench +5.3
  • Mejora en seguimiento de instrucciones (instruction following): ToolcallFormatIFBench +2.8
  • Logró la puntuación más alta en 6 benchmarks principales de codificación: SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode

Características del modelo y enfoque

  • Modelo exclusivo hospedado ofrecido a través de Alibaba Cloud Model Studio
  • Mejoras en el rendimiento de agentes reales (real-world agent) y en la confiabilidad del conocimiento (knowledge reliability)
  • Puede probarse de inmediato de forma interactiva en Qwen Studio
  • El nombre del modelo en la API es qwen3.6-max-preview y pronto podrá usarse en la API de Alibaba Cloud Model Studio

Uso de la API y funciones

  • Compatible con protocolos estándar de la industria, como OpenAI-compatible chat completions y responses API, así como interfaces compatibles con Anthropic
  • Mediante la función preserve_thinking, es posible conservar el proceso de razonamiento (reasoning content) de turnos anteriores, recomendado para tareas agénticas
  • Al configurar enable_thinking: True, se puede recibir por streaming de forma separada el contenido de razonamiento y la respuesta
  • Se ofrecen Base URL regionales para la API: Beijing, Singapur y Estados Unidos (Virginia)

Estado de desarrollo

  • Actualmente está en fase de preview release y continúa mejorando de forma iterativa; se prevén mejoras adicionales en versiones posteriores

1 comentarios

 
GN⁺ 10 일 전
Comentarios de Hacker News
  • Me parece un poco gracioso que la gente se obsesione solo con las comparaciones de SOTA. Yo he visto casos en los que glm 5.1 logró cosas que Opus no pudo, y también lo he visto escribir mejor código. Aún no he probado qwen max, pero también he visto que el modelo local 122b lee mejor la documentación y la procesa con más precisión. Al final, los benchmarks son solo una parte; en la práctica, cada modelo tiene fortalezas distintas, así que no creo que tenga sentido hablar de ellos como si estuviéramos comparando un martillo y una llave inglesa en una escala simple de superioridad

    • Yo uso GLM-5.1 en pi.dev de Ollama Cloud para proyectos personales y la verdad estoy bastante satisfecho. En el trabajo usamos pi.dev junto con Claude Sonnet y Opus 4.6. Claude Code también está bien, pero desde una actualización reciente me resultó incómodo porque había que hacer compact demasiado seguido. Cuando usaba pi.dev, no eché de menos MCP tool calling porque la integración por API funcionaba bien. De hecho, sentí que para crear sitios web GLM-5.1 lo hacía mejor que Claude Opus, y también está rindiendo muy bien en la plataforma de desarrollo full stack que estoy construyendo ahora
    • GLM 5.1 fue el primer modelo que me hizo sentir que los modelos chinos de verdad ya habían alcanzado el nivel. Por eso cancelé mi suscripción a Claude Max y, sinceramente, no la extraño para nada. Viendo lo divididas que están las opiniones, parece que ya llegamos a una etapa en la que importan más las diferencias de dominio y patrón de uso que una jerarquía absoluta de SOTA
    • La razón casi única por la que sigo usando Claude y ChatGPT es por el tool calling. También tienen funciones útiles como skills. Probé qwen y deepseek, pero hubo casos en los que ni siquiera podían sacar bien la documentación. Me da curiosidad cómo procesan documentos o Excel con estas herramientas, y si se puede, yo también quisiera cambiarme
    • Hace unos meses, Qwen3-Coder me generó código Rust mucho mejor que Claude Opus o Google Gemini. Me impresionó sobre todo porque hasta producía código que aprovechaba las extensiones vectoriales x86-64 de Rust. Yo lo llamaba desde harnesses como Zed editor o trae CLI, y de verdad me sorprendió muchísimo
    • Los modelos en general tienen puntuaciones de benchmark parecidas y las diferencias son pequeñas, así que en una situación así me parece razonable elegir por otros criterios. En mi caso, si sale un plugin de JetBrains decente, me cambio de proveedor de inmediato
  • Llevo varios meses usando Claude Code de forma constante en la empresa y hace poco también lo aproveché bien en un pequeño proyecto personal de sitio web. El fin de semana pasado intenté por primera vez hacer self-hosting. Me pregunto si alguien, después de usar bastante CC o Codex y quedar razonablemente satisfecho, encontró una configuración self-hosted que valga la pena. Yo probé varias combinaciones con 32GB DDR5, AMD 7800X3D, RTX 4090, Windows y WSL, usando ollama, docker desktop model runner, pi-coding-agent, opencode y Gemma 4, Qwen, GLM-5.1. Como el uso base de RAM ya era alto, no pude correr buenos modelos como Gemma4-31B. En Windows puro, el manejo de rutas de archivos se rompía seguido, y la modalidad de correr pi u opencode en WSL mientras el modelo corría en docker desktop tuvo cierto éxito. Aun así, el rendimiento percibido era demasiado lento comparado con CC, y el nivel de acabado de las herramientas me pareció muy superior del lado de CC harness. Gasté demasiado tiempo en la configuración y no pude usarlo mucho en la práctica, pero igual fue un experimento interesante

    • Te convendría probar un modelo MoE y hacer offloading de la inferencia al CPU. Ejemplos serían Gemma 4 26b-a4b o qwen3.6 35b-a3b. Con 32GB de RAM puede quedar algo justo si además tienes otras apps abiertas, pero si tienes suficiente RAM del sistema, corre bastante bien. También puedes subir algunas capas al GPU, aunque hubo problemas con la combinación de modelos MoE y llama.cpp. En cambio, si dejas el KV cache en la GPU, la velocidad sale bastante bien y también puedes mantener una ventana de contexto razonable. Yo vi resultados muy impresionantes en local. Además, recomiendo mucho clonar directamente llama.cpp en WSL2 y dejar que un modelo frontier como Claude Code haga la instalación y el tuning. Las apps montadas encima de llama.cpp no exponen todas las opciones y flags, y con solo poner mal un flag puedes arruinar mucho el rendimiento, por ejemplo haciendo que no funcione el context cache. Si compilas directo desde el código fuente, cuando aparezcan problemas puedes revisar el código real enseguida. Con esa máquina, en Gemma 4 deberías sacar al menos unos 20~40tok/s, así que se puede usar perfectamente en la práctica, y qwen3.6 podría ir todavía más rápido porque sus parámetros activos son 3b
    • El problema que estás viendo probablemente venga de que falta VRAM y por eso no puedes cargar el modelo completo de una sola vez. También podrías probar llmfit
  • Me preocupa que este sector parezca ir hacia sacar primero algo gratis para hacerse conocido y luego volverlo todo propietario. Aun así, ojalá sigan saliendo open weights. El día que nadie publique open weights va a ser realmente amargo. Si llegamos a ese mundo, a la gente común le va a resultar más difícil poseer su propio compute

    • Me parece una generalización un poco exagerada. Muchos modelos de EE. UU. fueron cerrados desde el principio, mientras que los modelos fuera de EE. UU., especialmente los modelos chinos, fueron más abiertos desde etapas tempranas. De hecho, en China hubo casos de modelos que empezaron siendo proprietary y luego pasaron a públicos, y entre los modelos grandes de Qwen hubo ejemplos así
    • Yo lo veo como un movimiento de estrategia nacional. Parece una dinámica de seguir publicando modelos gratuitos competitivos para debilitar el moat que las empresas occidentales quieren construir con modelos proprietary. Mientras se mantenga una narrativa favorable para China, no creo que haya muchas probabilidades de que vuelvan por completo a lo proprietary
    • Incluso desde la perspectiva de los fabricantes de chips, supongo que les conviene que siga existiendo un entorno donde podamos correr modelos locales
    • Sí. Creo que para los laboratorios chinos el open source es una especie de estrategia comercial. No tienen muchas otras formas efectivas de marketing para dar a conocer sus modelos y servicios de inferencia, así que en parte eligen ese camino por eso. También vale la pena leer este texto relacionado
    • Siempre sentí que la estructura ya era parecida desde antes. Al final, esto también se parece mucho a SaaS, y la diferencia es que hoy el plan de suscripción más bajo de los frontier labs casi parece una prueba gratis
  • Hoy también salió Kimi K2.6, así que me parece bastante natural compararlos. Solo viendo el precio, Qwen cuesta 1.3 dólares de entrada y 7.8 dólares de salida, mientras que Kimi cuesta 0.95 de entrada y 4 de salida, así que Qwen se ve más caro. Además, en el post de anuncio solo coinciden dos benchmarks, y tanto en SWE-Bench Pro como en Terminal-Bench 2.0 Kimi quedó un poco por encima de Qwen. Claro, cada modelo tiene sus fortalezas y los benchmarks no lo son todo, pero si uno mira solo los números, Kimi se siente más atractivo

    • Siento que los modelos chinos han perdido algo de atractivo a medida que suben los precios. Y desde que salió Gemma-4, no me parece que queden muchos modelos en la frontera de Pareto. Mi impresión personal va por ahí, y también puedes mirar las estadísticas del leaderboard de arena
  • La ironía de este anuncio, para mí, está en el nombre mismo. Max-Preview es proprietary y solo en la nube. Para mí, el Qwen que realmente importa es la serie open weights que la gente corre en su propio hardware. Yo corro 32B y 72B en local con dual A4000. Todavía hay una diferencia respecto al Max hosted, pero se nota que con cada release esa brecha se acorta. Por eso, la pregunta realmente interesante no es cómo se compara Max con Opus, sino cuándo el tier open-weight va a volver irrelevante al tier cloud para la mayoría de las cargas de trabajo

  • Mientras todos persiguen solo el SOTA, yo resuelvo todo mi trabajo de programación con varias sesiones paralelas en MiniMax M2.5 por 10 dólares al mes, y casi nunca me topo con límites

    • Si se trata de trabajo serio, para la mayoría de los desarrolladores profesionales la diferencia entre 10 y 100 dólares al mes no es algo sobre lo que valga tanto la pena pensar. Habrá excepciones, como estudiantes o usuarios de países de bajos ingresos, pero siempre me parece raro ver a un desarrollador con salario alto ahorrar demasiado en herramientas. Siento que incluso los modelos SOTA actuales todavía son difíciles de confiar del todo más allá de tareas puntuales, así que no me atrae nada ahorrar entre 10 y 100 dólares al mes mientras superviso modelos aún peores. Con modelos self-hosted sí me divierto experimentando en tareas ligeras y descartables, pero en trabajo realmente importante no quiero desperdiciar mi tiempo
    • Me da curiosidad saber dónde pagas esos 10 dólares al mes. Quisiera preguntar si es OpenRouter
    • Me interesa saber cómo lo usas en la práctica. Si usas opencode o algún otro frontend
  • Yo también revisé la documentación de context caching de Qwen e hice pruebas con Opus, Codex y Qwen, y sí siento que Qwen es fuerte en muchas tareas de programación. Pero lo que más me importa es cómo se comporta en sesiones largas. Qwen presume una ventana de contexto grande, pero en la práctica la eficiencia en contexto largo parece depender mucho de cómo funciona el context caching. Según la documentación oficial, ofrece tanto caching implícito como explícito, pero el TTL dura solo unos minutos y además hay restricciones como matching por prefijo y una cantidad mínima de tokens. Por esas limitaciones, en flujos de trabajo donde el contexto sigue creciendo, como los agentes de programación, puede que la reutilización de caché no funcione tan bien como uno esperaría. Entonces, aunque el precio por token se vea bajo, en sesiones largas el cache hit rate puede caer y aumentar el recálculo, haciendo que el costo percibido se sienta mayor. Aun así, en tareas de seguridad personalmente hubo casos en los que Qwen me fue mejor que Opus. En mi experiencia, Qwen funciona muchísimo mejor que Opus en tareas cortas como métodos o funciones individuales, pero visto como experiencia de programación integral, me parece más un generador a nivel de función que un asistente de programación autónomo end-to-end como Claude

    • Aun así, sí creo que best practice es cortar las sesiones largas y empezar de nuevo con sesiones cortas. Incluso en Claude Code Best Practices, Anthropic dice que “una sesión nueva y limpia con un mejor prompt casi siempre es mejor que una sesión larga con modificaciones acumuladas”
    • La última vez que lo revisé, context caching solo reducía costo y latencia, y no cambiaba qué tokens se generaban realmente
  • Viendo que Qwen se compara con Opus 4.5, me cuesta un poco tomarlo como algo de buena fe. Entiendo que no incluyan Opus 4.7 porque es muy reciente, pero Opus 4.6 salió hace ya bastante tiempo

    • Para mí, Opus 4.5 fue el primer punto en el que sentí que el modelo era lo suficientemente bueno en una variedad de problemas. Antes de eso, usar IA para desarrollo casi siempre me hacía perder más tiempo por las alucinaciones, así que no era una elección productiva. Pero si el progreso se hubiera detenido en Opus 4.5, igual creo que ya habríamos podido resolver muchísimo trabajo real con más rapidez. No creo que el desarrollo de software vaya a volver por completo a centrarse en escribir todo a mano. Por eso, si ofreces un nivel similar o un poco mejor que Opus 4.5 por una décima parte del precio, para mucha gente ya sería bastante atractivo. Claro, para los desarrolladores occidentales sigue valiendo la pena pagar más de 100 dólares al mes por Opus 4.7. El tiempo que te hacen perder los modelos de menor nivel sale mucho más caro. Por un tiempo seguiré pagando el premium por modelos que me hagan perder menos tiempo y den mejores resultados con menos correcciones de prompt. Al mismo tiempo, la velocidad del cambio es realmente asombrosa, y hoy los modelos abiertos ya llegaron a un nivel capaz de competir con modelos frontier de hace dos años. Qwen 3.6 MoE 35B A3B o los modelos grandes de Gemma 4 pueden correr en equipos bastante normales, como una Macbook potente, Strix Halo o GPUs recientes de 24GB o 32GB, y no cuestan mucho más que una laptop de desarrollador de la era pre-AI. Escriben código, escriben texto bastante bien, usan herramientas y tienen un contexto suficiente para trabajo real. Todavía no están al nivel de Opus 4.5, pero son bastante impresionantes. Yo ya mezclo varios modelos para seguridad y revisión de código y, aunque sigo sintiendo que Claude Code y Opus son lo mejor para la mayoría del desarrollo de software, igual estoy dispuesto a usar Qwen. Los modelos pequeños también rinden muy bien para su tamaño, así que tengo expectativas altas para los grandes
    • Si el dinero no importara en absoluto, entonces bastaría con mirar solo el máximo rendimiento, como Codex 5.4 u Opus 4.7. Pero para mucha gente la calidad frente al costo es una variable enorme. Incluso entre los suscriptores de Claude, por costo y presión de uso hay muchos que no pueden usar siempre Opus 4.7 y terminan usando Sonnet o versiones anteriores de Opus. Por eso, si miras la curva de calidad por valor, este tipo de comparación sí tiene bastante sentido
    • En los últimos meses, el rendimiento de Opus 4.6 ha sido demasiado inconsistente, así que no quería desperdiciar tokens a propósito
    • Cuando salió Sonnet 4.6, cambié mi modelo por defecto de Opus a Sonnet. Mi sensación fue que Sonnet 4.6 estaba más o menos al nivel de Opus 4.5. 4.6 y 4.7 son mejores, claro, pero en la mayoría de las tareas el salto no es tan grande, así que ahora ahorrar costos ya es una opción completamente razonable. Si modelos más baratos llegan a ese nivel, eso sería todavía más importante, y GLM 5.1 se ve bastante cerca, por eso lo uso mucho. Desde esa perspectiva, comparar con Opus 4.5 también me parece válido
    • Creo que las comparaciones deben hacerse entre los objetivos más parecidos. Y cuando los benchmarks los publica directamente el proveedor, es obvio que puede elegir frameworks donde su modelo rinde bien y dejar fuera lo que le conviene menos. Por eso, al final, lo que de verdad vale son los benchmarks independientes
  • Últimamente, viendo a los proveedores chinos, siento que hay un patrón. Primero, que están yendo hacia mantener los modelos como closed source; segundo, que están subiendo bastante los precios. En algunos casos, casi un 100 por ciento

    • Suena un poco raro decirlo como si fuera una característica exclusiva de las empresas chinas. Las empresas de otros países no son para nada diferentes en eso
    • Qwen max siempre fue solo cloud, y como es un modelo de más de 1T, me parece natural que sea caro
    • Me gustaría devolver la pregunta: ¿en qué se diferencia eso de las empresas estadounidenses cuando suben mucho los precios?
    • Me pregunto si eso también aplica a modelos como GLM 5.1, DeepSeek V3.2 o el recién salido Kimi K2.6. En realidad no me parece que encaje muy bien con esos casos
    • Lo primero que me viene a la cabeza es que a las empresas estadounidenses también les encanta esa jugada
  • Lo curioso es que puedes conocer toda la familia de modelos Qwen que se pueden correr en local y aun así no saber absolutamente nada de los modelos en la nube. Yo solo conocía las series 3.5 y quizá uno de 3.6, y el nombre Plus fue la primera vez que lo vi ahora

    • Si mal no recuerdo, la serie Plus existe desde que se hizo público Qwen chat. Al menos recuerdo haber usado directamente un modelo Plus a comienzos del año pasado