本文重點
- Jetson Orin 是一個從 Nano、NX 到 AGX 的平台家族；Jetson Thor 也有 T4000 與 T5000，不是一對一型號比較。
- TOPS、FP4 TFLOPS 與特定模型 tokens/sec 的精度、測試條件不同，不能混成單一效能排名。
- Orin Nano、NX、AGX 的功耗帶從 7 W 到 60 W；Thor T4000、T5000 則是 40 W 到 130 W 等級，電力與散熱會先淘汰不適合的候選。
- Thor 的大記憶體與多感測器 I/O 是平台能力訊號，但最終仍取決於實際載板、相機、網路、容器與模型版本。
- JetPack 7 官方支援 Orin 與 Thor；Thor 採 SBSA 軟體堆疊，遷移前要重新驗證映像、周邊驅動與自訂載板。
- 高階模型可協助感知與規劃，但即時控制、急停與安全限制仍要保留在獨立且可驗證的層。
直接答案：先選工作條件，再選 Orin 或 Thor
Jetson Orin 與 Jetson Thor 都能做機器人和邊緣 AI，但它們不是單純的新舊世代替換。
- Jetson Orin 是一個從 Orin Nano、Orin NX 到 AGX Orin 的平台家族，功耗與記憶體範圍差異很大。
- Jetson Thor 目前要再分 T4000 和 T5000，面向更高記憶體、多感測器與生成式 AI 工作負載。
最穩的選法不是先問「哪個跑分比較高」，而是依序確認：
- 機器要接哪些相機、LiDAR、CAN、Ethernet 或其他 I/O？
- 模型、影像緩衝、點雲與其他程序同時要多少記憶體？
- 電池、電源、尺寸與散熱能接受多少瓦？
- 哪些工作需要低延遲，哪些工作有硬性 deadline？
- 現有的 JetPack、容器、驅動與自訂載板是否能在目標平台重現？
只有這五件事都能回答，才有意義比較模組規格。
先把官方規格放在正確位置
NVIDIA 對 Orin 與 Thor 使用的效能單位、精度和測試條件不完全相同。因此下表保留官方原始說法，但不是跨列效能排名。
| 平台 | 官方 AI 效能訊號 | 記憶體 | 官方功耗範圍 | 適合先拿來判斷什麼 |
|---|---|---|---|---|
| Jetson Orin Nano | 最高 67 TOPS | 4 GB 或 8 GB | 7 W 到 25 W | 尺寸與功耗很受限的邊緣推論；先驗證模型與影像緩衝是否放得下。 |
| Jetson Orin NX | 最高 157 TOPS | 8 GB 或 16 GB | 10 W 到 40 W | 需要比 Nano 更高推論與 I/O 餘裕、但仍有明確功耗上限的裝置。 |
| Jetson AGX Orin | 最高 275 TOPS | 32 GB、64 GB 或 Industrial 版本 | 15 W 到 60 W | 多模型、較多感測器或需要較大記憶體的機器人與場域邊緣平台。 |
| Jetson Thor T4000 | 1200 FP4 TFLOPS（sparse） | 64 GB LPDDR5X | 40 W 到 70 W | 模型、記憶體與感測器需求已超過 Orin，但功耗仍需要被控制的部署。 |
| Jetson Thor T5000 | 2070 FP4 TFLOPS（sparse） | 128 GB LPDDR5X | 40 W 到 130 W | 高記憶體、多感測器與較重的 VLM、VLA 或多模型組合；必須同步驗證電源和熱設計。 |
原始欄位可下載：JSON 選型表｜CSV 選型表。資料只整理官方公開欄位，刻意不把不同單位變成本站的效能分數。
哪些條件會讓 Thor 成為合理候選？
以下不是「一定要買 Thor」的規則，而是值得把 Thor 放進 PoC 比較的訊號：
- 模型、影像、點雲與服務程序已讓 AGX Orin 的記憶體沒有足夠餘裕。
- 機器需要多路高頻感測器，而且資料進入 GPU 的路徑是瓶頸。
- 工作負載包含較大的 VLM、VLA 或多模型並行，且已在代表性資料上量到推論或排隊問題。
- 整機可以接受 40 W 以上的電力、散熱、電池與機構成本。
- 團隊願意重新驗證作業系統映像、周邊驅動、容器、載板與現場回復流程。
Thor 的官方資料列出較大的記憶體、25 GbE 網路、相機與 PCIe 能力，也列出 JetPack 7、Holoscan、Isaac 與相關軟體堆疊。這些是系統能力的起點，不是保證任何相機、任意容器或自訂載板都能直接運作。
哪些情況先留在 Orin 比較務實？
如果下面條件成立，先把 Orin 的實機測試做紮實通常更有價值：
- 任務只需要較小的感知模型或固定功能推論，沒有明確的記憶體壓力。
- 機器是電池供電、空間有限，或熱設計不能超過既有功耗帶。
- 已有 Orin 載板、相機、CAN、Ethernet、容器與遠端維護流程，改平台的整合成本高。
- 真正瓶頸是感測器校正、資料品質、控制週期或安全流程，而不是模型吞吐。
不要把「Orin 能跑」直接寫成「所有任務都適合 Orin」。同樣地，也不要把「Thor 有更多算力」寫成「會自動提高機器人的安全或任務成功率」。
軟體遷移不是只換一塊板子
JetPack 7 官方同時列出 Orin 與 Thor 支援，但 Thor 採用 SBSA 軟體堆疊與對應安裝方式。實際遷移至少應拆成下面幾項：
| 驗證面向 | 要驗證什麼 | 不能只靠什麼判斷 |
|---|---|---|
| 系統映像與容器 | JetPack 版本、CUDA、TensorRT、ROS 2、容器基底與模型 runtime 是否可重現。 | 開發機能建置成功。 |
| 感測器與 I/O | 相機、編碼器、CAN、Ethernet、USB、PCIe 與時間同步是否在實際載板上穩定。 | 模組規格表列出介面。 |
| 模型與記憶體 | 代表性模型、相機數、並發與資料緩衝下的記憶體餘裕與 OOM 行為。 | 單一模型 Demo。 |
| 功耗與散熱 | 持續負載、環境溫度、風道與降頻下的耗電、時脈和回復狀態。 | 短時間 MAXN 跑分。 |
| 控制與安全 | 模型超時、感測器失效、網路中斷與重啟時的降級、停止與人工接管。 | 模型平均延遲或展示影片。 |
不要把供應商 benchmark 當成你的機器 benchmark
NVIDIA 的 Jetson Thor 技術文章有列出在指定模型、量化、序列長度、並發與 MAXN 模式下，Thor 與 AGX Orin 的比較結果。這類資料可用來確認某一組工作負載值得 PoC，但不能直接回答你的機器人能跑多快，因為結果還會受感測器、資料前處理、模型版本、控制頻率、散熱與實際載板影響。
要做自己的判斷，至少在代表性任務上記錄：
- 感測器輸入到模型輸出的平均、P95、P99 與最差延遲。
- 模型、影像、點雲與其他程序的記憶體上限與餘裕。
- 實際功耗、溫度、降頻、風扇與電池續航。
- 網路或感測器異常時，系統是否會受控地降級或停止。
- 模型、JetPack、驅動與載板版本是否能被記錄和回復。
選型結論
Orin 適合不是因為它比較舊或便宜，而是因為它在你的模型、感測器與功耗邊界內已經足夠；Thor 適合不是因為跑分比較大，而是因為你的真實工作負載確實需要它的記憶體、多感測器與生成式邊緣 AI 餘裕，而且整機能承受新的電力、散熱與軟體驗證成本。
先把問題量出來，再決定是否換平台。這比先選世代、最後才發現 I/O、散熱或安全流程不合格，更接近可部署的物理 AI。
常見問題
Jetson Thor 一定比 Jetson Orin 更適合嗎？
不一定。Thor 提供更高的官方算力與記憶體帶，但也落在更高功耗、散熱與整合要求。若任務的模型、相機、記憶體與控制期限已能在 Orin 的實際功耗和載板條件內穩定完成，升級不一定帶來等比例的部署價值。
Jetson Orin 的 TOPS 和 Thor 的 FP4 TFLOPS 可以直接比嗎？
不可以直接排名。TOPS 與 FP4 TFLOPS 的精度、計算方式和條件不同；特定模型的 tokens/sec 又受模型、量化、序列長度、並發與功耗模式影響。應先比較同一模型、同一測試方法和同一系統條件。
既有 Jetson Orin 軟體可以直接搬到 Thor 嗎？
JetPack 7 官方同時支援 Orin 與 Thor，但 Thor 使用 SBSA 軟體堆疊。容器、CUDA 相依套件、相機與 CAN 驅動、硬體加速、載板 BSP、開機與熱設計都要在目標平台重新驗證，不能把「有支援」當成免測遷移。
開發套件可以直接當量產機器人的主機嗎？
開發套件適合 bring-up、原型與軟體驗證。量產前仍要確認量產模組、載板、供電、散熱、介面、機構、遠端更新與供應生命週期；開發板跑得動不等於現場設備能長期運作。
Jetson 能取代工作站或安全控制器嗎？
Jetson 適合貼近機器的感測、AI 推論與部分規劃工作。工作站仍適合模擬、訓練和資料處理；安全控制、急停與硬性限制應有獨立、可驗證的機制，不能只依賴高階模型或單一邊緣電腦。