Documentation – Binary manager parameters

Net: Owner

Fri, 24 Apr 2026 00:00:00 +0000

Owner is the GitHub account that owns the llama.cpp repository used to download native binaries. The default ggml-org targets the upstream project.

Quick reference


Type	`string`
Default	`"ggml-org"`
Category	Native binary source
Field on	`BinaryManagerParameters.Owner`

What it does

The BinaryManager constructs a GitHub release URL from github.com/<Owner>/<Repo>/releases/tag/<ReleaseTag>. Owner fills the first slot.

"ggml-org" (default) — upstream llama.cpp maintainers. Recommended.
A different owner — only when you mirror upstream releases to a fork that stays byte-compatible.

When to change it

Scenario	Value
Default	`"ggml-org"`
Air-gapped enterprise mirror	Fork owner that hosts matching releases

Changing Owner without a byte-compatible mirror produces binaries whose P/Invoke signatures differ from what the SDK expects — runtime crashes.

Example

var preset = new Qwen25Preset();
// preset.BinaryManagerParameters.Owner = "ggml-org"; // default

Interactions

Repo — the repository name on that owner.
ReleaseTag — specific release under the owner/repo.

What’s next

Repo — repository name.
ReleaseTag — version pin.
Binary manager hub — all binary-manager knobs.

Net: Repo

Fri, 24 Apr 2026 00:00:00 +0000

Repo is the GitHub repository name paired with Owner to form the source URL.

Quick reference


Type	`string`
Default	`"llama.cpp"`
Category	Native binary source
Field on	`BinaryManagerParameters.Repo`

What it does

Together with Owner, forms the GitHub path: github.com/<Owner>/<Repo>/releases/tag/<ReleaseTag>. The BinaryManager queries the GitHub API for the release listing and downloads the matching asset.

"llama.cpp" (default) — the upstream project. Correct for the default Owner = "ggml-org".
Different repo name — only if you host releases in a differently-named repository with byte-compatible binaries.

When to change it

Scenario	Value
Default	`"llama.cpp"`
Enterprise mirror under a renamed repo	Mirror repo name

Do not change unless you control a mirror.

Example

var preset = new Qwen25Preset();
// preset.BinaryManagerParameters.Repo = "llama.cpp"; // default

Interactions

Owner — paired.
ReleaseTag — release selector.

What’s next

Owner — repository owner.
ReleaseTag — version pin.
Binary manager hub — all binary-manager knobs.

Net: ReleaseTag

Fri, 24 Apr 2026 00:00:00 +0000

ReleaseTag pins the specific llama.cpp release from which native binaries are downloaded. The SDK’s P/Invoke signatures are validated against the default tag; changing it without a tested migration risks runtime failures.

Quick reference


Type	`string`
Default	`"b8816"` (on SDK v26.5.0)
Category	Native binary source
Field on	`BinaryManagerParameters.ReleaseTag`

What it does

Identifies a GitHub release under <Owner>/<Repo>. The engine downloads the asset whose name matches your platform and acceleration from that release.

"b8816" (default on v26.5.0) — the upstream release validated against this SDK version.
Older / newer tag — only when you control a matching validation story.

The Aspose team tracks upstream llama.cpp releases and bumps the default ReleaseTag in each SDK minor version. The llama-cpp-migration skill automates the per-release validation and updates.

When to change it

Scenario	Value
Default (recommended)	`"b8816"` or unset
Dev / testing a new upstream release	That tag, only in dev
Pinned to an older validated tag	Specific older tag

Changing ReleaseTag to a tag whose P/Invoke signatures differ from the SDK’s expectations produces runtime crashes. Never ship an unvalidated tag to production.

Example

var preset = new Qwen25Preset();
preset.BinaryManagerParameters.ReleaseTag = "b8816";  // explicit pin for reproducibility

Interactions

Owner and Repo — together with ReleaseTag form the source URL.
BinaryPath — cache location per tag; different tags use different subfolders.
Session persistence portability — sessions assume a consistent ReleaseTag across save / load.

What’s next

Binary download fails troubleshooting — common issues.
Binary manager hub — all binary-manager knobs.
Offline deployment — pre-populating binaries for a pinned tag.

Net: BinaryPath

Fri, 24 Apr 2026 00:00:00 +0000

BinaryPath is the folder where native llama.cpp binaries are cached. First-run downloads land here; subsequent runs for the same ReleaseTag and acceleration load from this cache.

Quick reference


Type	`string`
Default	`<LocalAppData>/Aspose.LLM/runtimes`
Category	Native binary source
Field on	`BinaryManagerParameters.BinaryPath`

What it does

On Windows: %LOCALAPPDATA%\Aspose.LLM\runtimes.
On Linux / macOS: equivalent Environment.SpecialFolder.LocalApplicationData path joined with Aspose.LLM/runtimes.
Override to control where binaries are cached.

The binary manager subdivides this folder per ReleaseTag × acceleration variant, so multiple configurations can coexist.

When to change it

Scenario	Value
Default	unset
Shared cache across services	`/srv/aspose-llm/runtimes` (or equivalent)
Read-only root filesystem	Writable volume path
Pre-populated deployment (offline)	Path to bundled binaries
Docker / container	Volume mount path

Example

var preset = new Qwen25Preset();
preset.BinaryManagerParameters.BinaryPath = @"/opt/aspose-llm/runtimes";

using var api = AsposeLLMApi.Create(preset);

For air-gapped deployments:

// Copy pre-downloaded binaries to a location accessible on the target host,
// then point BinaryPath there.
preset.BinaryManagerParameters.BinaryPath = "/opt/aspose-llm/runtimes";
preset.EngineParameters.ModelCachePath = "/opt/aspose-llm/models";

Interactions

ReleaseTag — cache is subdivided per tag.
PreferredAcceleration — cache also subdivides per acceleration.
EngineParameters.ModelCachePath — separate cache for model files.

What’s next

Offline deployment — pre-populating BinaryPath.
Binary manager hub — all binary-manager knobs.

Net: SystemSpecification

Fri, 24 Apr 2026 00:00:00 +0000

SystemSpecification is an override for the OS, architecture, and acceleration capabilities the SDK auto-detects. Almost always left null.

Quick reference


Type	`SystemSpec?`
Default	`null` (auto-detect)
Category	Native binary source
Field on	`BinaryManagerParameters.SystemSpecification`

What it does

At construction, the engine inspects the host OS, CPU architecture, and available accelerations (GPU, AVX levels). The result is a SystemSpec that drives the asset-selection logic in BinaryManager.

null (default) — auto-detect. Correct for almost every deployment.
Explicit SystemSpec — override for specific testing / cross-platform preparation scenarios.

When to change it

Scenario	Value
Default	`null`
Force a specific target during offline binary preparation	Custom `SystemSpec`

Do not touch this for normal runtime usage.

Example

var preset = new Qwen25Preset();
// preset.BinaryManagerParameters.SystemSpecification = null; // default

Interactions

PreferredAcceleration — higher-level acceleration selector; usually preferred over raw SystemSpec overrides.

What’s next

PreferredAcceleration — acceleration control.
Binary manager hub — all binary-manager knobs.

Net: PreferredAcceleration

Fri, 24 Apr 2026 00:00:00 +0000

PreferredAcceleration forces the SDK to download a specific acceleration variant of the native binaries. Set it to override auto-detection.

Quick reference


Type	`AccelerationType?` enum
Default	`null` (auto-detect best available)
Values	`None`, `CUDA`, `HIP`, `Metal`, `Vulkan`, `Kompute`, `OpenCL`, `SYCL`, `AVX512`, `AVX2`, `AVX`, `OpenBLAS`, `NoAVX`
Category	Native binary source
Field on	`BinaryManagerParameters.PreferredAcceleration`

What it does

At binary download time, the manager picks an asset matching your host and PreferredAcceleration. When null, the auto-detection priority is: CUDA > HIP > Metal > Vulkan > best CPU AVX level.

null (default) — auto-detect.
CUDA — NVIDIA GPUs (Windows / Linux).
HIP — AMD GPUs on Linux.
Metal — Apple Silicon.
Vulkan — cross-vendor GPU; Windows AMD users; Intel iGPUs.
AVX2 / AVX512 — force CPU at a specific instruction level.
NoAVX — legacy x64 without AVX.

When to change it

Scenario	Value
Default	`null`
CPU-only despite having a GPU	`AVX2` or `AVX512`
Force CUDA on a CUDA-capable host	`CUDA`
Windows + AMD GPU	`Vulkan` (HIP is Linux-only)
Cross-vendor single-codepath deployment	`Vulkan`
Force a specific AVX level to test performance	`AVX2` vs `AVX512`

Example

using Aspose.LLM.Abstractions.Acceleration;

var preset = new Qwen25Preset();
preset.BinaryManagerParameters.PreferredAcceleration = AccelerationType.CUDA;
preset.BaseModelInferenceParameters.GpuLayers = 999;

using var api = AsposeLLMApi.Create(preset);

Interactions

GpuLayers — pair a GPU acceleration with a non-zero GpuLayers to actually use the GPU.
SystemSpecification — lower-level override; PreferredAcceleration is the recommended path.

What’s next

Acceleration overview — per-backend setup.
Supported acceleration — platform × backend matrix.
GPU not detected troubleshooting — when auto-detection falls back to CPU.