Skip to main content
Clients reach your custom model through the server’s HTTP routes. A standard Truss model serves POST /predict with arbitrary JSON, and your predict method can return a single JSON response or a generator that streams output as it’s produced. You can also expose OpenAI- and Anthropic-style /v1 endpoints by implementing the matching methods, and access the raw request object when you need to customize deserialization or cancel long-running predictions.

Streaming

Streaming returns results as they’re generated instead of waiting for the full response, which cuts wait time for generative models.
  • Faster response time: Get initial results in under 1 second instead of waiting 10 or more seconds.
  • Improved user experience: Partial outputs are immediately usable.
To stream, return a generator from predict that yields chunks as they’re produced. The following sections walk through deploying Falcon 7B with streaming enabled.

Initialize Truss

Create a new Truss for the model:
Terminal

Implement the model without streaming

This first version loads the Falcon 7B model without streaming:
model/model.py

Add streaming support

To enable streaming:
  • Use TextIteratorStreamer to stream tokens as they’re generated.
  • Run generate() in a separate thread to prevent blocking.
  • Return a generator that streams results.
model/model.py

Configure config.yaml

config.yaml

Deploy and invoke

Deploy the model:
Terminal
Invoke with:
Terminal

/v1 endpoints

Custom Truss models normally serve POST /predict with arbitrary JSON. To also support additional HTTP routes, define the matching methods on your Model class. Use these methods when you want custom Python logic but still want clients to call your model through the server’s built-in HTTP endpoints. If you deploy a custom Docker container, Baseten can forward requests to any route exposed by the underlying server. See Custom Docker containers.

Which method to implement

Implement any subset of these methods, depending on the interface you want to expose.

API families

This page uses HTTP endpoints as the umbrella term because Truss can expose endpoints from more than one API family.

chat_completions

Implement chat_completions when your model should accept chat requests.
model/model.py
The request body follows the chat schema, so model_input typically includes fields like:
  • messages
  • model
  • stream
  • sampling parameters such as temperature and max_tokens
If you already have a predict method that handles the same payload shape, chat_completions can simply delegate to it.

completions

Implement completions when your model should accept prompt-style completion requests.
model/model.py
Use completions for workloads such as autocomplete, prompt continuation, or fine-tuned models that are designed to extend text instead of following chat-style instructions.

embeddings, messages, and responses

Implement embeddings, messages, or responses when your deployment should expose those HTTP endpoints from custom model code.
model/model.py
These methods are forwarded directly to the matching /v1/* route, so your implementation can return whatever JSON shape that endpoint expects. messages maps to the Anthropic-style /v1/messages route. embeddings and responses map to OpenAI-style /v1/embeddings and /v1/responses routes.

Request and response expectations

  • These methods receive the parsed JSON payload as model_input.
  • If you include a second argument annotated as fastapi.Request, you can inspect disconnects or request metadata just like in predict. See Request handling.
  • Return JSON that matches the endpoint you expose. Baseten does not automatically convert an arbitrary predict response into a different response object for custom model code.

Endpoint paths

When these methods are defined, your deployment serves the matching HTTP routes in addition to /predict.
For production, replace {env} with production. For development deployments, use development.

Request handling

Truss extracts and validates payloads for you. Access the raw request object when you need to:
  • Customize payload deserialization, for example binary protocol buffers.
  • Handle disconnections and cancel long-running predictions.
You can mix request objects with standard inputs, or use only the request.

Use request objects in Truss

You can define request objects in preprocess, predict, and postprocess:
model/model.py

Rules for using requests

  • The request must be type-annotated as fastapi.Request.
  • If you use only the request, Truss skips payload extraction for better performance.
  • If you use both the request and standard inputs:
    • The request must be the second argument.
    • Preprocessing transforms the inputs, but the request object stays unchanged.
    • postprocess can’t take only the request; it must receive the model’s output.
    • If predict uses only the request, you can’t use preprocess.
The following example streams output while checking for client disconnects, returning early to cancel the prediction:
model/model.py
You must implement request cancellation at the model level, which varies by framework.

Cancel requests in specific frameworks

TRT-LLM (polling-based cancellation)

For TensorRT-LLM, use response_iterator.cancel() to terminate streaming requests:
model/model.py
See full example in TensorRT-LLM Docs.

vLLM (abort API)

For vLLM, use engine.abort() to stop processing:
model/model.py
See full example in vLLM Docs.

Unsupported request features

  • Streaming file uploads: Use URLs instead of embedding large data in the request.
  • Client-side headers: Most headers are stripped; include necessary metadata in the payload.

Next steps

  • The Model class: Write the predict, chat_completions, and request-handling methods these endpoints call.
  • Custom Docker servers: Forward requests to any route your own container exposes.