In NVIDIA Jetson Orin Nano Super on Turing Pi 2.5: Complete Setup Guide, we moved an 8GB Jetson Orin Nano module from NVIDIA’s developer kit to Turing Pi 2.5, flashed Jetson Linux directly through the board, booted from NVMe, connected over Ethernet and SSH, and verified JetPack and CUDA.
Once that node is running, the bigger question is what role the Jetson should play inside a four-node Turing Pi system.
Turing Pi 2.5 can mix supported NVIDIA Jetson modules with Turing RK1 and Raspberry Pi CM4 nodes. That lets you keep databases, storage, web services, automation, and other general-purpose workloads on general-purpose nodes while reserving NVIDIA hardware for inference, computer vision, speech processing, or other accelerated workloads.
This guide covers the supported Jetson families, how they differ in 2026, how they fit into the Turing Pi 2.5 hardware layout, and the systems you can build around them.
1. NVIDIA Jetson modules supported by Turing Pi 2.5
Turing Pi 2.5 has four vertical 260-pin SO-DIMM compute-module sockets and allows supported modules to be mixed across them.
Turing Pi 2.5 currently supports Jetson Orin Nano, Orin NX, Xavier NX, TX2 NX, and Jetson Nano B01. The original Jetson Nano A02 is not supported.
The important distinction in 2026 is that physical Turing Pi compatibility does not mean every supported Jetson belongs to the same NVIDIA software generation or product lifecycle.
| Module family | Memory | Headline AI performance | NVIDIA software branch | NVIDIA availability | Best fit today |
| Jetson Orin Nano | 4GB or 8GB | 4GB: up to 34 TOPS; 8GB: up to 67 TOPS | JetPack 7.2.1 / Jetson Linux 39.2.1 | Through January 2032 | New compact AI builds |
| Jetson Orin NX | 8GB or 16GB | 8GB: up to 117 TOPS; 16GB: up to 157 TOPS | JetPack 7.2.1 / Jetson Linux 39.2.1 | Through January 2032 | Higher-performance AI workloads |
| Jetson Xavier NX | 8GB or 16GB | Up to 21 TOPS | JetPack 5.1.7 / Jetson Linux 35.6.5 | Final shipments by July 15, 2027 | Existing Xavier systems |
| Jetson TX2 NX | 4GB | 1.33 TFLOPS | JetPack 4.6.6 / Jetson Linux 32.7.6 | Final shipments by July 15, 2027 | Existing legacy systems |
| Jetson Nano B01 | 4GB | 472 GFLOPS | JetPack 4.6.6 / Jetson Linux 32.7.6 | Through January 2027 | Existing Nano hardware |
The figures are not directly comparable across every generation because the architectures and performance metrics changed over time. They are more useful for placing each module within its own NVIDIA generation than for predicting application performance.
For a new build, Orin Nano and Orin NX are the two most relevant families. NVIDIA’s Jetson Orin specifications list Orin Nano 4GB at up to 34 TOPS, Orin Nano 8GB at up to 67 TOPS, Orin NX 8GB at up to 117 TOPS, and Orin NX 16GB at up to 157 TOPS.
Those TOPS figures are not application benchmarks. They do not tell you directly how many LLM tokens per second a model will generate, how many frames a detector will process, or how quickly a complete application will respond. Model size, precision, memory use, runtime, batching, preprocessing, and power mode all matter.
Orin Nano Super is not a separate Turing Pi module family
The 8GB module we tested in the setup guide is an Orin Nano running NVIDIA’s higher-performance Super configuration.
Super mode lets existing Orin Nano and Orin NX hardware run higher performance profiles supported by newer JetPack releases. It does not create a separate compute-module family.
With Super mode, Orin Nano 8GB reaches up to 67 TOPS and supports a 25W power mode, while Orin NX 16GB reaches up to 157 TOPS with power modes up to 40W. For Turing Pi 2.5 compatibility, they remain Orin Nano and Orin NX modules.
Hardware compatibility does not mean identical JetPack support
The Jetson Linux archive shows Orin Nano and Orin NX on JetPack 7.2.1 with Jetson Linux 39.2.1. Xavier NX remains on the JetPack 5 / Jetson Linux 35.x branch, while TX2 NX and Jetson Nano remain on JetPack 4 / Jetson Linux 32.x. NVIDIA has also scheduled JetPack 5 to reach end of life in Q3 2026.
That affects the kernel, CUDA generation, JetPack packages, framework support, and container compatibility. Older modules remain useful when you already own them, but Orin Nano and Orin NX provide the clearest software path for a new deployment.
2. A Jetson is a node, not an accelerator card
A Jetson installed in Turing Pi 2.5 is not a GPU that another compute module accesses over the backplane. It is a complete computer with its own CPU, GPU, memory, operating system, storage, and network identity.
If an RK1 is running a web application and an Orin Nano is running an AI model, the RK1 does not automatically gain access to the Jetson GPU. The two systems communicate over the network, just as two separate servers would.
Application node
|
| Ethernet
v
Jetson inference node
|
v
NVIDIA GPU
The application can send an API request to the Jetson, receive the result, and remain unaware of the CUDA or TensorRT details behind that endpoint. The same pattern works for vision, speech, embeddings, image generation, or classification.
Four slots do not mean one four-node supercomputer
Installing several Jetsons in one Turing Pi also does not automatically combine their GPUs or memory.
Node 1: Jetson Orin Nano
Node 2: Jetson Orin Nano
Node 3: Jetson Orin NX
Node 4: RK1
This is still four independent machines. If several Jetsons need to serve one application, the software must distribute requests or workload stages between them. A model loaded into Node 1 cannot simply use Node 2’s memory because the modules share a motherboard.
That independence is what makes deliberate workload placement possible.
3. Designing a mixed four-node system
With a standalone Jetson developer kit, it is easy to place the model, database, application, storage, API, and monitoring on one machine. Turing Pi makes it practical to assign those roles to different nodes.
Mostly self-hosting, with one AI node
Node 1: RK1 Application / API
Node 2: RK1 Database / storage
Node 3: RK1 Automation / monitoring
Node 4: Orin Nano 8GB AI inference
This is the simplest way to add NVIDIA acceleration to a conventional homelab. The RK1 nodes handle ordinary server workloads while the Orin Nano exposes inference, speech, embeddings, or vision over the network.
For the general-purpose side of that split, the Turing Pi 2.5 self-hosted apps guide covers a broader ARM homelab stack, while the RK3588 architecture deep dive explains how the RK1 behaves under real workloads.
More AI headroom
Node 1: RK1 Application services
Node 2: RK1 Database / storage
Node 3: Orin Nano Lighter inference / speech
Node 4: Orin NX Heavier inference / vision
The split does not have to be Orin Nano versus Orin NX. Two Orin Nano nodes could serve different models, or one could handle speech while the other handles embeddings or vision.
NVIDIA-heavy system
Node 1: Orin Nano
Node 2: Orin Nano
Node 3: Orin NX
Node 4: Orin NX
This makes sense when the application can use several independent accelerated workers. Requests can be routed across nodes, or different Jetsons can run different models and pipelines.
The useful unit is still the node. Turing Pi gives those nodes a compact common platform, not a shared GPU-memory pool.
Dense Jetson builds need deliberate power and cooling
A four-node Turing Pi is physically compact, but several Jetsons under sustained load place much higher demands on power and cooling than lightly loaded general-purpose nodes.
NVIDIA lists Orin Nano power options from 7W to 25W and Orin NX from 10W to 40W, depending on the module and mode. For demanding workloads, the Jetson configuration guide shows how to switch from the default quiet fan profile to cool, while the cooling guide covers heatsink installation for Orin Nano and Orin NX.
For a multi-Jetson build, size the power supply for sustained load, install suitable heatsinks, provide case airflow, and verify temperatures under the workload you actually intend to run.
You can also start with general-purpose nodes and add Jetson later when a real workload justifies it.
4. Orin Nano and Orin NX serve different roles
For most new Turing Pi builds using NVIDIA hardware, the practical choice is between Orin Nano and Orin NX.
Both use NVIDIA’s compact Orin form factor, Ampere-generation GPUs, LPDDR5 memory, and the current Jetson software stack, but their compute and memory ceilings differ substantially.
Jetson Orin Nano
NVIDIA offers Orin Nano with 4GB or 8GB of LPDDR5. With the higher-performance profiles available today, the 4GB model reaches up to 34 TOPS and the 8GB model reaches up to 67 TOPS.
The 8GB version is a useful starting point for:
- local LLM inference with appropriately sized and quantized models
- embeddings and reranking
- speech recognition
- object detection and image classification
- vision-language experiments
- internal AI APIs
- CUDA and TensorRT development
It is also the hardware we have tested directly on Turing Pi 2.5.
Eight gigabytes is useful but still a hard shared-memory limit. Model weights, the operating system, runtime overhead, KV cache, and other processes compete for the same memory.
The 4GB model belongs to the same family, but its 34 TOPS ceiling and smaller memory pool make it a meaningfully lighter choice for generative AI. It should not be treated as an 8GB Super module with only half the RAM.
Jetson Orin NX
Orin NX is the step up when the workload needs more accelerated compute or, with the 16GB module, more memory.
NVIDIA lists Orin NX 8GB at up to 117 TOPS and Orin NX 16GB at up to 157 TOPS with the higher-performance profiles available today.
The extra headroom is useful for:
- heavier computer-vision pipelines
- larger local models that fit within available memory
- more inference concurrency or batching headroom
- multiple accelerated stages on one node
- applications where 8GB becomes the main constraint
Concurrency still depends on model size, context length, precision, runtime, batching strategy, and latency target. Orin NX gives you more room; it does not guarantee a particular number of simultaneous requests.
It is also not automatically a better place for a PostgreSQL database, reverse proxy, DNS server, or Git service. The reason to choose Orin NX is accelerated work that can use its additional compute or memory.
What about Xavier NX, TX2 NX, and Jetson Nano?
Those older Jetson families remain supported on Turing Pi 2.5, which is useful if you already own them or maintain an existing deployment.
For a new purchase, the lifecycle has changed. NVIDIA’s Jetson product lifecycle lists Orin Nano and Orin NX through January 2032. NVIDIA’s May 2026 EOL update set July 15, 2026 as the last forecast and purchase-order deadline for Xavier NX and TX2 NX, with final shipments due no later than July 15, 2027. That order deadline has passed. Jetson Nano is listed through January 2027.
Combined with the older software branches, that makes Orin Nano and Orin NX the stronger foundation for a new 2026 build intended to grow over several years.
5. What can you actually build?
A shared local inference server
One Jetson can host a model runtime and expose an inference API to the rest of the network.
Laptop --------\
\
RK1 app ----------> Jetson inference API ---> Local model
/
Automation -----/
Clients do not need their own GPU or copy of the model. They send requests to one internal service and receive the result.
That can support local chat interfaces, summarization, classification, code tools, document processing, or application features without sending every request to a cloud model provider.
A private retrieval and AI system
A local document assistant is a good example of why multiple nodes are useful.
RK1: Web UI + application API
|
v
RK1: Documents + vector database
|
v
Jetson: LLM inference
Document storage and retrieval are normal server workloads. Generation is the part that benefits most directly from the Jetson GPU. Keeping those layers separate also prevents the inference node from becoming the default home for every supporting service.
A local AI camera pipeline
Jetson is a natural platform for edge vision, but the carrier and camera input matter.
For a server-style Turing Pi deployment, a network or RTSP camera is the cleanest example:
Network camera / RTSP
|
v
Jetson
Detection / classification
|
+----+----+
| |
v v
RK1 DB RK1 dashboard / automation
The Jetson processes frames while another node handles event retention, dashboards, notifications, or other integrations.
Direct CSI cameras and sensor-heavy projects need more care. The board does not expose every developer-kit peripheral to every slot, so connectivity must be checked against the actual slot I/O. For projects centered on direct cameras, sensors, and local peripherals, NVIDIA’s developer-kit carrier or another purpose-built Jetson carrier may be more convenient.
Local speech processing
A Jetson can run local transcription or other audio inference while applications elsewhere submit recordings and consume the output. That can support meeting transcription, searchable audio, voice interfaces, accessibility tools, and speech-to-LLM pipelines while keeping raw audio on the local network.
GPU-aware container and Kubernetes workloads
A mixed cluster can distinguish between general-purpose nodes and nodes with NVIDIA acceleration, then place workloads accordingly.
CPU workload ------> RK1
Database ------> RK1
Web service ------> RK1
GPU workload ------> Jetson
The important part is not Kubernetes itself. It is exposing the hardware difference to the scheduler so accelerated workloads land on nodes that can actually run them.
If you are already using k3s, the Turing Pi 2.5 RK1 setup guide and persistent storage and load-balancing guide provide the general cluster foundation.
6. What Turing Pi adds around the Jetson
The Jetson module provides the CPU, GPU, memory, media engines, and NVIDIA software stack. Turing Pi provides the environment around it.
The board combines four compute slots with an integrated 1GbE switch, BMC, four M.2 Key-M slots, SATA connectivity, and centralized power and management in a mini-ITX platform.
The available NVMe PCIe link also depends on the Jetson family: Orin NX uses PCIe 4.0 x4, Orin Nano PCIe 3.0 x4, Xavier NX PCIe 4.0 x4, TX2 NX PCIe 3.0 x2, and Nano B01 PCIe 2.0 x1. The full mapping is available in the Turing Pi 2.5 Specs and I/O Ports reference.
That difference matters for storage-heavy builds because support does not imply identical I/O capability across every module.
The BMC changes how the machines are operated as well. Nodes can be powered, accessed over serial, and placed into recovery workflows without treating each module as an isolated board on a desk.
We used that directly with Orin Nano. The module stayed installed in Turing Pi while the board exposed its recovery interface over USB OTG for flashing.
The four slots do not expose identical peripheral I/O
Board-level peripheral I/O is distributed across the four nodes like this:
| Node | Main board-level I/O |
| Node 1 | GPIO, Mini PCIe, HDMI, DSI, M.2, switchable USB 2.0 |
| Node 2 | Mini PCIe, M.2 |
| Node 3 | M.2, 2x SATA 3 |
| Node 4 | M.2, 4x USB 3.0 |
That matters when choosing where a Jetson should sit. A headless inference service may care mainly about Ethernet and NVMe. A workload that needs USB devices, display output, SATA, or another peripheral may make one slot more useful than another.
The Specs and I/O Ports reference includes the complete slot and module mapping for builds that depend on a particular peripheral.
When Turing Pi becomes the better home for a Jetson
NVIDIA’s developer kit is an excellent platform for bringing up a Jetson, testing models, and working directly with displays, cameras, USB devices, sensors, and other local peripherals.
Once the Jetson starts becoming part of a larger system, Turing Pi 2.5 offers a different advantage.
Instead of operating as a standalone development board, the Jetson becomes one managed node alongside application servers, storage, databases, monitoring, and other infrastructure. It shares the same compact platform as the rest of the system, with centralized power and management, local NVMe storage, networking between nodes, serial access, and recovery workflows available through the Turing Pi board.
That makes Turing Pi particularly useful when a Jetson moves from experimentation into a persistent service. An Orin Nano can run an inference API while an RK1 hosts the application. An Orin NX can process vision workloads while another node stores events and serves the dashboard. Additional nodes can be added or reassigned without rebuilding the Jetson itself.
Moving the module does not add compute resources to the Jetson. Performance still depends on the module, configured power mode, cooling, storage, and software stack. What changes is the system around it.
For a single Jetson with lots of directly attached peripherals, the NVIDIA developer kit remains a natural choice. For a Jetson that needs to live alongside the rest of a self-hosted or edge-compute stack, Turing Pi 2.5 gives it a much more integrated place to run.
Conclusion
NVIDIA Jetson support turns Turing Pi 2.5 into a platform that can mix conventional ARM infrastructure with GPU-accelerated edge compute.
For a new build in 2026, Orin Nano and Orin NX are the most relevant options. Orin Nano provides a practical entry point for local inference, speech, vision, embeddings, and internal AI APIs. Orin NX adds substantially more accelerated compute and a 16GB option when memory or inference headroom becomes the limiting factor.
Older Jetson modules remain useful when you already own them, but their software branches and shorter remaining availability make Orin Nano and Orin NX the more practical starting point for a new build.
The key architectural decision is not whether every node should be a Jetson. It is where accelerated work belongs. A Jetson can become the inference, vision, or speech worker while databases, storage, web services, monitoring, and automation remain on general-purpose nodes.
That is where Turing Pi’s four-node design matters: accelerated compute can be added where the workload needs it without turning the whole system into one GPU server.
FAQ
Which NVIDIA Jetson modules work with Turing Pi 2.5?
Turing Pi 2.5 supports Jetson Orin NX, Orin Nano, Xavier NX, TX2 NX, and Jetson Nano B01. The original Jetson Nano A02 is not supported.
Is Jetson Orin Nano Super a different compute module?
No. Super refers to higher supported performance modes for existing Orin hardware rather than a different Turing Pi form factor. Orin Nano 8GB reaches up to 67 TOPS and Orin Nano 4GB up to 34 TOPS with those higher-performance profiles.
Can I mix RK1 and Jetson modules in the same Turing Pi 2.5?
Yes. Supported compute modules can be mixed across the four slots. An RK1 and a Jetson remain independent computers and communicate over the network rather than sharing RAM or GPU resources.
Should I choose Orin Nano or Orin NX?
Orin Nano is a strong starting point for local inference, speech, vision, embeddings, and internal AI services. Orin NX is more appropriate when you need substantially more accelerated compute, more inference headroom, or the 16GB memory option.
Are Xavier NX, TX2 NX, and Jetson Nano still worth using?
They can be if you already own them. For new purchases, lifecycle and software support matter more. NVIDIA’s July 15, 2026 last-order deadline for Xavier NX and TX2 NX has passed, with final shipments due by July 15, 2027. Jetson Nano is listed through January 2027, while Orin Nano and Orin NX are listed through January 2032. JetPack 5, used by Xavier NX, is also scheduled to reach end of life in Q3 2026.
Are all four Turing Pi node slots identical?
No. All four can host supported modules, but board-level peripheral mapping differs. Node 1 exposes interfaces including HDMI and DSI, Node 3 carries SATA, and Node 4 carries the board’s USB 3.0 ports. Each node also has an M.2 path.
Can a Jetson use NVMe storage on Turing Pi 2.5?
Yes. Supported Jetson modules can use the node’s M.2 path, but the available PCIe link differs by Jetson family. Our Orin Nano 8GB setup boots its root filesystem directly from NVMe installed in Turing Pi 2.5. The flashing process is covered in NVIDIA Jetson Orin Nano Super on Turing Pi 2.5: Complete Setup Guide.
Can I connect cameras directly to a Jetson on Turing Pi 2.5?
It depends on the interface and slot. Network cameras are straightforward because the Jetson can consume the stream over Ethernet. Direct CSI, USB, display, or sensor-heavy designs require checking Turing Pi’s slot-specific I/O and the selected module’s compatibility.
Do I need NVIDIA’s developer-kit carrier to flash an Orin Nano for Turing Pi?
Not for the setup we tested. We flashed Jetson Linux while the Orin Nano remained installed in Turing Pi 2.5 by exposing its recovery interface through the board’s USB OTG connection.
What should I consider before running several Jetsons in one Turing Pi?
Plan power and cooling as part of the system design. Orin Nano modes reach up to 25W and Orin NX up to 40W, depending on the module and configuration. Use suitable heatsinks, provide case airflow, size the power supply for sustained load, and verify thermals under the workloads you intend to run.