Text Generation
Transformers
Safetensors
GGUF
English
qwen2
decompilation
reverse-engineering
python
bytecode
code
verified-generation
conversational
text-generation-inference
Instructions to use BlazingCustoms/pybytecode-v3-1.5b with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use BlazingCustoms/pybytecode-v3-1.5b with Transformers:
# Use a pipeline as a high-level helper from transformers import pipeline pipe = pipeline("text-generation", model="BlazingCustoms/pybytecode-v3-1.5b") messages = [ {"role": "user", "content": "Who are you?"}, ] pipe(messages)# Load model directly from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer = AutoTokenizer.from_pretrained("BlazingCustoms/pybytecode-v3-1.5b") model = AutoModelForCausalLM.from_pretrained("BlazingCustoms/pybytecode-v3-1.5b", device_map="auto") messages = [ {"role": "user", "content": "Who are you?"}, ] inputs = tokenizer.apply_chat_template( messages, add_generation_prompt=True, tokenize=True, return_dict=True, return_tensors="pt", ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=40) print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[-1]:])) - Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use BlazingCustoms/pybytecode-v3-1.5b with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf BlazingCustoms/pybytecode-v3-1.5b:F16 # Run inference directly in the terminal: llama cli -hf BlazingCustoms/pybytecode-v3-1.5b:F16
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf BlazingCustoms/pybytecode-v3-1.5b:F16 # Run inference directly in the terminal: llama cli -hf BlazingCustoms/pybytecode-v3-1.5b:F16
Use pre-built binary
# Download pre-built binary from: # https://github.com/ggerganov/llama.cpp/releases # Start a local OpenAI-compatible server with a web UI: ./llama-server -hf BlazingCustoms/pybytecode-v3-1.5b:F16 # Run inference directly in the terminal: ./llama-cli -hf BlazingCustoms/pybytecode-v3-1.5b:F16
Build from source code
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-server llama-cli # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama-server -hf BlazingCustoms/pybytecode-v3-1.5b:F16 # Run inference directly in the terminal: ./build/bin/llama-cli -hf BlazingCustoms/pybytecode-v3-1.5b:F16
Use Docker
docker model run hf.co/BlazingCustoms/pybytecode-v3-1.5b:F16
- LM Studio
- Jan
- vLLM
How to use BlazingCustoms/pybytecode-v3-1.5b with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "BlazingCustoms/pybytecode-v3-1.5b" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "BlazingCustoms/pybytecode-v3-1.5b", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker
docker model run hf.co/BlazingCustoms/pybytecode-v3-1.5b:F16
- SGLang
How to use BlazingCustoms/pybytecode-v3-1.5b with SGLang:
Install from pip and serve model
# Install SGLang from pip: pip install sglang # Start the SGLang server: python3 -m sglang.launch_server \ --model-path "BlazingCustoms/pybytecode-v3-1.5b" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "BlazingCustoms/pybytecode-v3-1.5b", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker images
docker run --gpus all \ --shm-size 32g \ -p 30000:30000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env "HF_TOKEN=<secret>" \ --ipc=host \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path "BlazingCustoms/pybytecode-v3-1.5b" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "BlazingCustoms/pybytecode-v3-1.5b", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }' - Ollama
How to use BlazingCustoms/pybytecode-v3-1.5b with Ollama:
ollama run hf.co/BlazingCustoms/pybytecode-v3-1.5b:F16
- Unsloth Studio
How to use BlazingCustoms/pybytecode-v3-1.5b with Unsloth Studio:
Install Unsloth Studio (macOS, Linux, WSL)
curl -fsSL https://unsloth.ai/install.sh | sh # Run unsloth studio unsloth studio -H 0.0.0.0 -p 8888 # Then open http://localhost:8888 in your browser # Search for BlazingCustoms/pybytecode-v3-1.5b to start chatting
Install Unsloth Studio (Windows)
irm https://unsloth.ai/install.ps1 | iex # Run unsloth studio unsloth studio -H 0.0.0.0 -p 8888 # Then open http://localhost:8888 in your browser # Search for BlazingCustoms/pybytecode-v3-1.5b to start chatting
Using HuggingFace Spaces for Unsloth
# No setup required # Open https://huggingface.co/spaces/unsloth/studio in your browser # Search for BlazingCustoms/pybytecode-v3-1.5b to start chatting
- Pi
How to use BlazingCustoms/pybytecode-v3-1.5b with Pi:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf BlazingCustoms/pybytecode-v3-1.5b:F16
Configure the model in Pi
# Install Pi: npm install -g @mariozechner/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "llama-cpp": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "BlazingCustoms/pybytecode-v3-1.5b:F16" } ] } } }Run Pi
# Start Pi in your project directory: pi
- OpenClaw new
How to use BlazingCustoms/pybytecode-v3-1.5b with OpenClaw:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf BlazingCustoms/pybytecode-v3-1.5b:F16
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "BlazingCustoms/pybytecode-v3-1.5b:F16" \ --custom-provider-id llama-cpp \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
- Docker Model Runner
How to use BlazingCustoms/pybytecode-v3-1.5b with Docker Model Runner:
docker model run hf.co/BlazingCustoms/pybytecode-v3-1.5b:F16
- Lemonade
How to use BlazingCustoms/pybytecode-v3-1.5b with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull BlazingCustoms/pybytecode-v3-1.5b:F16
Run and chat with the model
lemonade run user.pybytecode-v3-1.5b-F16
List all available models
lemonade list
- Hermes Agent
How to use BlazingCustoms/pybytecode-v3-1.5b with Hermes Agent:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf BlazingCustoms/pybytecode-v3-1.5b:F16
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default BlazingCustoms/pybytecode-v3-1.5b:F16
Run Hermes
hermes
- Atomic Chat
File size: 7,888 Bytes
0b19a1b | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 | # Data card β PyBytecode v2 / v3 training corpus
The corpus behind `pybytecode-v2-1.5b` and `pybytecode-v3-1.5b`. Written 2026-08-04; no data card
existed before.
**This corpus is not distributed.** Section 5 states why, as a property of the artifact rather
than an apology. The model weights are unaffected β see `WEIGHTS-LICENSE-PROPOSAL.md`.
---
## 1. What it is
| | |
|---|---|
| Task | Python 3.12 bytecode disassembly β original source |
| Rows | **48,196** (identical row set in v2 and v3) |
| Row shape | `{"input": <disassembly>, "output": <source>}` |
| Source dataset | `codeparrot/github-code-clean` (the dataset itself is Apache-2.0) |
| Shards used for training | 0β5 |
| Unit | one top-level function plus its transitive helpers and imports |
| Python | 3.12, `optimize=0` |
| Files | `data/foundry/pybytecode-v2_train.jsonl`, `-v3_train.jsonl`, `-v3-sft_train.jsonl` |
v3 differs from v2 in the **input representation only**. v2's `rep.py` omitted the exception
table's `end`, so a bare `try:` body and a `try/else:` body that compile to the same instruction
stream were byte-identical in the model's input. v3 emits `EXC try=Ls..Le -> ...` and the end
label joins the label set, making the two distinguishable. 14,122 of 48,196 inputs changed;
no row was added, removed or relabelled (`data/foundry/pybytecode-artifacts/v3_build_report.json`).
Any v2βv3 delta is therefore attributable to the representation fix alone.
## 2. Licence filtering β what was dropped, and why
`scripts/pybytecode/extract_v2.py` filters **per row** on `github-code-clean`'s `license` column
and keeps seven permissive values:
```
mit apache-2.0 bsd-2-clause bsd-3-clause isc unlicense cc0-1.0
```
Every GPL, LGPL, AGPL, MPL and EPL row is dropped before extraction, along with everything the
column does not positively identify. The intent was to avoid training on reciprocally-licensed
source; the filter is a hard gate, not a preference.
Rows are then dropped by a chain of quality gates, each counted rather than silently applied:
unparseable; not stable under `ast.unparse` round-trip (`canonicalise(canon) != canon`); does not
compile; disassembly or source over the size ceiling; duplicate of an already-kept unit
(SHA-1 of the canonical source).
## 3. Decontamination against the test sets
Three layers, because one is never enough (`scripts/pybytecode/build_final.py`):
1. **Shard-disjoint** β training from shards 0β5, held-out pool from shards 8β9. The held-out
pool was never read during training extraction.
2. **Repo-disjoint** β any repo appearing in training is removed from the held-out pool outright.
A repo can span shards, so layer 1 does not imply this.
3. **Fingerprint-disjoint** β an identifier-blind structural fingerprint (every `Name`/`arg`/
attribute β placeholder, every literal β its type name). This catches the same algorithm under
renamed variables, which exact match misses. It caught 15 items exact match missed.
The CSN benchmarks apply the same identifier-blind fingerprint against this corpus. On the
600-row licensed rebuild it removed 3 rows.
## 4. Labelling
Labels are the canonical source itself, so the supervision is exact by construction. The grading
tier attached to each unit was assigned **by running an oracle**, not by inspection:
- **tier A / behavioural** β differential execution. Kills 100% of injected semantic bugs; the
gold tier.
- **tier B / stub** β stubbed execution. Kills 78.9%, so scores on it are an **upper bound**.
- **tier C / AST-exact** β undercounts by roughly 2.4Γ, so scores on it are a **lower bound**.
Only 5.43% of all real top-level Python functions survive to be behaviourally adjudicable. That
ceiling is why the byte-identical recompile oracle exists: it needs no runnable environment and
so has 100% coverage.
## 5. The corpus cannot be redistributed
**Per-row attribution was not retained.** `extract_v2.py` carried `repo` and `license` on every
row through extraction, and `build_final.py:118` writes only `{"input", "expected"}` when it
emits the final splits. The intermediate pool that still held the metadata was written to `/tmp`
and no longer exists.
The consequence is specific: the corpus is 48,196 excerpts of MIT-, BSD-, Apache-, ISC- and
public-domain-licensed source, and every one of those licences except the two public-domain
dedications requires the copyright notice to be reproduced with the copy. We cannot produce those
notices, because we no longer know which row came from which repository. Redistributing the file
would strip required notices from tens of thousands of copyright holders.
This is a limitation of the artifact, not of the licences: nothing about the corpus is unlicensed
or reciprocally licensed. It is not fixable by adding a licence file, and it is not repaired by
listing the source dataset β attribution under these licences is per-work, not per-collection.
**It is fixable by rebuilding.** Extraction is deterministic and the source dataset is public.
Carrying `repo`, `license` and file path through `build_final.py`'s writer β one line β produces
an equivalent corpus that *is* redistributable with a `NOTICES` file. That is the recommended
fix for a v4 and it does not require retraining anything to be useful.
## 6. Held-out evaluation sets built from the same corpus
`data/foundry/pybytecode-v3-ood-{behavioural,stub,ast,doc}_test.jsonl` are drawn from the
held-out shards of this same corpus and **inherit section 5 exactly** β they carry no attribution
and cannot be redistributed either.
They are named `-ood-` but they are **not out-of-distribution**: they are the same source and the
same distribution as training, held out three ways. Matching all 974 canonicalised
`google-research-datasets/mbpp` rows against them yields **0 matches** in all four files, while
the v1-era `pybytecode-ood_test.jsonl` matches at **400/400**. Only that v1-era file is MBPP.
Full evidence in `LICENSING-DETERMINATION.md` Β§4.
They remain sound *generalisation* tests, and the numbers measured on them stand. Only the label
is wrong, and it should be corrected wherever it appears.
**On the tier-A set specifically (n=279, the set behind the 91.04% and 97.49% figures):** it is
the complete behaviourally-adjudicable population of the held-out pool β the 400-row cap did not
truncate it, whereas the stub and ast tiers both hit that cap. The pool was therefore larger than
400 units, but its exact size is **not recoverable**: `build_final.py` printed its census to
stdout and no run log was kept. The framing "279 of 400 = 70% of the set" does not describe these
files (the four tiers are largely disjoint populations β the 279 behavioural rows share 9 function
names with the 400 stub rows and 8 with the 400 ast rows) and should not be used. Report the
denominator as 279 with the sentence above, or rebuild the pool to recover the true rate.
## 7. Known confound, stated rather than engineered away
`extract_v2.py` carries `from __future__ import annotations`, and its `compile()` call inherits
the flag, so the training bytecode has PEP-563 stringised annotations. **Real `.pyc` files are not
compiled that way.** The benchmarks deliberately compile with `dont_inherit=True`, giving the
model an input distribution it was not trained on for annotated functions. Any resulting handicap
is a real property of the model and is counted against it.
## 8. Provenance summary
| Field | Value |
|---|---|
| Base model | `Qwen/Qwen2.5-Coder-1.5B-Instruct` (Apache-2.0) |
| Rows | 48,196 |
| Method | LoRA r=16, Ξ±=32, all attention + MLP projections, 1 epoch, lr 2e-4 |
| Build scripts | `scripts/pybytecode/{extract_v2,build_final,build_v3,rep,gen,verify}.py` |
| Grader hashes | all six match `grader.sha256` in `data/models/models.jsonl` |
| Redistributable | **No** β Β§5 |
|