DeepSeek V4.1-Flash-1017: pesos abiertos, postentrenamiento RLSF y nueva API de búsqueda
Según THE DECODER, el 17 de octubre de 2026 DeepSeek publicó V4.1-Flash-1017, que según la empresa supera a rivales mayores en tareas de programación y agentes con menor coste por tarea, con pesos disponibles en Hugging Face y ModelScope y, por primera vez, una API propia de búsqueda y extracción abierta a desarrolladores.
Qué ha cambiado
Según THE DECODER, el 17 de octubre de 2026 DeepSeek publicó una versión actualizada de su modelo Flash, DeepSeek-V4.1-Flash-1017. El medio informa de que esta versión puede usarse a través de la web, la aplicación y la API de la compañía, y de que los pesos están publicados en Hugging Face y ModelScope. En comparación con su predecesor directo V4.1-Flash, el reportaje afirma que mejora en puntuaciones de referencia, velocidad de finalización de tareas y longitud de salida, y la empresa lo describe como una mejora de Pareto en la relación rendimiento-coste. En cuanto al método de entrenamiento, el reportaje indica que esta versión emplea aprendizaje por refuerzo con autofeedback (RLSF), que permite al modelo usar su propia confianza interna o críticas autogeneradas como señal de recompensa, sin depender de evaluadores humanos ni de modelos de recompensa externos. El reportaje señala que el modelo está ajustado para entornos de desarrollo como DeepSeek Harness (se recomienda v0.2.1-rc.1 o superior), Tencent CodeBuddy y WorkBuddy. En las autoevaluaciones de DeepSeek, el reportaje afirma que esta versión supera en varias categorías de programación y agentes a modelos mayores como Claude Opus 5, GPT 5.6-Sol, Kimi K3 y GLM 5.3. El gráfico de costes de DeepSWE citado en el reportaje muestra que esta versión obtiene una puntuación del 77,0 % con un coste medio por tarea ligeramente inferior a 0,20 dólares; en configuración reducida, con unos 0,10 dólares, sigue superando el 72 %; su predecesor obtuvo un 74,2 % pero con unos 0,50 dólares por ejecución. Además, el reportaje indica que DeepSeek abre por primera vez su motor de búsqueda interno a desarrolladores en forma de API Search y Fetch, con un precio de 0,75 dólares por cada 1000 llamadas por endpoint, y que los usuarios de la API de DeepSeek pueden usarla gratis hasta el 31 de octubre de 2026 a las 16:00 UTC mediante herramientas del lado del servidor en DeepSeek Harness, Claude Code y Codex. El reportaje menciona asimismo que el gobierno chino supuestamente planea endurecer las normas de publicación de modelos de pesos abiertos, e incluso podría bloquear por completo su publicación, siendo uno de los criterios si el sistema figura entre los diez más capaces.
Impacto para desarrolladores
Lo siguiente es análisis e inferencia basados en el contenido del reportaje, no hechos verificados de forma independiente. Primero, pesos abiertos y licencia de código abierto son dos cosas distintas: el reportaje solo indica que los pesos están publicados en Hugging Face y ModelScope, sin dar términos de licencia concretos, por lo que los límites de derechos de uso comercial, redistribución y entrenamiento derivado deben determinarse según el archivo de licencia real en esas plataformas, y no pueden inferirse de la simple visibilidad de los pesos. Segundo, el reportaje afirma que la salida es más corta y que baja el coste por tarea, un cambio con impacto más directo en cargas de agentes como llamadas a herramientas de varios turnos y modificaciones de código a nivel de repositorio, porque el coste de esas cargas depende tanto del número de tokens generados como del número de rondas de ida y vuelta; si las cifras del reportaje se sostienen, los modelos de presupuesto de agentes de programación cobrados por tarea, correcciones masivas y reproducción de evaluaciones deben recalcularse. Tercero, la apertura de las API Search y Fetch cambia la forma de integrar agentes conectados y generación aumentada por recuperación: antes los desarrolladores solían construir su propia capa de recuperación o conectar búsqueda de terceros; ahora pueden incrustar la recuperación en la cadena de herramientas del lado del servidor del proveedor, a costa de trasladar a este el control sobre la calidad de recuperación, el alcance de rastreo y las cuotas. Cuarto, el supuesto plan de endurecimiento regulatorio de la publicación de pesos abiertos mencionado en el reportaje, si se materializa, afectaría las decisiones de despliegue y redistribución que dependen de modelos chinos de pesos abiertos, pero el reportaje lo formula como un plan supuesto, sin documento oficial, por lo que no debería fijarse una estrategia de largo plazo basándose en ello. Cabe subrayar que las cifras comparativas y de coste del reportaje provienen de autoevaluaciones de DeepSeek, y el propio reportaje señala que aún no hay referencias independientes; la impresión subjetiva de los desarrolladores sobre la calidad del código puede diferir mucho de los resultados de referencia.
Integración y evaluación
Lo siguiente son recomendaciones y análisis condicionales, no hechos del reportaje. Recomendación uno: hacer una evaluación A/B de la misma tarea centrada en la longitud de salida. El reportaje afirma que esta versión produce salidas más cortas y reduce el coste por tarea; la decisión real es si migrar la canalización de agentes actual a esta versión. Si tu carga consiste en llamadas a herramientas de varios turnos y modificaciones a nivel de repositorio, el beneficio puede ser notable: conviene fijar el mismo conjunto de tareas y ejecutar esta versión y su predecesor directo por separado, registrando tokens de salida por tarea, rondas de llamadas a herramientas y tasa final de fusión exitosa. Si la carga es pregunta-respuesta corta de un solo turno, el beneficio de salidas más cortas es limitado y la prioridad de migración debería bajar. Criterio medible: reducción de tokens de salida por tarea y cambio en la tasa de éxito en el mismo conjunto de tareas. Recomendación dos: tratar la API de búsqueda como una decisión de arquitectura, no como un interruptor de función. El reportaje indica 0,75 dólares por cada 1000 llamadas por endpoint y uso gratuito temporal en herramientas concretas; la decisión real es seguir construyendo la recuperación propia o migrarla al lado del proveedor. La condición previa es aceptar la salida de datos y la dependencia de cuotas; conviene hacer primero tráfico en sombra en una ruta de recuperación no crítica, comparando relevancia de recuperación, latencia y tasa de fallos, y luego decidir si se cambia la ruta principal. Criterio medible: diferencia de relevancia de recuperación frente a la solución actual y aumento de latencia de extremo a extremo en el mismo conjunto de consultas. Recomendación tres: verificar primero la licencia y luego decidir entre llamar a la API o autohospedar los pesos; el reportaje no revela términos de licencia ni alcance de uso comercial, y hasta verificarlo la autohospedación debería limitarse a evaluación interna. Recomendación cuatro: al evaluar, fijar el identificador de versión del modelo (el sufijo de fecha 1017) y la versión del entorno de ejecución, para evitar conclusiones erróneas por comparar versiones distintas. Sobre el coste de uso continuado y las condiciones de pago, guíate por la página de precios del proveedor, no por cifras históricas o ventanas gratuitas del reportaje.
Límites y cuestiones pendientes
Hay que tener en cuenta: la disponibilidad de API descrita en el reportaje se refiere a la plataforma propia de DeepSeek. En el catálogo en vivo de KimiSeek ya existe una coincidencia exacta con DeepSeek V4.1 Flash 1017 (id: deepseek-v4.1-flash-1017), que coincide con el nombre de versión del reportaje; sin embargo, el estado de inclusión en el catálogo puede cambiar y la disponibilidad real debe consultarse en el catálogo en vivo; además, otra entrada del catálogo, DeepSeek V4.1 Flash sin sufijo de fecha, no debe mezclarse con la versión del reportaje. En segundo lugar, todas las comparaciones de referencia en programación y agentes, las puntuaciones de DeepSWE y las cifras de coste por tarea del reportaje provienen de autoevaluaciones de DeepSeek, sin reproducción independiente, y el propio reportaje señala que aún no hay referencias independientes. En tercer lugar, el reportaje no revela el tipo de licencia de la publicación de pesos, el número de parámetros ni los requisitos de hardware de inferencia, factores que afectan directamente a la viabilidad y la estimación de costes de la autohospedación. En cuarto lugar, la ventana gratuita de las API de búsqueda y extracción tiene una fecha límite clara, y los 0,75 dólares por cada 1000 llamadas del reportaje corresponden a la fecha del reportaje; su continuidad debe consultarse en la documentación oficial. En quinto lugar, el reportaje menciona que China podría endurecer las normas de publicación de pesos abiertos, pero por ahora es solo información periodística, sin documento oficial, y no debería fijarse una estrategia de despliegue a largo plazo basándose en ello.
Ilustraciones de la noticia original
