On November 11, 2026, TIER IV announced five end-to-end (E2E) autonomous driving AI models designed for different system requirements, including whether a map is used and how the sensors are configured. E2E autonomous driving uses neural networks to link everything from perception of the surrounding environment to trajectory generation. The company presents the new lineup as a concrete development outcome of its next-generation architecture, "Autoware 2.0." Autoware 2.0 flexibly combines AI models with conventional rule-based technology, with the aim of letting automakers and others choose technologies according to their use case and performance requirements. However, each model differs in the sensor and map conditions it requires, as well as in its degree of integration with Autoware, so both need to be checked before any real-world deployment.
Five E2E autonomous driving AI models: comparing input conditions and integration status
The five models TIER IV introduced on November 11 are "Alpamayo 2 Edge," "AutoE2E," "METEOR," "OnePlanner," and "LatentDrive." They range from a model that generates driving trajectories from camera images alone to models that use LiDAR and high-definition maps, and each takes a different approach to driving planning. Some models are already integrated with Autoware, while others are still being integrated or validated in in-vehicle environments.
The table below summarizes each model's configuration and integration status based on TIER IV's announcement. For METEOR, it also reflects the implementation status described in the official card for the published model, in addition to the announcement.
| Model | Main configuration / input conditions | Trajectory generation characteristics | Autoware integration status |
|---|---|---|---|
| Alpamayo 2 Edge | Camera images only. 2 billion parameters | Generates driving trajectories by leveraging reasoning capability | Integrated. Optimization and adaptation to real vehicles are ongoing |
| AutoE2E | Centered on a Reactive Model, combined with a World Model and a Reasoning Model. Supports setups from cameras alone to LiDAR and radar | The Reactive Model, which handles real-time driving decisions, has been released | Reactive Model integrated. World Model and Reasoning Model are in development |
| METEOR | No HD map required. The announcement states support for 1 to 8 cameras, as well as LiDAR and radar | Converts camera images into a BEV representation shared by perception and trajectory generation | The v157 currently distributed is a reference model with its own runtime. An Autoware ROS 2 node is not yet implemented |
| OnePlanner | Uses LiDAR point clouds, HD maps, route information, traffic signal states, and vehicle driving state | Built on BEVFusion; generates trajectories up to 6 seconds ahead | Integrated |
| LatentDrive | One or three cameras. No HD map required | Uses V-JEPA latent features to generate trajectories up to 4 seconds ahead | Integration and in-vehicle validation in progress |
The 6 seconds and 4 seconds in the table indicate the time range of the trajectories the models generate. They are not processing latency or the length of time autonomous driving can continue. Also, even if integration with Autoware is complete, that alone does not mean the safety validation and approvals required for commercial operation have been completed. Beyond whether a model has an input configuration suited to the intended use, the state of the software and trained models actually available must also be checked.
The models also differ in how they plan driving. OnePlanner, for example, uses features extracted during perception directly for behavior planning, reducing the intermediate processing that conventionally converts them into information such as object positions and speeds. Alpamayo 2 Edge, meanwhile, is a reasoning-type model with 2 billion parameters, whereas AutoE2E uses a relatively lightweight configuration of 79.9 million parameters. However, parameter count alone cannot determine which model is superior in recognition accuracy, driving performance, or power consumption. TIER IV is also considering commercializing AutoE2E for robotaxi applications.
TIER IV CEO Shinpei Kato explained that it is important to be able to choose technologies according to use case and performance requirements, without depending on a specific AI model or semiconductor environment. The announcement is an effort to broaden those choices. However, no performance evaluation comparing the five models under identical conditions was presented, so real differences will need to be verified for each use case and in-vehicle environment.
What METEOR's public implementation shows about semiconductor support and porting conditions
Of the models introduced, METEOR is a multi-task E2E autonomous driving AI that TIER IV developed in-house and that does not depend on HD maps. It is intended mainly for privately owned vehicles. It uses a convolutional neural network (CNN) to extract features from camera images and convert them into a bird's-eye view (BEV) representation of the vehicle's surroundings. By sharing this BEV representation between perception of the surrounding environment and trajectory generation, it handles multiple tasks within a single neural network. While it does not require an HD map, implementation conditions vary depending on the camera configuration and the semiconductor it runs on.
According to the METEOR GitHub repository, the technology is being developed not as a single model but as a model family sharing a common training foundation. The public repository distinguishes the base model METEOR from METEOR2, which supports multiple cameras, and METEOR2 Nano, which targets monocular cameras. What the models share is the training data, training methods, and the basic structure of perception and driving planning. For semiconductor support, the key element is the process that converts camera image features into BEV. By changing the implementation of this conversion to match the operations the target semiconductor supports, TIER IV aims to deploy the models across different computing environments.
In its November 11 announcement, TIER IV explained that METEOR supports semiconductor environments such as those from NVIDIA and Renesas. This does not mean, however, that the same trained weights can run unchanged on every semiconductor. In practice, the model configuration, conversion processing, and inference engine must be adapted to the target semiconductor, so the available models and execution environments must be checked individually.
The scope of the published code and trained models also varies. The GitHub repository contains code for METEOR2 and METEOR2 Nano, but it states that pretrained weights for both models will be released in the future. Therefore, even if the source code is available, it is not necessarily possible to immediately download a trained model and reproduce the same inference results. When considering porting to an in-vehicle semiconductor, the first thing to check is whether the required model weights have been published.
METEOR itself was not first published on November 11. In a September 8 technical article, TIER IV had already introduced it as an open-source reference model. According to that article, METEOR is trained using driving data collected through Co-MLOps, and the auto-labeling platform "CoMET" generates training labels from information such as LiDAR. In other words, even though the model uses only camera images during actual driving, LiDAR is used at the stage of generating the data needed for training. The sensors required at inference time and those used to create training data need to be considered separately.
Safety also does not rest on neural-network-based driving planning alone. TIER IV has explained a policy of running rule-based safety checks independently of the trajectories the AI generates. In developing METEOR, it is also automating data processing, training, evaluation, and improvement with agentic AI, while humans set development goals and review results. These mechanisms are part of the autonomous driving system combining AI and conventional technology that Autoware 2.0 envisions.
Challenges in integrating the published model into in-vehicle systems
METEOR v157, currently distributed on Hugging Face, presupposes the eight cameras mounted on TIER IV's data recording system (DRS). According to the official model card, inputs require images from the eight cameras, calibration information such as each camera's intrinsic and extrinsic parameters, and the ego vehicle's speed. The published ONNX model uses a camera-only configuration and infers from images at a single point in time; it does not include temporal-history processing that uses past image information. The model may be able to run with other camera configurations, but with a configuration different from the one used in training, retraining and adjustments to calibration-related processing are needed, and accuracy is not guaranteed.
The inference engine also has to be built to match the semiconductor in use. Although METEOR is distributed in ONNX format, TensorRT execution engines depend on the GPU architecture and TensorRT version, so they must be generated for each target environment. Furthermore, the distributed v157 is a reference model with its own Python and C++ runtime, and the ROS 2 node for connecting directly to Autoware has not yet been implemented. Being able to obtain the model and run inference on it standalone is a separate stage from being able to integrate it into an in-vehicle system that uses Autoware.
There are also discrepancies between published materials regarding the model's scale. TIER IV's November 11 announcement gives METEOR's parameter count as 16 million, while the model card for the distributed v157 states 54 million. According to the GitHub description, this 54 million also includes a refiner responsible for additional correction processing. It has not been confirmed whether the 16-million-parameter model cited in the announcement and the distributed v157 share the same configuration and version, so the two cannot be treated as specifications of the same model. This difference needs to be resolved when comparing model scale or processing performance.
Safety-related constraints are also made explicit. The METEOR v157 model card positions the distributed model as a research and evaluation artifact and explains that it is not a certified autonomous driving system. It also states clearly that it must not be used to control vehicles on public roads. In addition, absolute values such as recognition accuracy measured in internal validation have not been published, so the information available for independently evaluating safety and performance in real-world environments is currently limited. These constraints, however, concern the distributed METEOR v157 and do not necessarily apply to the other models introduced.
The five E2E autonomous driving AI models TIER IV has presented broaden the options for automakers and developers to choose technologies according to conditions such as sensor configuration, whether a map is needed, and the in-vehicle semiconductor. At the same time, open-source availability and the stage of Autoware integration differ, and the mere existence of a model does not mean deployment in an in-vehicle system is complete. Going forward, what will matter is whether a trained model matching the target vehicle's camera configuration can be obtained, whether an inference environment can be built on the semiconductor in use, and whether connection to Autoware and validation on real vehicles progress. Once these conditions are met, developers will be able to select the model suited to their use case and move forward with evaluation toward practical deployment.