Après avoir développé un flux d'application, déployez-le en tant que service Elastic Algorithm Service (EAS). EAS propose la mise à l'échelle automatique et une surveillance complète des opérations et de la maintenance pour aider votre application à s'adapter avec souplesse aux évolutions et à la croissance de votre activité.
Prérequis
Créez et déboguez un flux d'application. Consultez la rubrique Développement de flux d'application.
Déployer un flux d'application
Accédez à LangStudio et sélectionnez un espace de travail. Dans l'onglet Application Flow, cliquez sur un flux d'application débogué, puis cliquez sur Deploy dans le coin supérieur droit. Assurez-vous que le runtime est démarré avant le déploiement. Les paramètres clés sont décrits ci-dessous.

|
Parameter |
Description |
|
Resource Information |
|
|
Resource Type |
Sélectionnez les public resources ou un dedicated resource group que vous avez créé. |
|
Instances |
Définissez le nombre d'instances de service. Pour la production, configurez plusieurs instances afin de réduire les risques liés à un point de défaillance unique. |
|
Deployment Resources |
Si le flux d'application est utilisé uniquement pour la planification des flux métier, sélectionnez des CPU resources appropriées en fonction de la complexité du flux. Les ressources CPU sont généralement plus rentables que les ressources GPU. Après le déploiement, la facturation des ressources s'applique. Consultez la rubrique Facturation d'Elastic Algorithm Service (EAS). |
|
VPC : Le flux d'application est déployé en tant que service EAS. Pour garantir l'accès client, sélectionnez un VPC. Par défaut, les services EAS ne peuvent pas accéder à Internet. Pour activer l'accès à Internet, configurez un VPC disposant d'une connectivité Internet. Consultez la rubrique Accès EAS aux ressources publiques et privées. Remarque
Si un flux d'application utilise une connexion à une base de données vectorielle (telle que Milvus), assurez-vous que le VPC configuré correspond au VPC de l'instance de base de données vectorielle ou que les deux VPC sont connectés. |
|
|
History |
|
|
Enable History |
S'applique uniquement aux flux d'application de type chat. Lorsqu'elle est activée, cette option permet au système de stocker et de transmettre l'historique des conversations sur plusieurs tours. À utiliser conjointement avec le paramètre d'en-tête de requête. |
|
History Storage |
Le stockage local ne prend pas en charge le déploiement multi-instances. Pour les services de production, utilisez un stockage externe tel qu'ApsaraDB RDS. Pour plus d'informations, consultez l'Annexe : Historique des chats. Important
Avec le stockage local, le déploiement multi-instances n'est pas pris en charge, et le passage d'une instance unique à plusieurs instances est également impossible. Sinon, l'historique des chats peut ne pas fonctionner correctement. |
|
Enable Tracing : Lorsque cette option est activée, vous pouvez afficher les enregistrements de trace pour évaluer l'effet du flux d'application après le déploiement. |
|
|
Rôles et autorisations : Dans le flux d'application, si vous utilisez une base de données vectorielle Faiss (sélectionnez une base de données vectorielle Faiss ou Milvus lors de la création d'une base de connaissances) ou « Alibaba Cloud IQS Search » (requis par le modèle Chatbot basé sur la recherche web IQS), vous devez sélectionner un rôle approprié. |
|
Pour plus d'informations sur la configuration des paramètres, consultez la rubrique Déploiement personnalisé.
Débogage en ligne
Appeler le service
Débogage en ligne
Après un déploiement réussi, vous êtes redirigé vers PAI-EAS. Dans l'onglet Online Debugging, configurez et envoyez une requête. La clé dans le corps de la requête doit correspondre à la valeur du paramètre Chat Input dans le nœud de démarrage. Cette rubrique utilise le champ par défaut question.

Effectuer des appels API
-
Dans l'onglet Overview, récupérez l'endpoint et le token.

-
Envoyez une requête API.
Appelez le service en mode simple ou complet. Le tableau suivant décrit les différences.
Property
Simple Mode
Complete Mode
Request path
<Endpoint>/<Endpoint>/runFeature description
Renvoie directement les résultats de sortie du flux d'application.
Renvoie une structure complexe, incluant l'état des nœuds, les messages d'erreur et les messages de sortie du flux d'application.
Scenario
-
Seul le résultat final est nécessaire ; les détails du traitement interne ne sont pas importants.
-
Convient aux requêtes ou opérations simples pour obtenir rapidement des résultats.
-
Vous devez comprendre en détail le processus d'exécution du flux d'application, y compris l'état de chaque nœud et les éventuels messages d'erreur.
-
Adapté au débogage, à la surveillance ou à l'analyse de l'exécution du flux d'application.
Advantages
Simple d'utilisation, aucune nécessité d'analyser des structures complexes.
-
Fournit des informations complètes pour vous aider à comprendre en profondeur le processus d'exécution du flux d'application.
-
Aide à résoudre les problèmes et à optimiser les performances du flux d'application.
Mode simple
Commande cURL
Code Python
Mode complet
Langstudio prend en charge les Server-Sent Events (SSE), qui permettent d'afficher l'état, les messages d'erreur et les messages de sortie de chaque nœud lors de l'exécution du flux d'application. Vous pouvez également personnaliser le contenu du
node_run_infosdans les événements. L'exemple suivant utilise le débogage en ligne. Vous devez ajouter/runà l'adresse d'appel, puis modifier le corps de la requête :
Le tableau suivant décrit les paramètres du corps de la requête.
Field Name
Type
Default Value
Description
inputs
Mapping[str, Any]
None
Le dictionnaire de données d'entrée. Les clés doivent correspondre aux noms des champs d'entrée définis dans le flux d'application. Si le flux n'a pas d'entrées, ce champ est ignoré.
stream
bool
True
Contrôle le format de réponse. Valeur par défaut : Dynamic. Valeurs valides :
-
True : répond avec un streaming SSE. Le Content-Type dans l'en-tête de réponse est
text/event-stream, et les données sont renvoyées au format DataOnly, divisées en différents événements : RunStarted, NodeUpdated, RunOutput et RunTerminated. Pour plus d'informations, consultez les tableaux ci-dessous. -
False : répond avec un seul corps JSON. Le Content-Type dans l'en-tête de réponse est
application/json. Vous pouvez consulter les informations de réponse dans la section Débogage en ligne.
response_config
Dict[str, Any]
-
Contrôle les informations détaillées sur les nœuds incluses dans la réponse en streaming (lorsque stream=True).
∟ include_node_description
bool
False
(Dans response_config) Indique s'il faut inclure les descriptions des nœuds dans le flux d'événements SSE.
∟ include_node_display_name
bool
False
(Dans response_config) Indique s'il faut inclure les noms d'affichage des nœuds dans le flux d'événements SSE.
∟ include_node_output
bool
False
(Dans response_config) Indique s'il faut inclure les sorties des nœuds dans le flux d'événements SSE.
∟ exclude_nodes
List[str]
[]
(Dans response_config) Liste des noms de nœuds à exclure du flux d'événements SSE.
Les données renvoyées sont divisées en différents événements : RunStarted, NodeUpdated, RunOutput et RunTerminated :
-
Méthode d'appel compatible OpenAI
Les flux d'application de type chat déployés prennent en charge l'appel compatible OpenAI et peuvent être utilisés par des clients compatibles avec OpenAI.
Méthode basée sur l'API OpenAI
Cet exemple illustre les appels en streaming à l'aide de commandes curl. Voici des exemples de requêtes et de réponses :
Exemple de requête :
curl --location '<Endpoint>/v1/chat/completions' \
--header "Authorization: Bearer $DASHSCOPE_API_KEY" \
--header 'Content-Type: application/json' \
--data '{
"model": "default",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "Who are you?"
}
],
"stream":true
}'
Le tableau suivant décrit les paramètres de requête.
|**Parameter**
|
**Description**
| | --- | --- | |
--location '<Endpoint>/v1/chat/completions'
|
L'URL de destination de la requête. Remplacez `
| |
--header "Authorization: Bearer $DASHSCOPE_API_KEY"
|
L'en-tête HTTP. Remplacez `$DASHSCOPE_API_KEY` par le token que vous avez obtenu à l'étape 1.
| |
"model": "default"
|
Le nom du modèle, qui est fixé à `default`.
| |
"stream":true
|
Indique si les informations renvoyées sont en **streaming**. **Remarque : le streaming n'est pris en charge que lorsqu'un nœud LLM est utilisé comme nœud de sortie du flux d'application (un nœud LLM est l'entrée directe du nœud final).**
|
Exemple de réponse :
data: {"choices":[{"delta":{"content":"","role":"assistant"},"index":0,"logprobs":null,"finish_reason":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}
data: {"choices":[{"finish_reason":null,"delta":{"content":"I am"},"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}
data: {"choices":[{"delta":{"content":"a large"},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}
data: {"choices":[{"delta":{"content":"language model"},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}
data: {"choices":[{"delta":{"content":"created by Alibaba Cloud"},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}
data: {"choices":[{"delta":{"content":". I am called Qwen."},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}
data: {"choices":[{"delta":{"content":""},"finish_reason":"stop","index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}
data: [DONE]
Intégration avec d'autres clients
Cet exemple illustre l'intégration avec ChatBox v1.13.4 sur la plateforme Windows.
Téléchargez et installez Chatbox.
-
Ouvrez ChatBox et configurez le nom du fournisseur de modèle, par exemple LangStudio, comme suit.

-
Sélectionnez le fournisseur de modèle configuré et définissez les paramètres de requête de service.

Le tableau suivant décrit les paramètres clés.
|
**Parameter**
|
**Description**
| | --- | --- | |
API Mode
|
Fixé à `OpenAI API Compatible`.
| |
API Key
|
Définissez-le sur le token du service déployé, consultez la section Obtenir l'endpoint et le token dans l'onglet Overview.
| |
API Host
|
Définissez-le sur l'endpoint du service déployé (voir Obtenir l'endpoint et le token dans l'onglet Overview.) et ajoutez le suffixe `/v1` à la fin. Cet exemple utilise un endpoint Internet. Par conséquent, l'hôte API est `http://langstudio-20250319153409-xdcp.115770327099****.cn-hangzhou.pai-eas.aliyuncs.com/v1`.
| |
API Path
|
Fixé à `/chat/completions`.
| |
Model
|
Cliquez sur **New** et saisissez un **Model ID** personnalisé, par exemple qwen3-8b.
| -
Appelez le service déployé dans la boîte de dialogue de chat.

Afficher les enregistrements de trace
Après avoir appelé un service, le système génère automatiquement un enregistrement de trace. Dans l'onglet New, recherchez l'enregistrement de trace que vous souhaitez gérer et cliquez sur Model ID dans la colonne Tracing Analysis.

Les données de trace vous permettent d'afficher les informations d'entrée et de sortie de chaque nœud du flux d'application, telles que les résultats de rappel de la base de données vectorielle ou les informations d'entrée et de sortie du nœud LLM.
Annexe : Historique des chats
Pour les flux d'application basés sur le chat, LangStudio propose une fonctionnalité permettant de stocker l'historique des conversations multitudes. Vous pouvez choisir d'utiliser un stockage local ou externe pour enregistrer l'historique des chats.
Types de stockage
Stockage local : le service utilise le disque local pour créer automatiquement une base de données SQLite nommée chat_history.db sur l'instance EAS où le flux d'application est déployé, afin d'enregistrer l'historique des chats. Le chemin de stockage par défaut est
/langstudio/flow/. Notez que le stockage local ne prend pas en charge le déploiement multi-instances. Vérifiez régulièrement l'utilisation du disque local. Vous pouvez également afficher ou supprimer l'historique des chats à l'aide de l'API fournie ci-dessous. Si une instance EAS est supprimée, l'historique des chats associé est également effacé.Stockage externe : prend en charge ApsaraDB RDS for MySQL. Pour utiliser le stockage externe, vous devez configurer une connexion RDS MySQL pour stocker l'historique des chats lors du déploiement d'un service. Pour plus d'informations, consultez la rubrique Configuration de la connexion au service - Base de données. Le service crée automatiquement des tables suffixées par le nom du service dans la base de données RDS MySQL que vous avez configurée. Par exemple, le service crée la table
langstudio_chat_session_<Nom du service>pour stocker la session de chat et la tablelangstudio_chat_history_<Nom du service>pour stocker l'historique des chats.
Prise en charge des sessions ou des utilisateurs
Chaque requête de chat adressée à un flux d'application est sans état. Si vous souhaitez que plusieurs requêtes soient traitées comme faisant partie de la même conversation, vous devez configurer manuellement l'en-tête de requête. Pour savoir comment effectuer des appels, consultez la section Effectuer des appels API.
|**Request header**
|
**Data type**
|
**Description**
|
**Note**
| | --- | --- | --- | --- | |
Chat-Session-Id
|
String
|
L'ID de session. Pour chaque requête de service, le système attribue automatiquement un identifiant unique à la session pour distinguer les différentes sessions, et le renvoie via le champ `Chat-Session-Id` dans l'en-tête de réponse.
|
Les IDs de session personnalisés sont pris en charge. Pour garantir l'unicité, un ID de session doit comporter entre 32 et 255 caractères et peut contenir des lettres, des chiffres, des traits de soulignement (_), des tirets (-) et des deux-points (:).
| |
Chat-User-Id
|
String
|
L'ID utilisateur, qui identifie l'utilisateur auquel appartient le chat. Le système n'attribue pas automatiquement d'ID utilisateur. Les IDs utilisateur personnalisés sont pris en charge.
|
-
|
API d'historique des chats
Le service de flux d'application fournit également des opérations API de gestion des données d'historique des chats, qui vous permettent d'afficher et de supprimer facilement ces données. Vous pouvez obtenir le schéma API complet en envoyant une requête GET à {Endpoint}/openapi.json. Ce schéma est construit selon la norme Swagger. Pour une compréhension et une exploration plus intuitives de ces opérations API, nous vous recommandons d'utiliser Swagger UI pour effectuer des opérations de visualisation, rendant les actions plus simples et plus claires.