רגע! לפני שהולכים... 👋
אל תפספסו! מסלולי לימוד נפתחים בקרוב - מקומות מוגבלים
| מסלול Machine Learning | 06/10 |
| מסלול Cyber | 08/10 |
| מסלול Computer Vision | 08/10 |
| מסלול RT Embedded Linux | 04/11 |
| מסלול Full Stack | 16/11 |
✓ ייעוץ אישי ללא התחייבות | תשובה תוך 24 שעות

עודכן לאחרונה: 18 ספטמבר, 2026
אם יש לך מודל Deep Learning שעובד מצוין על שרת עם GPU ענקי, אבל קורס כשאתה מנסה להריץ אותו על התקן Edge — TensorRT הוא התשובה. מנוע האופטימיזציה של NVIDIA לוקח מודל שאומן ב-PyTorch או TensorFlow, מבצע עליו סדרה של טרנספורמציות חכמות — מיזוג שכבות, קוונטיזציה, בחירת Kernel אופטימלי לחומרה הספציפית — ויוצר "מנוע" בינארי שרץ מהר בצורה דרמטית. אנחנו מדברים על Latency שיורד מ-50 מילישניות ל-8, על Throughput שקופץ פי חמישה, ועל צריכת חשמל שמצטמצמת. במציאות הישראלית, שבה חברות ביטחון, רובוטיקה, רכב אוטונומי ו-Smart City מריצות מודלים על Jetson, Orin ו-DLA — זה לא פינוק, זה הכרח.
TensorRT (בקיצור TRT) הוא SDK של NVIDIA שמבצע אופטימיזציה ל-Inference — כלומר להרצת מודל שכבר אומן. הוא לא כלי לאימון. הוא כלי שלוקח מודל מוכן ו"מהדר" אותו לגרסה שמנצלת כל טיפת ביצועים מהחומרה שיש לך.
בניגוד להרצה רגילה דרך PyTorch או TensorFlow, שבה ה-Framework מבצע פעולות גנריות, TensorRT מנתח את הגרף החישובי של המודל ומבצע אופטימיזציות ברמה נמוכה. הוא מכיר את ה-GPU הספציפי שלך — את כמות ה-CUDA Cores, את גודל ה-Cache, את רוחב הפס של הזיכרון — ומתאים את הביצוע בדיוק אליו.
Layer Fusion: במקום להריץ Convolution, אחריו Batch Normalization, אחריו ReLU כשלוש פעולות נפרדות — TensorRT ממזג אותן לפעולה אחת. פחות גישות לזיכרון, פחות Kernel Launches, יותר מהירות.
Precision Calibration: המודל המקורי עובד ב-FP32 — 32 ביטים לכל מספר. TensorRT יודע להמיר ל-FP16 (חצי דיוק) ואפילו ל-INT8 (שמינית מהגודל) עם ירידה מינימלית בדיוק. על חומרת Jetson Orin, FP16 רץ כמעט כפול מ-FP32, ו-INT8 מוסיף עוד 30–50 אחוזים.
Kernel Auto-Tuning: TensorRT מריץ בנצ'מרקים על החומרה שלך ובוחר את ה-CUDA Kernel האופטימלי לכל פעולה. לכן תהליך הבנייה לוקח זמן — אבל התוצאה מותאמת בדיוק למכשיר שלך.
Dynamic Tensor Memory: ניהול חכם של זיכרון GPU כך שטנסורים שכבר לא נחוצים משתחררים מיד, ומרחב הזיכרון מנוצל באופן מקסימלי.
נקודת מפתח: TensorRT לא משנה את המודל שלך — הוא משנה את הדרך שבה המודל רץ על החומרה. זו אופטימיזציה ברמת ההרצה, לא ברמת הארכיטקטורה.
TensorRT הוא הבחירה הנכונה כשאתה עובד עם חומרת NVIDIA — מ-Jetson Nano ועד A100 בשרת. אם היעד שלך הוא Edge device עם GPU של NVIDIA, אין תחרות אמיתית. גם ב-Datacenter, חברות ישראליות רבות משתמשות ב-TensorRT דרך Triton Inference Server כדי לשרת אלפי בקשות Inference בשנייה.
מתי זה לא מתאים? אם החומרה שלך היא CPU בלבד, או Coral TPU של Google, או NPU של Qualcomm — TensorRT לא רלוונטי. שם תצטרך כלים אחרים כמו TensorFlow Lite, OpenVINO, או SNPE. וגם אם אתה בשלב מחקר מוקדם ועדיין משנה ארכיטקטורה כל יום — אין טעם לבצע אופטימיזציה כל פעם מחדש. TensorRT נכנס לתמונה כשהמודל קפוא ומוכן לפרודקשן.
התהליך הסטנדרטי כולל שלושה שלבים: ייצוא ל-ONNX, המרה ל-TensorRT Engine באמצעות trtexec, והרצה. בואו ניכנס לכל שלב.
ONNX (Open Neural Network Exchange) הוא פורמט ביניים סטנדרטי שמאפשר להעביר מודלים בין Frameworks. TensorRT יודע לקרוא אותו ישירות. הנה הקוד:
import torch
import torchvision.models as models
# טעינת מודל מאומן — כאן ResNet50 כדוגמה
model = models.resnet50(pretrained=True)
model.eval()
model.cuda()
# יצירת קלט דמה בגודל שהמודל מצפה לו
dummy_input = torch.randn(1, 3, 224, 224).cuda()
# ייצוא ל-ONNX
torch.onnx.export(
model,
dummy_input,
"resnet50.onnx",
export_params=True,
opset_version=17,
do_constant_folding=True,
input_names=["input"],
output_names=["output"],
dynamic_axes={
"input": {0: "batch_size"},
"output": {0: "batch_size"}
}
)
print("ONNX export complete!")
שימו לב ל-dynamic_axes — זה מאפשר להריץ את המודל עם Batch Size משתנה, מה שקריטי כשאתה רוצה לבנות Engine אחד שמשרת גם Inference בודד וגם Batch של 16.
אחרי הייצוא, כדאי לוודא שה-ONNX תקין:
import onnx
model = onnx.load("resnet50.onnx")
onnx.checker.check_model(model)
print("ONNX model is valid!")
trtexec הוא כלי שורת פקודה שמגיע עם TensorRT. הוא מבצע את כל האופטימיזציות ובונה Engine בינארי. הנה הפקודה:
# המרה בסיסית ל-FP16
trtexec \
--onnx=resnet50.onnx \
--saveEngine=resnet50_fp16.engine \
--fp16 \
--workspace=4096 \
--minShapes=input:1x3x224x224 \
--optShapes=input:8x3x224x224 \
--maxShapes=input:16x3x224x224 \
--verbose
# המרה ל-INT8 עם Calibration
trtexec \
--onnx=resnet50.onnx \
--saveEngine=resnet50_int8.engine \
--int8 \
--fp16 \
--calib=calibration_cache.bin \
--workspace=4096 \
--minShapes=input:1x3x224x224 \
--optShapes=input:8x3x224x224 \
--maxShapes=input:1x3x224x224
כמה נקודות חשובות: הדגל --fp16 מפעיל חישובים בחצי דיוק. --workspace קובע כמה MB של זיכרון GPU TensorRT יכול להשתמש בהם בזמן הבנייה (יותר = יותר אפשרויות אופטימיזציה). ה-Shapes מגדירים את טווח גדלי ה-Batch שהמנוע יתמוך בהם.
טעות נפוצה: Engine שנבנה על שרת עם RTX 4090 לא ירוץ על Jetson Orin — ולהפך. TensorRT Engine הוא ספציפי לחומרה. חובה לבנות אותו על אותו סוג GPU שעליו הוא ירוץ, או להשתמש ב-Cross-Compilation עם trtexec ועם הדגלים המתאימים.
אחרי שיש לנו קובץ .engine, נריץ אותו עם TensorRT Python API:
import tensorrt as trt
import pycuda.driver as cuda
import pycuda.autoinit
import numpy as np
from PIL import Image
import torchvision.transforms as transforms
# טעינת ה-Engine
TRT_LOGGER = trt.Logger(trt.Logger.WARNING)
def load_engine(engine_path):
with open(engine_path, "rb") as f:
runtime = trt.Runtime(TRT_LOGGER)
return runtime.deserialize_cuda_engine(f.read())
engine = load_engine("resnet50_fp16.engine")
context = engine.create_execution_context()
# הגדרת Dynamic Shape
context.set_input_shape("input", (1, 3, 224, 224))
# הקצאת זיכרון
input_shape = (1, 3, 224, 224)
output_shape = (1, 1000)
d_input = cuda.mem_alloc(np.zeros(input_shape, dtype=np.float32).nbytes)
d_output = cuda.mem_alloc(np.zeros(output_shape, dtype=np.float32).nbytes)
h_output = np.empty(output_shape, dtype=np.float32)
# עיבוד תמונה
transform = transforms.Compose([
transforms.Resize(256),
transforms.CenterCrop(224),
transforms.ToTensor(),
transforms.Normalize(mean=[0.485, 0.456, 0.406],
std=[0.229, 0.224, 0.225])
])
img = Image.open("test_image.jpg")
input_data = transform(img).unsqueeze(0).numpy()
# העתקה ל-GPU והרצה
stream = cuda.Stream()
cuda.memcpy_htod_async(d_input, input_data, stream)
context.execute_async_v2(
bindings=[int(d_input), int(d_output)],
stream_handle=stream.handle
)
cuda.memcpy_dtoh_async(h_output, d_output, stream)
stream.synchronize()
# תוצאות
predicted_class = np.argmax(h_output)
confidence = np.max(h_output)
print(f"Predicted class: {predicted_class}, Confidence: {confidence:.4f}")
הקוד הזה אמיתי ורץ כמות שהוא על Jetson Orin עם JetPack מותקן. על שרת — צריך לוודא ש-TensorRT וה-Python Bindings מותקנים.
קוונטיזציה ל-INT8 היא הקפיצה הגדולה באמת. במקום 32 ביטים למספר (FP32), אתה משתמש ב-8 ביטים. זה אומר שהמודל קטן פי 4 בזיכרון, והחישובים מהירים בהרבה — במיוחד על חומרת Jetson שיש לה Tensor Cores ייעודיים ל-INT8.
אבל — ויש "אבל" גדול — INT8 דורש Calibration. צריך להגיד ל-TensorRT מה הטווח הדינמי של הערכים בכל שכבה, כדי שהמיפוי מ-Float ל-Integer יהיה מדויק. בשביל זה צריך Dataset קטן (בדרך כלל 500–1000 תמונות מייצגות).
import tensorrt as trt
import numpy as np
import os
from PIL import Image
import torchvision.transforms as transforms
class ImageCalibrator(trt.IInt8EntropyCalibrator2):
def __init__(self, calibration_dir, batch_size=8):
super().__init__()
self.batch_size = batch_size
self.cache_file = "calibration_cache.bin"
self.transform = transforms.Compose([
transforms.Resize(256),
transforms.CenterCrop(224),
transforms.ToTensor(),
transforms.Normalize([0.485, 0.456, 0.406],
[0.229, 0.224, 0.225])
])
self.images = [os.path.join(calibration_dir, f)
for f in os.listdir(calibration_dir)
if f.endswith(('.jpg', '.png'))]
self.current_index = 0
import pycuda.driver as cuda
import pycuda.autoinit
self.device_input = cuda.mem_alloc(
batch_size * 3 * 224 * 224 * 4
)
def get_batch_size(self):
return self.batch_size
def get_batch(self, names):
if self.current_index >= len(self.images):
return None
batch = []
for i in range(self.batch_size):
if self.current_index >= len(self.images):
break
img = Image.open(self.images[self.current_index])
img = self.transform(img).numpy()
batch.append(img)
self.current_index += 1
batch = np.array(batch, dtype=np.float32)
import pycuda.driver as cuda
cuda.memcpy_htod(self.device_input, batch)
return [int(self.device_input)]
def read_calibration_cache(self):
if os.path.exists(self.cache_file):
with open(self.cache_file, "rb") as f:
return f.read()
return None
def write_calibration_cache(self, cache):
with open(self.cache_file, "wb") as f:
f.write(cache)
לפי מחקרים של NVIDIA עצמם, ברוב מודלי ה-Classification וה-Detection, ירידת הדיוק ב-INT8 עם Calibration טובה היא פחות מ-1%. על YOLO למשל, מדובר בירידה של 0.3–0.5 mAP בלבד — בזמן שה-Throughput כמעט מכפיל את עצמו.
| קריטריון | TensorRT | ONNX Runtime | OpenVINO | TFLite |
|---|---|---|---|---|
| חומרת יעד | NVIDIA GPU בלבד | CPU, GPU, NPU (רב-פלטפורמי) | Intel CPU/GPU/VPU | ARM CPU, Coral TPU, GPU |
| ביצועים על NVIDIA GPU | ⭐ הטוב ביותר | טוב (עם TRT backend) | לא רלוונטי | לא רלוונטי |
| תמיכה ב-INT8 | מלאה עם Calibration | חלקית | מלאה עם POT | מלאה עם PTQ/QAT |
| Dynamic Shapes | כן (עם Min/Opt/Max) | כן | חלקית | מוגבלת |
| קלות שימוש | בינונית — עקומת למידה | פשוטה מאוד | פשוטה | פשוטה |
| תמיכה ב-Transformers | כן — BERT, GPT, ViT | כן | כן | חלקית |
| פריסה בפרודקשן | Triton Inference Server | ONNX Runtime Server | OpenVINO Model Server | TF Serving / Edge TPU |
| רישיון | חינמי (Proprietary) | MIT | Apache 2.0 | Apache 2.0 |
השורה התחתונה ברורה: אם אתה עובד על חומרת NVIDIA — ובשוק הישראלי, Jetson ו-DGX נמצאים בכל מקום מחברות ביטחון ועד סטארטאפים של AgriTech — אין סיבה שלא להשתמש ב-TensorRT. על חומרה אחרת, כל כלי מתאים לאקוסיסטם שלו.
YOLO הוא כנראה מודל ה-Object Detection הפופולרי ביותר בפרויקטי Edge AI בישראל — מזיהוי עצמים בקו ייצור, דרך מערכות מעקב ועד דרונים. הנה התהליך המלא להאצה שלו:
# על Jetson Orin עם JetPack מותקן
# שלב 1: התקנת ultralytics
pip install ultralytics
# שלב 2: ייצוא ל-TensorRT ישירות מ-ultralytics
yolo export model=yolov8n.pt format=engine device=0 half=True imgsz=640
# זה ייצור קובץ yolov8n.engine מוכן להרצה
# שלב 3: הרצת Inference עם ה-Engine
yolo predict model=yolov8n.engine source=test_video.mp4 device=0
ספריית ultralytics עושה את כל העבודה הכבדה — ייצוא ONNX, המרה ל-TensorRT, ואופטימיזציה — בפקודה אחת. אבל אם אתה צריך שליטה מלאה, הנה הגרסה הידנית:
# ייצוא ידני ל-ONNX ואז ל-TensorRT
python -c "
from ultralytics import YOLO
model = YOLO('yolov8n.pt')
model.export(format='onnx', imgsz=640, simplify=True)
"
# המרה עם trtexec ושליטה מלאה על הפרמטרים
trtexec \
--onnx=yolov8n.onnx \
--saveEngine=yolov8n_int8.engine \
--int8 \
--fp16 \
--workspace=4096 \
--minShapes=images:1x3x640x640 \
--optShapes=images:4x3x640x640 \
--maxShapes=images:8x3x640x640 \
--buildOnly
על Jetson Orin NX עם 16GB RAM, YOLOv8n ב-FP16 רץ ב-3.5ms לפריים — כלומר מעל 280 FPS. ב-INT8 אפשר להגיע ל-2.1ms. לשם השוואה, PyTorch רגיל נותן כ-12ms לאותו מודל על אותה חומרה. זה ההבדל בין מצלמת אבטחה ש"רואה" בזמן אמת לכזו שמפספסת כל פריים שני.
התשובה הקצרה: לא, אם עושים את זה נכון. לפי מדידות שפרסמה NVIDIA על מגוון רחב של מודלים, ה-Drop בדיוק ב-FP16 הוא כמעט אפסי — פחות מ-0.1% ברוב המקרים. ב-INT8 עם Calibration נכונה, הירידה היא בטווח של 0.1–1%. על מודלים מסוימים, INT8 אפילו שיפר ביצועים בזכות אפקט של רגולריזציה.
הכלל: ככל שהמודל גדול יותר, כך הוא סובלני יותר לקוונטיזציה. מודל עם מיליוני פרמטרים "סופג" את אובדן הדיוק הרבה יותר טוב ממודל זעיר. ואם Calibration לא מספיקה — יש QAT (Quantization-Aware Training) שבו המודל מאומן מראש "לדעת" שהוא יעבוד ב-INT8.
שורה תחתונה לפועלים: התחילו תמיד עם FP16 — זה Zero-Risk Optimization. עברו ל-INT8 רק אחרי שיש לכם Dataset calibration ייצוגי, ומדדו את הדיוק לפני ואחרי. אל תנחשו — מדדו.
במציאות של פרודקשן, אתה לא מריץ סקריפט Python. אתה צריך שרת Inference שיודע לקבל בקשות HTTP/gRPC, לנהל מודלים מרובים, לעשות Dynamic Batching, ולמקסם את ניצול ה-GPU. כאן נכנס Triton — שרת קוד פתוח של NVIDIA שתומך ב-TensorRT engines כ-Backend.
# מבנה תיקיות למודל ב-Triton
model_repository/
└── yolov8_detector/
├── config.pbtxt
└── 1/
└── model.plan # זה ה-TensorRT engine שבנינו
# תוכן config.pbtxt
cat > model_repository/yolov8_detector/config.pbtxt << 'EOF'
name: "yolov8_detector"
platform: "tensorrt_plan"
max_batch_size: 16
input [
{
name: "images"
data_type: TYPE_FP16
dims: [ 3, 640, 640 ]
}
]
output [
{
name: "output0"
data_type: TYPE_FP16
dims: [ 84, 8400 ]
}
]
dynamic_batching {
preferred_batch_size: [ 4, 8, 16 ]
max_queue_delay_microseconds: 100
}
instance_group [
{
count: 2
kind: KIND_GPU
}
]
EOF
# הרצת Triton Server
docker run --gpus all --rm -p 8000:8000 -p 8001:8001 -p 8002:8002 \
-v $(pwd)/model_repository:/models \
nvcr.io/nvidia/tritonserver:latest \
tritonserver --model-repository=/models
עם ההגדרה הזו, Triton יבצע Dynamic Batching אוטומטי — אם מגיעות 16 בקשות בודדות בתוך 100 מיקרושניות, הוא יאגד אותן ל-Batch אחד ויריץ Inference יחיד. זה מכפיל את ה-Throughput בצורה דרמטית.
TensorRT הוא הכלי הכי חזק שיש כיום להאצת מודלי Deep Learning על חומרת NVIDIA — בין אם זה Jetson Orin Nano בשטח ובין אם זה A100 ב-Datacenter. התהליך דורש עבודה — ייצוא ל-ONNX, בניית Engine, ולפעמים Calibration ל-INT8 — אבל התוצאות מצדיקות כל רגע.
עודכן: 2026-09-17
כן. TensorRT תוכנן ומותאם באופן בלעדי לחומרת NVIDIA — מ-Jetson Nano ועד H100 ב-Datacenter. אם אתה עובד על Intel, תסתכל על OpenVINO. על Qualcomm — SNPE. על ARM בלי GPU — TensorFlow Lite. אין כלי אחד שמתאים לכולם, ו-TensorRT עושה דבר אחד ועושה אותו הכי טוב: NVIDIA GPUs.
ONNX Runtime הוא Framework הרצה רב-פלטפורמי שיכול לרוץ על CPU, GPU ו-NPU ממגוון יצרנים. TensorRT הוא מנוע אופטימיזציה שמוציא את המקסימום מ-NVIDIA GPUs ספציפיים. בפועל, אפשר להשתמש ב-ONNX Runtime עם TensorRT כ-Execution Provider — כלומר לקבל את ה-API הנוח של ONNX Runtime עם הביצועים של TensorRT. זו אפשרות מצוינת כשרוצים פשטות ללא ירידת ביצועים משמעותית.
תלוי בגודל המודל, במורכבות הגרף, ובחומרה. מודל קל כמו YOLOv8n ייבנה תוך 2–5 דקות. מודל גדול כמו ResNet152 עם INT8 Calibration יכול לקחת 20–40 דקות. מודלי Transformer גדולים — שעה ומעלה. הבנייה מתבצעת פעם אחת, וה-Engine שנוצר נשמר לקובץ ונטען מיידית בהרצות הבאות.
בהחלט. התהליך: ייצוא המודל ל-ONNX באמצעות ספריית optimum של Hugging Face, ואז המרה ל-TensorRT עם trtexec. לחלופין, NVIDIA פרסמה את TensorRT-LLM — כלי ייעודי להאצת מודלי שפה גדולים (LLMs) שמטפל בכל המורכבות של Attention Layers, KV-Cache ו-Tensor Parallelism. בשוק הישראלי, חברות רבות כבר משתמשות בזה להרצת מודלי שפה מקומיים על שרתים פרטיים.
trtexec מושלם לפרוטוטייפ מהיר ולבנצ'מרקים. אם כל מה שאתה צריך זה להמיר מודל ולבדוק ביצועים — trtexec עם הדגל --benchmark נותן את התשובה בדקות. Python API (או C++ API) נדרש כשצריך שליטה מלאה — Custom Plugins, Calibration מותאמת אישית, אינטגרציה לתוך Pipeline קיים. ברוב הפרויקטים, מתחילים עם trtexec ועוברים ל-API רק כשצריך.
כן, אבל עם מגבלות. צריך להגדיר מראש Min, Optimal ו-Max shapes בזמן בניית ה-Engine. TensorRT ימצא את ה-Kernel הטוב ביותר עבור ה-Optimal Shape, אבל יתמוך בכל גודל בטווח. שימו לב: ככל שהטווח רחב יותר, כך האופטימיזציה פחות אגרסיבית. אם אתם יודעים שהקלט תמיד באותו גודל — עדיף Static Shapes לביצועים מקסימליים.
TensorRT לא תומך בכל אופרטור ONNX. כשנתקלים בשכבה לא נתמכת, יש שלוש אפשרויות: (1) להחליף את השכבה בגרסה תואמת — למשל Swish במקום Custom Activation; (2) לכתוב TensorRT Plugin מותאם ב-C++ שמממש את הפעולה; (3) להשתמש ב-ONNX Runtime עם TRT EP, שמריץ שכבות נתמכות ב-TensorRT ושכבות אחרות ב-CUDA/CPU. האפשרות השלישית היא לרוב הכי פרקטית כשלא רוצים להשקיע בכתיבת Plugins.
המדריך הזה מכסה את הבסיס — ויש עוד הרבה עומק. מ-TensorRT-LLM למודלי שפה גדולים, דרך DeepStream לניתוח וידאו בזמן אמת, ועד אופטימיזציות מתקדמות עם Custom Plugins. אם בא לכם להעמיק, ללכלך ידיים על חומרה אמיתית, ולבנות את הכישורים שהתעשייה הישראלית צמאה להם — יש מדריכים נוספים ומסלולי הכשרה מעשיים באתר rt-ed.co.il. הדלת פתוחה.