YOLO Vision 2026:

Exportação de modelos com Ultralytics YOLO#

Ultralytics YOLO ecosystem and integrations

Introdução#

O objetivo final de treinar um modelo é implantá-lo para aplicações no mundo real. O modo de exportação no Ultralytics YOLO26 oferece uma gama versátil de opções para exportar o teu modelo treinado para diferentes formatos, tornando-o implantável em várias plataformas e dispositivos. Este guia abrangente visa orientar-te sobre as nuances da exportação de modelos, mostrando como alcançar a máxima compatibilidade e desempenho.



Watch: How to Export Ultralytics YOLO26 in different formats for Deployment | ONNX, TensorRT, CoreML 🚀

Por que escolher o modo de exportação do YOLO26?#

  • Versatilidade: Exporta para múltiplos formatos, incluindo ONNX, TensorRT, CoreML e muito mais.
  • Desempenho: Obtém até 5x de aceleração em GPU com TensorRT e 3x de aceleração em CPU com ONNX ou OpenVINO.
  • Compatibilidade: Torna o teu modelo universalmente implantável em inúmeros ambientes de hardware e software.
  • Facilidade de uso: CLI simples e API Python para uma exportação de modelos rápida e direta.

Principais funcionalidades do modo de exportação#

Aqui estão algumas das funcionalidades de destaque:

  • Exportação com um clique: Comandos simples para exportar para diferentes formatos.
  • Exportação em lote: Exporta modelos capazes de inferência em lote.
  • Inferência otimizada: Modelos exportados são otimizados para tempos de inferência mais rápidos.
  • Vídeos tutoriais: Guias aprofundados e tutoriais para uma experiência de exportação fluida.
Dica
  • Exporta para ONNX ou OpenVINO para obter até 3x de aceleração em CPU.
  • Exporta para TensorRT para obter até 5x de aceleração em GPU.

Exemplos de uso#

Exporta um modelo YOLO26n para um formato diferente como ONNX ou TensorRT. Vê a secção de Argumentos abaixo para uma lista completa de argumentos de exportação.

Exemplo
from ultralytics import YOLO

# Load a model
model = YOLO("yolo26n.pt")  # load an official model
model = YOLO("path/to/best.pt")  # load a custom-trained model

# Export the model
model.export(format="onnx")

Argumentos#

Esta tabela detalha as configurações e opções disponíveis para exportar modelos YOLO para diferentes formatos. Estas definições são críticas para otimizar o desempenho, o tamanho e a compatibilidade do modelo exportado em várias plataformas e ambientes. A configuração adequada garante que o modelo esteja pronto para implantação na aplicação pretendida com eficiência ideal.

ArgumentoTipoPredefiniçãoDescrição
formatstr'torchscript'Formato de destino para o modelo exportado, como 'onnx', 'torchscript', 'engine' (TensorRT) ou outros. Cada formato permite compatibilidade com diferentes deployment environments.
namestrNoneNome do destino de hardware para os formatos que exigem um: arquitetura Hailo ('hailo8', 'hailo8l', 'hailo10h', 'hailo15h', 'hailo15l'; predefinição: 'hailo8l'), chip Rockchip RKNN (predefinição: 'rk3588'), SoC Huawei Ascend (um --soc_version do CANN; predefinição: 'Ascend310B4') ou destino Qualcomm QNN HTP (predefinição: '73'). Distinto do par de nomes de execução project/name utilizado por outros modos.
imgszint ou tuple640Tamanho de imagem desejado para a entrada do modelo. Pode ser um número inteiro para imagens quadradas (por exemplo, 640 para 640×640) ou uma tupla (height, width) para dimensões específicas.
kerasboolFalseAtiva a exportação para o formato Keras para o SavedModel do TensorFlow, fornecendo compatibilidade com o serviço e APIs do TensorFlow.
optimizeboolFalseAtiva uma maior otimização do compilador para DEEPX, reduzindo a latência de inferência enquanto aumenta o tempo de compilação.
quantizeint ou strNonePrecisão da quantização: 16 (FP16, reduz o tamanho do modelo e pode acelerar a inferência em hardware compatível) ou 8 (INT8/PTQ, comprime ainda mais o modelo com perda mínima de accuracy, principalmente para edge devices; precisa de calibração data/fraction); 32/não definido é FP32. Formatos de exportação que suportam precisão mista de peso/ativação também aceitam a notação 'w8a8'/'w16a16'/'w8a16'/'w8a32'. Substitui os sinalizadores obsoletos half/int8 (half=True16, int8=True8, ainda aceitos com um aviso de obsolescência). Apenas as precisões suportadas pelo formato de destino são permitidas (veja abaixo).
dynamicboolFalsePermite tamanhos de entrada dinâmicos para exportações de TorchScript, ONNX, OpenVINO, TensorRT e CoreML, aumentando a flexibilidade ao lidar com dimensões de imagem variadas.
simplifyboolTrueSimplifica o grafo ONNX intermediário com onnxslim para as exportações que criam um (consulte Export Formats), melhorando potencialmente o desempenho e a compatibilidade com os mecanismos de inferência.
opsetintNoneEspecifica a versão do opset ONNX para as exportações que constroem um grafo ONNX (consulte Export Formats), para compatibilidade com diferentes analisadores e tempos de execução do ONNX. Se não for definido, usa a versão mais recente suportada.
workspacefloat ou NoneNoneDefine o tamanho máximo do espaço de trabalho em GiB para as otimizações do TensorRT, equilibrando o uso de memória e o desempenho. Use None para alocação automática pelo TensorRT até o máximo do dispositivo.
nmsboolFalseAdiciona Non-Maximum Suppression (NMS) ao modelo exportado quando suportado (consulte Export Formats), melhorando a eficiência do pós-processamento de detecção. Não disponível para modelos end2end. Para o CoreML, é suportado apenas para modelos de detecção.
conffloatNoneLimite de confiança usado sempre que o NMS em tempo de exportação é gerado: exportações nms=True; exportações de deteção não end-to-end da Hailo; e exportações de deteção, pose e segmento da IMX, que forçam internamente nms=True. O valor predefinido é 0.25 quando não definido, exceto para exportações da IMX, cuja predefinição é 0.001.
ioufloat0.7Limite de IoU usado sempre que o NMS em tempo de exportação é gerado: exportações nms=True; exportações de deteção não end-to-end da Hailo; e exportações de deteção, pose e segmento da IMX, que forçam internamente nms=True.
max_detint300Número máximo de deteções mantidas na saída do modelo exportado. Aplica-se a exportações nms=True em todos os formatos, exceto CoreML, cujo pipeline NMS não tem limite de deteções, além de exportações de deteção end-to-end sem NMS (YOLO26, YOLOv10, limitadas ao número de âncoras disponíveis) e exportações de deteção, pose e segmento da IMX.
agnostic_nmsboolFalseAtiva a NMS agnóstica de classes onde quer que a NMS em tempo de exportação seja gerada através do pipeline padrão nms=True, incluindo o próprio estágio de NMS do CoreML, suprimindo caixas sobrepostas com pontuações mais baixas entre diferentes classes, em vez de apenas dentro da mesma classe. Não é respeitado pelas configurações de NMS geradas pelo Hailo ou pelo IMX, que não têm opção agnóstica de classes e permanecem conscientes das classes independentemente desta flag. Também integrado em exportações de ponta a ponta sem NMS (YOLO26, YOLOv10), onde apenas evita que a mesma deteção apareça sob múltiplos rótulos de classe (duplicados com IoU=1.0), e não a supressão por limiar de IoU entre caixas distintas.
batchint1Especifica o tamanho da inferência em lote do modelo de exportação ou o número máximo de imagens que o modelo exportado processará simultaneamente no modo predict. Para exportações do Edge TPU, isso é definido automaticamente como 1.
devicestrNoneEspecifica o dispositivo para exportação: GPU (device=0), CPU (device=cpu), MPS para Apple silicon (device=mps), Huawei Ascend NPU (device=npu ou device=npu:0) ou DLA para NVIDIA Jetson (device=dla:0 ou device=dla:1). As exportações do TensorRT usam automaticamente a GPU, mas o TensorRT 11.0 não suporta DLA.
verboseboolTrueEleva o registo do construtor do TensorRT para a gravidade VERBOSE durante a exportação format='engine'. Outros formatos de exportação ignoram-no.
datastrNoneCaminho para o YAML do dataset, essencial para a calibração da quantização INT8; a classificação, em alternativa, aceita um diretório de dataset ou o nome de um dataset integrado. Se não for especificado com o INT8 ativado, o Ultralytics seleciona um dataset de calibração específico da tarefa quando necessário, ou recorre ao dataset predefinido para a tarefa do modelo.
splitstr'val'Divisão do dataset ('train', 'val' ou 'test') utilizada para construir o dataloader de calibração de quantização INT8 a partir de data.
fractionfloat1.0Especifica a fração do conjunto de dados a ser usada para calibração de quantização INT8. Permite calibrar em um subconjunto do conjunto de dados completo, útil para experimentos ou quando os recursos são limitados. Se não especificado com INT8 ativado, o conjunto de dados completo será usado.
end2endboolNoneSubstitui o modo ponta a ponta em modelos YOLO que suportam inferência sem NMS (YOLO26, YOLOv10). Configurá-lo como False permite exportar esses modelos para serem compatíveis com o pipeline tradicional de pós-processamento baseado em NMS. Consulte o End-to-End Detection guide para obter detalhes.

Ajustar estes parâmetros permite personalizar o processo de exportação para atender a requisitos específicos, tais como o ambiente de implementação, restrições de hardware e metas de desempenho. Selecionar o formato e as configurações adequadas é essencial para alcançar o melhor equilíbrio entre o tamanho do modelo, a velocidade e a precisão.

Formatos de Exportação#

Os formatos de exportação disponíveis para o YOLO26 encontram-se na tabela abaixo. Podes exportar para qualquer formato utilizando o argumento format, por exemplo, format='onnx' ou format='engine'. Podes prever ou validar diretamente em modelos exportados, ou seja, yolo predict model=yolo26n.onnx. São mostrados exemplos de uso para o teu modelo após a conclusão da exportação. Os modelos também podem ser exportados diretamente do navegador na Ultralytics Platform sem qualquer configuração local.

FormatoArgumento formatModeloMetadadosArgumentos
PyTorch-yolo26n.pt-
TorchScripttorchscriptyolo26n.torchscriptimgsz, quantize, dynamic, nms, batch, device
ONNXonnxyolo26n.onnximgsz, quantize, dynamic, simplify, opset, nms, batch, data, fraction, device
OpenVINOopenvinoyolo26n_openvino_model/imgsz, quantize, dynamic, nms, batch, data, fraction, device
TensorRTengineyolo26n.engineimgsz, quantize, dynamic, simplify, opset, workspace, nms, batch, data, fraction, device
CoreMLcoremlyolo26n.mlpackageimgsz, dynamic, quantize, nms, batch, device
TF SavedModelsaved_modelyolo26n_saved_model/imgsz, keras, quantize, opset, nms, batch, data, fraction, device
TF GraphDefpbyolo26n.pbimgsz, opset, batch, device
TF Edge TPUedgetpuyolo26n_edgetpu.tfliteimgsz, quantize, opset, data, fraction, device
PaddlePaddlepaddleyolo26n_paddle_model/imgsz, batch, device
MNNmnnyolo26n.mnnimgsz, batch, dynamic, quantize, simplify, opset, nms, device
NCNNncnnyolo26n_ncnn_model/imgsz, quantize, batch, device
IMX500imxyolo26n_imx_model/imgsz, quantize, data, fraction, nms, device
RKNNrknnyolo26n_rknn_model/imgsz, batch, name, quantize, simplify, opset, data, fraction, device
ExecuTorchexecutorchyolo26n_executorch_model/imgsz, batch, device
Axeleraaxelerayolo26n_axelera_model/imgsz, batch, quantize, data, fraction, device
DEEPXdeepxyolo26n_deepx_model/imgsz, quantize, simplify, opset, data, optimize, device
Qualcomm QNNqnnyolo26n_qnn.onnximgsz, batch, name, quantize, simplify, opset, data, fraction, device
LiteRTlitertyolo26n.tfliteimgsz, quantize, batch, data, fraction, device
Hailohailoyolo26n_hailo_model/imgsz, name, quantize, data, fraction, simplify, conf, iou
Huawei Ascendascendyolo26n_ascend_model/imgsz, batch, name, quantize, opset, simplify, nms

Opções de Quantização#

Usa o argumento quantize para solicitar a precisão da exportação. Os valores de texto não diferenciam maiúsculas de minúsculas, e o Ultralytics padroniza os apelidos aceites antes da exportação:

Valores da solicitaçãoValor canônicoSignificado
8, "8", "int8", "w8a8"8Pesos e ativações INT8
16, "16", "fp16", "w16a16"16Pesos e ativações FP16
32, "32", "fp32", "w32a32"32Exportação FP32; igual a não definido, exceto para CoreML NMS ML Programs, que usam FP16 como padrão
"w8a16""w8a16"Pesos INT8 com ativações de 16 bits (FP16; INT16 no LiteRT)
"w8a32""w8a32"Pesos INT8 com ativações FP32 (INT8 dinâmico no LiteRT, sem necessidade de calibração)

As flags obsoletas half=True e int8=True ainda são aceites com avisos de depreciação e redirecionam para quantize=16 e quantize=8.

Nem todos os formatos de exportação suportam todas as precisões. Pedidos explícitos de quantize geram essa precisão ou falham antes da exportação:

FormatoFP32 (32/não definido)FP16 (16)INT8 (8)W8A16 ("w8a16")Notas
PyTorchN/AN/AN/AFormato de treinamento/checkpoint nativo.
TorchScript✅ Apenas GPUA exportação FP16 TorchScript requer device=0; a exportação em CPU é FP32.
ONNXINT8 utiliza quantização estática do ONNX Runtime e dados de calibração.
OpenVINOINT8 utiliza quantização pós-treinamento NNCF.
TensorRTINT8 requer dados de calibração representativos.
CoreML✅¹CoreML INT8 é quantização de pesos; W8A16 usa pesos INT8 com ativações FP16. ¹NMS ML Programs não definidos usam FP16 como padrão.
TF SavedModelA exportação INT8 utiliza calibração TensorFlow.
TF GraphDefSem conversão de precisão no momento da exportação.
Edge TPU✅ automáticoEdge TPU requer INT8; é ativado automaticamente quando não definido.
PaddlePaddleSem conversão de precisão no momento da exportação.
MNNINT8 é quantização de pesos através da conversão MNN.
NCNNFormato de runtime móvel/embarcado.
IMX500✅ automáticoIMX500 requer quantização; INT8 é ativado automaticamente quando não definido.
RKNN✅ dependente do chipRK3588/RK3576/RK3566/RK3568/RK3562/RK2118/RV1126B suportam FP16 ou INT8; as variantes RV1103/RV1106 são apenas INT8.
ExecuTorchSem conversão de precisão no momento da exportação.
Axelera✅ automáticoA exportação Axelera requer INT8; é ativado automaticamente quando não definido.
DEEPX✅ automáticoA exportação DEEPX requer INT8; é ativado automaticamente quando não definido.
Qualcomm QNN✅ automáticoA exportação QNN HTP é fixada em pesos INT8 com ativações de 16 bits.
LiteRTO INT8 estático (8) e "w8a16" (pesos int8 + ativações int16) utilizam dados de calibração; também suporta INT8 dinâmico "w8a32" (sem calibração). quantize=16 não é uma exportação separada; um modelo FP32 é executado em FP16 em tempo de execução através do delegado da GPU.
Huawei Ascend✅ automáticoAs convoluções do Ascend AI Core aceitam apenas entradas FP16/INT8, portanto o ATC compila FP16; ele é ativado automaticamente quando não definido.

Para exportações INT8 e W8A16, fornece dados de calibração representativos com data, como data="coco8.yaml", a menos que a integração de destino documente um comportamento padrão ou ativado automaticamente. O esquema LiteRT "w8a32" (INT8 dinâmico) não necessita de dados de calibração.

O que vem a seguir#

Encontra o guia de integração do teu destino de implementação — ONNX, TensorRT, CoreML e muito mais estão na lista completa de integrações — para saberes como executar o modelo exportado.

FAQ#

Como exporto um modelo YOLO26 para o formato ONNX?#

Exportar um modelo YOLO26 para o formato ONNX é direto com o Ultralytics. Ele fornece métodos Python e CLI para exportar modelos.

Exemplo
from ultralytics import YOLO

# Load a model
model = YOLO("yolo26n.pt")  # load an official model
model = YOLO("path/to/best.pt")  # load a custom-trained model

# Export the model
model.export(format="onnx")

Para mais detalhes sobre o processo, incluindo opções avançadas como o tratamento de diferentes tamanhos de entrada, consulta o guia de integração do ONNX.

Quais são os benefícios de usar o TensorRT para exportação de modelos?#

Usar o TensorRT para exportação de modelos oferece melhorias de desempenho significativas. Modelos YOLO26 exportados para TensorRT podem alcançar até 5x de aceleração de GPU, tornando-o ideal para aplicações de inferência em tempo real.

  • Versatilidade: Otimiza modelos para uma configuração de hardware específica.
  • Velocidade: Alcança inferência mais rápida através de otimizações avançadas.
  • Compatibilidade: Integra-se perfeitamente com hardware NVIDIA.

Para saberes mais sobre a integração do TensorRT, consulta o guia de integração do TensorRT.

Como ativo a quantização INT8 ao exportar o meu modelo YOLO26?#

A quantização INT8 é uma excelente forma de comprimir o modelo e acelerar a inferência, especialmente em dispositivos de edge. Eis como podes ativar a quantização INT8:

Exemplo
from ultralytics import YOLO

model = YOLO("yolo26n.pt")  # Load a model
model.export(format="onnx", quantize=8, data="coco8.yaml")

A quantização INT8 pode ser aplicada a formatos como ONNX, TensorRT, OpenVINO, CoreML e Rockchip RKNN. Para obter ótimos resultados de quantização, fornece um conjunto de dados representativo utilizando o parâmetro data. Consulta Opções de Quantização para ver os valores aceites de quantize e os formatos suportados.

Por que é importante o tamanho de entrada dinâmico ao exportar modelos?#

O tamanho de entrada dinâmico permite que o modelo exportado lide com dimensões de imagem variáveis, proporcionando flexibilidade e otimizando a eficiência de processamento para diferentes casos de uso. Ao exportar para formatos como ONNX ou TensorRT, ativar o tamanho de entrada dinâmico garante que o modelo se consiga adaptar a diferentes formas de entrada sem problemas.

Para ativar esta funcionalidade, usa a flag dynamic=True durante a exportação:

Exemplo
from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.export(format="onnx", dynamic=True)

O redimensionamento de entrada dinâmico é particularmente útil para aplicações onde as dimensões de entrada podem variar, como no processamento de vídeo ou ao lidar com imagens de diferentes fontes.

Quais são os principais argumentos de exportação a considerar para otimizar o desempenho do modelo?#

Compreender e configurar os argumentos de exportação é crucial para otimizar o desempenho do modelo:

  • format: O formato de destino para o modelo exportado (por exemplo, onnx, torchscript, tensorflow).
  • imgsz: O tamanho de imagem desejado para a entrada do modelo (por exemplo, 640 ou (height, width)).
  • quantize: Precisão de quantização, tal como 8/"int8", 16/"fp16", 32/"fp32", ou os esquemas mistos de peso/ativação "w8a16" e "w8a32" (LiteRT INT8 dinâmico) em formatos suportados. Consulta Opções de Quantização.
  • optimize: Ativa uma otimização de compilador superior para exportações DEEPX.

Para a implementação em plataformas de hardware específicas, considera utilizar formatos de exportação especializados como TensorRT para GPUs NVIDIA, CoreML para dispositivos Apple, ou Edge TPU para dispositivos Google Coral.

O que representam os tensores de saída nos modelos YOLO exportados?#

Quando exportas um modelo YOLO para formatos como ONNX ou TensorRT, a estrutura do tensor de saída depende da tarefa do modelo. Compreender estas saídas é importante para implementações de inferência personalizadas.

Para modelos de deteção YOLO26 (por exemplo, yolo26n.pt), a exportação de ponta a ponta (end-to-end) está ativada por predefinição nos formatos que a suportam, pelo que a saída tem a forma de (batch_size, max_detections, 6) com valores [x1, y1, x2, y2, confidence, class_id]. Com o max_det=300 predefinido, isto é habitualmente (batch_size, 300, 6). Alguns formatos restritos recorrem automaticamente ao layout de saída tradicional quando os operadores de ponta a ponta não são suportados.

Para modelos de deteção sem ser de ponta a ponta, ou modelos YOLO26 exportados com end2end=False, a saída é tipicamente um único tensor com a forma de (batch_size, 4 + num_classes, num_predictions), onde os canais representam as coordenadas das caixas mais as pontuações por classe, e num_predictions depende da resolução de entrada da exportação (e pode ser dinâmico).

Para modelos de segmentação (por exemplo, yolo26n-seg.pt), normalmente obterás duas saídas: o primeiro tensor com a forma de (batch_size, 4 + num_classes + mask_dim, num_predictions) (caixas, pontuações de classe e coeficientes de máscara) e o segundo tensor com a forma de (batch_size, mask_dim, proto_h, proto_w), contendo protótipos de máscara utilizados com os coeficientes para gerar máscaras de instâncias. Os tamanhos dependem da resolução de entrada da exportação (e podem ser dinâmicos).

Para modelos de pose (por exemplo, yolo26n-pose.pt), o tensor de saída tem tipicamente a forma de (batch_size, 4 + num_classes + keypoint_dims, num_predictions), onde keypoint_dims depende da especificação da pose (por exemplo, número de pontos-chave e se a confiança está incluída), e num_predictions depende da resolução de entrada da exportação (e pode ser dinâmico).

Os exemplos em exemplos de inferência ONNX demonstram como processar estas saídas para cada tipo de modelo.

Existe uma API de inferência C++ oficial da Ultralytics?#

O Ultralytics não fornece atualmente uma API de inferência em C++ dedicada para modelos YOLO. Para implementações em C++, exporta o modelo para um formato de tempo de execução como ONNX, TensorRT, TorchScript ou MNN e, em seguida, carrega o artefacto exportado com a API C++ nativa desse tempo de execução.

Por exemplo, exporta um modelo de deteção com yolo export model=yolo26n.pt format=onnx e executa o ficheiro .onnx com o ONNX Runtime C++, ou exporta com format=engine e executa o motor TensorRT a partir de uma aplicação TensorRT em C++. Quando utilizas o pós-processamento personalizado em C++, faz corresponder o layout do tensor de saída para a tua tarefa e definições de exportação; as exportações de deteção de ponta a ponta do YOLO26 normalmente retornam (batch, max_det, 6), enquanto as exportações que não são de ponta a ponta retornam tensores de previsão em bruto que exigem pós-processamento externo.

Por que razão o output0 é FP32 ao exportar modelos quantizados com end2end=True?#

Ao exportar com quantize=16 (FP16) ou quantize=8 (INT8), a maioria dos tensores é convertida para uma precisão inferior para reduzir o tamanho do modelo e melhorar o desempenho. No entanto, quando o end2end=True está ativado, o pós-processamento (incluindo os índices de classe) é incorporado diretamente no grafo exportado.

O tensor output0 contém índices de classe, que são representados internamente como valores de ponto flutuante. O FP16 não consegue representar de forma fiável valores inteiros acima de 2048 devido à sua precisão de mantissa limitada. Para evitar uma potencial perda de precisão ou IDs de classe incorretos, o output0 é mantido propositadamente em FP32.

Este comportamento é esperado e também se aplica a exportações de precisão inferior ou quantizadas, onde a fidelidade do índice de classe deve ser preservada.

Se forem necessárias saídas completas em FP16, exporta com end2end=False e realiza o pós-processamento externamente.

Comentários