PascalRT

PascalRT is a workstation-specific native inference-runtime project for the Dell XPS 8930 / Core i7-8700 / GeForce GTX 1070 stack installed under D:\LocalAI. The target is one C++20 and CUDA C++ service that exposes an OpenAI-compatible API to Open WebUI while keeping an internal backend ABI for a future local UI.

The production D:\LocalAI installation now runs the final18 PascalRT compatibility release on the port-8080 backend path used by Open WebUI. The promotion is transactional and preserves the exact b10295 incumbent for a one-command rollback. The separately developed native execution engine remains experimental; the production release uses the pinned, directly linked llama.cpp compatibility executor while adding the qualified Pascal-specific policy, caching, attestation, and deployment work described below.

Production status (2026-09-02)

• Installed executable: D:\LocalAI\ModelRuntime\runtime\llama-server.exe, SHA-256 669ce1531f7532bf3e3580f7cb3ab413257d70b504097b23ff1421e43bbfadcf. It is the exact staged Release build pascalrt-prod-20260902-sm61-669ce153-b10295-reasoning-checkpoint-final18-cuda129: CUDA 12.9, native sm_61, 141 Pascal cubins and no PTX.
• The deployed balanced Ornith preset keeps the 131,072-token context, Q4_0 K/V, all useful GPU layers, six pinned physical CPU cores, one latency-first slot, and a bounded 2 GiB / 32-entry serialized recurrent-state checkpoint LRU. Default reasoning is off; an explicit reasoning request remains supported and quality-tested.
• A matched fresh-process control found final18 within measurement noise of the incumbent on cold traffic: decode 24.030384 versus 24.138766 token/s (-0.449%) and 2k prefill 419.378765 versus 422.437229 token/s (-0.724%). No cold-speed uplift is claimed. On the recurrent A/B/A branch workload the new checkpoint path reduced A2 TTFT from 4073.366 to 196.337 ms (+95.180%) and total sequence wall time from 13030.325 to 9292.020 ms (+28.689%), with exact output parity.
• The repeated 30-minute soak passed: 1,818.992 measured seconds, 176 requests, zero request errors, -0.603% p95 decode drift, 75 C maximum, 765 MiB minimum free VRAM, 8.65 GiB minimum free RAM, zero net pagefile growth, and a final 127,179-token retrieval needle with the exact expected answer.
• Frozen incumbent-versus-final18 quality passed all eight cases, including tokenizer Unicode/adversarial inputs, fixed generation, JSON tools, explicit reasoning, stop handling, image input, and the 127,179-token needle. The production Open WebUI application-path report also passes both default-policy and explicit-thinking-off probes with pinned Open WebUI 0.11.0 provenance. The screenshot prompt that previously ended in hidden reasoning now produced 1,034 visible characters, zero reasoning characters, stop, and [DONE] through the signed-in production application route.

Evidence is under bench/results and quality/results; the concise measured record and exact rollback command are in RESULTS.md.

Archived native-engine status (2026-08-31)

This section preserves the dated state of the independent native executor. It does not describe the final18 compatibility release now serving production.

The independent native engine was not yet production, and the reason was measured rather than assumed. LLAMACPP-REPLACEMENT-PLAN.md §6 is the dated campaign log and RESULTS.md is the measurement record; both state the basis of every number, because this project has repeatedly found that a figure without its basis is misleading.

What works. Started on the production launcher's exact command line and its unmodified models.ini, pascalrt-server reads the preset, satisfies Get-BackendState (Healthy, ModelsPresent, DefaultLoaded), and returns exactly 703 to Invoke-BackendSmokeTest — for Ornith-1.5 and for Gemma4, with no llama.cpp in the process. The executable route remains one file: scripts/Switch-LocalAIRuntime.ps1 installs PascalRT under the name llama-server.exe so the launcher, its watchdog and Stop-LocalAI.ps1 need no edit. The same transaction installs four hash-attested linked-compat catalog overlays (including Qwen3.8) and its one-command rollback restores the two prior manifests while deleting only the exact bytes installed at the two formerly absent paths.

What does not. Against llama.cpp b10295 on the same host:

	PascalRT	b10295
Gemma4 decode	94.6 ms/token	41.93 ms — 2.26x slower
Ornith decode	~450 ms/forward pass	~41 ms/token — ~11x slower
prefill	~12 tok/s	166.9 tok/s — ~14x slower
Ornith context	8,192	131,072 — refused by name, never truncated
Qwen3.6	unavailable	serving

Two of those numbers deserve their context. b10295's 41.93 ms is a speculatively decoded token (draft-MTP, ~1.93 emitted per forward pass), so PascalRT is already faster per forward pass and loses per emitted token. And prefill is slow for one structural reason: the microbatch is 1, so a prompt token costs a decode token.

Therefore, at that archived native-engine snapshot, its cutover had not been performed. The transaction mechanism is hermetically verified, but the intended overlay payloads remain unstaged. The three vision: true linked manifests must pass live projector/image tests on the final build before release handoff; leaving production on an unqualified build would be a regression.

Current status

• Native bounded WinSock service with bearer authentication, SSE, cancellation, model registry, metrics, and an OpenAI-compatible API boundary. The mock backend remains available for wire-contract tests.
• Bounds-checked GGUF and safetensors readers plus an architecture-aware 128k memory planner. The exact Modilify Mk1 checkpoint catalog, NF4 companions, topology, tokenizer, special tokens, and chat template are validated against the installed artifacts.
• CUDA 12.9, native-only sm_61 kernel lab with stable arenas, Q4_0 GEMV, online FP16-KV attention, exact bitsandbytes NF4 double-quant primitives, grouped top-8 experts, exact Modilify norm/RoPE/router/gating operations, and topology-checked hybrid 128k attention/cache storage and staging. The tied-vocabulary path retains the full 256 x 262,144 FP32 logits (268,435,456 bytes) in the transient arena and reuses them for the statistics pass while preserving 65,536-token projection/reduction chunk boundaries. This removes exactly the second tied-head projection and adds exactly 201,326,592 workspace bytes (192 MiB); the CUDA vocabulary test verified the result bit-for-bit. The installed Torch CUDA Philox exponential-race sampler contract remains exact: 4,364 seeded rows matched sampled-ID hashes, with exact generator-state transitions and bounded confidence/entropy error.
• Directly linked, pinned GGUF compatibility executor plus a read-only native Modilify catalog that validates all 49,491 tensors and 8,133 NF4 groups.
• Reference-identical native Modilify tokenizer and allocation-free diffusion commit/rolling policy, each verified against frozen installed-runtime vectors. The initial CUDA noise canvas is also bit-exact to the pinned installed Torch build across 315,392 checked token IDs. Authenticated tokenize/detokenize routes are wired into the same service.
• A checked 128k Modilify execution planner that preserves the tied embedding/head allocation and rejects insufficient live RAM/VRAM rather than paging or overcommitting. The strict resident graph binder resolves 302 legal projection slots without duplicating tied weights. Maximum-model/base blueprint 0xd7acf2c4a23815bf accounts for 3,760,862,208 device-allocation bytes and 14,608,367,616 combined host-allocation bytes; admission, including configured safety reserves, requires 5,103,039,488 device bytes and 18,903,334,912 host bytes. The host figures are unchanged by retained logits.
• Allocation-free native prefill and denoise components compose the embedding, latent recurrence, exact RoPE, 30-layer decoder, hybrid cache, tied vocabulary projection, and sampler. A split-layer plus 30-layer resumable scheduler preserves resident-path output while safely pausing for paged experts. A single-copy 11,789,767,680-byte resident host expert store, request-scoped generation owner, concrete native session, and text-only OpenAI backend are integrated and pass their component/contract tests.
• Real checkpoint-backed native Modilify generation now works through the WinSock OpenAI-compatible service. OpenAI temperature: 0 follows the deployed Python contract and is clamped to 0.01; it is not treated as greedy decoding. Channel-aware routing now excludes non-visible channels and yields the exact visible content and SHA-256 produced by the matched fixed smoke. That exact result does not generalize to the longer paired quality probes.
• The balanced profile caches six exact expert layers. Its retained-logit validation completed five measured requests without errors and with exact Modilify online content/hash parity. Median TTFT, wall time, and decode were 9,252.406 ms, 17,178.778 ms, and 0.890118 token/s; minimum free VRAM was 1,573 MiB, maximum temperature was 73 C, and p95 power was 132.8735 W. The historical retained-logit matrix passed 49/49 tests. After the current artifact-contract, model-transition, provenance, and CUDA-architecture additions, the integrated Release matrix passes 65/65 tests.
• Transactional model PREPARE now locks the candidate ticket and runs the exact loader role/sidecar contract while the active backend is still serving. A static rejection therefore cannot tear down the known-good model. Status distinguishes stable, candidate_loading, rollback_loading, and restoring_known_good; capacity admission remains post-detach because this 8 GB board cannot safely hold two full backends.
• The paged Modilify expert path now gathers page N+1 into the already-budgeted second pinned host page while page N consumes the sole reusable device payload. It adds no worker, device allocation, or arithmetic/order change. Five exact-geometry synthetic scheduling A/B processes improved by 11.46--31.29% (14.55% from process medians); this qualifies the overlap mechanism, not installed-model end-to-end speed.
• Reproducible benchmark, endpoint-parity, thermal-soak, and atomic shadow-promotion/rollback harnesses. When CIM access is denied or unavailable, scripts/PascalRTHarness/PascalRTHarness.psm1 now falls back without elevation to GlobalMemoryStatusEx for physical-memory sampling and Perflib Paging File(_Total) counters for pagefile sampling. The case catalog is versioned: bench/cases/performance.v2.json is the live benchmark and canonical promotion default and carries a deterministic per-iteration prompt nonce so a benchmark cannot silently measure llama.cpp's prompt cache. v1 remains explicitly selectable for archival reports, and v1-versus-v2 comparisons fail closed by name.

The llama.cpp replacement campaign for the three installed GGUF models is tracked separately in LLAMACPP-REPLACEMENT-PLAN.md. Its state as of 2026-08-30:

• Phase 1 is code-complete; no live model has run it. execution_ready() is now derived from publication evidence the resource binder computes - projection dispatch arity over all 995 operation bindings, the F32 operator launch chain across all 30 layers, canonical KV sourcing, and transactional output publication - rather than being deliberately unreachable. Prefill is one transaction chain over the whole prompt span, so the 262,144-vocab tied output head and the sampler are paid once per prompt instead of once per prompt token. Sampling is real: OpenAI temperature/top_p/seed translate fail-closed (temperature: 0 is greedy here, deliberately unlike the Modilify backend's 0.01 clamp), the session threads rng_offset_after into each next token and refuses inconsistent reports, and unseeded requests draw from a per-backend SplitMix64 stream. The adapter, loader wiring, and a deployable manifest (schema/pascalrt-model.gemma4-native-gguf.json, 36 read-only assertions against the installed tree) are in place. The live smoke - --list-models ready, a streamed completion, fixed-seed reproducibility - has not been run: it is blocked on the two operator actions in plan section 6.13, namely placing one pascalrt-model.json beside the installed weights and a machine quiet enough to admit the 19,693,821,952-byte no-paging plan.
• Phase 3 is complete in code. The two-entry SHA-256 chat-template allow-list is replaced by a sandboxed Jinja evaluator with hard caps on template bytes, evaluation steps, depth, string bytes, container elements, and output bytes, no include/import/extends, no environment access, and a pinned clock. The manifest gained an additive-optional runtime block (KV type, expert placement narrowed to placements the session can reach, sampler defaults composed as request > manifest > engine default before the unchanged admission table). Gemma4 graph identity is derived from container metadata under named arithmetic relations instead of pinned literals; a synthetic variant checkpoint with a different sliding pattern, 657 tensors, and a different quantization mix compiles, and fifteen negative controls each refuse by name. The D:\LocalAI\Models literal is gone from core - the model root is threaded from the server's validated catalog root. GET /v1/models/{id}, OPTIONS CORS preflight on a compiled-in loopback-only origin, and named unsupported_parameter rejections for logprobs and top_logprobs are served. presence_penalty and frequency_penalty are composed request > manifest/preset > engine default and carried into the b10295 sampler chain.
• Definition-of-done gate 2 is open, and the reference side of it is now in question. Re-running the exact binaries the oracle fixture pins - hashes verified - against the exact hashed model showed that the fixture is not reproducible by its own binaries: no configuration of five reproduces its step 3, including the pure-CPU run, and step 12 flips with -ctk/--n-cpu-moe. Each configuration is individually deterministic, so this is configuration sensitivity, not noise; the fixture simply records no runtime configuration. Measured llama.cpp flag-induced relative logprob spread reaches 1.5300 logits, and 0.4289 for merely moving five of thirty expert layers between its own CPU and CUDA kernels. The fixture is annotated PROVISIONAL in place; no fixture value was changed and no gate was weakened. Against the recipe configuration PascalRT agrees on 12 of 16 steps, not 14; steps 6 and 10 remain real, PascalRT-specific divergences of more than 0.49 and 0.79 logits with a measured magnitude and no measured cause. The router divergence probe that would settle them is built and ready but was refused all session by host admission, short 0.98-1.38 GB of the requirement. The gate was not defeated and no run was made against it.
• The incumbent decode baseline was re-measured and it moved the bar up. Seven measured repetitions per case on b10295 put Gemma 4 at 23.8453 tok/s decode p50 on short-code-128, superseding deployment.json's 20.82 for gate purposes. These captures are canonical for decode only; their TTFT and prefill figures measure a warm prompt cache and are not gate values until the v2 catalog recapture takes an exclusive window.
• Phase 2 measured results, kept and rejected. The Gemma4 top-8 router ran <<<1,1>>> at 513.5 us per launch and 30 launches per token, 83% of all per-token reduction-and-routing work; the parallel replacement is 19.6 us, a +96.11% to +96.21% paired median across five runs, with byte-identical expert IDs and weights over 4,016 adversarial and uniform-bit-pattern logit sets. A warp-shuffle tail in the router GEMV is +9.43% to +10.67%, bitwise identical. An order-matched Q4_K device GEMV reproduces the production AVX2 eight-lane-then- tree accumulation order exactly and is bitwise identical to it (0 of 45,950 output words differing). A coalesced Q5_0/Q8_0 routed-down GEMV raised effective weight-read bandwidth from 9.1 to 26.3-35.0 GB/s (Q8_0 25.0 to 53.8-54.6 GB/s) with 0 of 380,920 words differing against both the host AVX2 kernel and the device kernel it replaces. Mixed host/device expert dispatch is proven bitwise under every mask tried, and the production bind now injects the device-compute backend. The placement widening was deliberately withheld five times, most recently because the per-layer histogram shows the deployed unprofiled plan lands its 979 device slabs as 128 each on layers 0-6, 83 on layer 7, and zero on 22 layers - and because no hot_expert_resident binding has ever been executed against the real container. Changes measured and rejected rather than promoted: warp-shuffle tails in rms_kernel and prepare_kernel at every installed geometry, and prefill microbatch widening, which is a monotone regression saturating at +16.5%.
• Phase 4 is open at component level only. The qwen35moe Gated-DeltaNet decode kernels and the 256-expert MoE FFN are transcribed from the vendored graph builder with file/line citations, each with a host reference oracle. With device-computed transcendentals seeded into the host reference, 0 of 41,000,960 recurrent words differ; the MoE router matched 0 expert-id mismatches over 2,064 adversarial 256-wide logit sets. Both carry component benchmarks. Neither has been compared against b10295 on a real tensor, and integration into a servable qwen35moe path has not started.
• Standing terms while gate 2 is open (plan section 6.11). The loopback shadow endpoint may serve; nothing may promote. Slice 5.5's promotion machinery is not to be exercised against the native engine until gate 2 has a passing, recorded resolution, and every serving artifact produced meanwhile carries the qualification caveat in its own record. No speed claim is made against the incumbent - none is admissible until the interleaved ABBA benchmark of at least 101 paired observations per case has been run.

This is not yet a production replacement. The linked llama.cpp compatibility backend is explicitly transitional, and loaded-GGUF execution under PascalRT is not yet accepted: the native Gemma4 engine is servable in principle on the loopback shadow port, but it has never answered a request against the installed checkpoint, and definition-of-done gate 2 is measured-failing against a reference fixture that is itself provisional. Native Modilify loading, 128k admission, and fixed-smoke generation now work, but no real 128k needle test or successful 30-minute soak has been completed. Structured tools, image input, explicit reasoning controls, and production cutover remain unsupported/not done. The current matched Python reference has a lower p50 wall time, so PascalRT does not yet claim a production speed win: retained-logit balanced remains 35.65% slower by median wall time. Paired short-code and prose probes also produced degraded, nonmatching long outputs. The same degeneration was reproduced by the Python checkpoint/profile, so it is not solely a native regression, but neither exact long-output equivalence nor acceptable task quality has been established. The production D:\LocalAI deployment remains untouched. See LLAMACPP-REPLACEMENT-PLAN.md for the campaign ledger, the definition of done, and the standing refusals, and RUNTIME-PLAN.md for the measured inventory, hard limits, memory ledger, and acceptance gates; RESULTS.md records the measurements completed so far, and MODILIFY-NATIVE-SPEC.md pins the installed model's native execution contract. OPENWEBUI-INTEGRATION.md defines the shadow, cutover, rollback, and future internal-UI boundary.

Latest measured profile snapshot

Profile/runtime	Exact expert layers cached	Measured runs	p50 TTFT	p50 wall	Median decode	Minimum free VRAM	Result
PascalRT balanced, retained logits	6	5	9,252.406 ms	17,178.778 ms	0.890118 token/s	1,573 MiB	Recommended candidate; 0 errors and exact visible content/hash parity
PascalRT maximum-model, earlier smoke	0	5	10,332.658 ms	19,331.167 ms	not reported	not compared here	Safer capacity fallback; timing predates retained-logit validation
Matched Python reference	deployment-defined	3	not comparable	12,664.338 ms	not comparable	not compared here	Exact visible content/hash reference

The Python endpoint buffers its SSE response, so its observed TTFT and derived decode split are not comparable with PascalRT's genuinely streamed timings; wall time is the valid comparison. Against the prior balanced result, retained logits reduced median TTFT by 6.36% and median wall time by 7.62%, and increased median decode by 10.81%. The corresponding mean deltas exceed both 5% and two pooled standard deviations. This is a measured PascalRT improvement, not a production speed win: 17,178.778 ms remains 35.65% slower than the matched Python median wall time of 12,664.338 ms.

Latest post-retained-logit preliminary thermal diagnostic (v2)

bench/results/pascalrt-balanced-retained-logits-preliminary-thermal-v2-20260826.json completed six requests with zero errors in 383.651 seconds. Prefill wall times were 99,630.106, 98,038.928, and 98,178.308 ms. Bounded-decode wall times were 25,199.867, 25,028.501, and 25,106.860 ms, with post-first decode throughput of 1.975088, 1.973710, and 1.976083 token/s.

P95 decode drift was -0.335% and passed. Post-request free RAM never fell below 8.328 GiB. Pagefile use was 231.172 MiB at every post-request sample, for zero growth. The report records win32:GlobalMemoryStatusEx and perflib:Paging File(_Total) as the respective memory sources, exercising the new non-elevated harness fallback after CIM denial. GPU telemetry recorded 82/80 C maximum/p95 temperature, 1,570 MiB minimum free VRAM, 132.425 W p95 power, and 92% p50 utilization.

Every configured gate in this preliminary report passed except no-active-throttle. Seventeen samples carried active reasons: 10 GPU-idle 0x1 and seven SW power-cap 0x4; zero software-thermal 0x20 samples were recorded. Overall acceptance therefore remains failed. This was still only a six-minute diagnostic and did not execute a final real 128k needle; it is not the required 30-minute promotion soak.

The v1 post-retained report, bench/results/pascalrt-balanced-retained-logits-preliminary-thermal-20260826.json, remains evidence, but v2 supersedes it for current thermal and host-memory status. V1 completed six error-free requests in 375.354 seconds, passed p95 regression at +0.286%, recorded 10 active-throttle samples including one software-thermal 0x20, and lacked RAM/pagefile telemetry. The earlier pre-retained diagnostic completed five requests, recorded 26 active- throttle samples including five 0x20 and one combined 0x24, and had decode wall times of approximately 29.1--29.4 seconds. These runs were not performed in perfectly controlled environments, so no causal speed, power, or thermal claim is made from their differences. The required 30-minute soak and real 128k needle remain outstanding. The maximum-speed profile remains capacity-rejected on the real 8 GB board headroom.

Paired quality probes

Each row below is one measured request, not a stable latency distribution.

Case/runtime	TTFT	Wall	Output assessment
Short-code / Python	23,635.487 ms	30,811.880 ms	Pathological repeated backticks, spaces, and 33
Short-code / balanced native	15,747.639 ms	37,549.361 ms	Similarly pathological; hash does not match Python
Prose / Python	72,054.657 ms	129,605.240 ms	Severe repeated punctuation and formatting
Prose / balanced native	51,800.470 ms	115,317.582 ms	Still degraded, somewhat more coherent, and hash does not match Python

The checkpoint/profile-level degeneration appears in both runtimes. This rules out attributing the entire quality failure to PascalRT, but it does not make the outputs acceptable and does not satisfy long-output equivalence.

Exact device admission

All rows use the same conservative free-VRAM observation of 7,565,475,840 bytes.

Profile	Blueprint hash	Cached expert layers	Device allocation	Device admission	Result
Maximum-model	0xd7acf2c4a23815bf	0	3,760,862,208 bytes	5,103,039,488 bytes	Accepted
Balanced	0x4fe6159c1a8c0f70	6	6,118,815,744 bytes	7,460,993,024 bytes	Accepted
Maximum-speed	0xccdf2cee612f8e86	9	7,297,792,512 bytes	8,639,969,792 bytes	Capacity-rejected

Combined host allocation remains 14,608,367,616 bytes and host admission remains 18,903,334,912 bytes for all three profiles.

Clean build

The supported build is Release, CUDA Toolkit 12.9, and native sm_61 SASS with no embedded PTX or other GPU architectures.

From an already prepared Visual Studio x64 environment, build with the short-path preset. It puts the build tree at C:/PascalRTBuild/release because this checkout is 119 characters deep, and an in-tree build directory pushes the C++20 module scanner's <object>.obj.ddi files past the 259-character Windows MAX_PATH limit that MSVC still enforces:

cmake --preset pascal-release-shortpath
cmake --build --preset pascal-release-shortpath
ctest --preset pascal-release-shortpath

The pascal-release preset builds into ${sourceDir}/b/pascalrt and is usable only from a checkout short enough to stay inside that limit. Configure measures CMAKE_BINARY_DIR and stops with a FATAL_ERROR naming the measured length and the 112-character budget, rather than compiling for minutes and then dying in cl.exe -scanDependencies with fatal error C1083: Cannot open compiler generated file. Pass -DPASCALRT_ALLOW_LONG_BUILD_PATH=ON to override the guard for a component subset whose object paths stay short:

cmake --preset pascal-release
cmake --build --preset pascal-release
ctest --preset pascal-release

The clean-build helper runs the same configuration and also sanitizes the host's duplicate Path/PATH environment entries before invoking CMake. Give it a short -BuildPath from this checkout; its default bench/build-clean resolves to 137 characters here and the guard rejects it:

./scripts/Invoke-PascalRTCleanBuild.ps1 -BuildPath C:\PascalRTBuild\clean `
    -Configuration Release -RunBuild

On the audited workstation, a bare nvcc.exe currently resolves to CUDA 13.3 and CUDA_PATH to CUDA 13.0. Neither lists compute_61, so neither can compile for Pascal. Configure runs nvcc --list-gpu-arch on the resolved CMAKE_CUDA_COMPILER and fails closed when compute_61 is absent, so a stale cache or a toolkit picked up from the environment cannot silently produce a non-Pascal build. Use the checked-in presets or clean-build helper rather than ad-hoc CUDA commands. The CUDA binary gates resolve CUDA 12.9 cuobjdump.exe beside the configured compiler and reject PTX or any cubin other than sm_61.

The directly linked GGUF compatibility build has hundreds of long CUDA object names. On Windows, give it a short build directory so NVCC dependency files remain below the path limit:

$linkedBuild = Join-Path $env:TEMP 'pascalrt-lc61'
./scripts/Invoke-PascalRTCleanBuild.ps1 -BuildPath $linkedBuild -Configuration Release `
    -AdditionalCMakeArgument '-DPASCALRT_ENABLE_LLAMA_COMPAT=ON' -RunBuild

The resulting gate inspects the final server and the linked upstream CUDA archive as well as PascalRT's native kernel tests; every device image must be sm_61, with no PTX or other GPU architecture.

Safe inspection and shadow testing

Inspect a model without loading tensor payloads:

./b/pascalrt/pascalrt-inspect.exe D:\LocalAI\Models\example\model.gguf --context 131072 --sequences 1 --kv-type q4_0
./b/pascalrt/pascalrt-inspect.exe D:\LocalAI\Models\modilify-mk1-preview-128k\model.safetensors.index.json --context 131072 --sequences 1 --kv-type f16

PASCALRT_MODEL_ROOT defaults to D:\LocalAI\Models at configure time and can also be overridden in the process environment or with server --model-root. Each installed model may contain a pascalrt-model.json using the versioned manifest schema; the checked-in example is a starting point. Artifact and tokenizer references are relative to that manifest. PascalRT canonicalizes them, rejects .., out-of-root targets, and Windows reparse points, and never follows reparse directories during discovery.

./b/pascalrt/pascalrt-server.exe --list-models
./b/pascalrt/pascalrt-server.exe --catalog-model modilify-mk1-preview-128k `
    --allow-unauthenticated

Discovery is format-neutral, but manifest discovery is not execution enablement. pascalrt.native-gguf is the canonical native GGUF engine ID and is always registered for catalog recognition. The production preset now builds the exact Gemma4 family adapter and wires loaders.native_gguf.validate and .load; a build without those options still lists such manifests as unsupported_backend, and catalog selection, ticket acquisition, and loading all fail closed. Any other family becomes runnable only after the service registers an exact model-ID/architecture/format adapter and wires its validated loader. A manifest declares the canonical engine like this:

{
  "schema": "pascalrt.model-manifest.v1",
  "manifest_version": 1,
  "id": "future-gemma",
  "architecture": "gemma4",
  "format": "gguf",
  "backend": "pascalrt.native-gguf",
  "artifact": "model.gguf",
  "context_length": 131072
}

Do not install a production manifest for any family whose adapter is not qualified. The Gemma4 native-GGUF adapter is wired and its readiness predicate is now derived from publication evidence rather than withheld, but it has never been exercised against the installed checkpoint: the live serve smoke and the manifest placement are still deferred to the sanctioned window described in plan section 6.13, and definition-of-done gate 2 remains measured-failing. Until that window is taken, treat GGUF execution as available only through the explicitly enabled transitional llama.cpp.compat adapter.

Transactional model control is disabled by default. Enable it only on the IPv4 loopback listener with an attested catalog model and two distinct credentials:

$env:PASCALRT_API_KEY = 'replace-with-a-local-inference-secret'
$env:PASCALRT_MODEL_CONTROL_API_KEY = 'replace-with-a-separate-admin-secret'
$env:PASCALRT_ENABLE_MODEL_CONTROL = '1'
./b/pascalrt/pascalrt-server.exe --host 127.0.0.1 --port 18081 `
    --catalog-model modilify-mk1-preview-128k

--enable-model-control is the CLI equivalent of the opt-in environment variable. The administrative credential must contain 16–4096 non-whitespace bytes, is accepted only by model-control routes, and must never equal the inference bearer. The app discovers one immutable catalog snapshot, acquires and retains the initial artifact ticket before loading, and accepts loader inputs only from declared roles. Native Modilify requires a safetensors-index primary checkpoint directory plus regular-file tokenizer, configuration, and chat_template roles. Before any backend allocation, the configuration must be the same filesystem object as primary/config.json, and the template must match the qualified 18,961-byte Modilify template identity. llama.cpp.compat accepts a primary GGUF plus the optional tokenizer and chat_template roles when those adapters are linked. The native-GGUF loader accepts one regular primary GGUF file plus a tokenizer role and an optional chat_template override; absent an override it resolves the container's embedded template, and a load-time probe render must evaluate and publish an in-range end-of-generation token before any placement is made. Projector, draft, payload, and every role not declared by the selected loader fail closed. During model-control PREPARE, these same static checks run before the active backend is drained or detached. The administrative status response exposes the detached/recovery phase explicitly; it never implies blue/green residency on a board whose memory ledger allows only one backend at a time.

Start the deterministic contract-test service on the shadow port:

$env:PASCALRT_API_KEY = 'replace-with-a-local-random-secret'
./b/pascalrt/pascalrt-server.exe --host 127.0.0.1 --port 18081 `
    --tokenizer-json D:\LocalAI\Models\modilify-mk1-preview-128k\tokenizer.json

After building the current source, validate the native Modilify catalog and 128k admission without allocating the runtime arenas:

./b/pascalrt/pascalrt-server.exe `
    --modilify-root D:\LocalAI\Models\modilify-mk1-preview-128k `
    --modilify-profile balanced `
    --modilify-dry-run

Start a checkpoint-loading candidate on the loopback shadow port:

$env:PASCALRT_API_KEY = 'replace-with-a-local-random-secret'
./b/pascalrt/pascalrt-server.exe --host 127.0.0.1 --port 18081 `
    --modilify-root D:\LocalAI\Models\modilify-mk1-preview-128k `
    --modilify-profile balanced

Use --modilify-profile maximum-model when the safer capacity fallback is preferred. Do not select maximum-speed on this workstation: its 8,639,969,792-byte admission requirement exceeded the measured conservative 7,565,475,840-byte free-VRAM value. Keep Open WebUI on the existing llama.cpp endpoint until every release gate passes.

The deployment harness refuses live requests without -RunLive, refuses promotion without full quality and benchmark reports, and retains a dated route backup for rollback. Detailed commands are in scripts/README.md, bench/README.md, and quality/README.md.

Repository map

• include/pascalrt and src: native core, service, and CUDA components.
• apps/pascalrt-server: service entry point.
• tests: deterministic CPU, API-contract, CUDA, and harness tests.
• bench and quality: versioned cases, schemas, and generated-result locations.
• scripts: host capture, repeated benchmarks, endpoint parity, soak, and safe shadow promotion/rollback.
• third_party: pinned upstream reference trees used only during migration.

Generated benchmark reports and build products are local artifacts. Model files remain in place on D: and are never copied into this tree.