Evaluaciones de DeepSeek V3.2: qué miden sus benchmarks y hasta dónde se pueden comparar

Alcance: qué se puede afirmar con la evidencia disponible

Una puntuación de benchmark no describe por sí sola un modelo. Para interpretarla hacen falta, como mínimo, la tarea evaluada, el conjunto de pruebas, la métrica, la variante del modelo y las condiciones de ejecución. Si alguno de esos elementos cambia entre dos resultados, la comparación puede dejar de ser directa, aunque ambos números aparezcan en una misma tabla o se presenten como resultados del mismo sistema.

Esta revisión aplica ese criterio a DeepSeek-V3.2. El material disponible confirma la existencia de un paper con ese nombre y de una nota oficial de lanzamiento que distingue DeepSeek-V3.2 de DeepSeek-V3.2-Speciale. También identifica documentación del modelo en Hugging Face, un repositorio de DeepSeek para DeepSeek-V3.2-Exp y análisis externos sobre V3.2-Exp y sobre benchmarks de API. Los fragmentos aportados, sin embargo, no incluyen las tablas completas ni los protocolos de evaluación del paper.

Por eso, esta pieza no presenta puntuaciones concretas ni reconstruye una clasificación entre modelos. Tampoco convierte menciones generales a razonamiento, programación o uso de herramientas en resultados cuantitativos. Su propósito es delimitar qué permite afirmar el material localizado, separar fuentes de naturaleza distinta y especificar qué debe verificarse en los documentos íntegros antes de utilizar un número para elegir un modelo o comparar sistemas.

El índice de benchmarks y la ficha denominada «evaluaciones-deepseek-v32» sirven como rutas temáticas para organizar esa revisión; no constituyen, por sí mismos, evidencia de que una prueba se haya ejecutado ni de que un resultado sea reproducible. La entidad relevante para esta pieza es DeepSeek, y el modelo objeto de auditoría es DeepSeek-V3.2, no cualquier sistema cuyo nombre incluya «DeepSeek».

Inventario de fuentes y de lo que permiten comprobar

El paper titulado DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models es la fuente prioritaria para auditar las evaluaciones atribuidas al modelo. El fragmento disponible lo presenta como un trabajo sobre DeepSeek-V3.2, con énfasis general en eficiencia computacional, razonamiento y rendimiento de agentes. Ese resumen no revela los nombres de los benchmarks, sus puntuaciones, los conjuntos evaluados ni las condiciones de ejecución. Por tanto, no es suficiente para completar un inventario de pruebas.

La nota oficial de lanzamiento resulta útil para distinguir variantes: el material proporcionado separa V3.2, descrito en relación con el equilibrio entre inferencia y longitud, de V3.2-Speciale, descrito como una configuración orientada al razonamiento máximo. Es una distinción importante, pero no demuestra que una tabla concreta del paper evalúe una u otra variante. Para asignar cada resultado hace falta consultar el encabezado de la tabla, sus notas y la sección metodológica correspondiente.

La ficha del modelo en Hugging Face es documentación primaria del proveedor y confirma que existe una página identificada como DeepSeek-V3.2. El fragmento aportado no especifica un protocolo completo de benchmark. En paralelo, la reseña externa titulada DeepSeek V3.2-Exp Review se refiere explícitamente a V3.2-Exp y menciona evaluaciones de programación de forma general; no debe trasladarse automáticamente a V3.2.

El repositorio DeepSeek-V3.2-Exp también concierne a una variante experimental. El fragmento indica que sus configuraciones de entrenamiento se alinearon con las de V3.1-Terminus para estudiar el efecto de la atención dispersa. Eso caracteriza el propósito experimental descrito, pero no acredita que los resultados de Exp sean los del modelo V3.2. Por último, el análisis de DeepInfra se centra, según su título y descripción, en benchmarks de API, latencia y throughput. Es otra clase de medición y no se debe mezclar con pruebas de capacidad sin revisar su metodología.

Qué datos debe contener una ficha benchmark por benchmark

Para publicar una tabla de evaluaciones con trazabilidad, cada fila debe identificar la prueba y explicar qué tarea plantea. No basta con una etiqueta como «razonamiento» o «programación»: conviene especificar el conjunto o la versión del benchmark, el tipo de entrada y salida y el criterio de puntuación. También hay que consignar si el resultado corresponde a una ejecución directa, a una configuración con herramientas o a un sistema que combina modelo y entorno.

La métrica debe nombrarse y definirse, no solo reproducirse como cifra. Una tasa de acierto, una puntuación agregada y una medición de latencia responden a preguntas distintas. Si hay varias métricas, se debe indicar cuál se usa para la comparación principal y cómo se calculó. Si una prueba se ejecuta varias veces, es relevante conocer el número de intentos y la forma de agregarlos; si se informa un único resultado, no debe suponerse que sea un promedio o que tenga una incertidumbre estadística publicada.

La identificación del modelo también necesita precisión. «DeepSeek» puede referirse a distintas generaciones, y V3.2, V3.2-Speciale y V3.2-Exp no son nombres intercambiables. Una versión de API, una revisión de pesos o una configuración con herramientas pueden cambiar lo que se está evaluando. Si la fuente no identifica el artefacto exacto, esa limitación debe quedar visible en lugar de completarse por inferencia.

En los fragmentos disponibles no constan las filas necesarias para completar esa ficha. En consecuencia, una tabla de resultados cuantitativos estaría incompleta si se elaborara ahora. La tabla de evidencia anterior es deliberadamente una matriz de disponibilidad: evita presentar como comprobado lo que requeriría consultar y cotejar el paper completo.

Protocolo y comparabilidad: por qué dos cifras pueden no ser equivalentes

Una comparación válida exige algo más que usar el mismo nombre de benchmark. La versión del conjunto, las instrucciones, el prompt, el harness y el método de puntuación pueden afectar el resultado. También importan las herramientas disponibles: un agente con acceso a búsqueda, ejecución de código u otros recursos no se mide necesariamente en las mismas condiciones que el modelo aislado. Estas variables deben describirse en la fuente o controlarse al comparar.

El presupuesto de tokens es otra condición relevante. Si una ejecución puede generar más tokens, realizar más pasos o efectuar más intentos, puede disponer de más oportunidades para resolver una tarea. Eso no invalida la evaluación, pero obliga a describir el presupuesto y a evitar presentar el resultado como si se hubiera obtenido bajo recursos equivalentes. Lo mismo ocurre con límites de tiempo, parámetros de muestreo y criterios para repetir respuestas.

Los fragmentos suministrados no detallan el prompt, el harness, las herramientas, el presupuesto de tokens ni el número de ejecuciones de las pruebas del paper. Tampoco indican si las puntuaciones de DeepSeek y las de otros modelos se generaron con versiones idénticas de los conjuntos y procedimientos equivalentes. Por tanto, no se puede afirmar, a partir de este material, que una comparación particular sea justa o no lo sea; lo correcto es decir que no está verificada aquí.

Los análisis de API requieren una separación adicional. Una medición de latencia puede depender de la región, la carga del servicio, el tamaño de la entrada y la longitud de la respuesta. El throughput puede reflejar capacidad de servicio bajo una carga definida. Esas observaciones pueden ser útiles para evaluar una implementación, pero no sustituyen una prueba de capacidad del modelo, ni deben incorporarse a una clasificación de razonamiento sin justificar una relación entre las métricas.

Contaminación, reproducibilidad y límites de la evidencia

La contaminación de un conjunto de evaluación con datos de entrenamiento puede comprometer la interpretación de una puntuación, pero no debe inferirse solo porque un resultado parezca alto ni porque el benchmark sea conocido. Para sostener una afirmación sobre contaminación hacen falta pruebas y una explicación del método usado para detectarla o limitarla. Con el material disponible no se puede confirmar qué comprobaciones describe el paper, ni qué evidencia aporta sobre solapamientos.

La reproducibilidad depende de que se publiquen elementos suficientes para reconstruir la evaluación: versión del modelo, código o harness, instrucciones, configuración, acceso a los casos y condiciones de ejecución. La existencia de una ficha del modelo o de un repositorio no demuestra, por sí sola, que todos esos componentes estén disponibles para cada benchmark. Tampoco la descripción de una variante experimental prueba que sus evaluaciones puedan replicarse en condiciones idénticas.

En esta revisión, el nivel de detalle disponible es desigual. Hay indicios suficientes para separar las fuentes por objeto —paper del modelo, nota de lanzamiento, ficha, variante experimental y mediciones de API—, pero no para certificar el inventario completo de pruebas, reproducir sus puntuaciones o evaluar las comprobaciones de contaminación. Esta diferencia entre «la fuente existe» y «el protocolo está verificado» debe conservarse en cualquier resumen posterior.

Si el documento íntegro contiene apéndices, notas de tabla o enlaces a código, esos elementos podrían resolver parte de las preguntas pendientes. Hasta consultarlos, la ausencia de información en los fragmentos recibidos no debe convertirse en una afirmación de que DeepSeek omitió publicar el dato. La formulación precisa es más limitada: aquí no se cuenta con evidencia suficiente para comprobarlo.

Variantes y acceso: modelo, experimento y servicio

La nota oficial de lanzamiento diferencia DeepSeek-V3.2 de DeepSeek-V3.2-Speciale. Esa distinción basta para exigir que toda cifra se atribuya a una variante identificable, pero no basta para saber cuál se evaluó en cada prueba. Antes de comparar resultados, hay que revisar el nombre que aparece en la tabla original y cualquier nota que defina la configuración. Si la tabla solo dice «V3.2», no se debe reinterpretar automáticamente como Speciale o como V3.2-Exp.

V3.2-Exp merece un tratamiento independiente. La fuente de DeepSeek sobre esa variante la sitúa en un estudio de la atención dispersa y menciona una alineación de configuraciones de entrenamiento con V3.1-Terminus. Esa información ayuda a entender por qué una evaluación de Exp podría pertenecer a un experimento comparativo específico. No autoriza a sumar sus resultados a los de V3.2 como si fueran una sola versión.

También conviene distinguir pesos o modelo de las condiciones de acceso mediante API. La respuesta servida puede depender de una versión desplegada, de límites operativos y de parámetros de servicio. Un análisis externo de latencia y throughput puede describir el comportamiento de una API bajo las condiciones elegidas por quien mide; sin detalles de ese entorno, no debe atribuirse una diferencia exclusivamente a la arquitectura o a la capacidad general del modelo.

Para responsables de compra, esta separación evita una conclusión habitual pero débil: seleccionar una configuración porque aparece asociada a una puntuación de otra variante o a una medición de servicio que responde a una pregunta distinta. La decisión requiere identificar el producto exacto, el modo de acceso y la tarea real de despliegue, además de consultar si la evaluación refleja las restricciones y herramientas que tendrá el sistema en producción.

Qué permiten concluir las pruebas y qué queda fuera

Cuando se verifica una puntuación, su conclusión debe limitarse a la tarea, el conjunto y las condiciones en que se obtuvo. Un resultado en una prueba de programación no demostraría automáticamente un nivel general de programación en todos los lenguajes, repositorios o flujos de trabajo. Una evaluación de razonamiento tampoco demostraría por sí sola seguridad, fiabilidad sostenida, calidad de citas, adaptación a una organización o rendimiento en producción.

En este caso concreto, los fragmentos aportados no permiten formular conclusiones cuantitativas sobre DeepSeek-V3.2, ni sostener que supere a un modelo determinado en un benchmark específico. Sí permiten organizar las preguntas correctas: qué variante se probó, qué tarea se midió, qué métrica se informó, qué recursos se autorizaron y quién ejecutó la prueba. También permiten advertir que la reseña de V3.2-Exp y el análisis de benchmarks de API no son sustitutos del protocolo del paper.

Una valoración operativa debería complementar los benchmarks publicados con pruebas propias, usando tareas representativas y criterios fijados antes de comparar. En una evaluación interna conviene incluir fallos, variabilidad, costes y tiempos, no únicamente el mejor resultado. Si se emplean herramientas, la evaluación debe medir el sistema completo y documentar qué parte del rendimiento depende del modelo y cuál del entorno.

No es posible afirmar que una evaluación publicada prediga por sí sola el comportamiento de DeepSeek-V3.2 en todos los contextos. La transferencia depende de la proximidad entre la tarea de prueba y el uso real. Esta limitación no desacredita los benchmarks: delimita la pregunta que contestan y evita convertir una medición acotada en una afirmación general sobre capacidad.

Conclusión: resultados verificados y preguntas pendientes

La conclusión más sólida que permite el material disponible es metodológica. Existe un paper de DeepSeek-V3.2, una nota oficial que distingue V3.2 de V3.2-Speciale y materiales relacionados con una variante V3.2-Exp y con mediciones de API. Las fuentes no son intercambiables: cada una trata un objeto o una pregunta distinta. El fragmento del paper no proporciona aquí las tablas ni el protocolo completo, por lo que no hay base suficiente para publicar una clasificación cuantitativa verificada.

Antes de incorporar resultados a una comparativa, el siguiente paso es consultar el paper íntegro y registrar cada prueba con su versión, variante, métrica y condiciones. Después hay que cotejar las notas de tabla y los apéndices, y separar resultados oficiales de evaluaciones externas. Si una condición no aparece, debe quedar señalada como desconocida; no se debe rellenar a partir de la ficha del modelo, de una reseña o de la descripción de otra variante.

Para lectores del índice de benchmarks, la regla práctica es sencilla: una puntuación solo es comparable cuando la tarea y las condiciones relevantes están suficientemente alineadas. Para equipos que evalúan DeepSeek-V3.2, conviene exigir trazabilidad hasta la tabla original y realizar pruebas propias con el producto y la configuración que realmente se desplegarán. En el estado actual de la evidencia suministrada, los resultados concretos siguen pendientes de verificación documental.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.