Generated banner for Matlab Deploy AI Model
Generated logo for Matlab Deploy AI Model

Matlab Deploy AI Model

MathWorksOfficialCreated by MathWorks

  • Skill
  • Tool integration
  • Software development
  • BSD-2-Clause
  • Low risk

From the author

Generate C/C++ or CUDA code from an AI model (PyTorch, LiteRT) using MATLAB Coder or GPU Coder. Use when the user wants to integrate an AI model into an application with code generation as the end goal — generating MEX, CUDA MEX, static library, dynamic library, or executable — or using the model in Simulink for simulation and code generation. Covers PyTorch ExportedProgram (.pt2) via loadPyTorchExportedProgram and LiteRT (.tflite) via loadLiteRTModel (R2026a+). Keywords: PyTorch, torch, .pt2, ExportedProgram, loadPyTorchExportedProgram, invoke, codegen, MEX, CUDA, GPU, C, C++, deploy, AI model, deep learning model, LiteRT, TFLite, TensorFlow Lite, Simulink, slbuild, PyTorch ExportedProgram block, MATLAB Function block, dlosslib, loadLiteRTModel.
— the description by MathWorks

From the skill’s files

Taken from the skill’s own files (its description, section headings and stated usage). Not an AutoGineer summary, and not written by the author as one.

Generate C/C++ or CUDA code from an AI model (PyTorch, LiteRT) using MATLAB Coder or GPU Coder. Use when the user wants to integrate an AI model into an application with code generation as the end goal — generating MEX, CUDA MEX, static library, dynamic library, or executable — or using the model in Simulink for simulation and code generation. Covers PyTorch ExportedProgram (.pt2) via loadPyTorchExportedProgram and LiteRT (.tflite) via loadLiteRTModel (R2026a+). Keywords: PyTorch, torch, .pt2, ExportedProgram, loadPyTorchExportedProgram, invoke, codegen, MEX, CUDA, GPU, C, C++, deploy, AI model, deep learning model, LiteRT, TFLite, TensorFlow Lite, Simulink, slbuild, PyTorch ExportedProgram block, MATLAB Function block, dlosslib, loadLiteRTModel. Generate deployable C/C++ or CUDA code from an AI model using MATLAB Coder or GPU Coder. The workflow follows a common pattern regardless of…

What it does

  • When to Use
  • When NOT to Use
  • Supported Frameworks
  • Generic Workflow
  • Key Functions
  • Conventions

When to use it

  • Use when the user wants to integrate an AI model into an application with code generation as the end goal — generating MEX, CUDA MEX, static library, dynamic library, or executable — or using the…
  • User wants to generate C/C++/CUDA code from an AI model (PyTorch, LiteRT)
  • User has a model file (.pt2, .tflite) and wants to load it into MATLAB
  • User wants MEX acceleration for an AI model
  • User wants to generate CUDA code or GPU-accelerated MEX from an AI model
  • User wants to deploy an AI model to hardware

Advantages

The skill’s files do not state this.

Usage examples

The skill’s files do not state this.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/matlab/matlab-deploy-ai-model/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip matlab-deploy-ai-model.zip -d .agents/skills

Documentation by MathWorks

Generate C/C++/CUDA Code from an AI Model

Generate deployable C/C++ or CUDA code from an AI model using MATLAB Coder or GPU Coder. The workflow follows a common pattern regardless of model framework: load, inspect, write entry-point, generate MEX, verify, then generate production code.

When to Use

  • User wants to generate C/C++/CUDA code from an AI model (PyTorch, LiteRT)

  • User has a model file (.pt2, .tflite) and wants to load it into MATLAB

  • User wants MEX acceleration for an AI model

  • User wants to generate CUDA code or GPU-accelerated MEX from an AI model

  • User wants to deploy an AI model to hardware

  • User wants to use a PyTorch or LiteRT model in Simulink (simulation or code generation)

  • User wants to verify AI model numerics between the source framework and MATLAB

When NOT to Use

  • General MATLAB Coder usage (codegen syntax, config tuning, writing codegen-ready code)

  • Editable dlnetwork for Deep Learning Toolbox workflows (quantization, compression, transfer learning) — use importNetworkFromPyTorch (PyTorch), importNetworkFromTensorFlow (SavedModel), or importNetworkFromKeras (.keras/.h5) which return a dlnetwork. For deployment of an editable dlnetwork with model compression (INT8 quantization via dlquantizer, pruning, projection) or exportNetworkToSimulink workflows — use matlab-deploy-embedded-ai (Pattern 1).

  • Training or fine-tuning — this skill is for inference code generation only

Supported Frameworks

FrameworkModel formatLoad functionStatus
PyTorch.pt2loadPyTorchExportedProgramSupported (R2026a+)
LiteRT / TFLite.tfliteloadLiteRTModelSupported (R2026a+)

For PyTorch-specific details (API routing, entry-point pattern, export workflow, data layout, common mistakes): see references/pytorch-workflow.md.

For LiteRT-specific details (API routing, entry-point pattern, variable-size inputs, Simulink integration, conventions): see references/litert-workflow.md. For converting TensorFlow/Keras/.h5 to .tflite: see references/tensorflow-to-litert-conversion.md.

Generic Workflow

The code generation workflow follows the same steps for any framework:

1. Load and Inspect

Load the model and check its input/output specifications to determine expected shapes and types.

2. Write Entry-Point Function

Create a codegen-compatible entry-point function that:

  • Loads the model from a file path

  • Runs inference on an input

  • Returns the output

The model file path must be wrapped with coder.Constant so it's known at compile time.

3. Verify Numerics

Compare MATLAB inference output against the source framework to confirm correct loading. Use the same input data in both environments and compare with tolerance.

4. Generate MEX (First!)

Always generate MEX before lib/exe to verify on the host machine:

CPU MEX:

cfg = coder.config("mex");
codegen -config cfg -args {coder.Constant("model_file"), input} entryPoint

CUDA MEX (GPU acceleration):

cfg = coder.gpuConfig("mex");
codegen -config cfg -args {coder.Constant("model_file"), input} entryPoint

For CPU MEX SIMD acceleration (SIMDAcceleration = 'Full' for AVX2 on Intel/AMD), see the matlab-generate-code skill. For the DNN- inference-specific MEX AVX2 ceiling, see references/dnn-codegen-options.md.

5. Verify MEX Output

Compare MEX output against MATLAB reference using matlab.unittest with tolerance:

refOut = entryPoint("model_file", input);
mexOut = entryPoint_mex("model_file", input);
testCase = matlab.unittest.TestCase.forInteractiveUse;
testCase.verifyThat(mexOut, matlab.unittest.constraints.IsEqualTo(refOut, ...
    'Within', matlab.unittest.constraints.AbsoluteTolerance(single(1e-5))));
6. Generate Library/Executable

Once MEX is verified, generate production code:

cfgLib = coder.config("lib");
cfgLib.TargetLang = "C++";  % set to "C++" for C++ output; default is "C"
codegen -config cfgLib -args {coder.Constant("model_file"), input} entryPoint

For DLL: coder.config("dll"). For executable: coder.config("exe").

CUDA variants: Replace coder.config with coder.gpuConfig.

Performance tuning:

  • Generic knobs (SIMD instruction sets, reduction-loop vectorization, multithreaded loops): see the matlab-generate-code skill.

  • MATLAB Coder ↔ Simulink Coder property naming duality and slbuild set_param patterns: see the matlab-deploy-embedded-code skill.

  • DNN-inference-specific knobs (DLTargetLibrary / DeepLearningConfig to disable third-party DL libraries, LargeConstantGeneration to serialize weights to data files): see references/dnn-codegen-options.md.

For Simulink integration, use the dedicated PyTorch ExportedProgram block from dlosslib — set ModelFilePath to the .pt2 file and it auto-detects input/output shapes. No entry-point function or coder.Constant needed.

Pre/post-processing can be done with Simulink blocks around the dedicated block. If you need everything in a single block, use a MATLAB Function block with loadPyTorchExportedProgram + invoke (same pattern as the entry-point, but the model path is a string literal — no coder.Constant).

Both paths support slbuild code generation (requires fixed-step solver + ERT or GRT target). See references/simulink-workflow.md for full details.

8. Deploy to Hardware (Optional — requires Embedded Coder)

For embedded deployment, use the same entry-point function with an Embedded Coder configuration. See the matlab-deploy-embedded-code skill for ERT config, hardware settings, PIL/SIL verification, and target-specific options. Ask the user to install the skill if it is not installed

Key Functions

FunctionPurposePackageSince
coder.ConstantMake argument a compile-time constantMATLAB CoderR2011a
coder.gpuConfigCreate GPU (CUDA) code generation configGPU CoderR2017b
codegenGenerate codeMATLAB CoderR2011a
loadPyTorchExportedProgramLoad .pt2 into MATLABMATLAB Coder Support Package for PyTorch and LiteRT ModelsR2026a
loadLiteRTModelLoad .tflite into MATLABMATLAB Coder Support Package for PyTorch and LiteRT ModelsR2026a

Conventions

  • Always check the model's input specifications for correct input shape and type

  • Always generate MEX first, verify, then proceed to lib/exe

  • Always use coder.Constant for the model file path argument

  • Input data is typically single-precision (check model input specs to confirm)

  • Do NOT use importNetworkFromPyTorch, importNetworkFromTensorFlow, or importNetworkFromKeras in this skill — they return a dlnetwork on a different path. If the user needs a dlnetwork for quantization, projection, pruning, or exportNetworkToSimulink before code generation, route to matlab-deploy-embedded-ai instead

References

  • references/pytorch-workflow.md — Full PyTorch-specific workflow: API routing, entry-point pattern, export guidance, common mistakes, and conventions. Consult for any PyTorch/.pt2 model code generation task. Links to deeper PyTorch references (API signatures, data layout, numeric verification, supported models).

  • references/export-pytorch-models.md — Exporting an eager-mode PyTorch model to .pt2 with torch.export (upstream of loading). Consult when the user has a PyTorch model but no .pt2 file yet, or hits torch.export SerializeError / kwarg-mismatch errors. Links to pytorch-export-patterns.md (per-source templates) and pytorch-export-gotchas.md (torch 2.11 serialization fixes).

  • references/simulink-workflow.md — Simulink integration: dedicated PyTorch ExportedProgram block (Path A) vs MATLAB Function block (Path B), block mask parameters, code generation config, and key differences from command-line codegen.

  • references/litert-workflow.md — Full LiteRT-specific workflow: API routing (loadLiteRTModel → inputSpecifications → invoke), entry-point pattern, variable-size input handling, Simulink integration, and conventions. Consult for any LiteRT/.tflite model code generation task.

  • references/tensorflow-to-litert-conversion.md — Converting TensorFlow SavedModel/Keras/.h5 to .tflite via the Python tf.lite.TFLiteConverter API. Consult when the user has a TensorFlow model but no .tflite file yet.

  • references/litert-numeric-verification.md — Verifying MEX numerics against MATLAB reference for LiteRT models (tolerance guidance, common mismatches).

  • references/codegen-workflow.md — Shared code generation steps for both PyTorch and LiteRT: MEX generation, MEX verification, library/executable targets, coder.Constant usage, and coder.DeepLearningConfig notes.

  • references/dnn-codegen-options.md — DNN-INFERENCE-SPECIFIC codegen options: DLTargetLibrary / DeepLearningConfig('none') for the plain-C DL path, LargeConstantGeneration for serializing large DNN weights to data files, and MEX SIMD ceiling in a DNN-inference context. Read this when the generic file's knobs need DNN-specific framing (e.g., "the MEX SIMD cap matters because inference is the target").

See Also

  • matlab-generate-code — Generic MATLAB Coder tuning (SIMD instruction sets, OpenMP multi-threading, reduction-loop vectorization). Consult for performance options not specific to DNN inference.

  • matlab-deploy-embedded-ai — dlnetwork-based codegen with model compression (quantization, pruning, projection) and exportNetworkToSimulink workflows (Pattern 1). Use it when the source is an editable dlnetwork in MATLAB rather than a .pt2 / .tflite file.

  • matlab-optimize-gpu-codegen — CUDA-target codegen tuning (coder.gpuConfig, kernel fusion, memory-hierarchy options) when the deployment target is an NVIDIA GPU rather than CPU or embedded hardware.


Copyright 2026 The MathWorks, Inc.


Files

references/simulink-workflow.md

Integrate a PyTorch ExportedProgram (.pt2) or LiteRT (.tflite) model into a Simulink model for simulation and C/C++ code generation. Two paths exist — both support pre/post-processing; choose based on how you want to structure it: separate Simulink blocks around the dedicated model block (Path A), or everything inside a single block (Path B).

Path A: Dedicated PyTorch ExportedProgram Block (preferred)

The PyTorch ExportedProgram block (from the dlosslib library) is the recommended path. It auto-detects input/output shapes from the .pt2 file — no code to write.

Setup
% Create model and add the dedicated block
modelName = "my_pytorch_model";
new_system(modelName);
add_block("dlosslib/PyTorch ExportedProgram", [modelName "/MyModel"]);

% Point it at the .pt2 file (absolute path or on MATLAB path)
set_param([modelName "/MyModel"], "ModelFilePath", "/path/to/model.pt2");

After setting ModelFilePath, the block reads the .pt2 and auto-configures:

  • Input port shape and type from inputSpecifications

  • Output port shape and type from outputSpecifications

Block Mask Parameters
ParameterPurposeDefault
ModelFilePathPath to the .pt2 file"untitled.pt2"
FcnNameFunction name (if model defines multiple)'<empty>' (uses default)
SampleTimeBlock sample time"-1" (inherited)
InputsTablePer-input: name, type, model size, permutationAuto-detected from .pt2
OutputsTablePer-output: name, type, model size, port size, permutationAuto-detected from .pt2
Input Permutation (feeding HWC image data)

The InputsTable 4th column is a permutation vector that maps Simulink port signal dimensions to model dimensions. This lets you feed image data in NHWC layout (natural for MATLAB/Simulink) without manual permute calls. For multi-input models, each row in InputsTable specifies its own independent permutation — inputs can have different layouts.

% Default: identity [1 2 3 4] — port signal must be NCHW [1,3,224,224]
% To accept NHWC [1,224,224,3] at the port and permute internally:
set_param([modelName "/MyModel"], "InputsTable", ...
    "{'in1','single','[1 3 224 224]','[1 4 2 3]'}");

The permutation [1 4 2 3] means: port dim 1→model dim 1, port dim 2→model dim 4, port dim 3→model dim 2, port dim 4→model dim 3. So port shape NHWC is permuted to NCHW before inference.

Source-signal shape must match the pre-permutation port shape, not the model shape. The permutation reorders after the port receives the signal, so:

  • With InputsTable permutation [1 2 3 4] (identity, default): the source must produce NCHW (e.g., [1 3 224 224]) — same as the model.

  • With InputsTable permutation [1 4 2 3]: the source must produce NHWC (e.g., [1 224 224 3]) — the block permutes it to NCHW internally.

Feeding NCHW to a port configured with [1 4 2 3] double-permutes the axes, so sim() errors with a shape-mismatch inside the DL block. Verify the source shape before wiring: size(u) on a signal probe or a Display block inserted between the source and the DL block.

Signal Dimensionality (1-D vs 2-D)

Simulink Constant blocks with VectorParams1D = 'on' (the default) produce 1-D signals. Simulink passes 1-D signals as column vectors into MATLAB Function blocks and the internal MLFB of dedicated blocks. If the model expects a row vector (e.g., [1 4]), the input arrives as [4 1] and inference fails with a dimension mismatch.

This only affects models whose inputs are 2-D (e.g., [1 N] feature vectors). Image models with 4-D inputs ([1 H W C]) are unaffected because 4-D arrays cannot be collapsed to 1-D.

Fix: Set VectorParams1D = 'off' on the Constant block so the signal retains its 2-D shape:

add_block("simulink/Sources/Constant", [modelName "/Input"], ...
    "Value", "ones(1,4,'single')", "VectorParams1D", "off");

Alternatively, use a Reshape block between the source and the model block to enforce the expected dimensions.

Models with a variable-size batch dimension (Inf in inputSpecifications) require additional configuration in Simulink:

OutputsTable maximum size: The OutputsTable has an "Inferred Size" column that shows Inf for variable-size dimensions and a "Maximum Size" column that defaults to the same values. Users can set a finite upper bound in the Maximum Size column to constrain memory allocation.

When a maximum bound is required:

  • Rapid Accelerator mode

  • Accelerator mode

  • GPU Acceleration enabled (generated CUDA code)

In these modes, you must specify a finite maximum size for all variable-size dimensions — unbounded Inf is not supported.

Enable dynamic memory allocation: For variable-size signals, enable dynamic memory allocation on the model:

set_param(modelName, 'MATLABDynamicMemAlloc', 'on');

MATLAB Function block variable-size outputs: If using Path B (MATLAB Function block) and the block output is variable-size, you must enable variable-size output on the MATLAB Function block port. In the Ports and Data Manager, set the output port's "Variable size" property to on.

Connect and Simulate
% InputsTable permutation drives the required source shape:
%   [1 2 3 4] (default) → source produces NCHW, e.g. [1 3 224 224]
%   [1 4 2 3]           → source produces NHWC, e.g. [1 224 224 3]

% Example: identity permutation → NCHW source
add_block("simulink/Sources/Constant", [modelName "/Input"], ...
    "Value", "randn(1,3,224,224,'single')");   % NCHW
add_block("simulink/Sinks/Display", [modelName "/Output"]);
add_line(modelName, "Input/1", "MyModel/1");
add_line(modelName, "MyModel/1", "Output/1");

% Example: [1 4 2 3] permutation → NHWC source
% (Use this variant only when InputsTable was set with [1 4 2 3])
%   "Value", "randn(1,224,224,3,'single')"     % NHWC

% Simulate
out = sim(modelName, "StopTime", "0");
Simulation Modes

The dedicated PyTorch ExportedProgram block runs in all Simulink simulation modes: Normal, Accelerator, and Rapid Accelerator.

Contrast with the PyTorch co-execution block. MATLAB also offers a PyTorch co-execution path (the model is invoked via a Python interpreter through MATLAB↔Python interop). The co-execution block does NOT support Accelerator or Rapid Accelerator modes — those modes require the model to be compiled into the Simulink build, which the Python-interop path cannot provide. If Accelerator or Rapid Accelerator is needed, the dedicated dlosslib/PyTorch ExportedProgram block (Path A) is the only option. Co-execution is Normal-mode only.

Selecting the simulation mode. Simulink defaults to Normal mode — you must explicitly set SimulationMode to switch. Even with the dedicated block, Accelerator / Rapid Accelerator is not automatic:

set_param(modelName, "SimulationMode", "rapid-accelerator");  % "normal" | "accelerator" | "rapid-accelerator"

Do this before calling sim(modelName).

Optional: native hardware acceleration

For faster simulation on any mode, enable native hardware acceleration so Simulink uses SIMD instructions tuned to the host CPU:

set_param(modelName, "SimHardwareAcceleration", "native");   % default is "generic"

SimHardwareAcceleration accepts three values: "off", "generic" (default — baseline SIMD, portable across hosts), and "native" (host-CPU-specific SIMD, fastest). "native" may force a rebuild when the model is moved to a different host machine. This setting affects simulation only — it has no effect on generated code.

Generate Code

Configure the model for code generation, then build:

set_param(modelName, "Solver", "FixedStepDiscrete");
set_param(modelName, "FixedStep", "1");
set_param(modelName, "SystemTargetFile", "grt.tlc");  % Simulink Coder (generic)
% Or: set_param(modelName, "SystemTargetFile", "ert.tlc"); % Embedded Coder (embedded targets, requires EC license)
slbuild(modelName);

The code generator fully inlines the model inference into the generated code — no external runtime or .pt2 file needed at deployment.

For SIMD instruction sets, reduction-loop vectorization, and multithreaded loops, see the matlab-generate-code skill. For serializing large DNN weight constants to data files, see references/dnn-codegen-options.md. Those options apply equally to slbuild and command-line codegen.

Path B: MATLAB Function Block (single-block custom logic)

Use when you want pre/post-processing (normalization, permutation, argmax) and model inference all within a single block. Note: pre/post-processing can also be done with separate Simulink blocks around the dedicated PyTorch block (Path A) — Path B is for when you want everything self-contained in one block.

Setup
modelName = "my_pytorch_custom";
new_system(modelName);
add_block("simulink/User-Defined Functions/MATLAB Function", ...
    [modelName "/Inference"]);
Set the Block Script

Use MATLABFunctionConfiguration to set the function body:

config = get_param([modelName "/Inference"], "MATLABFunctionConfiguration");
config.FunctionScript = sprintf([ ...
    'function out = fcn(input)\n' ...
    '%%#codegen\n' ...
    'net = loadPyTorchExportedProgram(''model.pt2'');\n' ...
    'out = invoke(net, input);\n' ...
    'end\n']);

The model file path is a string literal in the block — do NOT use coder.Constant (that is only needed for MATLAB codegen). Simulink resolves compile-time constants from string literals automatically.

Key Differences from MATLAB Codegen
AspectMATLAB codegenSimulink (both paths)
Model pathcoder.Constant("model.pt2") in -argsString literal in block / mask parameter
Entry-pointSeparate .m fileInline in MATLAB Function block or not needed (Path A)
SolverN/AMust be fixed-step for codegen
Targetcoder.config("mex") / coder.config("lib")SystemTargetFile (grt.tlc for Simulink Coder, ert.tlc for Embedded Coder)
Build commandcodegenslbuild

When to Use Each Path

ScenarioRecommended
Drop-in model inference, no pre/post-processingPath A (dedicated block)
Pre/post-processing with separate Simulink blocks around the modelPath A (dedicated block) + surrounding blocks
All logic (pre-processing + inference + post-processing) in one blockPath B (MATLAB Function block)
Need the model inside a larger Simulink system with signal routingEither — Path A for clean interfaces, Path B for tight coupling
Need to parameterize the model file path at runtimeNeither — the .pt2 must be known at compile time

LiteRT Models

The same two paths apply to LiteRT (.tflite) models:

Path A: Dedicated LiteRT Block (preferred)

The dlosslib/LiteRT block has the same integration pattern as the PyTorch ExportedProgram block — set ModelFilePath to the .tflite file:

add_block("dlosslib/LiteRT", [modelName "/MyModel"]);
set_param([modelName "/MyModel"], "ModelFilePath", "/path/to/model.tflite");

The block auto-detects input/output shapes from the .tflite file.

Multi-signature models: For .tflite models containing multiple functions, use the FcnName drop-down (or set it programmatically) to select which function to invoke:

set_param([modelName "/MyModel"], "FcnName", "detect");
Path B: MATLAB Function Block

Same pattern as PyTorch but using loadLiteRTModel and invoke:

config = get_param([modelName "/Inference"], "MATLABFunctionConfiguration");
config.FunctionScript = sprintf([ ...
    'function out = fcn(input)\n' ...
    '%%#codegen\n' ...
    'net = loadLiteRTModel(''model.tflite'');\n' ...
    'out = invoke(net, input);\n' ...
    'end\n']);

For multi-signature models in a MATLAB Function block, pass FcnName to invoke:

'out = invoke(net, input, FcnName="detect");\n' ...

Code Generation Configuration Checklist

For either path, the Simulink model must be configured for code generation:

  1. Fixed-step solver — set_param(model, "Solver", "FixedStepDiscrete")

  2. System target file — "grt.tlc" (Simulink Coder, generic) or "ert.tlc" (Embedded Coder, embedded targets — requires EC license)

  3. Target language — "C" or "C++" (both work; defaults to "C")

  4. Build — slbuild(model) generates and compiles

The generated code fully inlines all model operations (convolutions, activations, etc.) with SIMD intrinsics where applicable. No external runtime dependency.


Copyright 2026 The MathWorks, Inc.


Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
MathWorks
Publisher
MathWorks (Official)
Source
matlab/matlab-agentic-toolkit · skills-catalog/code-generation/matlab-deploy-ai-model · commit 2a7f215
Licence
BSD 2-Clause License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.md)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by MathWorks or MathWorks.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download matlab-deploy-ai-model.zip