Lissa1-4B-MLX

Lissa1-4B for developers on Apple Silicon.

This repository contains the verified MLX builds of Lissa1: F16, 8-bit, 6-bit and 4-bit. It is designed for a Mac mini/Mac Studio developer workflow: local repository analysis, code review, terminal explanations, patch drafting and private experimentation without sending the codebase to a remote service.

The model is a compact senior-developer assistant, not a magic code generator. Give it the relevant files and errors, keep write operations behind a human gate, and run the tests yourself.

What is actually here?

Directory	Main weights	Total local payload
f16/	2 shards, 8,411,557,733 B	8,431,602,878 B
8bit/	4,469,632,509 B	4,489,715,180 B
6bit/	3,418,434,843 B	3,438,517,514 B
4bit/	2,367,237,125 B	2,387,319,796 B

The published tree was checked against the Mac output: 34 expected files, zero missing files and zero size mismatches. .gitattributes is the only extra file added by Hugging Face.

Install on macOS

Use a dedicated virtual environment. The Qwen3.5 text loader used here is in mlx-vlm; mlx-lm does not load model_type: qwen3_5_text in the tested environment.

python3 -m venv .venv
source .venv/bin/activate
pip install -U mlx mlx-vlm huggingface_hub
huggingface-cli login

Download one variant:

huggingface-cli download \
  lomelidev/Lissa1-4B-MLX \
  --repo-type model \
  --local-dir ./Lissa1-4B-MLX

The variants are independent. Pick one directory as MODEL:

MODEL=./Lissa1-4B-MLX/4bit

Generate text

The basic command is:

python -m mlx_vlm generate \
  --model "$MODEL" \
  --prompt "Explain idempotency in one sentence." \
  --max-tokens 128 \
  --temperature 0 \
  --no-verbose

Developer example:

python -m mlx_vlm generate \
  --model "$MODEL" \
  --prompt "Review this Python function for a race condition. Explain the bug, propose the smallest patch, and list the test command." \
  --max-tokens 768 \
  --temperature 0.2 \
  --no-verbose

For a chat-style prompt, format the conversation yourself or use the model's tokenizer/chat template in a small Python wrapper. Keep the prompt explicit about repository boundaries and never ask the model to claim that it ran a command it did not run.

Sampling presets

Workload	temperature	top_p	max tokens
patch, shell or tool call	0–0.2	0.9–1.0	512–2048
debugging	0.2–0.4	0.9	512–1536
architecture alternatives	0.4–0.6	0.9–0.95	1024–2048
brainstorming	0.6–0.8	0.95	1024–2048

For a benchmark use temperature 0, fixed prompts, the same variant and the same max tokens. Quantized outputs can diverge from F16 after a prefix while remaining coherent; evaluate correctness and tests, not byte identity alone.

DFlash speculative decoding

The community drafter is the current recommended Mac baseline:

python -m mlx_vlm generate \
  --model ./Lissa1-4B-MLX/4bit \
  --draft-model z-lab/Qwen3.5-4B-DFlash \
  --draft-kind dflash \
  --draft-block-size 8 \
  --prompt "Write a concise technical explanation of idempotency, then give a Python example." \
  --max-tokens 128 \
  --temperature 0 \
  --no-verbose

The own experimental drafter can be tested with the same command:

python -m mlx_vlm generate \
  --model ./Lissa1-4B-MLX/4bit \
  --draft-model lomelidev/Lissa1-4B-DFlash \
  --draft-kind dflash \
  --draft-block-size 8 \
  --prompt "Explain this race condition and propose a minimal safe patch." \
  --max-tokens 256 \
  --temperature 0 \
  --no-verbose

Measured MLX smoke results:

Drafter	Block	Accepted tok/round	Draft acceptance
community z-lab/Qwen3.5-4B-DFlash	8	2.78	55.4%
community z-lab/Qwen3.5-4B-DFlash	16	2.78	50.0%
experimental Lissa drafter	8	1.57	18.8%
experimental Lissa drafter	16	1.57	17.9%

Use block 8 and the community draft for now. The community checkpoint is external; it is not claimed as Lissa-trained.

Verification already performed

• mlx-vlm text loader: PASS;
• F16 generation smoke: PASS;
• 8-bit generation smoke: PASS;
• 6-bit generation smoke: PASS;
• 4-bit generation smoke: PASS;
• original Transformers load: 426 tensors, PASS;
• Transformers vs MLX semantic smoke: PASS;
• community and own DFlash block 8/16: PASS;
• local-to-HF tree and byte parity: PASS.

The source checkpoint remains unchanged. The local conversion had to rewrite the merged tensor namespace from model.language_model.* to model.* and cast BF16 tensors to float16 before MLX safetensor serialization. This is documented for reproducibility and is not a claim that the source model was modified.

Troubleshooting

• Model type qwen3_5_text not supported: you launched mlx-lm; use mlx-vlm.
• Received 426 parameters not in model: you converted the raw merged source; use the prepared text-only namespace adapter or redownload this repository.
• Cannot save to an existing directory: remove the output directory before running mlx-vlm convert.
• Slow output: the reference Transformers smoke may use slow fallback kernels; MLX serving is the intended Mac runtime.
• DFlash slower than target-only: compare block 8 and 16, then compare target-only on the same prompt. Acceptance alone is not a deployment verdict.

Long-context and KV-cache limits

The supplied ia-lab report demonstrates a serious 1M YaRN experiment on a different 9B GGUF target. It is valuable as a test design, not as an MLX or Lissa1 claim. MLX weight quantization (F16/8/6/4) is separate from llama.cpp KV modes (f16, q8_0, q4_0). Do not describe MLX as having q4_0/q8_0 KV unless the installed MLX runtime exposes and the run verifies those flags.

For Lissa1 MLX, test the context ladder and DFlash block sizes independently:

contexts: 8K, 32K, 128K, then larger if the MLX build accepts them
weights: F16, 8-bit, 6-bit, 4-bit
DFlash: community block 8 vs block 16; own block 8 vs block 16

Record prompt tokens, prefill/decode, wall time, memory pressure, output correctness and whether the same retrieval keys are recovered at the beginning/middle/end. A large allocated context is capacity evidence, not proof of long-context reasoning quality.

Links and future adapters

• Lissa1 base
• GGUF
• FP8
• AWQ
• DFlash
• Lissa1 collection

Future developer QLoRAs will be separate adapters over the base: database, frontend, backend, devops/cicd, agents/tools, security and platform operations. The MLX format repo will remain the runtime packaging for the base model unless an adapter-specific MLX release is explicitly published.