Cómo elegir gemini-4-carbon: guía de selección por tarea, contexto, intensidad de razonamiento y costo

Primero, definir con claridad el problema de selección

El error más común al seleccionar un modelo es tratar «qué modelo es más potente» como un problema de una sola variable. Las puntuaciones de los rankings, el número de parámetros y las afirmaciones promocionales son solo señales externas; lo que realmente determina el rendimiento de un modelo en tu sistema es en qué tarea se inserta, qué forma de salida produce y cuánto costo asume. Por eso, antes de abrir la documentación de cualquier modelo, conviene dejar escritas las tres condiciones previas siguientes.

Tipo de tarea: generar, extraer o juzgar

Las exigencias que distintas tareas imponen al modelo varían enormemente. La generación creativa valora la diversidad y la naturalidad del lenguaje; la extracción estructurada valora la estabilidad del formato y la fidelidad a entradas largas; las tareas de clasificación y juicio valoran más la consistencia, es decir, si la misma entrada, invocada varias veces, produce resultados predecibles. Solo clasificando la tarea en estas categorías sabrás qué medir con prioridad.

Forma de salida: qué puede consumir el sistema posterior

La forma de salida es una restricción dura, no una cuestión de preferencia. Si tu sistema posterior es un analizador, una escritura en base de datos o un componente de frontend, que el modelo pueda producir de forma estable una estructura de texto analizable importa mucho más que lo bien escrito que esté. La salida de esta interfaz es texto plano, y las restricciones de formato debes completarlas tú mismo en el prompt o en la capa de posprocesamiento; en el lado de entrada se admiten texto e imágenes, mientras que audio, video y PDF quedan fuera del alcance de soporte, por lo que los escenarios que involucren estas modalidades deben excluirse ya en la fase de selección o convertirse en una etapa previa.

Restricción de costo: costos estructurales más allá del precio unitario

En los modelos con precios por token, el costo no es un número, sino una función que varía con la estructura de la solicitud. La longitud de entrada, la longitud de salida, el número de reintentos y si se hacen varias rondas de reescritura cambian la factura final. Además, hay costos de ingeniería que se pasan por alto con facilidad: el trabajo de adaptación de prompts, el mantenimiento de los analizadores de salida y la construcción de evaluaciones de regresión. Si al puntuar la selección solo se comparan precios unitarios, es casi seguro que se tomará una decisión equivocada.

Escribe estas tres condiciones en un breve enunciado de requisitos; solo así todas las comparaciones horizontales posteriores tendrán una base de juicio común.

Convertir los requisitos en un marco puntuable

Una práctica útil es asignar un peso a cada una de las tres dimensiones y extraer por separado los elementos «obligatorios» para aplicarlos como veto único. Por ejemplo, la forma de salida suele ser un elemento de veto: si no se admite, no se puede usar, y no debería participar en la ponderación. La adecuación restante a la tarea y la sensibilidad al costo se distribuyen según la situación real del negocio. Así, aunque la información posterior sea incompleta, el equipo no derivará de un lado a otro en la discusión.

Los límites de capacidad de gemini-4-carbon y su forma de invocación

gemini-4-carbon se invoca mediante una interfaz compatible con Chat Completions, cuya dirección es https://api.hiapi.ai/v1/chat/completions, y admite salida en streaming. Cada modelo tiene dos rutas: la ruta estándar usa directamente el nombre del modelo, y la ruta de Vertex añade @vertex después del nombre del modelo (por ejemplo, gemini-4-carbon@vertex). La forma de invocación de ambas rutas es idéntica, pero los precios difieren; consúltese la tabla de precios más abajo.

En cuanto al posicionamiento, primero hay que distinguir tres variantes: Carbon es la variante más potente de la serie Gemini 4, orientada a las tareas de múltiples pasos y ciclos largos más complejas; gemini-4-argon es adecuado para la mayoría del trabajo de ingeniería de software y del trabajo del conocimiento, con un equilibrio entre capacidad y costo; gemini-3.8-flash es rápido y de bajo precio, adecuado para tareas de alta concurrencia y baja latencia.

Lo conocido: entrada de texto e imágenes, salida de texto plano

La entrada admite texto e imágenes, y la salida es texto, lo que significa que es apto para asumir tareas como conversación, resumen, reescritura, extracción, clasificación y generación de código. También significa que, si tu cadena de producto necesita que el modelo produzca directamente imágenes u otras modalidades, este camino no es viable en la forma actual, y habrá que diseñar una solución de composición en la capa externa o descartarlo directamente; el audio, el video y el PDF tampoco pueden usarse directamente como entrada, y deben convertirse a texto o imagen en una etapa previa.

Lo conocido: límites de contexto y de salida, con precios por token

El contexto es de 1.048.576 tokens y la salida máxima por invocación es de 65.536 tokens. Estas dos cifras determinan directamente la estrategia de segmentación: las entradas que superen el contexto deben recortarse o dividirse, y la parte de la salida que supere los 65.536 tokens debe dividirse en varias solicitudes en la capa de aplicación. La facturación por token implica que el costo varía con la longitud de entrada y de salida, y que la entrada, la entrada en caché y la salida se miden por separado.

Capacidades que se sabe no están admitidas: no diseñes como si lo estuvieran

Esta interfaz no admite actualmente llamadas a herramientas / function calling, búsqueda en internet ni computer use, ni tampoco salida estructurada / modo JSON. Estas capacidades deben implementarse por tu cuenta en la capa de aplicación: si necesitas datos externos, obtenlos tú mismo y añádelos al prompt; si necesitas un formato fijo, acuérdalo en el prompt y realiza validaciones tolerantes a errores en la capa de análisis; no supongas que la interfaz impondrá restricciones por ti.

Escribir los límites como una lista de restricciones

Se recomienda crear una ficha de capacidades en el documento de selección: rellenar uno por uno la ruta de la interfaz, las rutas de acceso, las modalidades de entrada y salida, el contexto y el límite de salida, los niveles de intensidad de razonamiento y los elementos no admitidos; las partes aún no cuantificadas, como el rendimiento multilingüe, se incluyen en la lista de verificación y se obtienen datos propios mediante pruebas reales a pequeña escala. Cualquier decisión de arquitectura que eluda estas restricciones debe señalar explícitamente su nivel de riesgo en la propuesta.

Comparación horizontal por requisitos de tarea, contexto, intensidad de razonamiento y costo

La clave de la comparación horizontal es establecer un conjunto de dimensiones estable, reutilizable y verificable por otros, en lugar de recopilar todos los datos. Los siguientes grupos de dimensiones cubren básicamente las necesidades de juicio en la selección de modelos de texto.

Dimensión uno: rendimiento en la tarea

Construye pequeños conjuntos de evaluación según los tipos de tarea que hayas definido, en lugar de puntuar con un conjunto genérico. En las tareas generativas, mide la tasa de utilidad y la preferencia humana; en las de extracción, la precisión de campos y la tasa de cumplimiento de formato; en las de juicio, la consistencia entre múltiples invocaciones. Cada dimensión debe tener criterios de decisión claros y un tamaño de muestra definido.

Dimensión dos: contexto, límite de salida e intensidad de razonamiento

Incluye el límite de longitud de contexto, el límite de salida por invocación, si se admite la devolución en streaming y si los niveles de intensidad de razonamiento pueden ajustarse a la distribución de dificultad de la tarea. El contexto de esta interfaz es de 1.048.576 tokens, la salida máxima por invocación es de 65.536 tokens y admite devolución en streaming; la intensidad de razonamiento se controla mediante reasoning_effort, con opciones low / medium / high. La salida estructurada no está dentro del alcance de soporte, por lo que las restricciones de formato deben gestionarse por tu cuenta en la capa de aplicación.

Dimensión tres: estructura de costos

Además de la relación proporcional del precio por token, hay que observar la diferencia entre los tres niveles de precio unitario —entrada, entrada en caché y salida— y el número de invocaciones necesarias para alcanzar la misma calidad. Un modelo que necesita varios reintentos para obtener una salida aceptable tiene un costo nominal bajo pero un costo real alto. Incluir la tasa de reintentos en el modelo de costos es imprescindible.

Dimensión cuatro: estabilidad y latencia

Incluye la distribución de latencia de cola larga, la tasa de tiempos de espera agotados y si los tipos de error son distinguibles. Mirar solo la latencia media tiene un valor limitado; son el P95 y el P99 los que determinan la experiencia del usuario.

Dimensión cinco: costo de migración y operación

Si los prompts existentes pueden reutilizarse, cuánto hay que cambiar los analizadores de salida, si es necesario reconstruir la línea base de evaluación y cómo integrar registros y monitoreo. Este punto suele pasarse por alto en las comparaciones a corto plazo, pero a menudo es donde, tras el cambio, el costo es más alto y surgen más problemas.

Dimensión seis: observabilidad

Si las solicitudes y respuestas pueden registrarse por completo, si el uso de tokens puede atribuirse a una línea de negocio concreta y si las anomalías pueden localizarse. La observabilidad determina si, una vez en producción, podrás descubrir los problemas.

Cómo usar esta lista

Puntúa cada modelo candidato en cada fila, establece los pesos según el negocio y conserva notas sobre el fundamento de las puntuaciones. El valor de la comparación horizontal reside en que el equipo comparta razones verificables sobre «por qué se elige este», no en obtener una clasificación absoluta. Cuando una celda carezca de información, márcala como pendiente de prueba real en lugar de rellenarla con un valor conjeturado.

Estimación del costo real con precios por token

La trampa intuitiva de la facturación por token es multiplicar el precio unitario por el número de solicitudes. El número así calculado suele estar muy lejos de la factura, porque ignora la estructura de la solicitud. La vía más fiable es de abajo hacia arriba, partiendo de una solicitud típica.

Primero, los precios unitarios (USD / millón de tokens, entrada / entrada en caché / salida):

• gemini-4-carbon ruta estándar 1.00 / 0.05 / 5.00; ruta @vertex 1.64 / 0.09 / 8.20
• gemini-4-argon ruta estándar 1.00 / 0.05 / 5.00; ruta @vertex 1.64 / 0.09 / 8.20
• gemini-3.8-flash ruta estándar 0.19 / 0.02 / 0.92; ruta @vertex 0.62 / 0.07 / 3.08

El precio unitario es solo el punto de partida; la estimación real debe basarse en la estructura de la solicitud.

Primer paso: desglosar la composición de tokens de una solicitud

Una invocación incluye tokens de entrada y tokens de salida, con precios unitarios distintos, y la entrada que acierta en caché tiene además un precio unitario propio. El lado de entrada incluye el prompt del sistema, el contexto, la entrada del usuario y los ejemplos; el lado de salida incluye el cuerpo de la respuesta y, si en el prompt se ha acordado un formato fijo, también deben contarse los caracteres de la estructura envolvente. Si mides una solicitud típica con esta estructura, descubrirás de inmediato que los costos fijos como el prompt del sistema representan una proporción muy alta en escenarios de alta frecuencia.

Segundo paso: multiplicar por el coeficiente de reintentos y regeneraciones

En el tráfico real, las solicitudes rara vez tienen éxito a la primera. Los reintentos por fallos de análisis, las regeneraciones por calidad insuficiente y la acumulación de contexto provocada por preguntas sucesivas amplifican el consumo de tokens. Calcular con registros reales la relación entre solicitudes efectivas y llamadas totales para obtener un coeficiente de amplificación es mucho más fiable que estimarlo a ojo.

Tercer paso: convertir a costo por cada mil solicitudes

Multiplica el número esperado de tokens por solicitud (incluido el coeficiente de amplificación) por el volumen de negocio para obtener el orden de magnitud del costo por cada mil solicitudes. El producto de este paso es una cifra comparable en las mismas unidades, útil para comparar horizontalmente entre modelos candidatos en lugar de intercambiar precios unitarios.

Cuarto paso: hacer un análisis de sensibilidad

Aumenta por separado la proporción de longitud de salida y la tasa de reintentos, y observa la pendiente de la curva de costo. Si el costo es extremadamente sensible a la longitud de salida, limitar la longitud de salida en el prompt y usar formatos más compactos aportará un beneficio muy directo. A la inversa, si domina el costo fijo de entrada, la optimización debe centrarse en recortar el contexto y simplificar los prompts fijos.

Errores de estimación habituales

Mirar solo el precio unitario, contar solo las solicitudes exitosas, ignorar la acumulación de contexto en varias rondas y extrapolar a producción las proporciones de una muestra pequeña de la fase de pruebas son los errores más comunes. La forma de evitarlos es sencilla: usar como parámetros la distribución real de longitudes del tráfico de producción, no unos cuantos ejemplos escritos a mano. Los precios unitarios figuran en la tabla anterior, y el modelo de estimación debe determinarlo tu propia estructura de solicitudes.

Recomendaciones de selección por escenario

Al llevar las dimensiones anteriores a escenarios concretos, el juicio se vuelve mucho más claro. Los tres tipos siguientes son las formas de carga más comunes de los modelos de texto, y los criterios de decisión se basan en indicadores medibles.

Tareas ligeras de alta concurrencia

Ejemplos típicos: reconocimiento de intenciones, clasificación de textos cortos, extracción de campos y reescritura breve. Estos escenarios tienen pocos tokens por solicitud, QPS alto y son sensibles a la latencia. El orden de prioridad en la selección es: si el P95 de latencia cumple el objetivo, si la tasa de cumplimiento de formato es estable y si el costo por solicitud es controlable. gemini-3.8-flash es la primera opción para este tipo de carga: es rápido y de bajo precio, con precios unitarios en la ruta estándar de 0.19 / 0.02 / 0.92; el nivel de intensidad de razonamiento debe elegirse según la evaluación de la tarea real; pero primero hay que validar la estabilidad del formato con tus entradas reales, especialmente cuando la salida vaya a ser analizada por un programa.

Procesamiento de textos largos

Ejemplos típicos: resumen de documentos, comparación de contratos y análisis de conversaciones largas. El contexto de esta interfaz es de 1.048.576 tokens y la salida máxima por invocación es de 65.536 tokens; la entrada solo admite texto e imágenes, y PDF, audio y video deben convertirse primero a texto antes de enviarse. Se recomienda hacer primero una prueba de esfuerzo con la entrada real más larga de tu negocio, confirmar la curva de degradación del rendimiento con distintas longitudes y decidir después si es necesario segmentar; si de verdad hace falta segmentar, el modelo de costos debe ajustarse en consecuencia, porque la segmentación introduce costos de contexto repetidos. Este tipo de carga suele caer dentro del ámbito de gemini-4-argon, que está más equilibrado entre capacidad y costo.

Escenarios donde prima la calidad

Ejemplos típicos: contenido generado para el usuario, razonamiento complejo y asistencia de escritura que requiere una alta tasa de utilidad. En estos escenarios la sensibilidad al costo por solicitud es baja, pero las exigencias de calidad y consistencia son altas. gemini-4-carbon es la variante más potente de la serie Gemini 4 y está orientada a las tareas de múltiples pasos y ciclos largos más complejas, por lo que es adecuada como modelo principal para este tipo de tráfico; el nivel de intensidad de razonamiento se elige igualmente según la evaluación de la tarea real. En la selección, el peso del conjunto de evaluación debe recaer más en la preferencia humana y en la consistencia entre múltiples invocaciones, y debe configurarse un plan de degradación: cuando el modelo principal no cumpla, degradar a gemini-4-argon o gemini-3.8-flash, o derivar a una persona. La coexistencia de varios modelos aumenta la complejidad operativa, pero en escenarios sensibles a la calidad suele valer la pena.

Principios generales de decisión

Decide según cuatro líneas: cuánto razonamiento profundo requiere la tarea —las tareas de múltiples pasos y ciclos largos priorizan Carbon, la ingeniería de software y el trabajo del conocimiento habituales usan Argon, y las tareas ligeras de alta concurrencia usan Flash—; si la entrada cae dentro del contexto y de las modalidades admitidas —si es muy larga, segmentar primero; si no es texto, convertir primero—; si el nivel de intensidad de razonamiento se ajusta a la dificultad de la tarea; y si el costo por solicitud está dentro del presupuesto. No sacrifiques la adecuación al escenario por unificar el stack tecnológico, ni fuerces el tráfico sensible a la calidad hacia un modelo inadecuado para ahorrar costos.

Consideraciones de migración e integración

Al pasar de un modelo existente a gemini-4-carbon, o al construir directamente nuevos escenarios sobre él, el trabajo de ingeniería se concentra en tres puntos. Desglosarlos y planificarlos con antelación evita los problemas concentrados antes del lanzamiento.

Reescritura de prompts

Distintos modelos tienen distinta sensibilidad a la estructura del prompt, al orden de las instrucciones y a los ejemplos de formato. Un prompt optimizado para otro modelo suele perder eficacia si se migra tal cual. Se recomienda conservar un prompt base independiente del modelo y mantener, para cada modelo, una capa de adaptación ligera donde se coloquen las convenciones de formato y los ejemplos. Así, cuando vuelvas a cambiar de modelo, el alcance de los cambios será controlable.

Análisis de salida

La salida en texto plano implica que el analizador debe tener expectativas claras sobre el formato. Una práctica habitual es acordar la estructura en el prompt y aplicar tolerancia a errores en la capa de análisis: campos faltantes, caracteres envolventes de más y devoluciones vacías deben tener ramas de tratamiento explícitas. Si el análisis falla, debe registrarse la respuesta original para poder atribuir la causa, en lugar de reintentar en silencio: los reintentos silenciosos ocultan problemas y amplifican el costo.

Evaluación de regresión

Establecer una línea base de evaluación antes de cambiar de modelo es un paso necesario. El método consiste en fijar un conjunto de evaluación que cubra tus principales tipos de tarea y entradas límite (muy largas, vacías, multilingües, con caracteres especiales), registrar las salidas e indicadores del modelo actual y ejecutar después el nuevo modelo sobre el mismo conjunto para comparar punto por punto. Cualquier caída de un indicador debe explicarse, no despacharse con un «en general parece mejor».

Forma de integración

Al integrar, usa la interfaz compatible con Chat Completions, con base_url https://api.hiapi.ai/v1, y pasa el nombre del modelo como parámetro en lugar de codificar a fuego las diferencias de invocación en el código; así, cambiar, aplicar despliegue gradual y revertir solo requiere modificar la configuración. La ruta también se expresa mediante el nombre del modelo: la ruta estándar usa directamente el nombre del modelo y la ruta de Vertex añade @vertex después del nombre. Se recomienda encapsular de forma unificada los reintentos, los tiempos de espera y los registros en la capa de solicitudes, para evitar que cada equipo de negocio escriba su propia versión.

POST https://api.hiapi.ai/v1/chat/completions
{
  "model": "gemini-4-carbon",
  "messages": [{"role": "user", "content": "Resume los límites de entrada de este documento de diseño que aparece a continuación"}],
  "reasoning_effort": "high",
  "stream": true
}

Al cambiar model por gemini-4-carbon@vertex se usa la ruta de Vertex, y el resto del cuerpo de la solicitud no cambia.

Despliegue gradual y orden de validación

Primero valida en el conjunto de evaluación offline, después haz una comparación en la sombra con un porcentaje pequeño de tráfico real y, solo al final, aumenta el volumen de forma gradual. Cada etapa debe tener criterios de aprobación claros, por ejemplo, una tasa de cumplimiento de formato no inferior a la línea base, un P95 de latencia dentro del presupuesto y un costo por solicitud sin aumentos anómalos.

Observación continua y estrategia de reversión tras el lanzamiento

La selección no es una decisión única. El rendimiento del modelo cambia con la deriva de la distribución de entradas y con la evolución de los prompts, y la observación posterior al lanzamiento determina si puedes descubrir y corregir las desviaciones a tiempo.

La proporción de derivación de tráfico debe ser controlable

El despliegue gradual no es una acción puntual, sino una capacidad permanente. Mantén la capacidad de derivar tráfico por línea de negocio y por grupos de usuarios, para que revertir sea un cambio de configuración y no un despliegue. La proporción de derivación, el ámbito de aplicación y la ruta de reversión deben constar en la documentación, de modo que personas distintas de los autores originales también puedan operar.

Los indicadores de calidad deben automatizarse

No dependas de muestreos manuales para detectar caídas de calidad. Convierte la tasa de cumplimiento de formato, la tasa de fallos de análisis, la tasa de devoluciones vacías y la tasa de tiempos de espera agotados en indicadores de alerta automática, y prepara para las tareas generativas una puntuación automática a pequeña escala o una revisión humana por muestreo. Cuando se active un umbral de indicador, debe poder degradarse el tráfico automáticamente.

El monitoreo de costos debe permitir atribuir

El consumo de tokens debe poder desglosarse por línea de negocio, por interfaz y por modelo. De lo contrario, si una función encarece sus costos sin avisar, solo verás una cifra en la factura total y no podrás localizarla. Configurar alertas de anomalías en el uso diario es mucho más eficaz que cuadrar cuentas a fin de mes.

Crear una lista de reversión

Revertir no termina con volver a derivar el tráfico. Después de revertir hay que confirmar: si los prompts antiguos siguen siendo válidos, si el analizador es compatible con ambos formatos, si es necesario limpiar la caché y si los indicadores de monitoreo vuelven a la línea base. Escribe estos pasos como una lista para no improvisar bajo presión.

Volver a ejecutar la evaluación periódicamente

Se recomienda volver a ejecutar con la misma periodicidad el mismo conjunto de evaluación y registrar la tendencia del rendimiento y del costo de los modelos. Cuando el cambio acumulado supere un umbral, recorre de nuevo el proceso de selección. El conjunto de evaluación y los scripts utilizados deben gestionarse con versiones junto al código, para garantizar que todos usen la misma vara de medir.