Cuantización DeepSeek V4.1 Flash: 26 tokens por segundo, con concesiones

Según informes, la cuantización de DeepSeek V4.1 Flash alcanza 26 tokens por segundo con dos RTX 3090, llevando un modelo grande a un experimento de escritorio. La compilación comunitaria utiliza 2.6127 bits por peso, una medida del almacenamiento numérico asignado a los parámetros del modelo. Su velocidad reportada conlleva requisitos de memoria sustanciales, una carga lenta y dudas sin resolver sobre el rendimiento en programación.

La principal tensión está entre la compresión y el trabajo útil. Que un modelo quepa en el hardware disponible importa, pero los desarrolladores necesitan en última instancia cambios correctos entregados dentro de un tiempo de espera aceptable. Un flujo ágil de texto generado no demuestra que un agente complete tareas de programación de forma eficiente.

Esa distinción también ofrece al experimento un punto de referencia práctico: Qwen. El autor ya utiliza a diario una configuración local basada en Qwen y describe DeepSeek como un experimento. Este es un informe sobre una opción de despliegue adicional, no evidencia de que se haya sustituido un flujo de trabajo de programación consolidado.

La cuantización DeepSeek V4.1 Flash obtiene una compilación comunitaria descargable

El avance concreto es un lanzamiento comunitario del modelo acompañado de un resultado detallado de escritorio, autoinformado.

El usuario de Reddit whiteh4cker afirma haber creado DeepSeek-V4.1-Flash-1017-dsx-2.6bit usando el motor dsx de lxe para tareas de programación y agentes. Las tareas de agentes permiten a un modelo dirigir acciones, como llamar herramientas o editar archivos. El informe de inferencia local ahora indica que los pesos se han subido.

Esta actualización importa porque el resumen original describía una subida aún en curso. Un artefacto disponible ofrece a otros usuarios algo que inspeccionar y reproducir. No demuestra que las cifras de rendimiento publicadas se generalicen más allá de la máquina del autor.

Los pesos cuantizados del modelo vinculados también distinguen este lanzamiento del modelo subyacente. DeepSeek proporciona el modelo original; el colaborador comunitario proporciona un derivado comprimido. El desarrollador de dsx proporciona el motor utilizado para ejecutarlo.

Estos roles conllevan diferentes tipos de evidencia. Las afirmaciones de capacidad de un desarrollador de modelos describen su lanzamiento y condiciones de evaluación. Las mediciones de un autor de compresión describen una conversión concreta. El benchmark de un motor describe una configuración de software y hardware.

Combinar esas afirmaciones en una única declaración sobre el “rendimiento de DeepSeek” ocultaría las diferencias importantes. El resultado de escritorio se refiere a un modelo comprimido específico que se ejecuta mediante una implementación especializada. No hereda automáticamente todas las capacidades o puntuaciones de benchmark asociadas al lanzamiento original.

El momento hace que la calidad de programación sea especialmente relevante. DeepSeek anunció la actualización 1017 el 17 de octubre de 2026. Su actualización del modelo de programación hace hincapié en el desarrollo de proyectos, una finalización más rápida de tareas y resultados más breves, según la empresa.

Estas afirmaciones establecen por qué los desarrolladores investigarían esta instantánea para programación local. No validan el derivado comprimido. Una conversión comunitaria debe obtener su propia evidencia, especialmente cuando pequeños cambios numéricos afectan al razonamiento prolongado o a las decisiones sobre herramientas.

La distinción resulta práctica para cualquiera que decida si descargar la compilación. La disponibilidad responde a si puede comenzar la experimentación. Un benchmark reproducible responde a si otra máquina se comporta de forma similar. Una evaluación de programación responde a si el experimento merece un lugar en el trabajo diario.

El informe avanza la primera pregunta y aporta pistas para la segunda. Deja la tercera en gran medida abierta. Sigue siendo un progreso útil, siempre que el resultado permanezca vinculado a su configuración y sus límites.

El escritorio tiene más en juego que sus tarjetas gráficas

Las tarjetas gráficas atraen la atención, pero la máquina completa determina si este despliegue es práctico.

El autor informa de 192 GB de memoria del sistema junto con las dos RTX 3090. Los pesos comprimidos ocupan 187.6 GB, mientras que las tablas Engram ocupan 203 GB en una unidad de estado sólido SATA. Engram es un componente de memoria de consulta aprendida que complementa el cálculo del modelo.

El tiempo de carga informado es de 90–110 minutos desde un disco duro mecánico. En un comentario, el autor aclara que este disco carga los pesos en memoria antes de la inferencia. La inferencia consiste en ejecutar el modelo para procesar entradas y generar resultados.

Esta aclaración evita una interpretación errónea fácil. El informe no dice que el disco mecánico suministre continuamente todo el cálculo del modelo durante la generación. El comportamiento de inicio y la generación en estado estable son mediciones distintas, con implicaciones diferentes para un desarrollador en activo.

Para quien deja un servidor de modelos en funcionamiento, el inicio puede convertirse en una interrupción ocasional. Para quien reinicia con frecuencia, cambia de modelos o comparte la estación de trabajo, puede dominar la experiencia. Por tanto, la misma velocidad de generación reportada sustenta juicios muy diferentes sobre la comodidad.

La presión recae en los desarrolladores que evalúan el despliegue local con hardware que ya poseen. Deben considerar conjuntamente la capacidad de memoria, la ubicación del almacenamiento, el comportamiento de inicio y la capacidad de respuesta sostenida. El nombre conocido de una tarjeta gráfica no convierte al sistema circundante en algo convencional.

La máquina reportada también cuestiona un atajo de compra habitual: seleccionar un modelo local principalmente por la memoria gráfica. La memoria del sistema y el almacenamiento forman parte del presupuesto de despliegue. Su disponibilidad determina qué configuraciones de modelos son siquiera viables.

Esto no demuestra que todos necesiten la configuración exacta del autor. Demuestra que el resultado no puede resumirse de forma responsable nombrando únicamente las tarjetas gráficas. Un informe reproducible necesita el resto de la máquina y sus ajustes de software.

Los hábitos operativos también importan. Una estación de trabajo dedicada puede mantener un modelo disponible entre tareas. Un escritorio compartido debe acomodar aplicaciones y cargas de trabajo que compiten entre sí. Ninguna de estas situaciones aparece en un titular de tasa de tokens, pero ambas afectan a si la configuración llega a ser útil.

Para un flujo de trabajo de programación, las interrupciones también van más allá del inicio. Un desarrollador puede necesitar cambiar la configuración de contexto, recuperar un proceso fallido o moverse entre proyectos. La pregunta relevante es cómo se comporta el sistema a lo largo de una sesión de trabajo.

Por eso este experimento genera una presión inmediata sobre la presentación de benchmarks, en lugar de demostrar una presión amplia sobre los proveedores alojados. Las afirmaciones de despliegue local deben describir la máquina completa. De lo contrario, los lectores no pueden saber si un resultado coincide con sus recursos.

La implicación útil es más limitada que una afirmación sobre sustituir servicios remotos. Esta configuración ofrece un candidato concreto para la experimentación local. Sus requisitos operativos siguen siendo parte del resultado, no detalles de fondo que deban eliminarse del titular.

Engram desplaza la pregunta del tamaño del modelo a la ubicación de los datos

La oportunidad técnica procede de tratar el cálculo y la información almacenada como recursos diferentes.

La investigación sobre memoria condicional de DeepSeek describe Engram como un mecanismo de consulta basado en secuencias cortas de tokens. Los tokens son las unidades de texto procesadas por un modelo de lenguaje. La investigación presenta la memoria condicional como complementaria al cálculo condicional.

El cálculo condicional activa partes seleccionadas de un modelo para una entrada determinada. En una arquitectura de mezcla de expertos, esas partes incluyen grupos de parámetros especializados llamados expertos. La idea más amplia es que la capacidad almacenada y el trabajo realizado para cada token no tienen por qué crecer conjuntamente.

Para este experimento de escritorio, la consecuencia importante es una cuestión de ubicación. ¿Qué información debe permanecer cerca de los procesadores gráficos? ¿Qué información puede residir en otro lugar? ¿Cuánta espera introduce mover o recuperar esa información?

Estas preguntas explican por qué el tamaño de archivo por sí solo no puede predecir la capacidad de respuesta. Un componente almacenado grande puede comportarse de forma distinta a un componente de tamaño similar que requiere aritmética repetida. Su patrón de acceso importa junto con su capacidad.

Aquí es también donde interactúan la compresión y la arquitectura. La cuantización reduce la precisión numérica utilizada para almacenar los valores del modelo. Engram se refiere a una parte distinta del diseño: proporcionar información aprendida mediante consultas. Ambas afectan al despliegue, pero no deben tratarse como técnicas intercambiables.

Una cifra menor de bits por peso describe un aspecto de un artefacto comprimido. No resume el uso completo de memoria del sistema. Tampoco revela cómo se representa o se accede a cada componente del modelo durante la ejecución.

El motor de inferencia dsx está diseñado específicamente para este modelo DeepSeek y utiliza Rust con CUDA, la plataforma de computación gráfica de NVIDIA. Su documentación describe la ubicación entre memoria gráfica, memoria del sistema y almacenamiento. Se trata de ingeniería especializada en torno a una arquitectura concreta.

Esa especialización crea una oportunidad y una obligación de mantenimiento. Un motor puede optimizarse en torno a un comportamiento conocido del modelo. Los usuarios deben comprobar entonces si las actualizaciones del modelo, los archivos modificados o ajustes diferentes siguen siendo compatibles con esa implementación.

La documentación actual también complica la observación de la publicación original sobre las imágenes. La publicación indica que la entrada de imágenes no parecía compatible. El repositorio ahora enumera opciones relacionadas con visión, por lo que la limitación debe seguir vinculada a la compilación probada.

Ninguna de las dos observaciones demuestra un rendimiento fiable con imágenes para la cuantización publicada. Una opción de software es evidencia de una función expuesta. Una evaluación multimodal satisfactoria establecería si la configuración completa maneja correctamente las tareas visuales.

Para los desarrolladores, esto importa cuando un agente debe inspeccionar capturas de pantalla, gráficos o resultados de interfaz. La asistencia de programación solo con texto y las pruebas de aplicaciones visuales imponen requisitos diferentes. Un resultado favorable en texto no puede resolver ambos.

La importancia más amplia es un cambio en las preguntas que invitan a plantear los despliegues locales. En lugar de preguntar solo si un modelo cabe, los lectores deben preguntar cómo están organizados sus componentes. La respuesta conecta capacidad, capacidad de respuesta, compatibilidad de funciones y mantenimiento.

Esto hace que el experimento sea técnicamente interesante sin exigir una afirmación de victoria arquitectónica. Ilustra una ruta concreta de despliegue. Que esa ruta ofrezca mejor trabajo de programación sigue siendo una pregunta independiente y medible.

Mejores puntuaciones de compresión dejan sin resolver la calidad de programación

La evaluación respalda investigar la compilación, mientras deja sin resolver su fiabilidad para programación.

La comparación del autor informa de una divergencia KL de 0.1972 para la nueva compilación. La divergencia KL mide las diferencias entre distribuciones de probabilidad, comparando aquí las salidas del modelo con una referencia. Un resultado menor indica una concordancia más estrecha bajo esa evaluación.

La misma comparación informa de un 82.59% de coincidencia en la opción principal y una perplejidad de 9.3626. La coincidencia en la opción principal registra las predicciones de tokens con mayor rango que coinciden. La perplejidad mide la incertidumbre predictiva sobre el texto de evaluación, y los valores más bajos generalmente indican una mejor predicción dentro de la misma prueba.

Estas mediciones abordan si la compresión modifica el comportamiento del modelo. No miden directamente si un agente de programación corrige un defecto. Tampoco establecen que cada discrepancia con la referencia produzca un fallo significativo.

Esa distinción funciona en ambos sentidos. Un token modificado puede dejar una respuesta igual de útil. Un cambio pequeño en una decisión crítica puede dirigir a un agente hacia una edición incorrecta o una llamada a herramienta innecesaria.

Por tanto, la programación plantea una prueba exigente para la compresión. El modelo debe mantener restricciones a lo largo de una secuencia de decisiones. Una evaluación útil debe examinar el trabajo resultante, en lugar de asumir que la concordancia a nivel de token se traslada directamente al éxito a nivel de proyecto.

El hilo contiene una advertencia relevante del desarrollador de dsx, lxe:

> “Cuando hice mi modelo original, la parte sorprendente de esta cuantización dinámica de unos 2 bits es que, únicamente debido a la cuantización, este modelo se vuelve más inseguro de sí mismo, casi duplicando el CoT frente al modelo completo en tareas difíciles. He descartado problemas de API y plantillas de prompts. ¿Con tus bpw, estás experimentando algo de esto?”

CoT significa cadena de pensamiento, el texto de razonamiento intermedio que genera un modelo. Esta es la observación del desarrollador sobre una compilación comprimida anterior. Es una hipótesis útil para probar la nueva versión, no un defecto confirmado en ella.

La respuesta del autor de la versión establece un límite para la evidencia disponible:

> “He estado usando DeepSeek mediante API en el trabajo para desarrollar software durante unos meses. Le encargué a este modelo de 2.6 bpw que escribiera una historia de 10 párrafos sobre la antigua China con razonamiento máximo mediante la interfaz web. Se comportó de forma similar a la versión de API. No piensa demasiado. Sin embargo, no lo probé con prompts más difíciles.”

Esa respuesta describe una comprobación conductual inicial. No responde a la cuestión de programación más difícil planteada por el desarrollador del motor. La escritura creativa y la reparación de software imponen exigencias distintas sobre planificación, precisión y uso de herramientas.

La siguiente evaluación útil compararía tareas de programación completadas en condiciones equivalentes. Debería registrar corrección, longitud del razonamiento, reintentos y tiempo transcurrido. Un modelo que genera más texto debe justificarlo con mejores resultados.

También hay una cuestión de información en torno a la propia referencia. Los lectores necesitan saber qué archivos de modelo, prompts y ajustes de evaluación produjeron la comparación. De lo contrario, una cifra favorable sigue siendo difícil de interpretar fuera de la configuración del autor.

La cuantización de DeepSeek V4.1 Flash tiene un argumento de calidad plausible, pero ese argumento se apoya actualmente en mediciones indirectas y comentarios conductuales limitados. La evidencia respalda una prueba controlada. No respalda declarar paridad con el modelo original en trabajo de programación exigente.

Qwen Hace Concreto el Equilibrio del Tiempo de Espera

La comparación práctica es el flujo de trabajo existente del autor, evaluado mediante el tiempo total de la tarea.

El autor afirma que utiliza a diario una configuración local basada en Qwen. La configuración de Qwen con dos GPU enlazada documenta el despliegue de Qwen3.8-Flash-Next en la misma clase de tarjetas gráficas. Eso convierte a Qwen en una alternativa relevante, aunque las configuraciones publicadas difieran.

Un nombre compartido de tarjeta gráfica no crea una comparación controlada. El modelo, la disposición de memoria, el software de servicio y la carga de trabajo de prueba pueden ser distintos. Por tanto, las tasas principales publicadas deben mantenerse vinculadas a sus propias condiciones.

La publicación de DeepSeek informa de un procesamiento de prompts de 170 tokens por segundo. El procesamiento de prompts, también llamado prefill, es el trabajo realizado sobre la entrada antes de la generación. La velocidad de generación mide la producción posterior de tokens de salida.

Estas etapas generan distintos tipos de espera. Un procesamiento de entrada lento retrasa la primera respuesta. Una generación lenta alarga la respuesta después de que empieza. Un desarrollador experimenta ambas, incluso cuando el titular de un benchmark enfatiza solo la segunda.

El ajuste de contexto informado es de 262.144 tokens. Una ventana de contexto es el presupuesto máximo de tokens disponible para entrada y salida. Seleccionar esa capacidad no establece que se haya procesado una ventana completa durante la medición de tiempo.

Esta es una distinción importante para el trabajo con repositorios. Un desarrollador podría proporcionar un mensaje de error breve o una gran colección de archivos fuente. El mismo servidor puede sentirse muy diferente según esas solicitudes.

Un agente añade otra capa porque su tarea puede implicar intercambios repetidos. Lee resultados de herramientas, revisa un plan y solicita información adicional. La demora total depende de esa secuencia, no de una única salida ininterrumpida.

El almacenamiento en caché, que reutiliza resultados calculados previamente, puede modificar la carga de procesamiento de entrada. Su beneficio depende de qué sigue siendo reutilizable entre solicitudes. Una comparación realista debería explicitar ese comportamiento en lugar de asumir que cada turno empieza desde cero.

El desacuerdo del hilo sobre la velocidad de los prompts refleja estas cargas de trabajo contrapuestas. Alguien que prueba solicitudes interactivas ocasionales puede valorar una configuración de forma diferente a alguien que ejecuta trabajos sin supervisión. El desacuerdo no puede resolverse únicamente con la cifra de generación.

Por tanto, la comparación con Qwen debería preguntar qué ocurre con una tarea real. ¿DeepSeek produce un parche correcto con menos reintentos? ¿Alguna espera adicional se traduce en mejores decisiones? ¿La configuración existente sigue siendo preferible para el trabajo rutinario?

Estas preguntas preservan la disyuntiva principal: capacidad comprimida frente a finalización fiable. Evitan convertir el artículo en una competencia sin respaldo entre familias de modelos. El ganador relevante puede cambiar según la carga de trabajo.

Por ejemplo, un desarrollador que investiga un repositorio desconocido necesita una interpretación útil del código proporcionado. Un desarrollador que realiza una edición acotada necesita una ejecución precisa con poca demora. Una comparación de modelos debería preservar esas diferencias en lugar de promediarlas.

El sistema de uso diario existente aporta a este experimento una valiosa referencia. El autor tiene un flujo de trabajo que merece conservarse, no un espacio vacío que llenar. DeepSeek debe ofrecer suficiente beneficio práctico para justificar el cambio.

Tres Resultados Determinarán si la Compilación se Convierte en una Herramienta de Uso Diario

La reproducción, los resultados de programación y la estabilidad operativa determinarán cuánto peso merece este resultado.

La primera señal es la reproducción independiente del artefacto publicado. Otro usuario debería identificar los archivos exactos, la revisión del motor, el hardware y los ajustes. Las mediciones resultantes deberían separar el inicio, el procesamiento de entrada y la generación.

Un resultado similar reforzaría la confianza en que el comportamiento informado se mantiene fuera de la máquina original. Un resultado diferente seguiría siendo informativo si puede aislarse su causa. La variación sin explicación limitaría la utilidad del titular.

La reproducción también debería aclarar la afirmación sobre el contexto. Los lectores necesitan las longitudes reales de entrada y salida junto con el máximo configurado. Esa información distingue una gran ventana disponible del rendimiento demostrado con una gran carga de trabajo activa.

La segunda señal es trabajo de programación completado bajo una comparación estable. Las mismas tareas deberían ejecutarse contra la compilación comprimida y una referencia apropiada. Los evaluadores deberían conservar los prompts, el acceso a herramientas y los criterios de finalización.

La corrección debe seguir siendo visible junto a la velocidad. Una respuesta rápida que no supera sus comprobaciones de aceptación no es una tarea completada. Una respuesta más lenta puede valer la pena si evita correcciones repetidas y reparación manual.

Esta evaluación también debería abordar la preocupación sobre el razonamiento planteada en el hilo. Una salida más larga no es inherentemente mejor ni peor. Su importancia depende de si el cálculo adicional produce un resultado más fiable.

Un resultado favorable reforzaría el argumento para aceptar las exigencias de recursos de esta compilación. Resultados débiles limitarían su papel, quizá a experimentación o cargas de trabajo seleccionadas. Cualquiera de los dos resultados mejoraría la evidencia actual.

La tercera señal es un funcionamiento repetible a lo largo de las sesiones de trabajo. El inicio, la recuperación, la presión de memoria y la compatibilidad de funciones requieren observación más allá de una demostración exitosa. La compatibilidad con imágenes merece una verificación explícita allí donde un flujo de trabajo propuesto dependa de ella.

La estabilidad reforzaría el argumento para mantener el modelo disponible durante toda la jornada. La intervención frecuente reduciría su atractivo para agentes sin supervisión. Ese juicio debe figurar junto al rendimiento de los benchmarks porque el mantenimiento también consume atención del desarrollador.

En los próximos meses, estas señales ofrecen una ruta más clara que perseguir cada captura de pantalla de una tasa de tokens mejorada. Conectan el artefacto descargable con la ejecución reproducible, luego con trabajo útil y después con uso sostenido. Cada paso responde a una pregunta de adopción diferente.

El resultado actual es alentador dentro de esa secuencia. Proporciona un modelo comprimido concreto y un relato de despliegue inusualmente específico. Su contribución más sólida es hacer posible una evaluación posterior.

Por ahora, considere la cuantización de DeepSeek V4.1 Flash como candidata para una prueba controlada frente a su flujo de trabajo actual de programación. Conserve la configuración y elija tareas con comprobaciones de aceptación claras. Registre el tiempo dedicado a esperar, revisar y reparar la salida, junto con el tiempo de ejecución del propio modelo. Mantenga los fallos en la comparación, especialmente los reintentos innecesarios y los cambios incorrectos que al principio parecen convincentes. Si la compilación admite las funciones que necesita y produce resultados fiables, sus requisitos de memoria y carga pasan a ser una disyuntiva informada. Si no lo hace, aun así obtendrá un límite útil para futuros experimentos. Antes de cambiar su herramienta de uso diario, plantee la pregunta que este benchmark deja abierta: ¿el modelo local termina correctamente su trabajo real, con una cantidad aceptable de supervisión?