ConceptsModels

Model Configurations

View as Markdown

Model configurations define the specific models you use for synthetic data generation and their associated inference parameters. Each ModelConfig represents a named model that can be referenced throughout your data generation workflows.

Overview

A ModelConfig specifies which LLM model to use and how it should behave during generation. When you create column configurations (like LLMText, LLMCode, or LLMStructured), you reference a model by its alias. Data Designer uses the model configuration to determine which model to call and with what parameters.

When a column includes multi_modal_context, the ModelConfig alias must point to a model that supports the media types you send. Data Designer can serialize image, audio, and video context blocks, but model capability is still provider-specific. Local audio/video paths require explicit URL mode (data_type=url) and require the model endpoint to have filesystem access to the same paths, typically a colocated vLLM server configured for local media access.

ModelConfig Structure

The ModelConfig class has the following fields:

FieldTypeRequiredDescription
aliasstrYesUnique identifier for this model configuration (e.g., "my-text-model", "reasoning-model")
modelstrYesModel identifier as recognized by the provider (e.g., "nvidia/nemotron-3-nano-30b-a3b", "gpt-4")
inference_parametersInferenceParamsTNoControls model behavior during generation. Use ChatCompletionInferenceParams for text/code/structured generation or EmbeddingInferenceParams for embeddings. Defaults to ChatCompletionInferenceParams() if not provided. The generation type is automatically determined by the inference parameters type. See Inference Parameters for details.
providerstrYesReference to the name of the Provider to use (e.g., "nvidia", "openai", "openrouter").
skip_health_checkboolNoWhether to skip the health check for this model. Defaults to False. Set to True to skip health checks when you know the model is accessible or want to defer validation.
Upgrade note

Every ModelConfig must now specify provider. Existing model_configs.yaml entries from older releases that omit provider or set it to null must be updated with an explicit provider name before loading. Agent tooling that parses data-designer agent context should read each model alias item’s provider field; the top-level default_provider and per-item configured_provider / effective_provider fields are no longer emitted.

Examples

Basic Model Configuration

1import data_designer.config as dd
2
3# Simple model configuration with fixed parameters
4model_config = dd.ModelConfig(
5    alias="my-text-model",
6    model="nvidia/nemotron-3-nano-30b-a3b",
7    provider="nvidia",
8    inference_parameters=dd.ChatCompletionInferenceParams(
9        temperature=0.85,
10        top_p=0.95,
11        max_tokens=2048,
12    ),
13)

Multiple Model Configurations for Different Tasks

1import data_designer.config as dd
2
3model_configs = [
4    # Creative tasks
5    dd.ModelConfig(
6        alias="creative-model",
7        model="nvidia/nemotron-3-nano-30b-a3b",
8        provider="nvidia",
9        inference_parameters=dd.ChatCompletionInferenceParams(
10            temperature=0.9,
11            top_p=0.95,
12            max_tokens=2048,
13        ),
14    ),
15    # Critic tasks
16    dd.ModelConfig(
17        alias="critic-model",
18        model="nvidia/nemotron-3-nano-30b-a3b",
19        provider="nvidia",
20        inference_parameters=dd.ChatCompletionInferenceParams(
21            temperature=0.25,
22            top_p=0.95,
23            max_tokens=2048,
24        ),
25    ),
26    # Reasoning and structured tasks
27    dd.ModelConfig(
28        alias="reasoning-model",
29        model="nvidia/nemotron-3-super-120b-a12b",
30        provider="nvidia",
31        inference_parameters=dd.ChatCompletionInferenceParams(
32            temperature=1.0,
33            top_p=0.95,
34            max_tokens=4096,
35        ),
36    ),
37    # Omni multimodal tasks
38    dd.ModelConfig(
39        alias="vision-model",
40        model="nvidia/nemotron-3-nano-omni-30b-a3b-reasoning",
41        provider="nvidia",
42        inference_parameters=dd.ChatCompletionInferenceParams(
43            temperature=0.60,
44            top_p=0.95,
45            max_tokens=2048,
46        ),
47    ),
48    # Embedding tasks
49    dd.ModelConfig(
50        alias="embedding_model",
51        model="nvidia/llama-nemotron-embed-1b-v2",
52        provider="nvidia",
53        inference_parameters=dd.EmbeddingInferenceParams(
54            encoding_format="float",
55            extra_body={
56                "input_type": "query"
57            }
58        )
59    )
60]

Experiment with max_tokens for Task-Specific Model Configurations The number of tokens required to generate a single data entry can vary significantly with use case. For example, reasoning models often need more tokens to “think through” problems before generating a response. Note that max_tokens specifies the maximum number of output tokens to generate in the response, so set this value based on the expected length of the generated content.

Skipping Health Checks

By default, Data Designer runs a health check for each model before starting data generation to ensure the model is accessible and configured correctly. You can skip this health check for specific models by setting skip_health_check=True:

1import data_designer.config as dd
2
3model_config = dd.ModelConfig(
4    alias="my-model",
5    model="nvidia/nemotron-3-nano-30b-a3b",
6    provider="nvidia",
7    inference_parameters=dd.ChatCompletionInferenceParams(
8        temperature=0.85,
9        top_p=0.95,
10        max_tokens=2048,
11    ),
12    skip_health_check=True,  # Skip health check for this model
13)

When to Skip Health Checks Skipping health checks can be useful when:

  • You’ve already verified the model is accessible and want to speed up initialization
  • You’re using a model that doesn’t support the standard health check format
  • You want to defer model validation until the model is actually used

Note that skipping health checks means errors will only be discovered during actual data generation.

See Also