comments-questionLanguage Model (LM) Invoker

gllm-inferencearrow-up-right | Tutorial: Language Model (LM) Invoker| Use Case: Utilize Language Model Request Processor | API Referencearrow-up-right | Cookbookarrow-up-right

What’s an LM Invoker?

The LM invoker is a unified interface designed to help you interact with language models to generate outputs based on the provided inputs. In this tutorial, you'll learn how to invoke a language model using OpenAILMInvoker in just a few lines of code. You can also explore other types of LM Invokers, available herearrow-up-right.

chevron-rightPrerequisiteshashtag

This example specifically requires completion of all setup steps listed on the Prerequisites page.

Available LM Invokers

The LM invoker provides the following built-in implementations:

  1. AnthropicLMInvoker

  2. AzureOpenAILMInvoker

  3. BedrockLMInvoker

  4. DatasaurLMInvoker

  5. GoogleLMInvoker

  6. LangChainLMInvoker

  7. LiteLLMLMInvoker

  8. OpenAIChatCompletionsLMInvoker

  9. OpenAILMInvoker

  10. PortkeyLMInvoker

  11. SeaLionLMInvoker

  12. XAILMInvoker

Installation

Quickstart

Initialization and Invoking

Let’s jump into a basic example using OpenAILMInvoker. We’ll ask the model a simple question and print the output.

Output:


Streaming

To achieve streaming, simply pass an event emitter when invoking the LM invoker. This allows us to process the generated tokens without having to wait for the entire generation process to finish.

In the example above, we're using the PrintEventHandler which is intended to print the streamed tokens in a beautified format. For more details about the event emitter, please refer to the event emitter tutorial page.


Message Roles

Modern LMs understand context better when you structure inputs like a real conversation. That’s where message roles come in. You can simulate multi-turn chats, set instructions, or give memory to the model through a structured message format.

Example 1: Passing a system message

Output:

Example 2: Simulating a multi-turn conversation

Output:


Multimodal Input

Our LM Invokers supports attachments (images, documents, etc.). This lets you send rich content and ask the model to analyze or describe them.

Loading Attachments

An Attachment is a content object that can be loaded in the following ways:

  • using a remote file (URL)

  • using a local file

  • using a data URL

  • using raw bytes

We can load the attachment in the following ways:

Example 1: Describe an image

Output:


Example 2: Analyze a PDF

Output:


Supported Attachment Types

Each LM might support different types of inputs. You can find more about supported type for each LM Invoker herearrow-up-right.


Structured Output

In many real-world applications, we don't just want natural language outputs — we want structured data that our programs can parse and use directly.

You can define your expected output using:

  1. A Pydantic BaseModel class (recommended).

  2. A JSON schema dictionary compatible with Pydantic's schema format.

When structured output is enabled, structured output results are stored in the outputs attribute of the LMOutput object and can be accessed via the structured_outputs property. The output type depends on the input schema:

  1. Pydantic instance → The output will be a Pydantic BaseModel instance.

  2. JSON schema dict → The output will be a Python dictionary.

Using a Pydantic BaseModel (Recommended)

You can define your expected output format as a Pydantic class. This ensures strong type safety and makes the output easier to work with in Python.

Output:

Using a JSON Schema Dictionary

Alternatively, you can define the structure using a JSON schema dictionary.

Output

If JSON schema is used, it must still be compatible with Pydantic's JSON schema, especially for complex schemas. For this reason, it is recommended to create the JSON schema using Pydantic's model_json_schema method.


Tool Calling

Tool calling means letting a language model call external functions to help it solve a task. It allows the AI to interact with external functions and APIs during the conversation, enabling dynamic computation, data retrieval, and complex workflows.

Think of it as:

The LM is smart at reading and reasoning, but when it needs to calculate or get external data, it picks up the phone and calls your "tool".

For more information about tools definition, please refer to this guide.

LM Invocation with Tool

Let's try to integrate a simple math operation tool to our LM invoker!

Output:

When the LM Invoker is invoked with tool calling capability, the model will return the tool calls. In this case, we still need to execute the tools and feed the result back to the LM invoker ourselves. If you'd like to handle this looping process automatically, please refere to the LM Request Processor component.


Native Tools

Native tools are a specific set tools that allow the language model to execute certain built-in capabilities during the invocation, enabling dynamic computation, data retrieval, and complex workflows. Similar to the user-defined tools, the native tools can be enabled by passing them through the LM invoker's tools parameter.

Each type of native tools is only available for certain LM invokers. Please find the available native tools below:

  1. Code interpreter — Writes and runs Python code in a sandboxed environment.

  2. Image generation — Generates an image based on the provided query.

  3. MCP Server — Uses remote MCP servers to give models new capabilities.

  4. MCP Connector — Retrieves data from remote MCP connectors.

  5. Skill — Manages custom skills on the provider's server side.

  6. Web search — Searches the web for relevant information.


Thinking

Certain language model providers and models supports thinking. Thinking allows models to produce an internal chain of thought before responding to the user. This enables model to perform advanced tasks such as complex problem solving, coding, scientific reasoning, and multi-step planning for agentic workflows.

When thinking is enabled, thinking results are stored in the outputs attribute of the LMOutput object and can be accessed via the thinkings property.

Let's try to perform thinking by using OpenAI's gpt-5-nano model:

Output:

For more fine-grained control, you can use ThinkingConfig to pass provider-specific thinking parameters. Provider-specific parameters can be found in the provider's documentation.

circle-info

Pass the provider specific parameter in kwargs


Output Analytics

Output analytics enables you to collect detailed metrics and insights about your language model invocations. When output analytics is enabled, the output includes the following extra attributes:

  1. token_usage : Input and output token counts.

  2. duration : Time taken to generate the output.

  3. finish_details: Additional details about how the generation finished.

To enable output analytics, simply need to set the output_analytics parameter to True.

Output:


Retry & Timeout

Retry & timeout functionality provides robust error handling and reliability for language model interactions. It allows you to automatically retry failed requests and set time limits for operations, ensuring your applications remain responsive and resilient to network issues or API failures.

Retry & timeout can be configured via the RetryConfig class' parameters:

  1. max_retries: Maximum number of retry attempts (defaults to 3 maximum retry attempts).

  2. timeout: Maximum time in seconds to wait for each request (defaults to 30.0 seconds). To disable timeout, this parameter can be set to None.

Let's try to apply it to our LM invoker!


Extra Capabilities

Some LM invokers also provide additional capabities that are useful in certain cases:

  1. Input Transformer — To transform the language model messages input before invocation.

  2. Output Transformer — To transform the raw output from the language model into a different format or structure.

  3. Batch Invocation — To manage batch requests for cheaper but slower invocations.

  4. File Management — To manage uploaded files in their server side. These files can then be used as inputs during invocations.

  5. Data Store Management — To manage built-in data stores to be used as internal knowledge base. This allows the LM invoker to perform built-in RAG (Retrieval-Augmented Generation).

If you encounter errors, refer to the Troubleshooting Guide for detailed explanations of common errors and how to resolve them.

Last updated

Was this helpful?