The wrapper approach works, but we would prefer to know whether the High-Level API is the officially recommended path for new Jetson Thor projects.
Questions:
Is the TensorRT-Edge-LLM High-Level Python API currently officially supported on Jetson AGX Thor with JetPack 7.2?
Is the “No math backend found” error a known issue on Jetson Thor?
Is there a missing backend, environment variable, build flag, or package required for the High-Level API on Thor?
Does NVIDIA currently recommend using the low-level llm_inference binary with a custom wrapper until the High-Level API is stable?
Is there a roadmap for production-ready High-Level Python API support on Jetson Thor?
We are not looking for a general installation guide.
We already have the low-level runtime working.
We mainly need architectural guidance so we can decide whether to continue with the wrapper architecture or invest more time into the High-Level Python API.
Server and API
Expanded high-level Python API and server validation for LLM, VLM, and streaming flows
Following might help with the math backend part.
Are you using any of these existing python packages? The version numbers may be old in a few cases. This is on Jetpack 7.2 Thor in a venv where I’ve got a wide variety of packages. One of the main, I would think would be to search pypi.org for cu13 and get torch with cuda; pip install torch torchvision --index-url https://download.pytorch.org/whl/cu132. I’ve also attached a pip freeze of the packages that are installed in another venv for trtllmEdge; I modified its requirements.txt to install torch with Cuda. trtllmEdge.txt (6.8 KB)
Here are the installable, or installed Cuda math libraries
edit: first run pip freeze | tee requirements.txt so you can return to where you are now if needed.
You could then try this to see if it resolves problem. pip install -U torch==2.12.0 torchvision==0.27.0 --index-url https://download.pytorch.org/whl/cu132
I finally got the TensorRT-Edge-LLM Python High-Level Runtime working on Jetson Thor (JetPack 7.2).
For reference, my environment is:
Jetson Thor
JetPack 7.2
CUDA 13.2
TensorRT 10.16.2.10
TensorRT-Edge-LLM 0.8
Python 3.12
The initial problems were not related to TensorRT itself.
The Python environment required several additional packages that were not installed automatically in my setup:
nvmath-python
nvidia-modelopt
requests
pydantic
einops
After installing these packages, all TensorRT-Edge-LLM Python modules imported successfully.
The only remaining issue was building the experimental Python runtime (_edgellm_runtime). During the CMake build I consistently received:
fatal error: math.h: No such file or directory
I spent quite some time isolating the problem.
The following tests all succeeded:
/usr/include/math.h exists.
Standalone CUDA programs compile correctly.
CUDA + <cuda_runtime.h> + <cmath> compile correctly.
device_link_stub.cu compiles correctly when built manually with nvcc.
The failure only occurred during the CMake build of _edgellm_runtime.
After resolving that build issue, the runtime compiled successfully:
_edgellm_runtime.cpython-312-aarch64-linux-gnu.so
Verification:
runtime import OK
LLMRuntime OK
TEXT: Hello there!
IDS: 4
The High-Level Python Runtime is now working correctly on Jetson Thor.
I’m still investigating the exact root cause of the math.h build issue, but I wanted to share the successful result in case it helps others working with TensorRT-Edge-LLM on Thor.
I had encountered the same missing math.h error when I last built TensorRT-Edge-LLM on Thor. After your errors thought other people might get them too. Looked at it again and did 2 small pr as follows. This includes how I built TensorRT-Edge-LLM.
diff --git a/experimental/pybind/CMakeLists.txt b/experimental/pybind/CMakeLists.txt
index 855f8bc..daa94de 100644
--- a/experimental/pybind/CMakeLists.txt
+++ b/experimental/pybind/CMakeLists.txt
@@ -111,6 +111,31 @@ find_package(
REQUIRED)
find_package(pybind11 CONFIG REQUIRED)
+# ── Work around Debian/Ubuntu pybind11-dev exporting /usr/include ─────────
+# The apt-installed `pybind11-dev` package ships a CMake config whose
+# `pybind11::pybind11_headers` target sets
+# INTERFACE_INCLUDE_DIRECTORIES = ${_IMPORT_PREFIX}/include
+# and `_IMPORT_PREFIX` resolves to `/usr`, so `/usr/include` gets propagated
+# to every consumer via `-isystem`. When nvcc then invokes host g++ on a CUDA
+# source, `-isystem /usr/include` reorders g++'s system header chain and
+# places `/usr/include` before `/usr/include/c++/<ver>`. libstdc++'s <cmath>
+# uses `#include_next <math.h>`, which now finds nothing after itself in the
+# search order, and compilation fails with:
+# /usr/include/c++/13/cmath: fatal error: math.h: No such file or directory
+# Filter `/usr/include` out of the interface so the real pybind11 headers
+# (in a subdirectory under _IMPORT_PREFIX) are still exposed but the bogus
+# root include is not. No-op for pip-installed pybind11 (its _IMPORT_PREFIX
+# points at the venv's site-packages, not /usr).
+if(TARGET pybind11::pybind11_headers)
+ get_target_property(_pybind11_iface_inc pybind11::pybind11_headers
+ INTERFACE_INCLUDE_DIRECTORIES)
+ if(_pybind11_iface_inc)
+ list(REMOVE_ITEM _pybind11_iface_inc "/usr/include")
+ set_property(TARGET pybind11::pybind11_headers PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES "${_pybind11_iface_inc}")
+ endif()
+endif()
+
# ── Header include paths (from source tree) ───────────────────────────────
set(EDGELLM_INCLUDE_DIRS
${EDGELLM_ROOT}/cpp ${EDGELLM_ROOT}/examples/multimodal
I also ended up with a working build, but only after isolating the pybind/device-link build path. Good to know that the math.h issue is reproducible on Thor and that you already opened PRs for it.
For now I will keep my current working build, but I’ll watch the PRs and rebuild from a clean checkout once the fixes are merged.
Thanks for taking the time to document your build steps.