Introduzca el token
Las indicaciones enviadas al modelo, las indicaciones del sistema y el historial de conversaciones se facturan según la tarifa unitaria de entrada.
Normas de facturación
Aquí no hay escalas de tarifas que haya que analizar caso por caso, ni recargos ocultos en las condiciones. La facturación se basa únicamente en dos aspectos: cuántos tokens se han utilizado en cada solicitud y cuál era la tarifa unitaria en el momento del consumo.
En una misma solicitud, las entradas, las aciertos en la caché, las salidas y los tokens de inferencia se contabilizan y se facturan por separado; así, los detalles de la factura pueden cotejarse partida por partida, sin que se mezclen las distintas unidades de precio en un total único.
Las indicaciones enviadas al modelo, las indicaciones del sistema y el historial de conversaciones se facturan según la tarifa unitaria de entrada.
En el caso de que la parte de la entrada coincida con la caché de prompts, se facturará según la tarifa unitaria más baja correspondiente a los aciertos en la caché.
El contenido de las respuestas generadas por el modelo se factura según la tarifa unitaria de salida, siendo la misma tanto para el modo en flujo continuo como para el modo no continuo.
Los tokens de reflexión generados por los modelos de razonamiento se contabilizan por separado según la unidad de precio de razonamiento, sin incluirlos en el precio de salida.
La unidad de precio es, de forma uniforme, USD / 1 millón de tokens. En el sistema de administración, la contabilidad se lleva a cabo en micro-USD en números enteros (1 USD = 1 000 000 micro-USD), y solo se convierte a decimales de dólares estadounidenses en la visualización de la página; de este modo, las facturas no acumulan desviaciones debido a errores de coma flotante.
El coste de esta operación se calcula multiplicando el consumo de cada tipo de token por la unidad de precio registrada en dicha solicitud y sumando los resultados. La unidad de precio procede de la lista de precios, mientras que el consumo se basa en las estadísticas reales de la pasarela; ninguno de ambos datos se calcula en la interfaz de usuario.
Coste = Tokens de entrada × Precio unitario de entrada + Tokens de caché × Precio unitario de caché + Tokens de salida × Precio unitario de salida + Tokens de inferencia × Precio unitario de inferencia
La unidad de precio es USD / 1 millón de tokens; el cálculo se realiza con números enteros en micro-USD y solo se convierte a decimales de dólar estadounidense en el momento de la visualización.
Ejemplo en tiempo real · El modelo con el precio de entrada más bajo del directorio actual
GPT-5.6 Luna Entrada 0.012 USD/1M × 1M + Salida 0.072 USD/1M × 1M = 0.084 USD
Se trata de una solicitud hipotética de «1 millón de tokens de entrada y 1 millón de tokens de salida», utilizada para ilustrar el método de cálculo; la factura real se calcula en función del número real de tokens de cada solicitud.
Estas normas se aplican tanto a las facturas de la consola como al consumo devuelto por la API; no existe una diferencia entre «las normas de la página» y «las del panel de control».
Cada solicitud se factura en función del consumo real de tokens: la entrada, las coincidencias en la caché, la salida y la inferencia se contabilizan por separado. No hay cuota mensual, ni consumo mínimo, ni cuota por inactividad.
El saldo de recarga no se pone a cero, no caduca mensualmente ni pierde validez por falta de uso prolongado; cada deducción se registra en el libro de cuentas y puede comprobarse partida por partida en la consola de facturación.
Cuando se produzca un consumo, anote el precio de venta vigente en ese momento en el registro correspondiente a dicho consumo. Los cambios de precio posteriores solo afectarán a las nuevas solicitudes; las facturas ya emitidas se interpretarán siempre según el precio vigente en el momento de su emisión.
No se cobrarán las solicitudes que no generen una respuesta de la capa superior, tales como errores de parámetros (400), errores de autenticación (401), saldo insuficiente (402), acceso denegado (403) o limitación de tráfico (429).
SSE ya ha comenzado a generar interrupciones en la fase posterior a la salida; solo se facturarán los tokens de entrada/salida realmente generados y se devolverá un error «upstream_stream_error», sin que se produzca una facturación duplicada.
Se admiten pagos mediante WeChat Pay, Alipay, tarjetas de crédito de UnionPay y transferencias bancarias entre empresas; tras la compra, podrá solicitar una factura de forma autónoma en la página de finanzas de la consola; los contratos y los trámites entre empresas se gestionan a través de la colaboración empresarial.
Comparta la misma respuesta con la página de selección de soluciones, para evitar discrepancias entre ambas. La respuesta debe escribirse directamente en el código HTML, de modo que se pueda leer sin necesidad de ejecutar JavaScript.
Facturación exclusivamente por consumo: la facturación se basa en el consumo real de tokens por cada solicitud, sin cuota mensual, sin suscripción obligatoria y sin consumo mínimo. El precio se expresa en dólares estadounidenses por cada millón de tokens, y la factura se calcula con precisión por cada solicitud.
No. El saldo recargado tiene validez indefinida; no se restablece a cero cada mes ni caduca por falta de uso durante un periodo prolongado.
Los tokens de entrada se facturan según la tarifa unitaria de entrada, mientras que los tokens de salida se facturan según la tarifa unitaria de salida; los tokens de entrada que se encuentran en la caché de prompts se facturan según la tarifa unitaria reducida por acierto en la caché. Estos tres conceptos se detallan por separado en el desglose de facturación de una misma solicitud.
Se admiten pagos a través de WeChat Pay, Alipay y tarjetas de crédito de UnionPay, así como transferencias bancarias entre empresas. Tras la compra, podrá solicitar una factura de forma autónoma en la página de finanzas de la consola.
Es posible que, cuando los proveedores de nivel superior modifiquen sus precios, realicemos ajustes simultáneos, que anunciaremos con antelación en la consola y en el registro de actualizaciones. El consumo ya generado se facturará según la instantánea de precios vigente en ese momento; las facturas anteriores no se modificarán como consecuencia de dichos ajustes.
No. Las solicitudes que no generen una salida en la capa superior, como los errores de parámetros (400), los errores de autenticación (401), los saldos insuficientes (402) o la limitación de flujo (429), no se facturarán; sin embargo, la parte de la respuesta en flujo que ya se haya generado se facturará según corresponda.
Los proyectos de bajo volumen de tráfico comienzan directamente con el plan de prueba, y el importe de la recarga tiene validez indefinida; para los contratos corporativos, las facturas y los canales exclusivos, se sigue el procedimiento de colaboración empresarial.