Matlab Deploy AI Model
MathWorksOfficialCreated by MathWorks
- Skill
- Tool integration
- Software development
- BSD-2-Clause
- Low risk
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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/matlab/matlab-deploy-ai-model/downloadUnzip 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), orimportNetworkFromKeras(.keras/.h5) which return adlnetwork. For deployment of an editabledlnetworkwith model compression (INT8 quantization viadlquantizer, pruning, projection) orexportNetworkToSimulinkworkflows — usematlab-deploy-embedded-ai(Pattern 1).Training or fine-tuning — this skill is for inference code generation only
Supported Frameworks
| Framework | Model format | Load function | Status |
|---|---|---|---|
| PyTorch | .pt2 | loadPyTorchExportedProgram | Supported (R2026a+) |
| LiteRT / TFLite | .tflite | loadLiteRTModel | Supported (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} entryPointCUDA MEX (GPU acceleration):
cfg = coder.gpuConfig("mex");
codegen -config cfg -args {coder.Constant("model_file"), input} entryPointFor 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} entryPointFor 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-codeskill.MATLAB Coder ↔ Simulink Coder property naming duality and
slbuildset_parampatterns: see thematlab-deploy-embedded-codeskill.DNN-inference-specific knobs (
DLTargetLibrary/DeepLearningConfigto disable third-party DL libraries,LargeConstantGenerationto serialize weights to data files): seereferences/dnn-codegen-options.md.
7. Use in Simulink
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
| Function | Purpose | Package | Since |
|---|---|---|---|
coder.Constant | Make argument a compile-time constant | MATLAB Coder | R2011a |
coder.gpuConfig | Create GPU (CUDA) code generation config | GPU Coder | R2017b |
codegen | Generate code | MATLAB Coder | R2011a |
loadPyTorchExportedProgram | Load .pt2 into MATLAB | MATLAB Coder Support Package for PyTorch and LiteRT Models | R2026a |
loadLiteRTModel | Load .tflite into MATLAB | MATLAB Coder Support Package for PyTorch and LiteRT Models | R2026a |
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.Constantfor the model file path argumentInput data is typically single-precision (check model input specs to confirm)
Do NOT use
importNetworkFromPyTorch,importNetworkFromTensorFlow, orimportNetworkFromKerasin this skill — they return adlnetworkon a different path. If the user needs adlnetworkfor quantization, projection, pruning, orexportNetworkToSimulinkbefore code generation, route tomatlab-deploy-embedded-aiinstead
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.pt2withtorch.export(upstream of loading). Consult when the user has a PyTorch model but no.pt2file yet, or hitstorch.exportSerializeError/ kwarg-mismatch errors. Links topytorch-export-patterns.md(per-source templates) andpytorch-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.tflitevia the Pythontf.lite.TFLiteConverterAPI. Consult when the user has a TensorFlow model but no.tflitefile 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.Constantusage, andcoder.DeepLearningConfignotes.references/dnn-codegen-options.md— DNN-INFERENCE-SPECIFIC codegen options:DLTargetLibrary/DeepLearningConfig('none')for the plain-C DL path,LargeConstantGenerationfor 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) andexportNetworkToSimulinkworkflows (Pattern 1). Use it when the source is an editabledlnetworkin MATLAB rather than a.pt2/.tflitefile.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
- ATTRIBUTION.mdAdded by AutoGineer1.0 KiB
- LICENSELicence file added by AutoGineer1.4 KiB
- SKILL.md10.8 KiB
- manifest.yaml617 B
- references/codegen-workflow.md4.0 KiB
- references/dnn-codegen-options.md6.9 KiB
- references/export-pytorch-models.md4.6 KiB
- references/litert-numeric-verification.md3.8 KiB
- references/litert-workflow.md14.7 KiB
- references/pytorch-api-reference.md2.6 KiB
- references/pytorch-data-layout.md4.1 KiB
- references/pytorch-export-gotchas.md4.7 KiB
- references/pytorch-export-patterns.md5.2 KiB
- references/pytorch-numeric-verification.md2.6 KiB
- references/pytorch-supported-models.md3.4 KiB
- references/pytorch-workflow.md5.7 KiB
- references/simulink-workflow.md12.7 KiB
- references/tensorflow-to-litert-conversion.md5.8 KiB
references/simulink-workflow.md
Using PyTorch and LiteRT Models in Simulink
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
inputSpecificationsOutput port shape and type from
outputSpecifications
Block Mask Parameters
| Parameter | Purpose | Default |
|---|---|---|
ModelFilePath | Path to the .pt2 file | "untitled.pt2" |
FcnName | Function name (if model defines multiple) | '<empty>' (uses default) |
SampleTime | Block sample time | "-1" (inherited) |
InputsTable | Per-input: name, type, model size, permutation | Auto-detected from .pt2 |
OutputsTable | Per-output: name, type, model size, port size, permutation | Auto-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
InputsTablepermutation[1 2 3 4](identity, default): the source must produce NCHW (e.g.,[1 3 224 224]) — same as the model.With
InputsTablepermutation[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.
Variable-Size (Dynamic Batch) in Simulink
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
| Aspect | MATLAB codegen | Simulink (both paths) |
|---|---|---|
| Model path | coder.Constant("model.pt2") in -args | String literal in block / mask parameter |
| Entry-point | Separate .m file | Inline in MATLAB Function block or not needed (Path A) |
| Solver | N/A | Must be fixed-step for codegen |
| Target | coder.config("mex") / coder.config("lib") | SystemTargetFile (grt.tlc for Simulink Coder, ert.tlc for Embedded Coder) |
| Build command | codegen | slbuild |
When to Use Each Path
| Scenario | Recommended |
|---|---|
| Drop-in model inference, no pre/post-processing | Path A (dedicated block) |
| Pre/post-processing with separate Simulink blocks around the model | Path A (dedicated block) + surrounding blocks |
| All logic (pre-processing + inference + post-processing) in one block | Path B (MATLAB Function block) |
| Need the model inside a larger Simulink system with signal routing | Either — Path A for clean interfaces, Path B for tight coupling |
| Need to parameterize the model file path at runtime | Neither — 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:
Fixed-step solver —
set_param(model, "Solver", "FixedStepDiscrete")System target file —
"grt.tlc"(Simulink Coder, generic) or"ert.tlc"(Embedded Coder, embedded targets — requires EC license)Target language —
"C"or"C++"(both work; defaults to"C")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.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download matlab-deploy-ai-model.zip