Model Configuration
Online evaluations use Model objects for model endpoints. A model can be the evaluation target that produces outputs, or it can be part of a judge-style metric such as LLM-as-a-Judge, RAG, or agentic metrics.
The Evaluator plugin SDK uses inline model objects from nemo_evaluator_sdk. Pass the model either as target=... or as a field on the metric class that needs a judge or embeddings model.
Initialize the SDK
Inline Model
Define the endpoint URL and model name directly:
Model API Authentication
api_key_secret is an optional property on the Model object. Omit it when the endpoint does not require API-key authentication.
For local evaluator.run(...) calls, api_key_secret must name an environment variable available to the local Python process. For example, api_key_secret="NVIDIA_API_KEY" reads os.environ["NVIDIA_API_KEY"].
For remote evaluator.submit(...) jobs, api_key_secret must name a NeMo platform secret in the target workspace. Create the secret before submitting the job:
Model as the Evaluation Target
Use target=model when the evaluator should call the model to generate the sample output before scoring.
Model on a Judge Metric
Use a model field on the metric when the metric itself calls an LLM to score existing outputs.
Runtime Parameters
Use RunConfigOnlineModel for model-target evaluations:
Use plain RunConfig for offline evaluations where the dataset already contains the output to score.
Model References
You can supply the evaluation target two ways. Which one is valid depends on whether you run the evaluation locally or submit it as a durable platform job.
Inline Model (required for evaluator.run(...))
evaluator.run(...) executes in your local Python process, so it needs the resolved endpoint details inline. Always pass an inline Model as the target (or as a judge/embeddings field on the metric). If your deployment stores platform model entities, resolve the entity into endpoint details before constructing the Model:
ModelRef (supported by evaluator.submit(...))
Durable remote evaluator.submit(...) jobs additionally accept a ModelRef target. A ModelRef names a platform model entity (workspace/model-name) and is resolved by the evaluator backend when the job runs, so you do not have to resolve the endpoint yourself. Use this for platform-managed model routing. A ModelRef target generates outputs online, so it requires an online run config (RunConfigOnlineModel):
ModelRef is not valid for evaluator.run(...); the local runtime cannot resolve a platform entity. Pass an inline Model for local runs and either a Model or a ModelRef for remote submits. See the Define and Run Custom Python Metrics tutorial for an end-to-end ModelRef + FilesetRef submit example.
For evaluating agentic systems, use an Agent request target instead of a Model. See Agent Configuration.