Skip to main content
Implement custom business logic, request handling, and inference patterns in model.py while maintaining TensorRT-LLM performance. Custom engine builder enables billing integration, request tracing, fan-out generation, and multi-response workflows.

Overview

The custom engine builder lets you:
  • Implement business logic: Billing, usage tracking, access control.
  • Add custom logging: Request tracing, performance monitoring, audit trails.
  • Create advanced inference patterns: Fan-out generation, custom chat templates.
  • Integrate external services: APIs, databases, monitoring systems.
  • Optimize performance: Concurrent processing, custom batching strategies.

When to use custom engine builder

Ideal use cases

Business logic integration:
  • Usage tracking: Monitor token usage per customer/request.
  • Access control: Implement custom authentication/authorization.
  • Rate limiting: Custom rate limiting based on user tiers.
  • Audit logging: Compliance and security requirements.
Advanced inference patterns:
  • Fan-out generation: Generate multiple responses from one request.
  • Custom chat templates: Domain-specific conversation formats.
  • Multi-response workflows: Parallel processing of variations.
  • Conditional generation: Business rule-based output modification.
Performance and monitoring:
  • Custom logging: Request tracing, performance metrics.
  • Concurrent processing: Parallel generation for improved throughput.
  • Usage analytics: Track patterns and optimize accordingly.
  • Error handling: Custom error responses and fallback logic.

Implementation

Fan-out generation example

Multi-generation fan-out generates multiple texts from a single request. Running them sequentially ensures the KV cache is created before subsequent generations.
model/model.py

Fan-out generation configuration

To deploy the above example, create a new directory, for example, fanout and create a fanout/model/model.py file. Then create the following config.yaml at fanout/config.yaml
config.yaml
Finally, push the model with truss push. TRT-LLM engine builds require a published deployment and do not support --watch mode.

How routing works

Custom engine builder exposes two endpoint paths:
  • /predict: calls your predict() method. Use this for custom request formats, business logic, or non-OpenAI patterns.
  • /v1/chat/completions: calls chat_completions() if defined, otherwise falls back to predict(). Use this for OpenAI-compatible clients.
To make both paths work, define chat_completions as an alias to predict (as shown in the fan-out example above). If you only define predict, the /v1/chat/completions endpoint still works but goes through your predict method with the raw OpenAI-format input.

Limitations and considerations

What custom engine builder cannot do

Custom tokenization:
  • Cannot modify the underlying tokenizer implementation
  • Cannot add custom vocabulary or special tokens
  • Must use the model’s native tokenization
Model architecture changes:
  • Cannot modify the TensorRT-LLM engine structure
  • Cannot change attention mechanisms or model layers
  • Cannot add custom model components

When to use standard engine instead

  • Standard chat completions without special requirements
  • No need for business logic integration

Monitoring and debugging

Request tracing