Exportação de modelos com Ultralytics YOLO#
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.
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.
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.
| Argumento | Tipo | Predefinição | Descrição |
|---|---|---|---|
format | str | 'torchscript' | Formato de destino para o modelo exportado, como 'onnx', 'torchscript', 'engine' (TensorRT) ou outros. Cada formato permite compatibilidade com diferentes deployment environments. |
name | str | None | Nome 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. |
imgsz | int ou tuple | 640 | Tamanho 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. |
keras | bool | False | Ativa a exportação para o formato Keras para o SavedModel do TensorFlow, fornecendo compatibilidade com o serviço e APIs do TensorFlow. |
optimize | bool | False | Ativa uma maior otimização do compilador para DEEPX, reduzindo a latência de inferência enquanto aumenta o tempo de compilação. |
quantize | int ou str | None | Precisã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=True → 16, int8=True → 8, ainda aceitos com um aviso de obsolescência). Apenas as precisões suportadas pelo formato de destino são permitidas (veja abaixo). |
dynamic | bool | False | Permite 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. |
simplify | bool | True | Simplifica 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. |
opset | int | None | Especifica 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. |
workspace | float ou None | None | Define 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. |
nms | bool | False | Adiciona 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. |
conf | float | None | Limite 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. |
iou | float | 0.7 | Limite 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_det | int | 300 | Nú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_nms | bool | False | Ativa 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. |
batch | int | 1 | Especifica 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. |
device | str | None | Especifica 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. |
verbose | bool | True | Eleva o registo do construtor do TensorRT para a gravidade VERBOSE durante a exportação format='engine'. Outros formatos de exportação ignoram-no. |
data | str | None | Caminho 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. |
split | str | '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. |
fraction | float | 1.0 | Especifica 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. |
end2end | bool | None | Substitui 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.
| Formato | Argumento format | Modelo | Metadados | Argumentos |
|---|---|---|---|---|
| PyTorch | - | yolo26n.pt | ✅ | - |
| TorchScript | torchscript | yolo26n.torchscript | ✅ | imgsz, quantize, dynamic, nms, batch, device |
| ONNX | onnx | yolo26n.onnx | ✅ | imgsz, quantize, dynamic, simplify, opset, nms, batch, data, fraction, device |
| OpenVINO | openvino | yolo26n_openvino_model/ | ✅ | imgsz, quantize, dynamic, nms, batch, data, fraction, device |
| TensorRT | engine | yolo26n.engine | ✅ | imgsz, quantize, dynamic, simplify, opset, workspace, nms, batch, data, fraction, device |
| CoreML | coreml | yolo26n.mlpackage | ✅ | imgsz, dynamic, quantize, nms, batch, device |
| TF SavedModel | saved_model | yolo26n_saved_model/ | ✅ | imgsz, keras, quantize, opset, nms, batch, data, fraction, device |
| TF GraphDef | pb | yolo26n.pb | ❌ | imgsz, opset, batch, device |
| TF Edge TPU | edgetpu | yolo26n_edgetpu.tflite | ✅ | imgsz, quantize, opset, data, fraction, device |
| PaddlePaddle | paddle | yolo26n_paddle_model/ | ✅ | imgsz, batch, device |
| MNN | mnn | yolo26n.mnn | ✅ | imgsz, batch, dynamic, quantize, simplify, opset, nms, device |
| NCNN | ncnn | yolo26n_ncnn_model/ | ✅ | imgsz, quantize, batch, device |
| IMX500 | imx | yolo26n_imx_model/ | ✅ | imgsz, quantize, data, fraction, nms, device |
| RKNN | rknn | yolo26n_rknn_model/ | ✅ | imgsz, batch, name, quantize, simplify, opset, data, fraction, device |
| ExecuTorch | executorch | yolo26n_executorch_model/ | ✅ | imgsz, batch, device |
| Axelera | axelera | yolo26n_axelera_model/ | ✅ | imgsz, batch, quantize, data, fraction, device |
| DEEPX | deepx | yolo26n_deepx_model/ | ✅ | imgsz, quantize, simplify, opset, data, optimize, device |
| Qualcomm QNN | qnn | yolo26n_qnn.onnx | ✅ | imgsz, batch, name, quantize, simplify, opset, data, fraction, device |
| LiteRT | litert | yolo26n.tflite | ✅ | imgsz, quantize, batch, data, fraction, device |
| Hailo | hailo | yolo26n_hailo_model/ | ✅ | imgsz, name, quantize, data, fraction, simplify, conf, iou |
| Huawei Ascend | ascend | yolo26n_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ção | Valor canônico | Significado |
|---|---|---|
8, "8", "int8", "w8a8" | 8 | Pesos e ativações INT8 |
16, "16", "fp16", "w16a16" | 16 | Pesos e ativações FP16 |
32, "32", "fp32", "w32a32" | 32 | Exportaçã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:
| Formato | FP32 (32/não definido) | FP16 (16) | INT8 (8) | W8A16 ("w8a16") | Notas |
|---|---|---|---|---|---|
| PyTorch | ✅ | N/A | N/A | N/A | Formato de treinamento/checkpoint nativo. |
| TorchScript | ✅ | ✅ Apenas GPU | ❌ | ❌ | A exportação FP16 TorchScript requer device=0; a exportação em CPU é FP32. |
| ONNX | ✅ | ✅ | ✅ | ❌ | INT8 utiliza quantização estática do ONNX Runtime e dados de calibração. |
| OpenVINO | ✅ | ✅ | ✅ | ❌ | INT8 utiliza quantização pós-treinamento NNCF. |
| TensorRT | ✅ | ✅ | ✅ | ❌ | INT8 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 SavedModel | ✅ | ❌ | ✅ | ❌ | A exportação INT8 utiliza calibração TensorFlow. |
| TF GraphDef | ✅ | ❌ | ❌ | ❌ | Sem conversão de precisão no momento da exportação. |
| Edge TPU | ❌ | ❌ | ✅ automático | ❌ | Edge TPU requer INT8; é ativado automaticamente quando não definido. |
| PaddlePaddle | ✅ | ❌ | ❌ | ❌ | Sem conversão de precisão no momento da exportação. |
| MNN | ✅ | ✅ | ✅ | ❌ | INT8 é quantização de pesos através da conversão MNN. |
| NCNN | ✅ | ✅ | ❌ | ❌ | Formato de runtime móvel/embarcado. |
| IMX500 | ❌ | ❌ | ✅ automático | ✅ | IMX500 requer quantização; INT8 é ativado automaticamente quando não definido. |
| RKNN | ❌ | ✅ dependente do chip | ✅ | ❌ | RK3588/RK3576/RK3566/RK3568/RK3562/RK2118/RV1126B suportam FP16 ou INT8; as variantes RV1103/RV1106 são apenas INT8. |
| ExecuTorch | ✅ | ❌ | ❌ | ❌ | Sem conversão de precisão no momento da exportação. |
| Axelera | ❌ | ❌ | ✅ automático | ❌ | A exportação Axelera requer INT8; é ativado automaticamente quando não definido. |
| DEEPX | ❌ | ❌ | ✅ automático | ❌ | A exportação DEEPX requer INT8; é ativado automaticamente quando não definido. |
| Qualcomm QNN | ❌ | ❌ | ❌ | ✅ automático | A exportação QNN HTP é fixada em pesos INT8 com ativações de 16 bits. |
| LiteRT | ✅ | ❌ | ✅ | ✅ | O 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ático | ❌ | ❌ | As 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.
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:
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:
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,640ou(height, width)).quantize:Precisão de quantização, tal como8/"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.