qwen3.6-27b-django-coder-gguf

qwen3.6-27b-django-coder-gguf

A Qwen3.6 27B LoRA fine-tune focused on Python/Django coding-agent workflows, released as a GGUF Q4_K_M quantization for local inference.

This model was trained to improve local coding-agent behavior on Python repositories, with emphasis on Django project development, traceback-driven debugging, and iterative code repair.

The release includes a GGUF Q4_K_M quantization intended for local inference with llama.cpp-compatible tools and coding agents.

Model Overview

• Model name: qwen3.6-27b-django-coder-gguf
• Base model: Qwen/Qwen3.6-27B
• Fine-tuning method: LoRA
• Release format: GGUF
• Quantization: Q4_K_M
• Primary focus: Python and Django coding-agent workflows
• Recommended use: local coding assistants, repository-level debugging, Django backend implementation, iterative code repair

Intended Use

This model is intended for local coding-agent workflows, especially when working with Python and Django repositories.

It is designed for tasks such as:

• building Django applications,
• adding backend features to existing Django projects,
• debugging Django runtime errors from logs and tracebacks,
• fixing issues across models, views, URLs, templates, forms, and admin configuration,
• performing iterative code repair inside a local development loop.

The model is best used inside coding-agent tools such as Kilo Code, llama.cpp-compatible interfaces, LM Studio, Ollama, or similar local inference setups.

Training Data Preparation

The training dataset was built from selected Python/Django repositories.

The data preparation process used a repository-to-SFT workflow based on Repo-to-sft, which extracts real Python/Django code from repositories and prepares supervised fine-tuning records in the following format:

Message, Response, Reasoning

The important design choice is that the Response field is based on original repository code, while the local model is used to generate the corresponding instruction-style Message and Reasoning.

The dataset was focused on Python .py files and Django-oriented repository code rather than frontend-specific training.

Dataset Design Rationale

The dataset was intentionally curated and balanced for practical backend Django/Python development rather than general Python syntax.

The goal was to expose the model to repository-level implementation patterns that appear in real Django systems, including database relationships, ORM/queryset usage, transactions, forms, validation, middleware, authentication, authorization, permissions, security-related patterns, signals, admin configuration, migrations, DRF/API views, and iterative traceback-driven debugging.

This design was intended to fill practical behavior gaps in local coding-agent workflows: understanding how Django components interact across files, making focused backend changes, preserving project structure, and repairing runtime issues without unnecessary rewrites.

The dataset contains 24k+ SFT records in Message, Response, Reasoning format and is weighted toward backend implementation patterns rather than frontend styling.

Source Repositories

The dataset was created from multiple Python/Django repositories, including projects such as:

• Django real-world example projects
• Django Oscar
• edx-platform
• Sentry
• Django polls examples
• Django todo applications
• Django Guardian
• Django framework code
• additional Python/Django repository datasets prepared for training

The goal was not to train a general frontend model, but to improve backend-oriented Python/Django coding behavior.

Conversion and Quantization Pipeline

The final GGUF model was produced using the following pipeline:

Qwen/Qwen3.6-27B base model
        +
LoRA adapter
        ↓
merged BF16/HF model
        ↓
GGUF F16
        ↓
GGUF Q4_K_M

During conversion, the merged model configuration required a compatibility fix before GGUF export.

The merged config declared:

"mtp_num_hidden_layers": 1

However, the merged weights did not contain MTP / NextN tensors for an additional layer. This caused the GGUF loader to expect a missing tensor:

blk.64.attn_norm.weight

The fix was to set:

"mtp_num_hidden_layers": 0

before running the HF-to-GGUF conversion. After this config correction, the F16 GGUF loaded successfully and was then quantized to Q4_K_M.

Observed Behavior

In local manual testing, the model showed strong practical behavior for Django coding-agent workflows.

Observed strengths:

• created a working Django e-commerce application,
• implemented cart, wishlist, orders, and checkout flows,
• quickly fixed Django errors when given runtime logs or tracebacks,
• produced shorter and more direct coding-agent outputs compared to the base model in local testing,
• worked well in an iterative development loop: generate code, run app, inspect error, patch code.

The model appears strongest on backend-oriented Django work, especially when editing or debugging existing Python/Django code.

Known Limitations

This model is primarily backend-oriented.

Known limitations:

• frontend design quality can be basic or visually inconsistent,
• generated UI may look plain or overly template-like,
• form validation may require explicit prompting and manual review,
• security-sensitive logic must always be reviewed,
• generated payment-related code should be treated as demo code only,
• the model has not been evaluated on a standardized public coding benchmark,
• outputs may contain bugs or incomplete assumptions.
• Because the dataset was intentionally backend-focused, frontend design quality can be basic or visually inconsistent. The model should be evaluated primarily as a Python/Django backend coding assistant rather than a frontend/UI generation model.

For production Django projects, always review generated code, run tests, inspect migrations, and manually verify authentication, authorization, validation, and security-sensitive behavior.

Recommended System Prompt

For Django-focused work, the following system instruction is recommended:

You are a Django-only Python coding agent. When the user asks for a Django app, always use Django project structure, Python files, templates, static files, models, views, urls, forms, admin and migrations. Never use Node.js, Express, npm, React, Next.js, Vite or TypeScript unless the user explicitly asks for them.

For stricter backend-only work:

Focus on Django backend implementation. Prefer models, views, forms, URLs, admin, migrations, templates, and server-side validation. Do not prioritize frontend styling unless explicitly requested.

Example Usage

llama.cpp

llama-cli \
  -m qwen3.6-27b-django-coder-Q4_K_M.gguf \
  -p "Create a Django e-commerce app with products, cart, wishlist, orders, and checkout." \
  -n 2048

llama-server

llama-server \
  -m qwen3.6-27b-django-coder-Q4_K_M.gguf \
  -c 32768

Example Prompt

You are working inside an existing Django project.

Add a wishlist feature:
- authenticated users can add and remove products from wishlist
- create or update the required model
- add views and URLs
- update templates
- do not use Node.js or frontend frameworks
- preserve the existing Django project structure

Debugging Prompt

Fix this Django error. Explain the cause briefly, then patch the relevant files only.

Traceback:
[paste traceback here]

Suggested Evaluation Areas

Recommended areas to test:

Release Notes

This release contains only the GGUF Q4_K_M model file.

No adapter, merged BF16 model, dataset, or evaluation suite is included in this release.

Disclaimer

This is a code-generation model intended for local development assistance. Generated code should be reviewed before use. Do not use generated payment, authentication, authorization, or validation logic without manual inspection and testing.