Complete the macOS Mojo release matrix, packaging, and Metal cutover #91

New Issue

hugo · 2026-08-31T12:13:29Z

hugo commented

2026-08-31 12:13:29 +00:00

Goal

Turn the verified Mojo-Metal implementations into a reproducible macOS DS4Server release, run the final Apple-platform acceptance matrix, and only then make Mojo the default.

This is the completion gate for the main transition. CUDA is a separate optional issue after this one and cannot delay Metal delivery.

Final Metal matrix

Run fresh builds from the same commit and lockfile on supported Apple hardware:

DS4Server native Metal versus Mojo-Metal.
All supported DeepSeek Flash, Pro, and V4 variants and enabled long-context, streaming, checkpoint, steering, and MTP modes.
GLM 5.2 baseline and enabled Compact KV, sparse or indexed attention, and MTP modes.
Qwen3.8-27B Q4 and Q8 text, long-context positions, MTP, and multimodal paths. Full Q8 performance is required where resident.
At least three independent measurement series per combination covering correctness, prefill, time to first token, stable decode, p95 latency, memory, transfers, and cold start.

No missing required Mac run may be reported as complete. No DGX or CUDA evidence is required here.

Build and packaging

Keep Cargo and build.rs as the only product build entry point.
Build Mojo from pinned dependencies and an offline frozen environment after bootstrap.
Package the Mojo library and only approved runtime files in the macOS application using relative release RPaths.
Copy and normalize libraries before final code signing, then inspect the finished bundle with otool and nm.
Prove execution on a supported Mac without the source checkout or project virtual environment.
Generate third-party license and notice material from the exact binary closure.
Fail release builds for lock drift, missing libraries, compiler warnings, absolute development RPaths, uninventoried non-system libraries, or unknown and non-redistributable dependencies.
Require Apple silicon and macOS 15 or newer, matching the floor established by #84 and the committed build/package configuration.

License gate

DS4Server remains MIT. Prefer Apache-2.0 with LLVM exceptions, MIT, BSD, or equivalent dependencies. Every dependency record must include exact source, license, use, distributed files, notices, alternative, and redistribution status. Unknown and non-redistributable are release blockers. MAX adoption remains subject to both the #84 license decision and native-Metal performance parity.

Cutover

Ship Mojo-Metal as opt-in first while native Metal remains selectable for diagnosis.
Make Mojo-Metal default only after the final matrix, Mac hardware CI, artifact audit, and rollback preparation pass.
Keep native Metal for a defined validation period.
Remove native Metal only when the operation inventory is closed, hardware CI is regular, no correctness or performance exception remains, baseline and rollback artifacts exist, and the user explicitly approves removal.
Do not introduce a generic accelerator plugin framework.

Definition of done

Rust still owns DS4 behavior and product state; Mojo owns macOS GPU inference.
DeepSeek, Qwen3.8, and GLM share one Mojo operation and model foundation.
Full runs produce identical tokens and observable DS4 state.
Mojo-Metal is not slower than native Metal on the same Mac.
There are no silent fallbacks, mixed benchmarks, unexplained regressions, extra token-path transfers, or license blockers.
Builds, fixtures, reports, license records, and the macOS release are reproducible.
The code retains narrow target and data-layout seams for future CUDA, but no CUDA work is required for completion.

Binding outcome from #84 (2026-08-31)

#84 stopped product integration on Mojo 1.0.0 because the open compiler/standard-library environment has no host-side Metal DeviceContext. The working max.gpu.host path requires MAX plus AsyncRT/KGEN dylibs whose component-specific redistribution permission could not be established. mojo build --emit shared-lib also links @rpath/libKGENCompilerRTShared.dylib for a trivial export.

Release acceptance must account for Mojo 1.0 requiring Apple silicon and macOS 15+. The product floor is Apple silicon and macOS 15 or newer. Packaging must enumerate, license, embed, rpath, sign, and clean-machine test every non-system dylib; the current AsyncRT/KGEN closure is not approved.

These constraints are acceptance criteria:

keep Mojo pinned to 1.0.0 through the committed uv.lock; do not use nightly or an older release;
do not add max, max-core, max-mojo-libs, AsyncRT, or KGEN to the product/build/package closure without an authoritative redistribution grant naming every shipped component;
do not treat Apache-licensed MAX Mojo source as permission to redistribute separately delivered runtime binaries;
target Apple silicon and macOS 15 or newer, while preserving native Metal as production until the runtime gate passes;
before implementation resumes, re-run the #84 closure, clean-machine packaging, code-signing, and same-workload parity gates documented in docs/MOJO_SPIKE_84.md;
CUDA remains a separate Linux/NVIDIA toolchain, runtime-closure, redistribution, and hardware-validation decision.

If the runtime grant or open host API changes, update #84 evidence first so this milestone has one source of truth.

## Goal Turn the verified Mojo-Metal implementations into a reproducible macOS DS4Server release, run the final Apple-platform acceptance matrix, and only then make Mojo the default. This is the completion gate for the main transition. CUDA is a separate optional issue after this one and cannot delay Metal delivery. ## Final Metal matrix Run fresh builds from the same commit and lockfile on supported Apple hardware: - DS4Server native Metal versus Mojo-Metal. - All supported DeepSeek Flash, Pro, and V4 variants and enabled long-context, streaming, checkpoint, steering, and MTP modes. - GLM 5.2 baseline and enabled Compact KV, sparse or indexed attention, and MTP modes. - Qwen3.8-27B Q4 and Q8 text, long-context positions, MTP, and multimodal paths. Full Q8 performance is required where resident. - At least three independent measurement series per combination covering correctness, prefill, time to first token, stable decode, p95 latency, memory, transfers, and cold start. No missing required Mac run may be reported as complete. No DGX or CUDA evidence is required here. ## Build and packaging - Keep Cargo and build.rs as the only product build entry point. - Build Mojo from pinned dependencies and an offline frozen environment after bootstrap. - Package the Mojo library and only approved runtime files in the macOS application using relative release RPaths. - Copy and normalize libraries before final code signing, then inspect the finished bundle with otool and nm. - Prove execution on a supported Mac without the source checkout or project virtual environment. - Generate third-party license and notice material from the exact binary closure. - Fail release builds for lock drift, missing libraries, compiler warnings, absolute development RPaths, uninventoried non-system libraries, or unknown and non-redistributable dependencies. - Require Apple silicon and macOS 15 or newer, matching the floor established by #84 and the committed build/package configuration. ## License gate DS4Server remains MIT. Prefer Apache-2.0 with LLVM exceptions, MIT, BSD, or equivalent dependencies. Every dependency record must include exact source, license, use, distributed files, notices, alternative, and redistribution status. Unknown and non-redistributable are release blockers. MAX adoption remains subject to both the #84 license decision and native-Metal performance parity. ## Cutover - Ship Mojo-Metal as opt-in first while native Metal remains selectable for diagnosis. - Make Mojo-Metal default only after the final matrix, Mac hardware CI, artifact audit, and rollback preparation pass. - Keep native Metal for a defined validation period. - Remove native Metal only when the operation inventory is closed, hardware CI is regular, no correctness or performance exception remains, baseline and rollback artifacts exist, and the user explicitly approves removal. - Do not introduce a generic accelerator plugin framework. ## Definition of done - Rust still owns DS4 behavior and product state; Mojo owns macOS GPU inference. - DeepSeek, Qwen3.8, and GLM share one Mojo operation and model foundation. - Full runs produce identical tokens and observable DS4 state. - Mojo-Metal is not slower than native Metal on the same Mac. - There are no silent fallbacks, mixed benchmarks, unexplained regressions, extra token-path transfers, or license blockers. - Builds, fixtures, reports, license records, and the macOS release are reproducible. - The code retains narrow target and data-layout seams for future CUDA, but no CUDA work is required for completion. ## Binding outcome from #84 (2026-08-31) #84 stopped product integration on Mojo 1.0.0 because the open compiler/standard-library environment has no host-side Metal `DeviceContext`. The working `max.gpu.host` path requires MAX plus AsyncRT/KGEN dylibs whose component-specific redistribution permission could not be established. `mojo build --emit shared-lib` also links `@rpath/libKGENCompilerRTShared.dylib` for a trivial export. Release acceptance must account for Mojo 1.0 requiring Apple silicon and macOS 15+. The product floor is Apple silicon and macOS 15 or newer. Packaging must enumerate, license, embed, rpath, sign, and clean-machine test every non-system dylib; the current AsyncRT/KGEN closure is not approved. These constraints are acceptance criteria: - keep Mojo pinned to 1.0.0 through the committed `uv.lock`; do not use nightly or an older release; - do not add `max`, `max-core`, `max-mojo-libs`, AsyncRT, or KGEN to the product/build/package closure without an authoritative redistribution grant naming every shipped component; - do not treat Apache-licensed MAX Mojo source as permission to redistribute separately delivered runtime binaries; - target Apple silicon and macOS 15 or newer, while preserving native Metal as production until the runtime gate passes; - before implementation resumes, re-run the #84 closure, clean-machine packaging, code-signing, and same-workload parity gates documented in `docs/MOJO_SPIKE_84.md`; - CUDA remains a separate Linux/NVIDIA toolchain, runtime-closure, redistribution, and hardware-validation decision. If the runtime grant or open host API changes, update #84 evidence first so this milestone has one source of truth.

hugo added the idea label 2026-08-31 12:13:29 +00:00

hugo added this to the Mojo GPU Backend Transition milestone 2026-08-31 12:14:26 +00:00

hugo changed title from ~~Complete the Mojo release matrix, packaging, cutover, and native-backend retirement~~ to Complete the macOS Mojo release matrix, packaging, and Metal cutover

2026-08-31 12:29:54 +00:00

hugo referenced this issue

2026-08-31 12:31:05 +00:00

Optional follow-up: add CUDA to the completed Mojo backend #92

hugo referenced this issue

2026-08-31 13:26:40 +00:00

Spike: prove a license-safe, performance-parity Mojo-Metal integration #84

hugo commented

2026-08-31 14:01:56 +00:00

Based on findings in #84, all work on MOJO migration is stopped. Licene-hell.

hugo closed this issue

2026-08-31 14:01:56 +00:00

hugo commented

2026-08-31 15:31:51 +00:00

Project decision: the Mojo backend effort is canceled. All committed spike tooling, dependencies, lockfiles, and documentation were removed in 9a33c61; generated probe state was deleted as well. The independent Apple-silicon/macOS-15 product floor remains. This issue is no longer actionable.

Project decision: the Mojo backend effort is canceled. All committed spike tooling, dependencies, lockfiles, and documentation were removed in `9a33c61`; generated probe state was deleted as well. The independent Apple-silicon/macOS-15 product floor remains. This issue is no longer actionable.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hugo/DS4Server#91