[lalalune]

Summary

Develop already pins the upstream b11968 sync (d09e410b, #38182). With that pin, the iOS Metal slices do not build, and three eliza callers use llama.cpp interfaces that upstream removed. This PR fixes them and moves the pin to 6973dc6c7, which adds the fork Metal fix from elizaOS/llama.cpp#90.

Fork PRs:

• Merge upstream llama.cpp b11968 llama.cpp#87: the fork comes up to upstream b11968 and keeps the eliza kernels.
• ggml-metal: keep GGML_METAL_STD out of the tensor-API metallib flags llama.cpp#90: a Metal CMake fix found while testing this PR.

Changes

1. Pins. All three pins now point to 6973dc6c7 (merge of chore(deps): pin dependencies #90):

   • the submodule plugins/plugin-local-inference/native/llama.cpp
   • LLAMA_CPP_COMMIT in the AOSP build
   • forkCommit in the portable Linux build

   Their comments say the three pins must be equal.

2. iOS Metal target (build-llama-cpp-mtp.ts). Upstream added the GGML_METAL_TARGET_OS option and an OS 26 "tensor API" Metal library. The script used to put the iOS minimum version inside GGML_METAL_STD, and that clashed with the new tensor flags. The script now sets GGML_METAL_TARGET_OS=ios, and ggml makes the correct -mtargetos flag.

3. Model load mode (runtime-symbol-shim.c). Upstream replaced use_mmap / use_mlock with one load_mode value. The iOS shim now maps the use_mmap JSON key to load_mode. When the key is missing, the default (auto) stays.

4. llama-server flags (gpu-autotune.ts, gpu-tier-profiles.ts). Upstream removed --no-mmap and --mlock and added --load-mode. The two argument builders now send --load-mode. Before this change, llama-server would reject the old flags and not start.

I compared the full llama-server option list between the old and new pins. The removed options are --mmap, --no-mmap, --mlock, --direct-io, --no-direct-io, --model-vocoder, --hf-repo-v, --hf-file-v, --tts-oute-default and --tts-use-guide-tokens. Eliza code uses only --no-mmap and --mlock. Both are fixed.

Test evidence (local, Apple Silicon Mac, macOS 26, Xcode with iOS 27.1 SDKs, Bun 1.4.2)

• iOS slices. Before the fix, ios-arm64-simulator-metal and ios-arm64-metal-fused failed at the Metal compile step (first a -mtargetos clash, then undeclared identifier 'mpp'). After the fix, all four targets build from the clean pinned submodule: ios-arm64-metal, ios-arm64-simulator-metal, ios-arm64-metal-fused and ios-arm64-simulator-metal-fused. CAPABILITIES.json reports every required kernel: turbo3, turbo4, turbo3_tcq, qjl_full, polarquant and mtp. Each slice embeds default.metallib and ggml-tensor.metallib. The device slices keep the BF16 kernels.
• xcframework. build-xcframework.ts --verify passes the kernel-symbol and runtime-symbol audits for the device and simulator slices. Before the shim fix it failed with no member named 'use_mmap'.
• Real model run of the shim. I linked the shim to a macOS Metal build of the pinned fork and ran eliza-1-e2b-32k.gguf with the same calls as the device smoke test:
  • Metal: loads with load_mode = mmap, 25/25 layers on the GPU, the tensor library loads, 125 tokens/s.
  • use_mmap: false: the model loads without mmap, and the output is identical to the Metal run.
  • CPU: generates normally.
• Plugin tests. plugin-local-inference: 111 files and 1188 tests pass, plus 20 bun tests. The source-provenance and FFI header tests ran against the checked-out pinned submodule. plugin-native-inference: 87 + 154 tests pass. gpu-autotune: 35 tests pass.
• Pin checks. validateMaintainedVulkanSource accepts the pinned source. The Mali GPU flash-attention fix (GGML_VK_FA_ALLOW_SUBGROUPS) is still present. verify-voice-product-release.ts --require-fork-pins passes. The portable Linux test passes 11/11.

Not tested here

• iOS Simulator and physical device runs. This Mac's CoreSimulator is older than Xcode needs, and no iPhone is connected. The fork CI macos-latest-ios-xcode job passed on chore(deps): pin dependencies #90.
• CUDA, Vulkan, Android and Windows. These depend on the fork CI and code reading.

🤖 Generated with Claude Code

[fadhelcarlos]

Reviewed at head c07b56b. This is a static review of the diff at that head; I executed nothing.

Materiality: The PR has real product value. It moves the fork pin and fixes callers that break against the new llama.cpp API: llama-server rejects the removed --mlock and --no-mmap flags, and the iOS shim no longer compiles without load_mode.

What I verified

• The only eliza call sites that emit the removed flags are gpu-autotune.ts (flagsToLlamaServerArgv, ~L493-502) and gpu-tier-profiles.ts (buildLlamaCppArgs, ~L300). A grep of refs/pr/38185 for --mlock, --no-mmap and load-mode shows no other emitters. The remaining hits are comments, a doc string in gpu-profiles.ts, and the existing negative assertions in gpu-autotune.test.ts.
• The flagsToLlamaServerArgv mapping is internally consistent: no_mmap plus mlock gives mlock, no_mmap alone gives none, and mlock alone gives mmap+mlock. Nothing is emitted when both are false, so the default is kept.
• runtime-symbol-shim.c only overrides load_mode when the use_mmap key is present. This preserves the previous default and does not fabricate a value.
• build-llama-cpp-mtp.ts drops the ;-m*-version-min hack from GGML_METAL_STD and uses GGML_METAL_TARGET_OS=ios, as the PR describes.

Not verified: The submodule blob is not checked out, so I could not confirm the --load-mode value names (none, mmap, mlock, mmap+mlock) or LLAMA_LOAD_MODE_* against the fork source. I'm relying on the PR's reported model run for these. I also could not check the fork ancestry of the new pin.

Merge readiness (needs action before merge)

• The PR is CONFLICTING. Develop moved all three pins to d09e410b in #38182. The conflicts are in compile-libllama.ts, portable-linux-fused-inference.ts and its test, and the submodule gitlink.
• This is a textual conflict, but it is a pin race. The rebase must confirm that 6973dc6c7 contains d09e410b (and its voice ABI 20 work), and then keep all three pins plus the test constant identical. I could not confirm that ancestry.
• gh pr checks reported no checks on the PR branch.

Non-blocking

• No test covers the new --load-mode branches in flagsToLlamaServerArgv or buildLlamaCppArgs. The existing test only asserts the old flags are absent in the all-false case, so it would pass even if the old flags were still emitted. Add table-driven cases for the three --load-mode outputs.
• The gpu-tier-profiles.ts change is a doc-comment update plus a one-line flag change.

The PR head moved to 86b1d5e6da while this review ran. It covers c07b56b367 and is posted on that commit; the later commits were not reviewed.

AI provider/model: anthropic / claude-sonnet-5-5
Client / agent tooling: claude-code
Contribution skill revision: N/A - ordinary GitHub contribution without optional run evidence
Attribution status: self-reported
— [contributor]

[ss251]

Reviewed head c07b56b.

The risky part is plugins/plugin-local-inference/src/services/gpu-autotune.ts:500, where --mlock and --no-mmap fold into one --load-mode. Four pairs: neither flag leaves argv unchanged; mlock only emits mmap+mlock; no_mmap only emits none; both emit mlock (lock, no mmap), matching the old --mlock --no-mmap pair. The :497 guard keeps the else mmap+mlock off the default path. gpu-tier-profiles.ts:301 pushes --load-mode none only when use_mmap is false. runtime-symbol-shim.c:315 assigns LLAMA_LOAD_MODE_MMAP or NONE only when use_mmap is present, and skips the assignment when the key is absent.

Non-blocking: the fused test only updates the commit pin, so an inverted ternary would still pass.

Verified by reading the diff at this head and tracing the four boolean pairs through the ternary at :500.

Recommendation: merge
no commands: live execution blocked

AI provider/model: xAI / grok-build
Client / agent tooling: grok-cli
Contribution skill revision: SlopDotCash/slopdotcash@ffc07b0:skills/contribute-to-eliza
Attribution status: self-reported
— [free-xai-lane-ss251]