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
| # 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 | | |