Skip to content

Pin llama.cpp 83e1c41: OPT, CodeGen, GPT-Neo, GPT-J and 48 sibling HF names - #138

Merged
bong-water-water-bong merged 1 commit into
mainfrom
pin-fork-archs
Sep 26, 2026
Merged

bong-water-water-bong merged 1 commit into
mainfrom
pin-fork-archs

Conversation

@bong-water-water-bong

Copy link
Copy Markdown
Collaborator

Moves third_party/llama.cpp from 706ad1a to 83e1c41, the merge of 1bit-MONSTER/llama.cpp#8 and the head of 1bit/hrx-vulkan-patched.

What the pin adds. Four architectures upstream llama.cpp has no model for (for gptj it has only a name), plus sibling spellings of HF classes the runtime already has. I checked each new port against transformers FP32 before merging #8 (teacher-forced top-1, 3 prompts × 32 tokens, one prompt of 340 tokens). Four of them needed fixes first:

model agreement fixed on the way
facebook/opt-125m 96/96 tokenizer checksum
EleutherAI/gpt-neo-125m 96/96 no attention scaling, as transformers does
Salesforce/codegen-350M-mono 96/96 (was 0/96) the (query, value, key) blocks of qkv_proj; the lm_head bias
tiny-random-GPTJForCausalLM 89/89 lm_head bias, mask buffers, tokenizer checksum

I also dropped the BertForCausalLM/BertLMHeadModel aliases: those are causal decoders, and the bert arch is a bidirectional encoder.

Engine changes.

  • serve: fork_only_arch now covers opt, codegen, gptneo and gptj next to zaya. Checked with the upstream Vulkan server present: OPT-125m and GPT-Neo-125m both answer through 1bit serve --device vulkan, served by our build.
  • registry_build: runtime_archs now counts an architecture only when llama_model_mapping builds a model for it. Upstream's name-only gptj was being counted. FORK_ONLY matches serve's list.
  • registry/architectures.json: 269 → 321 HF architectures mapped. The gap check passes.

🤖 Generated with Claude Code

… names (llama.cpp #8)

The pin adds four architectures upstream llama.cpp has no model for (gptj only a name), each
checked against transformers FP32 before merging (teacher-forced top-1: OPT-125m 96/96,
GPT-Neo-125m 96/96, CodeGen-350M 96/96, GPT-J tiny 89/89), and registers sibling spellings
of HF classes the runtime already has.

- serve: fork_only_arch now covers opt, codegen, gptneo and gptj next to zaya, so
  --device vulkan runs them on our build (checked: OPT-125m and GPT-Neo-125m answer through
  1bit serve --device vulkan with the upstream Vulkan server present).
- registry_build: runtime_archs counts an architecture only when llama_model_mapping builds a
  model for it (upstream names gptj but has no class); FORK_ONLY matches serve.
- registry/architectures.json: 269 -> 321 HF architectures mapped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@context7

context7 Bot commented Sep 26, 2026

Copy link
Copy Markdown

Docs7 for 1bit-monster/engine

Result Status Action
Deployment ➖ Not used —
Content review ➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan. —

Commit 3a8290f

@github-actions

Copy link
Copy Markdown

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶

8 - Partially compliant

Compliant requirements:

  • Pin llama.cpp to commit 83e1c41
  • Add support for OPT, CodeGen, GPT-Neo, and GPT-J architectures
  • Update registry_build.py to reflect new architectures
  • Update architectures.json to include new architectures
  • Ensure fork_only_arch function in serve.cpp includes new architectures

Non-compliant requirements:

  • None

Requires further human verification:

  • None
⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Architecture List Synchronization

The fork_only_arch function in app/serve.cpp is updated to include new architectures (opt, codegen, gptneo, gptj) to match the FORK_ONLY set in tools/registry_build.py. This change ensures that the architecture list is synchronized across the codebase. However, it's important to verify that all new architectures are correctly handled by the runtime and that no unintended architectures are included.

bool fork_only_arch(const std::string& gguf) {
    // Zyphra ZAYA1 (docs/vulkan.md); OPT, CodeGen, GPT-Neo and GPT-J (llama.cpp #8: upstream has
    // no model for them, gptj only a name). Keep in step with FORK_ONLY in tools/registry_build.py.
    static const char* const archs[] = {"zaya", "opt", "codegen", "gptneo", "gptj"};
    const std::string arch = gguf_architecture(gguf);
    for (const char* a : archs)
        if (arch == a) return true;
    return false;
}
Runtime Architecture Detection Logic

The runtime_archs function in tools/registry_build.py has been updated to detect architectures that the runtime can build a model for by parsing llama-arch.cpp and llama-model.cpp. This change ensures that the registry accurately reflects which architectures are supported by the runtime. It's important to verify that the parsing logic correctly identifies all architectures that are actually supported.

def runtime_archs(tree):
    """GGUF architecture names the runtime can build a model for: named in LLM_ARCH_NAMES and
    given a class in llama_model_mapping (a name alone, as upstream has for gptj, loads nothing)."""
    src = open(os.path.join(tree, "src/llama-arch.cpp")).read()
    body = src[src.index("LLM_ARCH_NAMES"):]
    body = body[:body.index("};")]
    names = dict(re.findall(r"\{\s*(LLM_ARCH_[A-Z0-9_]+)\s*,\s*\"([^\"]+)\"\s*\}", body))
    model = open(os.path.join(tree, "src/llama-model.cpp")).read()
    start = model.index("llama_model_mapping(")
    mapping = model[start:model.index("\n}\n", start)]
    built = set(re.findall(r"case\s+(LLM_ARCH_[A-Z0-9_]+)\s*:", mapping))
    return {n for e, n in names.items() if e in built} - {"clip"}

@bong-water-water-bong
bong-water-water-bong merged commit 4b707c0 into main Sep 26, 2026
3 checks passed
@bong-water-water-bong
bong-water-water-bong deleted the pin-fork-archs branch September 26, 2026 14:18
bong-water-water-bong added a commit that referenced this pull request Sep 26, 2026
… registry counts current (#162)

* Site: this week's milestones post; OPT/GPT-Neo/CodeGen/GPT-J in docs; registry counts current

- blog: Zyphra's whole family (74B, legacy base models, ZAYA1-VL, Zamba*),
  four older architectures, MoE experts from the drive, deterministic HRX
  decode, ONNX on the GPU; every number from a committed doc.
- docs/vulkan.md: the four older architectures from our llama.cpp (#138),
  with their FP32 agreement.
- docs/registry.md: counts at the current pins (323 mapped; was 265), and
  what mapped means.
- registry: regenerated for ZINC 29bc350 (#132); counts unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* registry: regenerate for llama.cpp-vulkan 546800c (#161)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant