Este documento describe cómo llamar al servicio de inferencia del modelo Kimi implementado en Alibaba Cloud Model Studio.
kimi-k3.1-pro admite OpenAI Chat Completions, OpenAI Responses, Anthropic Messages y la API nativa de DashScope.
Los endpoints de servicio son específicos de la región. Configure la URL base correcta para su región.
- Compatible con OpenAI
- DashScope
- Compatible con Anthropic
base_url que se indican a continuación también se aplican a las llamadas a OpenAI Responses; para las solicitudes HTTP, agregue /responses al base_url, como en POST {base_url}/responses.- EE. UU. (Virginia)
- Germany (Frankfurt)
- Singapore
- Japan (Tokyo)
- China (Beijing)
- China (Hong Kong)
base_url para llamadas SDK es: https://{WorkspaceId}.us-east-1.maas.aliyuncs.com/compatible-mode/v1URL de solicitud HTTP: POST https://{WorkspaceId}.us-east-1.maas.aliyuncs.com/compatible-mode/v1/chat/completions{WorkspaceId} con su ID de espacio de trabajo real.
Requisitos previos: Debe obtener una clave API y configurarla como variable de entorno. Si usa el SDK, debe instalar el SDK.
Primeros pasos
Los siguientes ejemplos usan entrada de solo texto. Para ejemplos multimodales, consulte llamada multimodal.
- Compatible con OpenAI
- DashScope
- Compatible con Anthropic
- Python
- Node.js
- HTTP
Respuesta
Llamadas multimodales
Los modelos kimi-k3.1-pro, kimi-k3, kimi-k2.7-code, kimi-k2.6 y kimi-k2.5 admiten entrada multimodal y salida de texto. kimi-k3.1-pro y kimi-k3 solo admiten entrada de texto e imagen, no entrada de video; kimi-k2.7-code, kimi-k2.6 y kimi-k2.5 pueden procesar simultáneamente texto, imágenes o video. Use el parámetro enable_thinking para habilitar el modo de pensamiento. Los siguientes ejemplos muestran cómo usar esta capacidad.
Habilitar o deshabilitar el modo de pensamiento
kimi-k2.6 y kimi-k2.5 son modelos de pensamiento híbrido. Estos modelos pueden responder después de pensar o responder directamente. Puede usar el parámetro enable_thinking para controlar si se habilita el modo de pensamiento:
true: Habilitar el modo de pensamientofalse(predeterminado): Deshabilita el modo de pensamiento
enable_thinking=true). Puede establecerlo en false para deshabilitar el pensamiento, pero se recomienda mantenerlo habilitado. En kimi-k3.1-pro, deshabilitar el pensamiento degrada significativamente la calidad de la salida, por lo que se recomienda encarecidamente mantenerlo habilitado. Ambos modelos conservan de forma predeterminada el reasoning_content histórico proporcionado por el cliente. Se recomienda reenviar el reasoning_content completo de los mensajes históricos del asistente en solicitudes de múltiples turnos.
kimi-k2.7-code es un modelo de solo pensamiento: el modo de pensamiento siempre está habilitado (enable_thinking tiene como valor predeterminado true y no se puede deshabilitar), y preserve_thinking tiene como valor predeterminado true.
kimi-k2.6 admite pasar el proceso de pensamiento en conversaciones de múltiples turnos usando el parámetro preserve_thinking. Para más información, consulte Pasar el proceso de pensamiento.
Los siguientes ejemplos muestran cómo usar una URL de imagen y habilitar el modo de pensamiento. El ejemplo principal demuestra la entrada de una sola imagen, mientras que el código comentado es un ejemplo de entrada de múltiples imágenes.
- Compatible con OpenAI
- DashScope
Comprensión de video
- Archivo de video
- Lista de imágenes
-
fps: Controla la frecuencia de extracción de fotogramas. El intervalo entre fotogramas extraídos es de
1/fpssegundos. El valor debe estar en el rango de [0.1, 10]. El valor predeterminado es 2.0.- Para escenas con mucho movimiento: Establezca un valor de fps más alto para capturar más detalles.
- Para videos estáticos o largos: Establezca un valor de fps más bajo para mejorar la eficiencia del procesamiento.
- max_frames: Especifica el número máximo de fotogramas a extraer de un video. El valor predeterminado y máximo es 2000. Si el número de fotogramas calculado a partir del valor de fps excede este límite, el sistema extrae automáticamente fotogramas uniformemente para mantenerse dentro del límite de max_frames. Este parámetro está disponible solo cuando usa el SDK de DashScope.
- Compatible con OpenAI
- DashScope
Al pasar un archivo de video al modelo usando el SDK de OpenAI o una solicitud HTTP, establezca el parámetro"type"en el mensaje de usuario en"video_url".
Pasar un archivo local
Los siguientes ejemplos muestran cómo pasar un archivo local. La API compatible con OpenAI solo admite codificación Base64, mientras que DashScope admite tanto codificación Base64 como rutas de archivo.
- Compatible con OpenAI
- DashScope
Limitaciones de archivos
- Limitaciones de imagen
- Limitaciones de video
-
Resolución de imagen:
- Tamaño mínimo: El ancho y el alto deben exceder cada uno
10píxeles. - Relación de aspecto: La relación entre el lado más largo y el más corto no debe exceder
200:1. - Resolución máxima: El máximo recomendado es
8K(7680x4320). Resoluciones más altas pueden causar tiempos de espera en llamadas a la API debido a tamaños de archivo grandes o transferencias de red lentas.
- Tamaño mínimo: El ancho y el alto deben exceder cada uno
-
Formatos de imagen compatibles
-
Los siguientes formatos son compatibles para resoluciones inferiores a 4K
(3840x2160):Formato de imagen
Extensión de archivo
Tipo MIME
BMP
.bmp
image/bmp
JPEG
.jpe, .jpeg, .jpg
image/jpeg
PNG
.png
image/png
TIFF
.tif, .tiff
image/tiff
WEBP
.webp
image/webp
HEIC
.heic
image/heic
-
Para resoluciones entre
4K(3840x2160)y8K(7680x4320), solo se admiten JPEG, JPG y PNG.
-
Los siguientes formatos son compatibles para resoluciones inferiores a 4K
-
Tamaño de imagen:
- Al proporcionar una imagen mediante una URL pública o ruta local, su tamaño no debe exceder
10 MB. - Al usar la codificación Base64, la cadena codificada no debe exceder
10 MB.
Para comprimir un archivo, consulte Cómo comprimir una imagen o video para cumplir con el límite de tamaño.
- Al proporcionar una imagen mediante una URL pública o ruta local, su tamaño no debe exceder
- Número de imágenes admitidas: Al proporcionar múltiples imágenes, el número total de tokens para todas las imágenes y texto no debe exceder el límite máximo de entrada del modelo.
Otras funciones
Modelo | |||||||
|---|---|---|---|---|---|---|---|
kimi-k3.1-pro | Compatible | Compatible | Compatible | Compatible (JSON Mode) | Compatible | No compatible | Compatible (caché implícita) |
kimi-k3 | Compatible | Compatible | Compatible | Compatible | Compatible (Responses API) | Compatible | Compatible |
kimi-k2.7-code | Compatible | Compatible | Compatible | No compatible | No compatible | No compatible | Compatible |
kimi-k2.6 | Compatible | Compatible | Compatible | No compatible | No compatible | No compatible | Compatible |
kimi-k2.5 | Compatible | Compatible | Compatible | No compatible | No compatible | No compatible | Compatible |
Herramientas cargadas dinámicamente
Cuando una aplicación necesita montar una gran cantidad de herramientas, colocar todas las declaraciones de herramientas en el campo tools de nivel superior de la solicitud a la vez provoca una Inflación de Definiciones de Herramientas: cada solicitud debe llevar la descripción y el esquema de parámetros de todas las herramientas, lo que aumenta el consumo de tokens; y cuantas más herramientas candidatas haya, mayor será la probabilidad de que el modelo elija la herramienta incorrecta y construya argumentos de llamada erróneos.
Las Herramientas Cargadas Dinámicamente le permiten inyectar herramientas bajo demanda durante una conversación: monte primero solo unas pocas herramientas principales y, cuando la conversación llegue a un punto donde se necesite una herramienta específica, insértela dinámicamente en messages, reduciendo así el consumo de tokens y mejorando la precisión en la selección de herramientas.
tokenization failed.El formato y los ejemplos de esta sección para inyectar herramientas en messages mediante el campo tools de un mensaje system (system.tools) se aplican a la API de OpenAI Chat Completions.Inyectar declaraciones de herramientas en mensajes
Inserte un mensaje con role establecido en system en messages y declare las herramientas que se cargarán mediante el campo tools de dicho mensaje. El formato es idéntico al del campo tools de nivel superior de la solicitud, y debe proporcionar la información completa de la herramienta (name, description, parameters).
- Un mensaje
systemque llevatoolstiene el mismo estado que un mensaje ordinario: las herramientas se vuelven visibles para el modelo a partir de la posición donde aparece ese mensaje en la listamessages. - Las herramientas cargadas dinámicamente coexisten con las herramientas globales declaradas en el campo
toolsde nivel superior de la solicitud; el modelo puede ver ambos tipos de herramientas al mismo tiempo. - Una declaración de herramienta inyectada dinámicamente debe ser una definición completa de herramienta; no puede pasar solo un nombre de herramienta ni hacer referencia a una herramienta declarada globalmente.
- Un mensaje
systemque llevatoolsno debe llevar también un campocontent, de lo contrario la solicitud fallará con un error 400. Al usar el SDK de OpenAI, puede pasar el campotoolsdirectamente enmessages.
Carga bajo demanda combinada con una herramienta de búsqueda
No hay una API dedicada de búsqueda de herramientas. Cuando hay muchas herramientas, puede combinar una herramienta de búsqueda personalizada con herramientas cargadas dinámicamente para cargar herramientas bajo demanda:
- Al inicio de la sesión, declare en el nivel superior de
toolssolo una herramientasearch_toolsimplementada por el backend de su aplicación (devuelve nombres de herramientas coincidentes y resúmenes por palabra clave), además de algunas herramientas principales que pueden usarse en cada turno. - Declare las palabras clave buscables (como un catálogo de herramientas o etiquetas de dominio) en el prompt del sistema para guiar al modelo a llamar primero a
search_toolscuando necesite una herramienta. Establecertool_choice: "required"en la primera solicitud garantiza al menos una llamada a herramienta, pero no garantiza que se llame primero asearch_tools. Si es obligatorio buscar primero, establezca explícitamentetool_choice: {"type": "function", "function": {"name": "search_tools"}}y luego restauretool_choicea"auto"después de la búsqueda. Cambiartool_choiceno rompe la caché de prefijos. - Basándose en los resultados devueltos por
search_tools, la aplicación inserta dinámicamente las declaraciones completas de las herramientas correspondientes enmessagesmediante un mensajesystemque llevatools. - El modelo puede entonces llamar a estas herramientas recién cargadas directamente en la generación subsiguiente.
Notas
- Las declaraciones de herramientas dinámicas surten efecto por solicitud y no son recordadas por el servidor. Si se siguen incluyendo en la siguiente solicitud depende del integrador: si se siguen incluyendo, las herramientas permanecen disponibles (lo que también ayuda a acertar en la caché de prefijos); si se deja de incluirlas, la declaración caduca; si la herramienta no se declara en otro lugar, el modelo no puede llamarla y la caché de prefijos después del punto de cambio podría fallar.
- Agregar una declaración de herramienta dinámica al final de
messagesno afecta la caché del prefijo existente; eliminar o modificar declaraciones de herramientas anteriores puede afectar los aciertos de caché después del punto de cambio. Declarar herramientas globales en el campotoolsde nivel superior de la solicitud tampoco afecta los aciertos de caché. - Un mensaje
systemque llevatoolstambién consume longitud de contexto, así que inyecte solo las herramientas realmente necesarias para la conversación actual. - Las declaraciones de herramientas dinámicas usan exactamente el mismo formato que las declaraciones globales de
tools, por lo que los integradores no necesitan mantener dos esquemas.
Parámetros predeterminados
Modelo | enable_thinking | temperature | top_p | presence_penalty | fps | max_frames |
|---|---|---|---|---|---|---|
kimi-k3.1-pro | true (se puede deshabilitar; se recomienda encarecidamente mantenerlo habilitado) | 1.0 | 0.95 | 0.0 | - | - |
kimi-k3 | true (se puede deshabilitar; se recomienda mantenerlo habilitado) | 1.0 | 0.95 | 0.0 | - | - |
kimi-k2.7-code | true (solo modo de pensamiento) | 1.0 | 0.95 | 0.0 | 2 | 2000 |
kimi-k2.6 | false | modo de pensamiento: 1.0 modo sin pensamiento: 0.6 | Ambos modos: 0.95 | Ambos modos: 0.0 | 2 | 2000 |
kimi-k2.5 | false | modo de pensamiento: 1.0 modo sin pensamiento: 0.6 | Ambos modos: 0.95 | Ambos modos: 0.0 | 2 | 2000 |
temperature=1.0, top_p=0.95 y presence_penalty=0.0. Si pasa un valor distinto del predeterminado en cualquiera de estos parámetros, se devuelve un error.
Los siguientes niveles de esfuerzo de razonamiento se aplican solo a kimi-k3.1-pro, con max como valor predeterminado:
max(predeterminado): razonamiento profundohigh: razonamiento mejoradomedium: razonamiento moderadolow: razonamiento ligero
- OpenAI Chat Completions: use el campo
reasoning_effortde nivel superior. Con el SDK de OpenAI para Python, pasereasoning_effort="max"directamente. - DashScope: use el parámetro
reasoning_effortdel SDK oparameters.reasoning_efforten las solicitudes HTTP. - OpenAI Responses: use
reasoning.effort. - Anthropic Messages: use
output_config.effort.
Modelos y facturación
La serie Kimi consiste en modelos de lenguaje grande de Moonshot AI.
- kimi-k3.1-pro: Admite entrada de texto e imagen, salida de texto y carga dinámica de herramientas. No admite entrada de video, Batch ni ajuste fino.
- kimi-k3: Un modelo insignia de Kimi. Razona y usa pensamiento preservado de forma predeterminada. Admite entrada de texto e imagen (no se admite entrada de video), tareas de conversación y de agente, y carga dinámica de herramientas.
- kimi-k2.7-code: Un modelo Kimi para programación. Sigue instrucciones de contexto largo de manera más confiable y logra mayores tasas de éxito en tareas de programación. Admite entrada de texto, imagen y video, modo de pensamiento, conversación y tareas de agente.
- kimi-k2.6: Un modelo de la serie Kimi con rendimiento mejorado en programación de largo alcance, seguimiento de instrucciones y autocorrección. Admite entrada de texto, imagen y video, modos de pensamiento y sin pensamiento, conversación y tareas de agente.
- kimi-k2.5: Logra un rendimiento de vanguardia (SOTA) en benchmarks de código abierto para tareas de agente, generación de código, comprensión visual y otras tareas de inteligencia general. Admite entrada de imagen, video y texto, modos de pensamiento y sin pensamiento, conversación y tareas de agente.
thinking_budget. No puede usar este parámetro para limitar la longitud del pensamiento.Para precios, consulte facturación de invocación de modelos.Para detalles sobre precios y ventana de contexto, consulte la consola de Model Studio. La facturación se basa en los recuentos de tokens de entrada y salida.
En el modo de pensamiento, la cadena de pensamiento cuenta como tokens de salida.