Jetson Orin vs Jetson Thor：機器人運算平台怎麼選？

直接答案：先選工作條件，再選 Orin 或 Thor

Jetson Orin 與 Jetson Thor 都能做機器人和邊緣 AI，但它們不是單純的新舊世代替換。

• Jetson Orin 是一個從 Orin Nano、Orin NX 到 AGX Orin 的平台家族，功耗與記憶體範圍差異很大。
• Jetson Thor 目前要再分 T4000 和 T5000，面向更高記憶體、多感測器與生成式 AI 工作負載。
• T3000 emulation 是 JetPack 7.2.1 在 AGX Thor Developer Kit 上提供的軟體驗證路徑；不能把它、產品 roadmap 與已在目標硬體可驗證的型號混成同一個「已上市」結論。

最穩的選法不是先問「哪個跑分比較高」，而是依序確認：

1. 機器要接哪些相機、LiDAR、CAN、Ethernet 或其他 I/O？
2. 模型、影像緩衝、點雲與其他程序同時要多少記憶體？
3. 電池、電源、尺寸與散熱能接受多少瓦？
4. 哪些工作需要低延遲，哪些工作有硬性 deadline？
5. 現有的 JetPack、容器、驅動與自訂載板是否能在目標平台重現？

只有這五件事都能回答，才有意義比較模組規格。

先把官方規格放在正確位置

NVIDIA 對 Orin 與 Thor 使用的效能單位、精度和測試條件不完全相同。因此下表保留官方原始說法，但不是跨列效能排名。

原始欄位可下載：JSON 選型表｜CSV 選型表。資料只整理官方公開欄位，刻意不把不同單位變成本站的效能分數。

2026-08 版本與產品狀態：別把模擬模式當成型號已落地

JetPack、開發套件、emulation 與量產模組回答的是不同問題。官方文件可以說明某個軟體版本提供了什麼路徑；它不能替你保證某個模組已供貨、某個載板能相容，或某個機器人的現場條件已通過。

為避免 release 名稱、模擬和量產狀態在交接時混在一起，本站提供可下載的JetPack 7.2 migration evidence checklist JSON｜CSV。它是本頁編輯方法的空白／證據欄位提示，不是升級腳本、相容性保證、採購清單或安全認證。

哪些條件會讓 Thor 成為合理候選？

以下不是「一定要買 Thor」的規則，而是值得把 Thor 放進 PoC 比較的訊號：

• 模型、影像、點雲與服務程序已讓 AGX Orin 的記憶體沒有足夠餘裕。
• 機器需要多路高頻感測器，而且資料進入 GPU 的路徑是瓶頸。
• 工作負載包含較大的 VLM、VLA 或多模型並行，且已在代表性資料上量到推論或排隊問題。
• 整機可以接受 40 W 以上的電力、散熱、電池與機構成本。
• 團隊願意重新驗證作業系統映像、周邊驅動、容器、載板與現場回復流程。

Thor 的官方資料列出較大的記憶體、25 GbE 網路、相機與 PCIe 能力，也列出 JetPack 7、Holoscan、Isaac 與相關軟體堆疊。這些是系統能力的起點，不是保證任何相機、任意容器或自訂載板都能直接運作。

在比較平台前，可先用機器人感測器資料量計算器把相機、已量測 ROS 2 topic、寫入速度與保存 TB 算出來；工具只做容量預算，不會替你驗證 CSI／GMSL、USB root hub、載板路由或 rosbag2 穩定性。真正接上多路相機後，請用Jetson 多相機掉幀驗收流程逐層隔離相機、API、ROS 2 與儲存。

哪些情況先留在 Orin 比較務實？

如果下面條件成立，先把 Orin 的實機測試做紮實通常更有價值：

• 任務只需要較小的感知模型或固定功能推論，沒有明確的記憶體壓力。
• 機器是電池供電、空間有限，或熱設計不能超過既有功耗帶。
• 已有 Orin 載板、相機、CAN、Ethernet、容器與遠端維護流程，改平台的整合成本高。
• 真正瓶頸是感測器校正、資料品質、控制週期或安全流程，而不是模型吞吐。

不要把「Orin 能跑」直接寫成「所有任務都適合 Orin」。同樣地，也不要把「Thor 有更多算力」寫成「會自動提高機器人的安全或任務成功率」。

軟體遷移不是只換一塊板子

JetPack 7 的官方文件同時列出 Orin 與 Thor 支援，但 Thor 採用 SBSA 軟體堆疊與對應安裝方式。JetPack 7.2.1 也特別提醒 Thor 的手動燒錄說明有變動；從 JetPack 7 起，Orin Nano Developer Kit 不再有 SD card image，應依官方文件改用統一 ISO。這些是版本與安裝方法的變動訊號，不是「更新後自然可用」的保證。實際遷移至少應拆成下面幾項：

不要把供應商 benchmark 當成你的機器 benchmark

NVIDIA 的 Jetson Thor 技術文章有列出在指定模型、量化、序列長度、並發與 MAXN 模式下，Thor 與 AGX Orin 的比較結果。這類資料可用來確認某一組工作負載值得 PoC，但不能直接回答你的機器人能跑多快，因為結果還會受感測器、資料前處理、模型版本、控制頻率、散熱與實際載板影響。

要做自己的判斷，至少在代表性任務上記錄：

1. 感測器輸入到模型輸出的平均、P95、P99 與最差延遲。
2. 模型、影像、點雲與其他程序的記憶體上限與餘裕。
3. 實際功耗、溫度、降頻、風扇與電池續航。
4. 網路或感測器異常時，系統是否會受控地降級或停止。
5. 模型、JetPack、驅動與載板版本是否能被記錄和回復。

選型結論

Orin 適合不是因為它比較舊或便宜，而是因為它在你的模型、感測器與功耗邊界內已經足夠；Thor 適合不是因為跑分比較大，而是因為你的真實工作負載確實需要它的記憶體、多感測器與生成式邊緣 AI 餘裕，而且整機能承受新的電力、散熱與軟體驗證成本。

先把問題量出來，再決定是否換平台。這比先選世代、最後才發現 I/O、散熱或安全流程不合格，更接近可部署的物理 AI。