Tokens y facturación de la API de LLM: estimación, lectura, presupuesto y ejemplos

Qué son los tokens y cómo se cobran

Un token es la unidad mínima de procesamiento de texto del modelo; no es un carácter ni una palabra, sino un "fragmento" intermedio. Piensa en él como las marcas de un medidor de agua: cuanto más usas, más rápido avanza. La facturación se divide en dos partes:

El precio de salida es 4 veces el de entrada; decir al modelo que sea conciso suele ahorrar más que reducir el contexto, aunque la historia crece. Usa saldo prepago, no suscripción; el saldo no caduca. Nuevas cuentas tienen $0.50 de prueba válidos por 7 días.

Un punto confuso común: los tokens de salida son los generados realmente, no tu max_tokens. max_tokens es solo un límite; si el modelo responde en 200 caracteres, solo se cobran esos tokens. Pero para presupuestar, calcula con el límite para cubrir el peor caso y evitar sorpresas con respuestas largas.

Estimación previa: cómo estimar chino e inglés

Sin enviar la petición, solo puedes estimar. Los siguientes son valores aproximados y pueden variar según el contenido:

El uso correcto de la estimación es juzgar el orden de magnitud: ¿este texto son 10.000 o 100.000 tokens? ¿Excede la ventana de contexto de 100.000? ¿Cuánto cuesta una llamada? Para precisión, lee usage. Una buena práctica es muestrear decenas de ejecuciones por escenario y promediar usage para reemplazar valores empíricos.

Ejemplo combinando estimación y medición real. Supón que procesas 2000 caracteres de comentarios en chino. Estimando 1,3 tokens/carácter, un mensaje son ≈2600 tokens. Con 200 tokens de instrucción, la entrada es ≈2800. Ejecuta 30 mensajes, lee usage y promedia. Si el promedio real es 2500, ajusta tu coeficiente a ≈1,15. Luego presupuesta el lote completo con este coeficiente ajustado para reducir el error. Este dato es solo una demostración; tus datos tendrán sus propios valores.

Leer usage: la verdadera "lectura del medidor"

Cada respuesta exitosa incluye usage con prompt_tokens, completion_tokens y total_tokens. En streaming no necesitas parámetros extra; el último bloque incluye usage automáticamente. El siguiente código muestra ambas formas de leer y convierte a dólares:

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

En streaming, ten cuidado: solo el último bloque tiene usage; los anteriores están vacíos. Usa if chunk.usage para verificar. Registra cada lectura en logs o base de datos para conciliación mensual, detección de anomalías y cálculo de costo por usuario.

Otra buena práctica: etiqueta cada función de negocio al registrar el gasto. Por ejemplo, registra "resumen", "soporte" y "traducción" por separado. Al final del mes, verás qué función cuesta más y si debes optimizar el prompt, recortar el historial o bajar max_tokens. Sin etiquetas, solo tienes un total y es difícil optimizar.

Tres ejemplos (con las suposiciones indicadas)

Ejemplo 1: preguntas y respuestas de atención al cliente

Suposición: cada petición tiene 800 tokens de entrada (incluyendo system y fragmentos de conocimiento) y 200 tokens de salida; 10.000 peticiones al día.

Coste por petición: 800 × 0,25 ÷ 1.000.000 = $0,0002; salida 200 × 1,00 ÷ 1.000.000 = $0,0002; total $0,0004. $4,00 al día, $120 en 30 días. Con esta velocidad, un crédito de prueba de $0,50 puede soportar unas 1.250 llamadas de este tipo.

Ejemplo 2: resumen de artículos largos

Suposición: cada artículo tiene 20.000 tokens de entrada y 600 tokens de salida para el resumen; un total de 500 artículos.

Por artículo: 20.000 × 0,25 ÷ 1.000.000 = $0,005; más 600 × 1,00 ÷ 1.000.000 = $0,0006; total $0,0056. 500 artículos cuestan $2,80 en total. Se ve que las tareas con entradas largas y salidas cortas son muy económicas.

Ejemplo 3: chat multironda y recorte de historial

Suposición: system 100 tokens; entrada del usuario 60 tokens por ronda, respuesta 150 tokens; una conversación de 20 rondas.

La entrada del plan de historial completo es: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3,200 + 39,900 = 43,100. Las tres primeras rondas del plan de recorte son 160, 370 y 580 respectivamente; de la ronda 4 a la 20, cada ronda cuesta 790, lo que suma 14,540. El costo difiere aproximadamente a la mitad, y la diferencia es mayor a medida que aumentan las rondas, porque la entrada del plan de historial completo crece cuadráticamente con el número de rondas.

De estos tres ejemplos se puede extraer una fórmula empírica: el coste lo determina principalmente el «número de peticiones × la cantidad de entrada y salida por petición», y dentro de la entrada, el historial y los materiales adjuntos son lo que más se puede ajustar. En atención al cliente, reducir la longitud de los fragmentos de conocimiento; en chat, recortar el historial; en resúmenes, dividir en bloques y hacer peticiones simultáneas. Todos siguen la misma lógica: no pagues tokens de más. Cabe destacar que las cifras de estos ejemplos provienen de las suposiciones indicadas arriba; tus datos reales deben basarse en el usage.

Observa otro cálculo inverso: si tu presupuesto mensual es de $30 y quieres saber cuántas conversaciones de 20 rondas puede soportar tu producto de chat mensualmente. Según el plan del ejemplo 3 "solo con las últimas 3 rondas", cada conversación cuesta aproximadamente $0.0066, por lo que $30 ÷ 0.0066 da aproximadamente 4545 conversaciones. Con el mismo presupuesto, si usas el plan de historial completo, cada conversación cuesta $0.0138, lo que alcanza solo para aproximadamente 2174 conversaciones. Esta es la diferencia práctica que trae el recorte del historial.

Control del presupuesto: ponle una válvula a tu programa

La estimación es solo una predicción; el límite es la garantía. Ejemplo de presupuesto diario en USD: usa el "peor caso" (salida en max_tokens) antes de pedir y el usage real después para llevar la contabilidad.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

Además de la válvula en el programa, hay tres medidas a nivel de configuración:

1. max_tokens según la tarea, no lo pongas siempre al máximo; por defecto 2048, máximo 32.000;
2. Limita la historia de chat; miracómo construir un chatbot para ver cómo hacerlo.
3. recarga solo la cantidad que planeas usar en la cuenta; cuando se agote, recarga de nuevo. El modelo prepago es naturalmente un límite duro.

El precio unitario y las reglas del saldo se rigen porla página de precios; los detalles de la interfaz están enexplicación de parámetros.

Resumen en checklist: antes, estima magnitud, fija max_tokens y revisa historial; durante, vigila usage en streaming; después, lleva contabilidad por función y compara presupuesto. Así se aclara la cuenta.