API on KnightLi Blog

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

Qué son los modelos en la nube de Ollama y cómo usarlos

Thu, 09 Apr 2026 18:42:32 +0800

Si usas normalmente Ollama para ejecutar modelos locales, entender los modelos en la nube será sencillo.

La diferencia central es solo una:
los modelos locales hacen inferencia en tu ordenador; los modelos en la nube hacen inferencia en la nube de Ollama y devuelven el resultado.

Qué es un modelo en la nube

Los modelos en la nube de Ollama conservan la forma de llamada de Ollama, pero cambian la ubicación del cálculo de local a la nube.

Las ventajas son:

Menor presión sobre el hardware local
Más fácil usar modelos grandes que tu máquina local no puede mover
Se mantiene el flujo de trabajo familiar de Ollama

Diferencia frente a modelos locales

Comparación	Modelo local	Modelo en la nube
Ubicación de ejecución	Máquina local	Nube
Requisitos de hardware	Altos	Bajos
Latencia	Más baja	Depende de la red
Privacidad	Más fuerte	La solicitud se envía a la nube

Si te importa más la privacidad, baja latencia y uso offline, el modelo local es más adecuado.
Si tu hardware local no alcanza pero quieres probar modelos más grandes, el modelo en la nube es más cómodo.

Cómo reconocer modelos en la nube

Actualmente, los modelos en la nube de Ollama suelen llevar el sufijo -cloud, por ejemplo:

`1`	`gpt-oss:120b-cloud`

La lista de modelos disponibles puede cambiar; toma la página oficial de Ollama como referencia final.

Cómo usarlos

Primero inicia sesión:

`1`	`ollama signin`

Después ejecuta directamente el modelo en la nube:

`1`	`ollama run gpt-oss:120b-cloud`

Si lo llamas desde código, también puedes configurar API Key:

`1`	`export OLLAMA_API_KEY=your_api_key`

Ejemplo en Python:

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

messages = [
    {"role": "user", "content": "为什么天空是蓝色的？"}
]

for part in client.chat("gpt-oss:120b-cloud", messages=messages, stream=True):
    print(part["message"]["content"], end="", flush=True)

Resumen

Los modelos en la nube de Ollama pueden entenderse en una frase:

el comando casi no cambia; solo que el modelo ya no corre en tu máquina local.

Si tu ordenador no puede mover modelos grandes pero quieres seguir llamando modelos al estilo Ollama, los modelos en la nube son una opción directa.