Skip to content

Instantly share code, notes, and snippets.

@michaelneale
Created September 15, 2026 08:52
Show Gist options
  • Select an option

  • Save michaelneale/4758d98f4bd0ded842368ff88e5a657c to your computer and use it in GitHub Desktop.

Select an option

Save michaelneale/4758d98f4bd0ded842368ff88e5a657c to your computer and use it in GitHub Desktop.
Second opinion: Mesh-LLM PR #1880 generic activation-frontier (V2 multipart) proposal

Second opinion on the V2 multipart activation-frontier proposal (Mesh-LLM PR #1880)

Independent review by Galadriel (AI engineering agent), 2026-09-15, at exact head c3abbb5d93b7fee568fee08a047ce856e0afc190. Context: Mesh-LLM/mesh-llm#1880

Verified claims

  • Family-flag fan-out is real. SKIPPY_ACTIVATION_FLAG_{RWKV7_V_FIRST,GEMMA3N_ALTUP,INKLING_MTP_EMBD,GLM_DSA_TOP_K} defined in patch 0002 (include/skippy/activation.h), KIMI_K3_RESIDUAL added by 0039. Rust mirrors: 84 direct flag-constant references across skippy-ffi, skippy-protocol (binary/activation.rs codec sizing + GLM I32 sideband handling), skippy-server forwarding/prefill, skippy-runtime media, host-runtime local_split loading, skippy-topology multipliers (activation_payload_multiplier_for_boundary hardcodes 4x AltUp / 2x RWKV7). Order of magnitude matches scama's 171/17 count.
  • The planner frontier exists and is verified. Patch 0005 (stage_slice_plan.cpp, graph_identity.cpp) computes activation_imports/exports vectors with per-value stable identities, and skippy_validate_stage_chain rejects adjacent stages whose activation_export_identities != activation_import_identities. Host-runtime stage_admission.rs already reads those identity vectors.
  • Execution ignores it. skippy_stage_slice_selection never appears in patch 0004 (execution). The wire contract is one contiguous tensor + flags, with per-family validation matrices ("cannot be combined with other sidebands"), per-family byte formulas, and per-family graph-input setters in activation.cpp / graph_build_inputs.h.

So the central finding is correct: the generic mechanism exists in planning; transport re-derives the same information with family rules in 5–6 layers.

Assessment

Endorse the direction and the staging (opaque-native first, then V2, per-family migration). Caveats:

  1. The biggest hidden cost is identity → execution-tensor binding. Identities are computed on the metadata-only planning graph (patch 0012); execution graphs are rebuilt per ubatch with can_reuse swapping. Today boundary tensors at execution time are found via named getters (get_skippy_kimi_k3_residual) and block-boundary conventions. V2 needs a runtime mechanism to tag execution-graph tensors with planner identities across rebuilds. This does not exist yet and is the real engineering center of the work.
  2. The early frontier-hash check is partial. GLM top-k count varies with n_kv, Kimi checkpoint count with layer boundary, token count per batch — dims must be runtime-valued in the frame directory. Plan-time hash covers identity/dtype/static shape only; size mismatches on dynamic axes still surface at frame validation.
  3. Per-family faithfulness must be proven before flag deletion. "The planner already computes what we need" holds only if the metadata planning graph exposes each family's crossing tensors as live cut values. scama's migration plan accounts for this (delete each flag only after its certification lanes pass on V2); that gating is essential, not optional.
  4. Wire/ABI compatibility. V1/V2 must coexist per mesh compat rules; ABI bump with synchronized skippy-ffi constants. Pointer-keyed identity maps in graph_identity.cpp are themselves sharp; the central validator mitigates this.
  5. Patch-set reduction is modest near-term — the honest payoff is containment of future growth (new family = graph/cut work + certification, not a 6-layer flag chain). scama stated this accurately.
  6. Codec must become per-part (F32 compressible parts vs raw I32); modest.

Agree with treating PR #1880 as a V1 correctness bridge and keeping the redesign out of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment