Model Provider Configuration

1. Introduction

Model providers maintain the connection information of large-model services, while model configuration maintains the specific models that can be invoked. AI chat, knowledge base Q&A, intelligent data query, protocol adaptation, Thing Model generation, and requirement evaluation all depend on the configuration here.

In simple terms: the provider determines "where to connect and which key to use", and the model determines "which model to invoke and which default parameters to use".

2. Operation Path

AI Empowerment > Provider Management
AI Empowerment > Model Management

Menu names may vary slightly between versions; refer to the actual admin console.

3. Preparation

Before configuring, prepare the following:

1. A model service account or an intranet model service address.
2. An API Base URL, such as a public model address, a gateway address, or an intranet Ollama address.
3. An API Key or the access key required by the platform.
4. The name or code of the model to invoke.
5. The network connectivity, proxy policy, and quota limits of the current environment.

For intranet private deployment, verify on the server that the backend can access the model service before configuring it on the page.

4. Provider Configuration

Field	Description	Recommendation
Provider code	The code by which the system identifies the provider adapter	Subject to the page dropdown; common values include QWEN, DEEPSEEK, OPENAI, AZURE_OPENAI, OLLAMA, etc.
Provider name	The name displayed on the page	Include the vendor, environment, or purpose, such as Qwen-Production
Region tier	Distinguishes domestic, overseas, private deployment, and other region policies	Select according to the actual location of the model service and the network policy
API base address	The Base URL of the model service	Use the API address given in the vendor documentation; enter the intranet address for intranet deployment
Authentication method	The authentication method used when invoking the model service	Subject to the page options; must match the vendor requirements
API Key	The access key of the model service	Not displayed in plain text after saving; maintained only by administrators
Extended configuration	Special vendor parameters or gateway parameters	Leave empty when there are no special requirements
Sort order	The display order on the page	Sort by frequency of use when there are multiple providers
Status	Whether the provider is enabled	Models under a disabled provider cannot be invoked
Remarks	Supplementary notes	Can record quota, owner, environment, and precautions

提示

API Keys are sensitive information. Do not send page screenshots, API logs, or configuration files containing keys to public groups.

5. Model Configuration

Field	Description	Recommendation
Owning provider	The provider the model belongs to	Create and enable the provider first, then add models
Model code	The code of the vendor's large model	Must exactly match a name actually supported by the vendor model, generally lowercase
Model name	The real model name on the vendor side	Must exactly match a name actually supported by the vendor
Model type	The capability category of the model	Subject to the page dropdown; at least one chat-capable model is required
Context length	The context size the model can process in a single call	Fill in according to the vendor model specifications; avoid setting it too large, which causes call failures
Default inference parameters	The default JSON parameters used when invoking the model	Parameters such as temperature, TopP, and max output can be set
Default or not	Whether it serves as the default model	Keep only one default model per capability type for automatic routing
Status	Whether the model is enabled	A disabled model is not invoked by new requests
Remarks	Supplementary notes	Can record the model purpose, price, quota, and applicable scenarios

Default inference parameters can be filled in according to what the model provider supports, for example:

{
  "temperature": 0.2,
  "topP": 0.8,
  "maxTokens": 2048
}

For scenarios such as operations Q&A, platform assistant, and protocol parsing, lowering randomness is usually recommended to make answers more stable; creative or explanatory content can use appropriately higher randomness.

6. Recommended Configuration Flow

1. Add a provider and fill in the provider code, API address, authentication method, and API Key.
2. Enable the provider.
3. Add a model and select its owning provider.
4. Fill in the model code, model name, model type, context length, and default parameters.
5. Set frequently used models as default and enable them.
6. Enter the AI chat and send a simple question to verify the response.
7. Then verify business capabilities such as the platform assistant, knowledge base Q&A, and protocol adaptation.

7. Acceptance Checks

Check Item	Pass Criteria
Provider status	The page shows enabled, and the API address and authentication method are correct
Key validity	AI chat does not return authentication failures
Model name	The model service recognizes it and does not return "model does not exist"
Default model	Auto-recognition or the platform assistant can select the model normally
Parameter configuration	Response length, speed, and stability meet expectations
Business verification	Knowledge base Q&A, intelligent data query, or protocol adaptation can enter the AI flow normally

8. FAQ

1. Authentication failure is returned

Check whether the API Key is correct, whether it has expired, and whether it has permission for the corresponding model; also confirm that the authentication method matches the vendor requirements.

2. It prompts that the model does not exist

Check whether the model name exactly matches the vendor console, especially case, version number, region restrictions, and deployment name. Services such as Azure OpenAI usually require the deployment name.

3. AI chat does not respond or responds very slowly

First check network connectivity from the server to the model service, proxy settings, the model service region, the maximum output length, and the vendor quota. If an intranet model is used, also confirm that the service port and access path are correct.

4. The knowledge base or protocol adaptation is unavailable

First confirm that the basic chat model works, then check whether the knowledge base has been built and published, whether the protocol materials were parsed successfully, and whether the related business switches are enabled.

5. Answers are unstable

Lower the temperature, appropriately reduce the maximum output length, and add clearer knowledge base content. For scenarios such as platform operations, protocol parsing, and requirement evaluation, more stable parameters are recommended.

9. Usage Suggestions

• Use different vendors or different API Keys for production and test environments to control cost and risk.
• When multiple providers coexist, clarify the default model first to avoid business calls falling on an unexpected model.
• Before switching the default model, verify quality, speed, cost, and context length in the AI chat.
• Do not configure production keys in demo environments.