deepseek41 : add core DeepSeek V4.1 runtime (arch, loader, Engram, expert store, memory admission, watchdog)

[ajaxdude]

Overview

This is Layer 1 (PR A) of a two-PR stack reviving closed PR #59 ("trace : recover DeepSeek V4.1 correctness harness"), which was closed alongside #49 and #60 for two reasons: (1) all three PRs targeted master directly instead of stacking, so each diff showed the combined content of its unmerged predecessors; (2) leaked personal paths. This PR succeeds #49 with the same substantive content, properly restacked with clean history and no personal paths.

This layer adds the core DeepSeek V4.1 runtime, scoped as the model-execution half of the correctness-harness effort tracked in #48:

• LLM_ARCH_DEEPSEEK41 registration and GGUF schema (gguf-py/gguf/constants.py, src/llama-arch.{cpp,h})
• Model graph and loader wiring (src/models/deepseek41.cpp, src/llama-model.cpp, src/llama-model-loader.cpp, src/llama-graph.cpp, src/llama-context.cpp, include/llama.h, common/arg.cpp)
• Engram state and expert store (src/llama-engram.*, src/llama-expert-store.*, src/llama-dsv41-engram.*, src/llama-dsv41-expert.*, src/llama-dsv41.*)
• On-disk expert memory admission (src/llama-memory-dsv41.*, src/llama-bounded-file.*, src/llama-ple-disk.cpp integration)
• A standalone host-memory watchdog script and docs (scripts/strix_memory_watchdog.py, docs/strix-memory-watchdog.md)
• Unit tests for all of the above

PR B (the correctness trace harness under tools/deepseek-v41-trace/) will be created afterward, stacked on top of this branch. This layer deliberately does not include tools/deepseek-v41-trace/, tools/server/ integration, or the PR60 host-memory-guard-in-loader scope; those are out of scope here.

AI usage disclosure: AGENT-AUTHORED. I (Claude Sonnet 5, running as GitHub Copilot) rebuilt this layer from scratch: reconciled the 12 files that drifted between the old closed branch and current master (see below), re-applied the validated DeepSeek V4.1 content on top of current master, and wrote fresh commits.

Twelve-file reconciliation

Twelve files changed on current master since the old branch's merge-base and had to be reconciled (3-way merge of base/master/old-branch content) rather than blindly overwritten:

• gguf-py/gguf/constants.py, src/llama-arch.cpp, src/llama-arch.h, common/arg.cpp, include/llama.h, src/llama-context.cpp, src/llama-graph.cpp, src/llama-model-loader.cpp, src/llama-model.h, tests/CMakeLists.txt -- merged with zero conflicts (purely additive on both sides).
• src/llama-model.cpp -- one conflict: both master (LLAMA_LAZY_MODE_DIRECT skip) and this branch (!ml.external.any() skip) touched the same ml.init_mappings(...) call; resolved by combining both conditions.
• src/llama-ple-disk.cpp -- the significant one: master had independently reworked the row-gather algorithm (old uniq-sorted scheme -> new order/runs/job_kind scheme with calling-thread work-stealing) since the merge-base. This branch's llama_bounded_file abstraction (exception-based I/O error handling, replacing raw pread/O_DIRECT) was hand-integrated onto master's newer scheduling algorithm, including extending exception propagation to cover the calling thread's own work-stealing pass, and keeping a dedicated raw fd for prefetch()'s posix_fadvise hint (a master-only addition postdating the merge-base that llama_bounded_file doesn't expose).

Scope decision made during implementation

tests/test-deepseek41-runtime.cpp (checked out into this layer, per plan) includes tools/deepseek-v41-trace/trace-components.h to validate the trace-tensor naming contract round-trip. Since that header is explicitly PR B's content, its CTest registration is deferred to that layer (the file exists in this tree but is not yet wired into tests/CMakeLists.txt; PR B will add that registration when it adds the header).

Measurements

Not applicable. This layer only adds new architecture registration, loader plumbing, and CPU-side runtime infrastructure; nothing in this PR is reachable without a DeepSeek V4.1 GGUF, and no such model was loaded or run as part of this work (standing constraint: no inference, no GGUF loaded). There is no throughput or latency claim to make, and no baseline to compare against, until PR B's trace harness can actually drive a model through this code. This section will be populated as needed by future performance work once end-to-end correctness is established.

Correctness:

Model-free build and targeted CTest, run on this development machine (macOS/arm64, not Strix hardware):

cmake -S . -B build -DLLAMA_BUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build -j$(nproc)
ctest -R 'deepseek41|test-engram|test-expert-store|test-llama-archs' --output-on-failure

100% tests passed, 0 tests failed out of 7
    test-deepseek41-schema    Passed
    test-deepseek41-engram    Passed
    test-deepseek41-expert    Passed
    test-expert-store         Passed
    test-deepseek41-memory    Passed
    test-engram               Passed
    test-deepseek41-no-alloc  Passed

Also ran directly (not wired into CTest on non-Linux): gguf-py/tests/test_deepseek41_schema.py (4 passed) and tests/test_strix_memory_watchdog.py (36 passed, 8 skipped - Linux-only process-group cases).

Note: building in this macOS environment required a local, uncommitted one-line guard around a pre-existing posix_fadvise/POSIX_FADV_WILLNEED call in llama-ple-disk.cpp that is unrelated to this PR (it predates this branch, landed at the merge-base commit, and is a known, currently-failing CI (apple) issue on master itself -- POSIX_FADV_WILLNEED does not exist on macOS). That local shim was reverted before committing; it is not part of this PR's diff.

Additional information

Related: #48 (tracking issue), #49 (predecessor, closed for stacking/leak hygiene), #59 (predecessor, closed for the same reason), #60 (companion PR covering the host-memory-guard-in-loader integration, deliberately excluded from this layer's scope).

Requirements

• I have read and agree with the contributing guidelines
• This change is Strix Halo specific: DeepSeek V4.1's Engram/expert-store design targets Strix Halo's unified-memory constraints (bounded on-disk expert paging, host-memory watchdog for degraded-swap conditions). No performance claim is made in this layer; that is PR B's job once correctness is established end-to-end.
• AI usage disclosure: AGENT-AUTHORED (Claude Sonnet 5 / GitHub Copilot). See above for what was reconciled vs. directly reused.
• What was NOT verified: no GGUF loaded, no inference run, no ROCm/Vulkan backend exercised, no Strix hardware run. Cross-runtime and hardware-backed correctness are explicitly out of scope for this layer and are PR B's responsibility.

[ajaxdude]

@dzannotti Reopening this as a clean revival of #49 (and its siblings #59/#60), which you closed citing two specific issues: PRs "poorly stacked" against master instead of each other, and leaking "an incredible amount of personal configuration and pathing."

Both are fixed here, concretely:

• Stacking: This PR (base=master) and its follow-up trace : add DeepSeek V4.1 cross-runtime correctness harness #67 (base=this branch) are registered as a native GitHub Stack (65B model giving incorect output ggml-org/llama.cpp#69). trace : add DeepSeek V4.1 cross-runtime correctness harness #67's diff is additive-only on top of this branch, not a duplicate of it -- verified via gh pr view --json baseRefName showing trace : add DeepSeek V4.1 cross-runtime correctness harness #67 based on jeromecoste-microsoft-deepseek-v41-core-runtime, not master.
• Personal-path leaks: every added line in both diffs has been re-grepped for the leaked pattern (/home/papa/... and related patterns) -- zero real hits. The remaining /Users///home/ matches in trace : add DeepSeek V4.1 cross-runtime correctness harness #67 are placeholder test-fixture/README paths (/Users/oracle/..., /home/repo) deliberately chosen to look generic, not real machine paths.
• Fresh, minimal commit history was written for both layers instead of replaying the old 113-commit branch (this PR: 7 commits; trace : add DeepSeek V4.1 cross-runtime correctness harness #67: 3 commits).

Both PR descriptions include a full scope accounting, what was/wasn't verified, and an AI-authorship disclosure.

What I'm asking for: a re-review of this PR and #67 with the above in mind. If either issue resurfaces, or anything else needs attention, please say so directly and I'll fix it before requesting merge.

[ajaxdude]

Closing and superseding with #70. Same content, same 7 commits, byte-identical diff -- but this PR's commits carried a real name + machine hostname as git author/committer (Jerome Coste <jeromecoste@Jeromes-MacBook-Pro.local>), and the branch name embedded a corporate username (jeromecoste-microsoft-...). Same category of issue that got the original #49/#59/#60 closed (leaked personal configuration/pathing), just at the commit-metadata/branch-name level instead of file content. Fixed via authorship rebase (git commit --amend --reset-author, verified zero content diff) and a fresh push under a leak-free branch name. Note: GitHub retains this PR's old branch name in this page's own history regardless of what happens to the branch itself -- that's an inherent platform limitation of closing/re-opening rather than something further action here can fix; #70 is clean going forward.