Implementación de rendimiento aprovisionado PTU

​

Visión general

• Servicio al cliente inteligente para aplicaciones bancarias (tráfico estable, requiere experiencia concurrente garantizada).
• Moderación de contenido en tiempo real para plataformas sociales (requiere procesamiento estable de tareas de canalización predecibles).
• API de traducción en la nube pública (proporciona garantías de servicio base para usuarios de paquetes estándar).

​

Reglas de facturación

• Los pedidos prepago entran en vigor en tiempo real después del pago, con un período de validez de N días que finaliza a las 23:59 del día N. Si el pedido se realiza después de las 22:00, la fecha de vencimiento se extenderá automáticamente por 1 día.
• Después de que expire un pedido prepago, el servicio se detendrá con un retraso de 2 horas, y los recursos se conservarán durante 14 horas después de la detención y luego se liberarán.
• Los pedidos de prepago admiten terminación anticipada; la parte utilizada se liquida con un coeficiente de 1.2x para reembolso. Para más detalles, consulte Reglas de reembolso por reducción de configuración.
• Para la facturación pospago, si la cuenta tiene saldos pendientes, los recursos implementados seguirán retenidos y facturándose durante 24 horas, tiempo durante el cual el servicio aún podrá utilizarse con normalidad. Después de 24 horas, el sistema detiene la facturación, la implementación del modelo entra en estado de saldo pendiente y los recursos subyacentes se eliminarán, pero la tarea de implementación del modelo se conservará. Una vez pagados los saldos pendientes, el sistema reasignará los recursos y restaurará el uso (las tarifas continuarán acumulándose después de la restauración). Si no desea seguir incurriendo en tarifas, puede eliminar la tarea de implementación del modelo y la facturación se detendrá tras la eliminación exitosa.

• En este caso (solo bajo la estrategia de "desbordamiento automático"), el encabezado de respuesta de la API incluirá: x-dashscope-ptu-overflow:true.
• Para estadísticas de TPM, vaya a: Monitoreo de modelos.

​

Modelos admitidos y precios

​

Entrada larga y caché de prefijos

​

Ejemplos de cálculo (usando glm-5.1)

Escenario 1: Entrada corta (10K tokens, sin caché)
  Consumo de entrada: 10K × 1.0 = 10KTPM

Escenario 2: Entrada larga (50K tokens, sin caché)
  Consumo de entrada: 32K × 1.0 + 18K × 1.33 = 55.94 KTPM
  Consumo de salida (asumiendo 1K tokens): 1K × 1.17 = 1.17 KTPM

Escenario 3: Entrada larga + acierto de caché (50K tokens, los primeros 30K aciertan en la caché)
  Entrada en caché (primeros 30K, dentro del escalón [0,32K)):
    30K × 1.0 × 0.2 = 6  KTPM
  Entrada no almacenada en caché (últimos 20K):
    2K × 1.0 + 18K × 1.33 = 25.94 KTPM
  Entrada total = 31.940 KTPM (43% de ahorro en comparación con sin caché)

​

Calculadora de cuotas de rendimiento aprovisionado

​

Campos de respuesta de API

​

Monitoreo y verificación

• Utilización de PTU: Tres curvas independientes para entrada, salida y salida en modo de pensamiento. En escenarios de entrada larga, los coeficientes escalonados pueden causar que la utilización supere el 100%. Este es un comportamiento esperado.
• Uso de tokens y aciertos de caché: Incluye la serie de datos cached_tokens para mostrar la proporción de aciertos de caché en relación con la entrada total.
• Recuentos de llamadas dentro y fuera de la cuota: Muestra la proporción de solicitudes que exceden la cuota PTU (bajo la estrategia de desbordamiento automático, las solicitudes pasan a la facturación de pago por uso; bajo la estrategia de usar-solo-capacidad-PTU, se devuelven errores 429).

​

Escalado

​

FAQ