LLM on KnightLi Blog

Qué modelos locales de IA puede ejecutar un portátil RTX 4060 8GB

Fri, 08 May 2026 13:41:15 +0800

Un portátil con RTX 4060 8GB puede ejecutar IA local, pero el límite es claro: lo importante no es si el modelo arranca, sino si cabe en VRAM. La versión móvil también depende de potencia, refrigeración, ancho de banda de memoria y ajustes del fabricante.

En 2026, 8GB de VRAM siguen siendo la línea de entrada para IA local. Con modelos cuantizados y herramientas adecuadas, puedes ejecutar LLM de 3B-8B, SDXL, SD 1.5, algunos flujos FLUX cuantizados, Whisper y extracción de características de imagen. Si fuerzas LLM de 14B+, modelos grandes sin cuantizar o flujos de imagen pesados, el rendimiento cae cuando se usa memoria del sistema.

Resumen: no persigas el modelo más grande. Usa modelos pequeños, pesos cuantizados y flujos de baja VRAM.

Presupuesto de VRAM

Windows 11, navegadores, drivers y procesos de fondo ya consumen memoria de GPU. El presupuesto real suele estar más cerca de 6.5GB-7.2GB que de los 8GB completos.

LLM: 3B-8B con cuantización 4-bit.
Imagen: SDXL, SD 1.5 y FLUX GGUF/NF4 low-VRAM.
Multimodal: modelos ligeros de unos 4B.
Voz: Whisper large-v3 funciona, pero los lotes largos calientan.
Indexación: CLIP, ViT y SigLIP encajan muy bien.

Un modelo pequeño completo en GPU suele ir mejor que uno grande con mucho offload.

LLM: modelos cuantizados de 3B-8B

Para chat y razonamiento local, usa Ollama, LM Studio, koboldcpp, llama.cpp u otro frontend compatible con GGUF. El punto cómodo en 8GB es 3B-8B en 4-bit.

Ligero general: Gemma 4 E4B

Gemma 4 E4B es uno de los modelos pequeños de la familia Gemma 4 de Google lanzada en 2026. Es adecuado para uso local y edge: preguntas, resúmenes, organización ligera, tareas multimodales simples e inferencia barata.

En una RTX 4060 de portátil, empieza por una versión cuantizada oficial o comunitaria. No comiences con los pesos de mayor precisión.

Razonamiento: DeepSeek R1 Distill 7B/8B, Qwen 3 8B

Para lógica, matemáticas, análisis complejo y texto largo, prueba DeepSeek R1 distill 7B/8B o Qwen 3 8B cuantizado.

Con Q4_K_M, los modelos de 8B suelen entrar en el presupuesto de una GPU de 8GB. La velocidad depende del contexto, backend, driver y modo de energía.

No empieces con 14B, 32B o más. Aunque arranquen con CPU offload, la experiencia suele ser peor que con un modelo menor completamente en GPU.

Código: Qwen 2.5 Coder 3B/7B

Qwen 2.5 Coder 3B es rápido y útil para autocompletado, explicación y generación pequeña. El 7B entiende mejor, pero consume más VRAM y tarda más.

Autocompletado: 3B.
Q&A y explicación: 3B o 7B.
Refactors pequeños: 7B cuantizado.
Arquitectura grande: no esperes meter todo el proyecto en 8GB.

Imagen: SDXL estable, FLUX cuantizado

SD 1.5 es muy amigable con 8GB, rápido y maduro. SDXL consume más pero sigue siendo viable.

Herramientas:

ComfyUI
Stable Diffusion WebUI Forge
Fooocus

FLUX ofrece mejor calidad y comprensión de prompt, pero los modelos originales son pesados. En 8GB usa GGUF, NF4, FP8 u otras rutas low-VRAM con ComfyUI-GGUF.

Consejos:

Usa FLUX.1 schnell GGUF Q4/Q5.
Reduce resolución o batch size.
Usa --lowvram en ComfyUI.
No combines demasiados LoRA, ControlNet y hi-res fix.
Vigila si la VRAM se libera al cambiar de workflow.

Puedes probar 1024px, pero no copies flujos pensados para GPUs de 16GB/24GB.

Multimodal y utilidades

Whisper large-v3 sirve para transcripción de audio. Para lotes largos, activa modo rendimiento y cuida la temperatura.

Para un sistema de búsqueda de fotos, la RTX 4060 8GB es muy adecuada. CLIP, ViT y SigLIP no consumen VRAM extrema y procesan miles de imágenes con rapidez.

Flujo típico:

Extraer embeddings con CLIP/ViT/SigLIP.
Guardarlos en SQLite o una base vectorial.
Buscar por texto o imagen similar.
Usar un LLM pequeño para etiquetas, descripciones o resúmenes.

Combos recomendados

Ollama / LM Studio
+ Gemma 4 E4B cuantizado
+ DeepSeek R1 Distill 7B/8B Q4
+ Qwen 3 8B Q4

1
2
3

Qwen 2.5 Coder 3B
+ Qwen 2.5 Coder 7B Q4
+ Continue / Cline / servidor local OpenAI-compatible

ComfyUI / Forge
+ SDXL
+ SD 1.5
+ FLUX.1 schnell GGUF Q4/Q5

1
2
3

CLIP / SigLIP / ViT
+ SQLite / FAISS / LanceDB
+ Gemma 4 E4B o Phi-4 Mini para organizar texto

Errores comunes

Escenario	Consejo
Modelos grandes	Evita 14B+ salvo que aceptes lentitud
Cuantización	Empieza con `Q4_K_M`; prueba Q5 si necesitas calidad
VRAM	Monitoriza con Task Manager o `nvidia-smi`
Temperatura	Usa modo rendimiento para imagen y lotes
Resolución	Empieza con 768px o una imagen 1024px
Navegador	Cierra pestañas pesadas en GPU
Driver	Mantén NVIDIA actualizado
Workflows	No copies flujos ComfyUI de 16GB/24GB directamente

Mi recomendación

Un portátil RTX 4060 8GB es una plataforma local de entrada con buena relación coste/rendimiento. Encaja con LLM 3B-8B, modelos pequeños de código, SDXL, SD 1.5, FLUX cuantizado, Whisper, búsqueda vectorial de imágenes y gestión local de fotos.

No encaja bien con uso prolongado de 14B/32B, modelos grandes sin cuantizar, FLUX por lotes de alta resolución, generación de video grande o muchos modelos residentes a la vez.

Para búsqueda de fotos, usa la GPU para extracción CLIP/SigLIP y etiquetado con modelos pequeños, y guarda vectores en SQLite, FAISS o LanceDB.

Referencias

Modelos LLM locales recomendados para una GPU RTX 3060

Fri, 08 May 2026 09:25:24 +0800

La versión más común de la RTX 3060 tiene 12GB de VRAM. No es una GPU de IA de gama alta, pero funciona muy bien para LLM locales, especialmente modelos de 7B, 8B, 9B y 12B.

Si solo quieres una regla rápida:

En una RTX 3060 12GB, prioriza modelos de alrededor de 8B en cuantización Q4_K_M o Q5_K_M. Elige Q4 para más estabilidad y prueba Q5 si quieres mejor calidad.

No empieces persiguiendo modelos de 32B o 70B. Aunque puedan ejecutarse con cuantización muy baja y CPU offload, la velocidad y la experiencia normalmente no son adecuadas para uso diario.

Primero mira el límite de VRAM

Al ejecutar LLM locales en una RTX 3060 12GB, el límite real es la VRAM.

Tamaño del modelo	Cuantización recomendada	Experiencia en RTX 3060 12GB
3B / 4B	Q4, Q5, Q8	Muy fácil, rápido
7B / 8B / 9B	Q4_K_M, Q5_K_M	Lo más recomendado; buen equilibrio
12B / 14B	Q4_K_M	Se puede probar, cuidado con contexto grande
30B+	Q2 / Q3 o offload parcial	Se puede experimentar, no diario
70B+	Cuantización extrema o mucha CPU/RAM	Más bien experimental

Un LLM local no solo consume VRAM por el archivo del modelo. También consumen contexto, KV cache, batch size, framework de inferencia y drivers.

Por eso 12GB de VRAM no significa cargar sin más un archivo de modelo de 12GB. Es mejor dejar margen para el sistema y el contexto.

Recomendación 1: Qwen3 8B

Si usas principalmente chino, Qwen3 8B es uno de los primeros modelos que vale la pena probar en una RTX 3060.

Sirve para:

Preguntas y respuestas en chino.
Resumen y reescritura.
Asistente diario de conocimiento.
Explicación simple de código.
RAG local.
Flujos Agent ligeros.

Elección recomendada:

1
2
3

Qwen3 8B GGUF
Q4_K_M: primera opción
Q5_K_M: mejor calidad, más presión de VRAM

La familia Qwen suele funcionar bien con chino. Para escritura diaria, organización de información y comprensión de instrucciones en chino, Qwen3 8B es un buen punto de partida.

Recomendación 2: Llama 3.1 8B Instruct

Llama 3.1 8B Instruct es un modelo general estable, con buena capacidad en inglés y ecosistema maduro.

Sirve para:

Preguntas en inglés.
Ayuda ligera con código.
Chat general.
Resumen de documentos.
Pruebas de prompts.
Comparar herramientas de inferencia.

Elección recomendada:

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M: mejor velocidad y estabilidad de VRAM
Q5_K_M: mejor calidad de respuesta

Si procesas sobre todo material en inglés, o quieres un modelo con muchos tutoriales y buena compatibilidad, Llama 3.1 8B sigue siendo una buena base.

Recomendación 3: Gemma 3 12B

Gemma 3 12B está más cerca del límite práctico de una RTX 3060 12GB.

Consume más VRAM que los modelos 8B, pero con cuantización Q4 todavía puede funcionar en una tarjeta de 12GB. Es una opción para quien quiera probar un modelo algo mayor en una sola GPU.

Sirve para:

Preguntas generales de mayor calidad.
Procesamiento de contenido en inglés.
Resúmenes y análisis algo más complejos.
Probar una mejora sobre modelos 8B.

Elección recomendada:

1
2
3

Gemma 3 12B GGUF
Q4_K_M u oficial QAT Q4
No abras demasiado el contexto

Si falta VRAM, reduce primero la longitud de contexto o vuelve a un modelo 8B. Para una 3060, 12B es “probable”, no una recomendación automática.

Recomendación 4: DeepSeek R1 Distill Qwen 8B

Si quieres probar modelos locales con estilo de razonamiento, puedes usar modelos como DeepSeek R1 Distill Qwen 8B.

Sirve para:

Problemas simples de razonamiento.
Análisis por pasos.
Aprender el estilo de salida de modelos de razonamiento.
Experimentos locales de bajo costo.

Elección recomendada:

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

Estos modelos a veces generan procesos de razonamiento más largos, así que la velocidad y el uso de contexto pueden sentirse más pesados que en modelos instruct normales. Para chat diario no siempre son más cómodos que Qwen3 8B, pero sirven bien para experimentar.

Recomendación 5: Phi / MiniCPM / modelos pequeños

Si tu 3060 es de 8GB, o tu RAM también es limitada, considera primero modelos de 3B o 4B.

Sirven para:

Preguntas rápidas.
Resúmenes simples.
Integración en pequeñas herramientas locales.
Chat de baja latencia.
Pruebas en equipos antiguos.

No siempre igualan la calidad de 8B o 12B, pero son ligeros, rápidos y fáciles de desplegar.

Cómo elegir cuantización

El formato local común es GGUF, con cuantizaciones como Q4, Q5, Q6 y Q8.

Cuantización	Características	Mejor para
Q4_K_M	Pequeña, rápida, calidad suficiente	Primera opción en 3060
Q5_K_M	Mejor calidad, más consumo	Probar con modelos 8B
Q6 / Q8	Más cerca de calidad original, más grande	Modelos pequeños o más VRAM
Q2 / Q3	Ahorra VRAM, baja calidad notable	Experimentar con modelos grandes

Para RTX 3060 12GB, lo más práctico es:

1
2
3

Modelos 8B: Q4_K_M o Q5_K_M
Modelos 12B: primero Q4_K_M
Modelos mayores: no recomendados como uso diario

Qué herramienta usar

Los principiantes pueden empezar con Ollama, porque instalar y ejecutar modelos es sencillo.

Comandos comunes:

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

Si quieres controlar mejor archivos GGUF, GPU layers y longitud de contexto, usa llama.cpp o herramientas gráficas basadas en llama.cpp.

Opciones comunes:

Ollama: lo más simple, ideal para empezar.
LM Studio: interfaz gráfica amigable, útil para descargar y cambiar modelos.
llama.cpp: control más fino, bueno para ajustar rendimiento.
text-generation-webui: muchas funciones, útil para probar backends.

Para chat local y preguntas simples, Ollama o LM Studio bastan.

No abras demasiado el contexto

Muchos modelos anuncian soporte de contexto largo, pero en una RTX 3060 no conviene usar siempre el máximo.

Cuanto más largo el contexto, más KV cache se usa y mayor presión de VRAM. Incluso si el modelo carga, un contexto largo puede reducir la velocidad.

Sugerencia:

1
2
3

Chat normal: 4K a 8K
Resumen de documentos: 8K a 16K
RAG de documentos largos: divide primero; no pegues todo de una vez

La 3060 funciona mejor con “contexto medio + buen modelo + buena recuperación” que intentando meter cientos de miles de tokens.

Elegir según uso

Si escribes principalmente en chino:

1
2

Primero: Qwen3 8B Q4_K_M
Alternativa: DeepSeek R1 Distill Qwen 8B

Si escribes principalmente en inglés:

1
2

Primero: Llama 3.1 8B Instruct Q4_K_M
Alternativa: Gemma 3 12B Q4_K_M

Si quieres velocidad:

1
2
3

Modelos 3B / 4B
8B Q4_K_M
Contexto entre 4K y 8K

Si quieres más calidad:

1
2
3

8B Q5_K_M
12B Q4_K_M
Acepta menor velocidad

Si quieres ayuda con código:

1
2

Modelos de código 8B sirven para explicar y pequeños cambios
Para ingeniería compleja, usa modelos cloud más fuertes

Los modelos locales en 3060 son útiles para explicar código, completar funciones, generar scripts pequeños y ayudar sin conexión. Para grandes refactors, bugs complejos y tareas Agent entre archivos, no esperes rendimiento al nivel de Claude Sonnet o GPT-5.

Expectativas razonables

La RTX 3060 12GB puede convertir los LLM locales de “juguete” en herramienta diaria, pero no replica modelos cloud de primera línea en casa.

Ventajas:

Bajo costo.
Más VRAM que tarjetas de 8GB.
Buena experiencia con modelos 8B.
Uso offline.
Procesamiento local de datos sensibles.

Límites:

Modelos grandes no van fluidos.
Contexto largo consume VRAM.
Menor velocidad que tarjetas de gama alta.
Modelos locales pequeños tienen razonamiento complejo limitado.
Multimodalidad y flujos Agent consumen más recursos.

La ruta estable es: usar 8B como asistente local diario, probar 12B para mejor calidad y dejar tareas complejas a modelos cloud.

Resumen

Modelos locales recomendados para RTX 3060 12GB:

Chino general: Qwen3 8B Q4_K_M
Inglés general: Llama 3.1 8B Instruct Q4_K_M
Prueba de más calidad: Gemma 3 12B Q4_K_M
Experimento de razonamiento: DeepSeek R1 Distill Qwen 8B Q4_K_M
Experiencia rápida con poca VRAM: modelos pequeños 3B / 4B

Elige primero Q4_K_M; en modelos 8B puedes probar Q5_K_M. Empieza con Ollama o LM Studio.

No trates la 3060 como un servidor de grandes modelos. Úsala como asistente local de conocimiento, procesador privado de documentos, ayuda ligera de código y tarjeta de experimentación, y encajará mejor con sus capacidades reales.

Referencias

Qwen3 8B GGUF: https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF: https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF: https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp: https://github.com/ggml-org/llama.cpp
Ollama: https://ollama.com

TradingAgents-CN: un marco multiagente de investigación de trading financiero para usuarios chinos

Fri, 01 May 2026 03:14:15 +0800

TradingAgents-CN es un marco de investigación de trading financiero multiagente orientado a usuarios chinos.

Su objetivo no es dar una respuesta simple a “qué acción comprar”, sino usar varios AI Agent para simular un equipo de análisis financiero más completo: alguien observa los fundamentales, alguien mira el análisis técnico, alguien sigue noticias y sentimiento, y alguien se encarga del riesgo y de la decisión final. Para quienes quieren estudiar LLM + Agent + análisis financiero, este tipo de proyecto es una buena puerta de entrada experimental.

Primero hay que dejar algo claro: estas herramientas son adecuadas para aprendizaje, investigación y análisis asistido, y no deben tratarse como asesoramiento real de trading. Los mercados financieros tienen riesgo, y las salidas del modelo también pueden ser erróneas, retrasadas o demasiado confiadas.

Qué problema resuelve

Un modelo de chat común también puede analizar acciones, por supuesto.

Puedes preguntar directamente: “Ayúdame a analizar si cierta empresa se puede comprar.” El modelo dará una respuesta que parece completa. Pero ese enfoque tiene varios problemas:

La cadena de análisis no es transparente
Las distintas dimensiones se mezclan con facilidad
Falta división de roles
Falta choque entre puntos de vista favorables y contrarios
Las advertencias de riesgo pueden quedarse en una formalidad
Es difícil reproducir el mismo proceso de análisis

La idea de TradingAgents-CN es dividir el análisis financiero en varios roles, dejar que distintos Agent se encarguen de distintas perspectivas y formar el resultado mediante colaboración, discusión y síntesis.

Esto se acerca más al proceso real de investigación de inversión. Un juicio de inversión normalmente no mira solo una noticia o un indicador técnico, sino que combina fundamentales de la empresa, entorno de mercado, tendencia de precios, sentimiento de capital, riesgo regulatorio y control de posición.

Qué significa análisis multiagente

Multiagente no significa simplemente dejar que varios modelos hablen por turnos.

Una práctica más valiosa es asignar responsabilidades claras a distintos Agent. Por ejemplo:

Agent de análisis de mercado: observa tendencias de mercado, cambios de precio y entorno general
Agent de análisis fundamental: observa negocio de la empresa, datos financieros y valor de largo plazo
Agent de análisis de noticias: observa anuncios, noticias, opinión pública e impacto de eventos
Agent de análisis técnico: observa tendencias, indicadores, soportes, resistencias y señales de trading
Agent de gestión de riesgo: observa volatilidad, drawdown, posición e incertidumbre
Agent de decisión: integra distintas opiniones y forma el juicio final

Esta estructura puede reducir el problema de que un único modelo “diga todas las conclusiones de una vez”.

Cuando distintos roles analizan el mismo objetivo, el sistema puede presentar juicios multidimensionales con más facilidad y también exponer discrepancias. Para quien aprende, esto suele aportar más que leer solo un resumen.

Por qué hace falta una versión china

El análisis financiero está muy ligado al entorno lingüístico.

Las fuentes de información que siguen los usuarios chinos, los hábitos del mercado, los nombres de acciones, los sistemas de negociación, el estilo de las noticias y los términos comunes son distintos de los del entorno inglés. Al usar directamente un marco en inglés, aparecen a menudo varios problemas:

Los nombres y códigos de acciones chinas no se procesan con fluidez
Se mezclan contextos de acciones A, acciones de Hong Kong y acciones estadounidenses
La comprensión de noticias financieras chinas es inestable
No es cómodo integrar fuentes de datos nacionales
El estilo de salida no encaja con los hábitos de lectura de usuarios chinos

El valor de TradingAgents-CN está en adaptar este proceso de análisis financiero multiagente al usuario chino. Hace más fácil construir, ejecutar y entender todo el flujo experimental de análisis de trading.

Para qué se puede usar

Este proyecto es más adecuado para investigación y análisis asistido que para órdenes automáticas.

Usos relativamente adecuados:

Aprender cómo colaboran los sistemas multiagente
Investigar el rendimiento de LLM en análisis financiero
Organizar información de una acción desde múltiples ángulos
Comparar diferencias entre modelos en tareas de investigación de inversión
Construir tu propio prototipo de Agent de análisis financiero
Revisar información histórica y puntos de riesgo de un activo
Practicar la división del proceso de investigación de inversión en tareas ejecutables

Si estás estudiando trading cuantitativo, ingeniería financiera, AI Agent o desarrollo de aplicaciones LLM, este tipo de proyecto puede ayudarte a entender la estructura de ingeniería detrás de un “asistente de investigación de inversión con IA”.

Para qué no es adecuado

No es adecuado tratarlo directamente como una herramienta para ganar dinero de forma segura.

Especialmente no es adecuado para:

Comprar o vender con toda la posición solo según la salida
Sustituir tu propio juicio de riesgo por la conclusión del modelo
Tratar predicciones de precio de corto plazo como resultados seguros
Ignorar costes de transacción, slippage y liquidez
Conectarlo a una cuenta real sin backtesting
Sustituir una estrategia de inversión de largo plazo por una conclusión de análisis puntual

Los LLM son buenos organizando información, generando explicaciones y simulando procesos de razonamiento, pero no poseen de forma natural una capacidad estable para predecir mercados. En los mercados financieros hay mucho ruido, eventos repentinos y juego conductual; la salida del modelo solo puede ser una referencia más.

Diferencia frente a un marco cuantitativo común

Los marcos cuantitativos tradicionales prestan más atención a datos, factores, backtesting, optimización de carteras y ejecución de trading.

Por ejemplo, puedes definir reglas de estrategia:

Ruptura de media móvil
Factor de momentum
Factor de valor
Filtro de volatilidad
Stop loss y take profit
Gestión de posición

Después usas datos históricos para hacer backtesting.

TradingAgents-CN se inclina más hacia un “marco de análisis con agentes”. Lo que le importa es cómo hacer que varios LLM Agent colaboren alrededor de una tarea financiera, cómo simular una discusión de research y cómo organizar noticias, fundamentales, análisis técnico y juicio de riesgo.

No son enfoques que se sustituyan entre sí.

Un uso más realista es: el sistema cuantitativo tradicional se encarga de reglas verificables y backtesting; el sistema de Agent se encarga de organización de información, generación de informes, comparación de opiniones y apoyo a la decisión. Que finalmente pueda entrar en trading real depende todavía de backtesting riguroso, control de riesgo y revisión humana.

Diferencia frente a preguntar directamente a ChatGPT

Preguntar directamente al modelo tiene la menor barrera de entrada, pero el proceso es muy laxo.

Preguntas una vez y responde una vez. Si cambias la forma de preguntar, la conclusión puede cambiar. Es difícil garantizar que analice siempre desde las mismas dimensiones, y también es difícil hacer que interprete de forma estable varios roles que se equilibran entre sí.

El valor de TradingAgents-CN es estructurar el flujo de análisis:

Roles más claros
Pasos más reproducibles
Fuentes de información más fáciles de organizar
Choque de opiniones más natural
Revisión de riesgo más fácil de separar
Salida más parecida al resultado de un proceso de investigación de inversión

Esto es útil para aprendizaje e investigación. Puedes observar cómo distintos Agent influyen en la conclusión final, y también sustituir modelos, ajustar prompts o modificar la división de roles para comparar cambios en los resultados.

Riesgos a vigilar al usarlo

Primero, calidad de datos.

El análisis financiero depende mucho de los datos. Si datos de mercado, reportes financieros, noticias o anuncios son incompletos o no están actualizados, por muy fluido que sea el análisis del Agent, puede estar construido sobre una base equivocada.

Segundo, alucinaciones del modelo.

Un LLM puede inventar hechos inexistentes, malinterpretar el significado de los datos o tomar información antigua como nueva. Cuando se trata de acciones concretas, hay que volver a la fuente de datos para verificar.

Tercero, sobreexplicación.

El modelo es muy bueno dando explicaciones “que parecen razonables”, pero los cambios de precio del mercado no necesariamente vienen de las razones que enumera. No confundas explicación posterior con prueba causal.

Cuarto, brecha entre backtesting y trading real.

Incluso si una estrategia se comporta bien con datos históricos, en trading real seguirá enfrentándose a slippage, comisiones, liquidez, suspensiones, límites de subida/bajada y mercados extremos.

Quinto, licencia y límites comerciales.

El README menciona que el proyecto usa una licencia mixta. Las condiciones para aprendizaje personal, investigación y uso comercial pueden ser distintas. Si planeas incorporarlo en un producto o servicio comercial, primero lee con cuidado la licencia del proyecto.

A quién le conviene estudiarlo

TradingAgents-CN es adecuado para:

Desarrolladores que quieren aprender arquitectura de AI Agent
Personas que quieren estudiar la capacidad de LLM en análisis financiero
Usuarios de trading cuantitativo que quieren incorporar análisis de lenguaje natural
Equipos que quieren construir herramientas auxiliares de investigación de inversión
Personas interesadas en cómo la colaboración multirol afecta decisiones
Usuarios que quieren experimentar con trading Agent en entorno chino

Si tu objetivo es obtener una simple sugerencia de compra o venta, este proyecto quizá no sea la mejor forma de abrirlo. Lo que más merece atención es el proceso, los roles, la colaboración y el control de riesgo, no la conclusión de una salida puntual.

Cómo puede ampliarse

Este tipo de marco tiene muchas direcciones de expansión:

Integrar más fuentes de datos fiables
Añadir soporte para modelos locales
Añadir módulo de backtesting
Afinar reglas distintas para acciones A, Hong Kong y Estados Unidos
Añadir Agent de análisis sectorial
Añadir gestión de cartera y control de posición
Reforzar citas de informes y trazabilidad de datos
Combinar conclusiones de Agent con señales cuantitativas tradicionales

Un sistema financiero de IA realmente valioso normalmente no deja que el modelo decida todo por sí solo, sino que lo inserta en un proceso verificable, trazable y controlado por riesgo.

Referencia

hsliuping/TradingAgents-CN

Una última frase

Lo que merece atención de TradingAgents-CN no es si puede predecir la siguiente vela K, sino que divide el análisis financiero en un proceso de colaboración multiagente.

Tratarlo como herramienta de aprendizaje e investigación es más razonable que tratarlo como una máquina automática de ganar dinero.

Prompt Optimizer: una herramienta de código abierto para optimización, pruebas y MCP rápidos

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer es una herramienta de código abierto para mejorar las indicaciones. Su objetivo es sencillo: ayudarle a convertir una indicación aproximada en algo más claro, más estable y más fácil de seguir para modelos de lenguaje grandes.

No es sólo una página que “pule mi mensaje”. El proyecto proporciona optimización rápida, prueba, comparación y evaluación de resultados, acceso a múltiples modelos, manejo de imágenes rápidas e integración MCP. Para las personas que suelen escribir avisos del sistema, avisos de usuario y plantillas de flujo de trabajo de IA, se siente más como un banco de trabajo de avisos dedicado.

¿Qué problema resuelve?

Mucha gente se encuentra con problemas similares cuando utiliza la IA:

Las indicaciones son cada vez más largas, pero la calidad del resultado no mejora claramente
La misma tarea se comporta de manera diferente después de cambiar de modelo.
Las indicaciones del sistema y las indicaciones del usuario están mezcladas y son difíciles de depurar.
Después de cambiar un mensaje, no está claro si la nueva versión es mejor
Las plantillas variables son útiles, pero el reemplazo manual y las pruebas son tediosos
La optimización rápida debería estar disponible para otras herramientas de IA, pero no existe una interfaz estándar

Prompt Optimizer está diseñado en torno a estos problemas. Divide la “escripción de un mensaje” en optimización, prueba, evaluación, comparación e iteración, por lo que el ajuste del mensaje ya no se basa únicamente en la intuición.

Características principales

1. Optimice las indicaciones del sistema y las indicaciones del usuario

Hay más de un tipo de aviso.

Las indicaciones del sistema suelen definir roles, objetivos, límites, reglas de salida y métodos de trabajo. Las indicaciones del usuario están más cerca de la entrada para una tarea específica. Cuando los dos se mezclan, el modelo puede perder el punto clave y la reutilización se vuelve más difícil.

Prompt Optimizer admite tanto la optimización de los mensajes del sistema como la optimización de los mensajes del usuario. Puede mejorar las definiciones de roles reutilizables a largo plazo por separado de la entrada para una tarea específica.

Esto es útil para:

Redacción de reglas para asistentes de codificación de IA.
Diseño de roles de atención al cliente, revisor, traducción y análisis.
Optimización de mensajes de texto a imagen
Convertir requisitos temporales en plantillas reutilizables
Preparar diferentes estilos de mensajes para diferentes modelos.

2. Probar y comparar resultados

Optimizar un mensaje no es suficiente. La pregunta importante es si el mensaje optimizado realmente funciona mejor.

El proyecto apoya el análisis, la evaluación de un solo resultado y la comparación de múltiples resultados. Puede ejecutar el mensaje original y el mensaje optimizado en la misma tarea y luego comparar si el resultado es más preciso, estable y está alineado con el objetivo.

Esto es más práctico que las indicaciones que sólo “parecen más profesionales”. Muchas indicaciones parecen completas en la superficie, pero producen resultados detallados, rígidos o incluso mal dirigidos. Las pruebas comparativas ayudan a revelarlo tempranamente.

3. Soporte multimodelo

El README dice que el proyecto admite servicios modelo como OpenAI, Gemini, DeepSeek, Zhipu AI y SiliconFlow, así como API personalizadas compatibles con OpenAI.

Esto es importante porque el rendimiento rápido depende en gran medida del modelo. El mismo mensaje puede comportarse de manera muy diferente entre modelos. Las pruebas multimodelo ayudan a determinar:

Si el mensaje en sí es débil
Si un modelo específico no es adecuado para la tarea
Si se necesitan diferentes versiones de avisos específicos del modelo
Si un modelo más pequeño puede volverse utilizable con un mensaje más claro Si utiliza Ollama localmente o su empresa tiene un servicio de modelo interno compatible con OpenAI, también se puede conectar a través de una API personalizada.

4. Modo de prueba avanzado

El proyecto proporciona gestión de variables de contexto, pruebas de conversación de múltiples turnos y soporte de llamadas a funciones.

La gestión de variables es útil para tareas con plantillas. Por ejemplo, si tiene solicitudes de respuestas de ventas de segunda mano, descripciones de productos, respuestas de correo electrónico, revisiones de códigos o generación de documentos, puede reemplazar variables como producto, precio, tono y usuario objetivo para probar diferentes entradas rápidamente.

Las pruebas de conversación de varios turnos ayudan a validar el comportamiento de diálogo de larga duración. Muchas indicaciones parecen estar bien en un solo turno, pero una vez que comienzan las preguntas de seguimiento, es posible que olviden las limitaciones, se desvíen del papel o repitan explicaciones. Las pruebas de múltiples vueltas están más cerca del uso real.

El soporte de llamadas de funciones es adecuado para aplicaciones de IA más orientadas a la ingeniería. Ayuda a validar el comportamiento del modelo en torno a llamadas a herramientas, generación de parámetros y resultados estructurados.

5. Avisos de generación de imágenes

Prompt Optimizer también admite flujos de trabajo de texto a imagen y de imagen a imagen. El README menciona la integración con modelos de imágenes como Gemini y Seedream.

La optimización de mensajes de imagen es diferente de las tareas de texto. Se centra más en el tema, la composición, la relación espacial, el estilo, el material, la iluminación, el estado de ánimo y las limitaciones. Convertir una idea vaga en una descripción visual controlable suele ser más valioso que simplemente alargar la indicación.

Si genera con frecuencia imágenes de productos, portadas, ilustraciones, elementos visuales clave o referencias de estilo, este tipo de optimización es útil.

Formas de usarlo

El proyecto proporciona varios puntos de entrada:

Versión en línea
Vercel autohospedado
Aplicación de escritorio
Extensión de Chrome
Implementación de Docker
Implementación de Docker Compose
Servidor MCP

La versión en línea es buena para pruebas rápidas. El proyecto señala que es una aplicación puramente frontend: los datos se almacenan localmente en el navegador y se envían directamente a los proveedores de IA.

La aplicación de escritorio es mejor cuando necesita conectarse directamente a diferentes modelos de API. Los entornos de navegador pueden encontrarse con los límites de CORS; la aplicación de escritorio evita esos problemas, especialmente cuando se conecta a Ollama local o API comerciales con políticas estrictas de origen cruzado.

La implementación de Docker es adecuada para su propio servidor o entorno de intranet. El README da este comando básico:

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

Para configurar claves API y contraseñas de acceso, pase variables de entorno:

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

Si Docker Hub es lento en China, el proyecto también proporciona una dirección de imagen de Alibaba Cloud en el README.

Qué permite MCP

Prompt Optimizer admite el protocolo de contexto modelo o MCP.

Cuando se ejecuta a través de Docker, el servicio MCP puede iniciarse junto con la aplicación web y se puede acceder a él a través de la ruta /mcp. Esto lo convierte de una herramienta web en algo a lo que pueden acceder aplicaciones compatibles con MCP, como Claude Desktop.

El archivo README enumera estas herramientas MCP:

optimize-user-prompt: optimiza las indicaciones del usuario
optimize-system-prompt: optimiza las indicaciones del sistema
iterate-prompt: realiza una iteración específica en un mensaje existente Estas interfaces son muy adecuadas para los flujos de trabajo de IA. Por ejemplo, al escribir un mensaje de tarea compleja, un cliente compatible con MCP puede llamar a la herramienta de optimización de mensajes directamente en lugar de requerir que abra una página web y copie el texto manualmente.

Diferencia con las herramientas de chat normales

Las herramientas de chat normales también pueden ayudar a reescribir las indicaciones, pero normalmente carecen de varias partes:

Guardar y comparar múltiples versiones es inconveniente
Probar varios modelos a la vez es inconveniente
Convertir variables en plantillas es un inconveniente
La validación de conversaciones de varios turnos es inconveniente
La integración a través de MCP o autohospedaje es inconveniente

El valor de “Prompt Optimizer” es que convierte la optimización rápida en un proceso repetible. No solo te ofrece una versión que “parece más completa”; le permite seguir ajustando las indicaciones en torno a resultados reales.

¿Quién debería usarlo?

Este proyecto merece atención si:

A menudo escribe mensajes del sistema.
Diseñar roles y formatos de salida para aplicaciones de IA.
Necesidad de comparar resultados de diferentes modelos.
Quiere convertir indicaciones en plantillas reutilizables
Necesidad de probar el diálogo de varios turnos o las llamadas a herramientas.
Quiere conectar la optimización rápida a un flujo de trabajo MCP
Quiere implementar una herramienta de aviso localmente o dentro de una intranet.

Si sólo ocasionalmente le haces una pregunta sencilla a AI, una página de chat normal es suficiente. Esta herramienta es mejor para las personas que tratan las indicaciones como activos mantenibles.

Notas de uso

En primer lugar, no trate los resultados de la optimización como absolutamente correctos.

Las herramientas de optimización rápidas pueden mejorar la calidad de la expresión, pero no pueden garantizar que un modelo nunca se malinterprete. Las tareas importantes aún necesitan casos de prueba, revisión manual y comparación de versiones.

En segundo lugar, no se limite a perseguir la longitud.

Un buen mensaje no es necesariamente más largo. Debería expresar más claramente los objetivos, los límites, los formatos de entrada y salida y los criterios de evaluación. La acumulación de reglas sin sentido puede hacer que el modelo no entienda el punto.

En tercer lugar, ajuste las indicaciones por modelo.

Los diferentes modelos responden de manera diferente a la configuración de roles, restricciones de formato, pasos de razonamiento y ejemplos. Un mensaje que funciona bien en un modelo grande puede no ser adecuado para un modelo más pequeño. Las pruebas multimodelo son una de las razones por las que esta herramienta es útil.

Cuarto, considere las claves y el control de acceso al implementar.

Si lo implementa públicamente, configure una contraseña de acceso y maneje las claves API con cuidado. El proyecto soporta el control de acceso a través de variables de entorno; no escriba configuraciones confidenciales directamente en repositorios públicos.

Referencia

linshenkx/prompt-optimizer

Pensamiento final

Prompt Optimizer es útil para convertir mensajes de “un párrafo temporal que escribí a mano” en “un activo de trabajo que se puede probar, comparar e iterar”.

Cuando comienzas a mantener mensajes en múltiples modelos, escenarios y versiones, este tipo de herramienta es más conveniente que una ventana de chat normal.

Google LangExtract: extraiga datos estructurados de texto largo con LLM

Fri, 01 May 2026 02:58:21 +0800

LangExtract es una biblioteca Python de código abierto de Google para extraer información estructurada de texto no estructurado.

Su caso de uso es sencillo: proporcione un fragmento de texto, un mensaje y algunos ejemplos, luego deje que un modelo de lenguaje grande extraiga campos de acuerdo con su definición y organice el resultado en datos que puedan procesarse.

A diferencia de simplemente pedirle a un modelo que resuma algo, “LangExtract” se centra en tres cosas:

Extraer información en una estructura fija.
Preservar la relación entre los resultados extraídos y sus ubicaciones de origen.
Soporte de documentos largos e inspección visual.

Si a menudo necesita extraer entidades, eventos, relaciones o atributos de informes, documentos, notas médicas, contratos, registros o páginas web, este tipo de herramienta es más flexible que las expresiones regulares escritas a mano y más fácil de conectar a flujos de trabajo de datos posteriores que las simples preguntas estilo chat.

¿Qué problema resuelve?

Muchas tareas de extracción de texto parecen simples, pero resultan problemáticas en la práctica.

Por ejemplo, es posible que desee extraer:

Personas, organizaciones y ubicaciones.
Eventos, horarios y participantes.
Medicamentos, dosis y reacciones adversas.
Modelos, parámetros y precios de productos.
Cláusulas, obligaciones y plazos del contrato.
Tipos de errores y contexto de los registros.

Si el formato es fijo, pueden funcionar las expresiones regulares o los analizadores tradicionales.
Pero una vez que el texto se vuelve más natural, las reglas rápidamente se complican.

Los modelos de lenguaje grandes son buenos para comprender el lenguaje natural, pero pedirle directamente a un modelo que lo “extraiga” a menudo causa varios problemas:

El formato de salida es inestable.
No está claro de dónde proviene la información en el texto fuente.
Es fácil pasar por alto los documentos largos
El procesamiento por lotes es difícil
Los resultados son incómodos de revisar manualmente

LangExtract aborda esta capa del problema: integra la comprensión de LLM en un flujo de trabajo de extracción más controlable.

Características clave de LangExtract

1. Utilice ejemplos para restringir el formato de extracción

LangExtract no se basa en un mensaje vago de una sola línea. En cambio, utiliza indicaciones y ejemplos para decirle al modelo:

Qué extraer
Cómo se llama cada campo
Cómo se debe llenar cada campo
Qué hacer cuando la información es incierta

Este enfoque de pocas tomas funciona bien para la extracción de información.
Cuanto más se acerquen sus ejemplos a los datos reales, más estable se volverá la salida estructurada del modelo.

2. Los resultados extraídos pueden vincularse a la fuente

El peor tipo de resultado de extracción es el que parece correcto pero no se puede rastrear.

Uno de los puntos importantes de “LangExtract” es alinear los resultados extraídos con las ubicaciones de origen. Cuando revise más tarde, no solo verá un resultado JSON; también puedes volver al texto original y ver de dónde vino la información.

Esto es importante en escenarios que requieren revisión, como textos médicos, textos legales, material de investigación y documentos comerciales internos.

3. Soporte para documentos largos

La extracción de documentos largos a menudo se topa con límites de ventana de contexto, resultados perdidos y resultados duplicados.

LangExtract proporciona un flujo de trabajo para texto largo: divide el documento, procesa fragmentos en paralelo y luego organiza los resultados extraídos. Esto lo hace más adecuado para informes completos, artículos, páginas web largas y documentos masivos, en lugar de solo fragmentos cortos.

4. Inspección visual

Si los resultados de la extracción solo están disponibles como JSON, es fácil pasar por alto los problemas.

LangExtract admite la visualización de resultados extraídos, lo que facilita ver qué extrajo el modelo y de dónde proviene.
Esto es útil para ajustar indicaciones, comprobar extracciones omitidas y encontrar falsos positivos.

¿Cuándo debería usarlo?

LangExtract es adecuado cuando:

Es necesario extraer campos estructurados del texto en lenguaje natural.
El formato del texto no está completamente arreglado.
Debes preservar la relación entre los resultados extraídos y el texto fuente.
Necesita procesar documentos más largos.
Los resultados requieren revisión humana
El resultado se incluirá posteriormente en tablas, bases de datos o flujos de trabajo de análisis de datos.

Los ejemplos típicos incluyen:

Extracción de síntomas, medicamentos, dosis y reacciones del texto médico.
Extracción de partes, obligaciones, montos y plazos de los contratos.
Extraer temas, métodos y conclusiones de los artículos.
Extracción de parámetros de especificación de documentos de producto.
Extracción de tipos de problemas y resoluciones de registros de soporte.

Si sólo necesita un resumen temporal de un breve fragmento de texto, un modelo de chat normal es suficiente.
Si desea convertir texto en datos que puedan procesarse más adelante, LangExtract es la mejor opción.

Instalación básica

El proyecto admite la instalación a través de pip:

`1`	`pip install langextract`

También puedes instalarlo desde la fuente:

1
2
3

git clone https://github.com/google/langextract.git
cd langextract
pip install -e .

Si desea utilizar una API modelo, configure la clave API para el proveedor del modelo correspondiente.
La documentación del proyecto se centra en el uso de Gemini y también puede conectarse a otros proveedores de modelos a través de adaptadores.

Flujo de uso básico

Un flujo de trabajo típico se ve así:

Prepara el texto fuente.
Describa claramente el objetivo de extracción.
Proporcione algunos ejemplos
Llame a LangExtract para realizar la extracción.
Inspeccionar el resultado estructurado.
Genere una página de visualización para revisarla si es necesario.

El segundo y tercer paso son los más importantes.

El mensaje debe describir claramente la tarea, por ejemplo:

Extraer sólo información explícitamente presente en el texto.
No completes hechos faltantes de sentido común.
Deje los campos vacíos cuando falte información
Mantener la misma estructura de campos para el mismo tipo de entidad.
Conservar fragmentos de código fuente o posiciones en la salida

Los ejemplos deben ser lo más parecidos posible a las entradas reales.
Si el texto real tiene ruido, abreviaturas, saltos de línea o residuos de tabla, los ejemplos deberían reflejarlo.

Cosas a tener en cuenta

En primer lugar, no amplíe demasiado la tarea de extracción.

“Extraer información útil” es demasiado vago.
Una mejor instrucción sería “extraer el nombre del medicamento, la dosis, la frecuencia y las reacciones adversas”.

En segundo lugar, no confíe plenamente en los resultados del modelo.

LangExtract puede alinear los resultados con el texto fuente, pero eso no significa que el modelo nunca omitirá o extraerá incorrectamente información. Los escenarios importantes aún requieren controles de muestreo o revisión humana.

En tercer lugar, los ejemplos son más útiles que las explicaciones largas.

En las tareas de extracción de información, los modelos suelen basarse más en ejemplos para comprender el formato de salida.
En lugar de escribir un conjunto de reglas largas y abstractas, proporcione algunos ejemplos de alta calidad. Cuarto, preste atención al costo y la velocidad para documentos largos.

La división de documentos largos, la extracción paralela y las llamadas de modelos tienen costos. Antes del procesamiento por lotes, utilice un pequeño conjunto de muestra para ajustar la estructura de campos y mensajes.

¿En qué se diferencia de Regex o PNL tradicional?

Las expresiones regulares son buenas para formatos de texto estables y bien definidos.

Los canales de PNL tradicionales funcionan bien cuando los límites de las tareas son claros y el modelo o diccionario ya está preparado.

LangExtract es mejor para texto cuyo formato es menos fijo pero cuyo significado es claro.
No requiere que escribas una regla para cada expresión posible; en cambio, el LLM aprende el objetivo de extracción a partir de ejemplos.

Pero no es un reemplazo completo de las expresiones regulares:

Para texto de formato fijo, las expresiones regulares son más económicas y estables.
Para escenarios de alto riesgo, aún se requiere validación y revisión.
Para el procesamiento por lotes a gran escala, el costo de la llamada al modelo es importante

Un enfoque práctico es manejar las partes con reglas claras con código y usar LangExtract para las partes con más variación semántica.

¿Para quién es?

Es posible que desee consultar LangExtract si está realizando alguna de las siguientes acciones:

Convertir texto largo en tablas.
Extracción de entidades y relaciones de documentos.
Limpiar datos antes de ponerlos en una base de conocimientos.
Extracción de campos del texto comercial.
Construcción de un prototipo de extracción de información impulsado por LLM.
Preservar evidencia entre los resultados extraídos y el texto fuente.

No es una herramienta de tipo “haga clic una vez y comprenda cada documento”. Es más como una biblioteca para diseñar un flujo de trabajo de extracción de LLM.

Aún necesita diseñar campos, escribir ejemplos e inspeccionar los resultados.
Pero en comparación con escribir manualmente llamadas de modelo, unir mensajes y analizar resultados cada vez, proporciona un marco de extracción más completo.

Referencia

google/langextract

Pensamiento final

El valor de LangExtract hace que “permitir que un LLM encuentre información en texto” sea más controlable.

No es para resúmenes casuales. Es para tareas de extracción de información con requisitos de campos, evidencia y revisión.
Si su trabajo convierte a menudo textos largos en datos estructurados, vale la pena intentarlo.

Por qué las API de LLM cobran por tokens: una guía clara sobre los costos de entrada, salida y contexto

Sat, 25 Apr 2026 08:44:32 +0800

Una de las cosas más fáciles de confundir acerca de la facturación API de LLM es por qué casi todas las plataformas eventualmente se reducen a una unidad: “token”. La verdadera pregunta es simple: ¿por qué los LLM cobran por token y por qué diferentes tokens pueden tener precios diferentes?

Para muchas personas que recién comienzan a usar API modelo, la parte más confusa no es la capacidad del modelo sino la factura. ¿Por qué el costo aumenta tan rápidamente incluso cuando solo hace unas pocas preguntas? ¿Por qué los insumos son más baratos que los productos? ¿Por qué la factura empieza a crecer mucho más rápido una vez que el contexto se alarga?

Una forma sencilla de pensarlo es la siguiente: no estás pagando por “una respuesta”. Usted paga por la computación y el ancho de banda consumidos durante todo el proceso de inferencia.

1. ¿Qué es una ficha?

En la facturación de LLM, un “token” no es un recuento de caracteres ni de palabras. Es la unidad que utiliza un modelo al procesar texto.

Un token podría ser:

Un solo carácter chino
Parte de una palabra inglesa.
Un signo de puntuación
Un breve fragmento de texto visto con frecuencia.

Es por eso que las plataformas API no suelen cobrar por frase ni por solicitud. Cobran según la cantidad de tokens que realmente lee y genera el modelo.
Esto es mucho más razonable que cobrar por recuento de solicitudes, porque una solicitud puede contener 20 caracteres, mientras que otra puede incluir 200.000 tokens de contexto. El consumo de recursos no es ni de lejos el mismo.

2. ¿Por qué los insumos y los productos se cotizan por separado?

La mayoría de las API de modelos actuales dividen los precios en dos partes:

Precio del token de entrada
Precio del token de salida

Y en muchos casos, los tokens de salida cuestan más que los tokens de entrada.

La razón no es difícil de entender.

Cuando un modelo procesa entradas, principalmente lee y codifica contenido existente. Pero cuando genera resultados, tiene que predecir el siguiente token, luego el siguiente, luego el siguiente. Esto no es sólo leer. Es un proceso continuo de inferencia y muestreo, que normalmente cuesta más cálculo.

Puedes pensar en ello más o menos así:

Entrada: entrega de materiales al modelo.
Resultado: pedirle al modelo que escriba la respuesta en el acto.

Escribir sobre el terreno suele costar más que leer los materiales una vez, por lo que es muy común que el precio de salida sea más alto.

3. Por qué el contexto prolongado hace que sea más fácil perder el control de los costos

Mucha gente piensa que sólo están añadiendo un poco más de información general, pero desde la perspectiva de la facturación modelo, el impacto suele ser mucho mayor de lo esperado.

La razón es que cada llamada de modelo generalmente tiene que procesar nuevamente el contexto completo incluido en esa solicitud.

Eso significa que si su solicitud contiene actualmente:

Un mensaje del sistema
Historial de conversaciones
Valores de retorno de la herramienta
trozos de documentos largos
Archivos de código fuente

todo eso se destina a la facturación del token de entrada.

Entonces, lo que realmente hace crecer los proyectos de ley no es a menudo la pregunta final en sí misma, sino la larga cadena de contexto que se le presenta.
A medida que aumenta el número de turnos de conversación, se acumulan las llamadas a herramientas y se siguen enviando mensajes anteriores, el coste del token crece ronda tras ronda.

4. Por qué es especialmente probable que las llamadas a herramientas inflen el uso de tokens

En escenarios como agentes, asistentes de codificación y automatización del flujo de trabajo, el uso de tokens suele ser mucho mayor que en el chat normal. La cuestión no es sólo que la modelo haya escrito un párrafo. Es que el flujo de trabajo sigue produciendo contenido como:

Leer archivos
Inspeccionar registros
Llamadas a API
Volviendo JSON
Introducir los resultados de la herramienta en el modelo.

Siempre que el resultado de cada llamada a la herramienta se inserte en la siguiente ronda de contexto, se convierte en una nueva fuente de tokens de entrada.

Es por eso que muchos desarrolladores finalmente se dan cuenta de:
El precio unitario del modelo no siempre es el verdadero problema. El flujo de trabajo en sí puede acumular el costo de los tokens capa por capa.

Por ejemplo, imagine un agente codificador haciendo lo siguiente:

Leer la estructura del proyecto.
Abra varios archivos fuente.
Ejecute un conjunto de pruebas
Vuelva a introducir los registros de errores en el modelo.
Leer más archivos relacionados

Cada paso puede hacer que las solicitudes posteriores tengan aún más contexto. Incluso si el precio unitario no cambia, la factura total puede aumentar rápidamente.

5. Por qué un mismo tipo de modelo puede tener precios muy diferentes

Las diferencias en los precios de los tokens entre modelos no se deben solo a que los proveedores quieran cobrar más. Suelen estar directamente relacionados con varios factores:

Tamaño del modelo
Eficiencia de inferencia
Longitud del contexto
Costo de implementación
Mercado objetivo

Cuanto más grande es el modelo, más parámetros activos utiliza y más compleja es su ruta de inferencia, mayor suele ser el costo de generar un token.
Si el modelo también admite un contexto ultralargo, un razonamiento más complejo o un mejor uso de las herramientas, la presión sobre la infraestructura aumenta aún más.

Entonces, el precio en realidad cubre varios tipos de costos:

Recursos de GPU o acelerador
Uso de VRAM
Latencia de inferencia
Estabilidad de la red y del servicio.
Capacidad máxima de concurrencia

Un modelo más barato no es necesariamente malo y un modelo más caro no es necesariamente la elección correcta para cada tarea. En muchos casos, la brecha de precios refleja cuánto costo de infraestructura requiere un cierto nivel de capacidad.

6. Por qué la entrada en caché es más barata

Muchas plataformas de modelos ahora ofrecen características como:

entrada en caché
almacenamiento en caché rápido
almacenamiento en caché de prefijos

La idea compartida detrás de ellos es simple: si una gran cantidad de insumos ya ha sido procesada una vez, no sigan calculándolos desde cero al precio completo.

Por ejemplo, si envía repetidamente el mismo mensaje del sistema, las mismas instrucciones de herramienta o el mismo prefijo de documento largo, es posible que la plataforma pueda almacenar en caché parte de ese cálculo. Luego, aunque todavía se utilice el token de entrada, la parte almacenada en caché se puede facturar a una tarifa más baja.

Esto también explica por qué muchas páginas de precios de API muestran tres o más niveles de precios:

Entrada estándar
Entrada en caché
Salida

La diferencia no es que el texto signifique cosas diferentes. Es que el cálculo subyacente puede ser reutilizable o no.

7. Por qué los “tokens baratos” no significan automáticamente un costo total más bajo

Cuando la gente ve un modelo anunciado como “muy barato por millón de tokens”, el primer instinto suele ser que el coste total también debe ser menor. En realidad, no siempre.

Esto se debe a que el costo total es aproximadamente:

precio unitario del token × volumen real del token

Y el volumen real de tokens puede verse amplificado por muchas cosas:

Avisos demasiado largos.
Historial de conversaciones que nunca se recorta
Demasiada salida de herramienta retroalimentada
Salida del modelo demasiado detallada
Reintentos repetidos para la misma tarea Por tanto, la factura real no está determinada únicamente por el precio. Suele estar determinado por:
Precio unitario del modelo
Longitud de entrada por ronda
Longitud de salida por ronda
Número de llamadas
Diseño de flujo de trabajo

Esta es también la razón por la que un “modelo de bajo costo” aún puede resultar costoso en los flujos de trabajo de algunos agentes. Es posible que necesite más rondas, más contexto suplementario y más ciclos de reintento.

8. Cómo los desarrolladores deberían estimar el costo del token

Si desea un mejor control presupuestario en un proyecto real, una forma sencilla de estimar el costo es:

Mida el promedio de tokens de entrada por solicitud
Mida los tokens de producción promedio por solicitud
Calcule cuántas rondas requiere una tarea completa
Multiplica por el precio del modelo.

Por ejemplo:

8k tokens de entrada por ronda
1k tokens de producción por ronda
10 rondas para una tarea

Entonces lo que realmente estás consumiendo no es “un intercambio de preguntas y respuestas”, sino:

Aproximadamente “80.000 tokens” de entrada
Aproximadamente “10.000 tokens” de producción

Y si se siguen agregando registros, resultados de herramientas y contenidos de archivos a lo largo del camino, el total crece aún más.

Por eso la planificación presupuestaria no debería centrarse únicamente en una única ronda. Debería observar cuántos tokens consumirá un ciclo de tarea completo de principio a fin.

9. Cómo controlar la factura en la práctica.

Si ya utiliza API o agentes, los siguientes métodos suelen ser los más eficaces:

Acorte el mensaje del sistema y elimine las palabras repetidas
Recortar el historial de conversaciones antiguas con regularidad
Mantenga solo los campos necesarios de los resultados de la herramienta
Recuperar primero y luego enviar solo las partes relevantes de documentos extensos
Limite la longitud de salida y evite la expansión ilimitada
Utilice modelos caros para tareas de alto valor y modelos más baratos para tareas de menor valor

En muchos casos, la mejor manera de ahorrar dinero es no cambiar a ciegas a un modelo más económico. Primero se trata de eliminar el consumo innecesario de tokens del flujo de trabajo.

10. Cómo pensar en todo esto

Al final del día, el precio de los tokens es una forma de cobrar por cuánto tuvo que leer, inferir y escribir el modelo.

No es como los precios de software tradicionales, donde la facturación por cuenta, por solicitud o mensual es suficiente para describir el uso de recursos. Una llamada de modelo es un proceso de cálculo dinámico. La cantidad de contexto que envía, las herramientas que invoca y la longitud del resultado que solicita afectan directamente el costo.

Entonces lo más importante es no memorizar tablas de precios. Está construyendo la intuición correcta:

El contexto prolongado aumenta el costo de los insumos
La producción prolongada aumenta el costo de generación.
Las cadenas de herramientas amplifican el uso total de tokens
El almacenamiento en caché y el diseño del flujo de trabajo pueden cambiar significativamente la factura.

Una vez que esos puntos estén claros, la estructura de precios de la mayoría de las API de LLM se vuelve mucho más fácil de entender.

Lanzamiento de la vista previa de DeepSeek-V4: contexto de 1M, dos modelos y notas de migración de API

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek lanzó Lanzamiento preliminar de DeepSeek V4 el 2026-04-24. Según la página de anuncio oficial, la actualización se centra en algunos temas muy claros: “1M context”, una línea de dos modelos con “V4-Pro” y “V4-Flash”, optimización dedicada para escenarios de agentes y migración de modelos del lado API.

Si reducimos el comunicado a una frase, la señal principal es la siguiente: DeepSeek no sólo está intentando crear un modelo más potente. Está impulsando el contexto ultralargo y las capacidades de los agentes hacia algo que esté listo para su implementación práctica.

1. Lo que se lanzó esta vez

Según la página oficial, DeepSeek-V4 Preview incluye principalmente dos líneas de productos:

-DeepSeek-V4-Pro -DeepSeek-V4-Flash

Las descripciones oficiales también son muy directas:

DeepSeek-V4-Pro: 1.6T total / 49B parámetros activos
DeepSeek-V4-Flash: 284B en total / 13B de parámetros activos

El nombre ya deja clara la estrategia. Esta no es una actualización de un solo modelo. DeepSeek está lanzando un modelo de gama alta y un modelo más rentable al mismo tiempo.

“V4-Pro” está posicionado alrededor del techo de rendimiento, y DeepSeek dice que puede competir con los mejores modelos de código cerrado del mundo. V4-Flash, por el contrario, se posiciona en torno a la velocidad, la eficiencia y el menor costo, lo que lo hace más adecuado para cargas de trabajo que se preocupan más por la latencia y el precio de API.

2. `1M contexto` es el título más visible

Una de las líneas más destacadas de la página oficial es: “Bienvenido a la era del contexto rentable de 1 millón de longitud”.

DeepSeek no se limita a decir que el modelo admite un contexto prolongado. Presenta “contexto 1M” como una capacidad predeterminada de esta generación. La página es explícita que:

1M context es ahora el estándar predeterminado en todos los servicios oficiales de DeepSeek
Tanto V4-Pro como V4-Flash admiten contexto 1M

La importancia de esto no es sólo que puedas colocar más tokens. Afecta directamente a tareas como:

Comprender grandes bases de código
Preguntas y respuestas de documentos extensos y síntesis de información.
Flujos de trabajo de agentes de múltiples turnos
Tareas complejas que abarcan múltiples archivos, herramientas y etapas.

Cuando la ventana de contexto es lo suficientemente grande, es menos probable que el modelo pierda el contexto a mitad del camino y vuelva a leer el material repetidamente. Esto es muy importante para la codificación agente y el trabajo de conocimiento complejo.

3. Qué enfatiza principalmente `V4-Pro`

Según el texto de la página oficial, “DeepSeek-V4-Pro” se centra en tres cosas:

Capacidad de codificación agente
conocimiento mundial
Capacidad de razonamiento

La página dice que “V4-Pro” alcanza SOTA de código abierto en puntos de referencia de codificación agente. También afirma ser líder entre los modelos abiertos actuales en el conocimiento mundial, sólo por detrás de “Gemini-3.1-Pro”, y afirma que su rendimiento en matemáticas, “STEM” y codificación supera a los modelos abiertos actuales y rivaliza con los mejores modelos de código cerrado.

En otras palabras, “V4-Pro” no se posiciona como un simple modelo de preguntas y respuestas. Está dirigido mucho más al razonamiento de alta dificultad, la codificación compleja y la ejecución de tareas a largo plazo.

4. `V4-Flash` no es solo una versión reducida

Otro punto destacable es que DeepSeek no presenta V4-Flash como modelo de gama baja. Más bien, subraya que el modelo ya es lo suficientemente sólido para muchas tareas prácticas.

Según el anuncio, V4-Flash:

Tiene una capacidad de razonamiento cercana a “V4-Pro”.
Funciona a la par con V4-Pro en tareas simples de agente
Utiliza menos parámetros, responde más rápido y es más económico para el uso de API

Eso significa que la alineación no es una estructura muy dividida de “un buque insignia, un nivel de entrada”. Está más cerca de:

V4-Pro: optimización para un mayor rendimiento y un techo más resistente
V4-Flash: optimización para una menor latencia y una mejor rentabilidad

Para los desarrolladores, esta suele ser una combinación más práctica, porque muchas tareas de producción no necesitan el modelo más sólido en teoría. Necesitan algo lo suficientemente fuerte, lo suficientemente rápido y lo suficientemente asequible.

5. El lanzamiento pone un claro énfasis en la optimización de los agentes.

Otra señal fuerte de la página de anuncios es que DeepSeek está impulsando activamente “V4” hacia casos de uso de agentes.

La página dice que “DeepSeek-V4” se ha integrado perfectamente con varios agentes líderes de IA, incluidos:

Código Claude
OpenClaw
Código Abierto

DeepSeek también dice que “V4” ya se está utilizando en sus flujos de trabajo de codificación agentes internos.

Eso significa que el objetivo ya no se limita al chat o a la finalización ordinaria. El modelo se está posicionando para flujos de trabajo más largos: leer código, comprender la estructura, llamar a herramientas, generar resultados y conectar todo el proceso.

Si ha estado prestando atención a los agentes de codificación recientemente, vale la pena señalarlo. Los proveedores de modelos ya no compiten sólo en base a puntos de referencia. También compiten sobre si el modelo realmente puede integrarse en flujos de trabajo reales.

6. La innovación estructural está al servicio de la eficiencia en el contexto a largo plazo.

En el aspecto técnico, la página resume el trabajo estructural de este lanzamiento como:

compresión por token
DSA (Atención escasa de DeepSeek)

La dirección es clara: hacer que el contexto largo sea más barato y más eficiente, al mismo tiempo que se reducen los costos de computación y memoria tanto como sea posible.

La página del anuncio no entra en detalles técnicos completos, pero al menos sugiere que DeepSeek no depende únicamente del escalamiento por fuerza bruta para admitir ventanas más largas. También está realizando optimizaciones a nivel de arquitectura específicamente para la eficiencia en contextos prolongados.

Para los usuarios reales, eso a menudo es más importante que simplemente ver un número de contexto mayor, porque la usabilidad real depende de algo más que si “1M” está técnicamente disponible. También depende de:

Si la velocidad sigue siendo aceptable
Si el costo sigue siendo aceptable
Si las tareas de contexto largo permanecen estables en la práctica

7. La API ya está disponible, pero la migración del modelo es importante

La página oficial indica claramente que la API está disponible hoy.

La ruta de migración también es relativamente sencilla:

Mantener la misma base_url
Cambie el nombre del modelo a deepseek-v4-pro o deepseek-v4-flash

La página también dice que ambos modelos admiten:

Contexto 1M
Modos duales “Pensamiento / No pensamiento”
Compleciones de Chat OpenAI
API antrópicas

Eso significa que si ya utiliza la API de DeepSeek, la ruta de actualización no es especialmente difícil. El trabajo principal es actualizar los nombres de los modelos y validar el comportamiento.

8. El calendario de jubilación para modelos antiguos es explícito.

Para los desarrolladores, uno de los detalles más importantes de la página es en realidad el aviso de retirada de modelos más antiguos.

DeepSeek dice explícitamente:

chat de búsqueda profunda
razonador de búsqueda profunda

quedará completamente retirado y será inaccesible después del 24 de julio de 2026 a las 15:59 UTC. La página también señala que estos dos modelos están siendo encaminados actualmente a los modos de pensamiento y no pensamiento de “deepseek-v4-flash”.

Eso significa que si su proyecto todavía hace referencia directa a deepseek-chat o deepseek-reasoner, ahora es el momento de planificar la migración en lugar de esperar hasta que se acerque la fecha de cierre formal.

9. Por qué vale la pena leer este comunicado

Si comprimimos la actualización en algunas conclusiones principales, se ven así:

DeepSeek está convirtiendo el “contexto 1M” de una característica premium a un estándar predeterminado
La estrategia de dos modelos es más clara: uno apunta al techo de rendimiento, el otro apunta a la velocidad y la rentabilidad.
La capacidad del agente se ha trasladado a un papel muy central.
La ruta de actualización de API es relativamente directa, pero el cronograma de retiro del modelo antiguo necesita atención pronto.

Para los usuarios generales, el cambio más visible puede ser que los documentos largos, los contextos de código largos y los flujos de trabajo largos sean más fáciles de encajar en una sola sesión.
Para los desarrolladores, el punto más importante es que si ya están creando agentes, asistentes de codificación, flujos de trabajo de conocimiento o canales de automatización complejos, esta generación está muy claramente diseñada para esos escenarios.

Esta no es sólo una actualización rutinaria del modelo de DeepSeek. Se lee más como una declaración más clara de la próxima dirección de su producto: contexto ultralargo, optimización de agentes y preparación de API más práctica.

Enlaces relacionados

Página oficial de noticias de DeepSeek: https://api-docs.deepseek.com/news/news260424
Informe técnico: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
Pesos abiertos: https://huggingface.co/collections/deepseek-ai/deepseek-v4

Explicación de la cuantificación de LLM: cómo elegir FP16, Q8, Q5, Q4 o Q2

Sun, 05 Apr 2026 22:09:11 +0800

El objetivo principal de la cuantificación es simple: intercambiar una pequeña cantidad de precisión por un tamaño de modelo más pequeño, un menor uso de VRAM y una inferencia más rápida.
Para la implementación local, elegir el formato de cuantificación correcto suele ser más importante que buscar un recuento de parámetros mayor.

¿Qué es la cuantización?

La cuantización significa comprimir los parámetros del modelo desde formatos de mayor precisión (como “FP16”) a formatos de bits más bajos (como “Q8” y “Q4”).

Una analogía simple:

Modelo original: como una foto de alta calidad, clara pero grande.
Modelo cuantificado: como una foto comprimida, ligeramente menos detallada pero más ligera y rápida.

Formatos de cuantificación comunes

Cuantización	Precisión/Ancho de broca	Tamaño	Pérdida de calidad	Uso recomendado
FP16	flotante de 16 bits	Más grande	Casi ninguno	Investigación, evaluación, máxima calidad
Q8_0	Entero de 8 bits	Más grande	Casi ninguno	PC de alta gama, calidad + rendimiento
Q5_K_M	5 bits mixto	Medio	Ligero	Conductor diario, elección equilibrada
Q4_K_M	Mixto de 4 bits	Más pequeño	Aceptable	Valor predeterminado general, valor fuerte
Q3_K_M	Mezclado de 3 bits	Muy pequeño	Notable	Dispositivos de baja especificación, ejecutar primero
Q2_K	Mixto de 2 bits	Más pequeño	Significativo	Límites extremos de recursos, respaldo

Reglas de denominación de cuantificación

Tome gemma-4:4b-q4_k_m como ejemplo:

gemma-4:4b: nombre del modelo y escala de parámetros.
q4: cuantificación de 4 bits.
k: K-quants (un método de cuantificación mejorado).
m: nivel medio (las opciones comunes también incluyen s/small y l/large).

Selección rápida por VRAM

RAM/VRAM	Cuantización recomendada
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32GB+	FP16 / T8_0

Comience con una versión que se ejecute de manera estable en su máquina, luego avance con precisión paso a paso en lugar de saltar directamente al modelo más grande.

Consejos prácticos

Comience con Q4_K_M de forma predeterminada y pruebe primero las tareas reales.
Si la calidad de la respuesta no es suficiente, suba a Q5_K_M o Q8_0.
Si la VRAM o la velocidad son el principal cuello de botella, baje a Q3_K_M.
Utilice el mismo conjunto de prueba cada vez que cambie de formato de cuantificación.

Conclusión

Calidad primero: FP16 o Q8_0.
Saldo primero: Q5_K_M.
Valor predeterminado general: Q4_K_M.
Reserva de baja especificación: Q3_K_M o Q2_K.

La clave no es “cuanto más grande, mejor”, sino “el resultado más estable y utilizable bajo los límites de su hardware”.

Publicaciones relacionadas

Comparación y selección de modelos Gemma 4
Desinstalar completamente Ollama en Linux
Ruta de almacenamiento y migración del modelo Ollama
Cómo comprobar si Ollama usa GPU