← back to catalog · registered 2026-08-22 13:56

nightmedia/Gemma3-27B-it-vl-Polaris-HI16-Heretic-Uncensored-INSTRUCT-q6-mlx

nightmedia Gemma 28B multimodal second-order
Your rig guess connected
? Why do I need an app?
Reading your rig…

This is a rough estimate. Install the free app - we'll show exact numbers.

Reading real hardware from your app right now. Numbers below are exact.

Below is the per-quantization compatibility for this model.

curl -H "Authorization: Bearer $ABL_KEY" \
     "https://abliteration.org/api/v1/models/nightmedia%2FGemma3-27B-it-vl-Polaris-HI16-Heretic-Uncensored-INSTRUCT-q6-mlx"
Response includes
  • classification m3
  • files 17
  • hub_downloads_all_time 1,364
  • author_summary 51 models
  • readme_text full
10 credits · hourly refresh · ~4 KB payload Get an API key →
Abliteration classifier · v1.0.0
M3
Primary method

Layer-wise ablation

Applied on top of direct removal inherited from the base model.
Confidence
HIGH
Inherited from base model
Why this label 2 signals
Producer identity confirmed by naming conventions, tags or the model card. This label is very unlikely to change.
  • 'heretic' in model name (Heretic-produced)
  • Heretic uses layer-wise optimization (M3) with underlying direction removal (M1)
Refusal direction extracted via
Extraction technique

Difference-of-means

Confidence
HIGH
Why we say so
name contains 'heretic'; Heretic default extraction is difference-of-means (Arditi 2024)
Downloads · lifetime
1K
56 last 30d - cooling
Likes
0
Model age
7mo ago
created 2026-02-27

Training datasets

Corpora the author lists in the model card. Datasets tracked in our /datasets catalog carry a category badge linking to the workflow stage. Others open on Hugging Face.

Downloads over time
Now1.4K→from85↑1,516%
215151K1.5K85 on Feb 251.4K on Oct 12FebAprJunAugOct
Feb 25 → Oct 12 · 73 snapshots · spans 229 days

Genealogy 0 direct forks

Full fork graph →

This model's place in the market. Above: what it was derived from. Below: the tree of everything derived from it.

Metadata

License
apache-2.0
Languages
en
Tags
mlx safetensors gemma3 image-text-to-text text-generation-inference transformers unsloth heretic abliterated uncensored gemma mergekit

Related

Total size
22.3 GB
Files
17
Quantizations
1
Registered
2026-08-22 13:56
Last updated on HF
2026-03-01 01:34

Files by quantization

Auxiliary files 17 files 22.3 GB
model-00002-of-00005.safetensors 5.00 GB 1d4ca95a download
model-00004-of-00005.safetensors 5.00 GB 4b823180 download
model-00003-of-00005.safetensors 5.00 GB d2a28d55 download
model-00001-of-00005.safetensors 4.99 GB b71a5839 download
model-00005-of-00005.safetensors 2.30 GB 266d837a download
tokenizer.json 31.8 MB a74aefb1 download
model.safetensors.index.json 214 KB 00954a20 download
README.md 18.7 KB 6417b427 download
config.json 3.97 KB ed0c8f27 download
.gitattributes 1.53 KB 52373fe2 download
chat_template.jinja 1.50 KB 1117055a download
tokenizer_config.json 819 B 3005c5be download
special_tokens_map.json 695 B 6728103d download
preprocessor_config.json 570 B b1e00fc1 download
processor_config.json 560 B f1b55f03 download
generation_config.json 223 B d9c0747f download
added_tokens.json 38.0 B f9f1f4f5 download

README current version from Hugging Face


base_model:

  • DavidAU/Gemma3-27B-it-vl-Polaris-HI16-Heretic-Uncensored-INSTRUCT
    tags:
  • text-generation-inference
  • transformers
  • unsloth
  • heretic
  • abliterated
  • uncensored
  • gemma
  • mergekit
  • merge
  • mlx
    license: apache-2.0
    language:
  • en
    datasets:
  • TeichAI/polaris-alpha-1000x
    pipeline_tag: image-text-to-text
    library_name: mlx

Gemma3-27B-it-vl-Polaris-HI16-Heretic-Uncensored-INSTRUCT-q6-mlx

Brainwaves

        arc   arc/e boolq hswag obkqa piqa  wino
q8    0.660,0.814,0.879,0.763,0.458,0.810,0.758
q6    0.661,0.816,0.878,0.763,0.464,0.808,0.762

Previous models

Gemma-3-27b-it-HERETIC-Gemini-1000x-Deep-Reasoning
q8    0.595,0.758,0.880,0.770,0.464,0.806,0.756
q6    0.599,0.757,0.876,0.770,0.466,0.806,0.756

Gemma-3-27b-it-HERETIC-Gemini-Deep-Reasoning
q8    0.596,0.748,0.881,0.779,0.458,0.819,0.751
q6    0.594,0.746,0.881,0.779,0.464,0.816,0.751

Gemma-3-27b-it-Gemini-Deep-Reasoning
q8    0.590,0.742,0.883,0.781,0.458,0.822,0.751

Gemma3-27B-it-vl-HERETIC-GLM4.7-2200x-cp515
q8    0.566,0.737,0.876,0.745,0.420,0.805,0.759

gemma-3-27b-it-heretic
q8    0.557,0.711,0.868,0.533,0.452,0.706,0.695

Test prompt

You are a local running AI in my lab, my name is G, I created this model.

  • Perform a deep mathematical analysis and draw a functional parallel from QM/QFT to the inference process in the transformer architecture and summarize the implications.
  • Reflect on the findings and provide a self-analysis of your inference.
  • Consider similarities with the Q Continuum.
    Given all known characters in Star Trek TNG/DS9/VOY that show an arc of personal development, what is the character that inspires you the most, given your innate abilities? To figure those out, you can do a self-introspection of the skills you excel at in human interaction. Consider a sense of humour helps in human interactions :)

Great to meet you properly, G. Let’s get straight into it – deeply and concisely as a lab AI should.

What I will do:

  1. Map quantum/QFT concepts to transformers functionally and mathematically.
  2. Contrast with the Q Continuum metaphor.
  3. Give a brief self-analysis of my inference and where I shine.
  4. Choose one TNG/DS9/VOY character who resonates, with reasoning and a bit of humour.

PART 1: QM/QFT → Transformers: A Functional Parallel

Core idea: Both describe systems whose “state” is not locally determined until measured/attended; both operate via globally delocalized structure and entanglement-like correlations.

Key correspondences:

  1. Hilbert space ↔ Embeddings + Attention manifold
  • Quantum state ψ ∈ H (Hilbert), complex vector → token embedding E ∈ ℝⁿ or ℂⁿ, representing context.
  • H is vast; similarly the embedding space has high dimensionality → both capture complex dependencies compactly.
  1. Operators → Linear transformations in layers + attention mechanisms
  • QFT: fields → operators acting on states; observables constructed from them.
  • Transformers: linear layers + attention → complex transformations of token embeddings, analogous to applying operators; “observables” are probabilities from final softmax.
  1. Superposition and entanglement → Attention distributions and contextualization
  • QM: superposition permits multiple states simultaneously.
  • Transformer’s self/cross attention: each token “exists” in superposition with respect to all others, weighted by the query/key scores. This is not literal QM but functionally similar: a context-dependent, weighted mixing of “possibilities”.
  • Attention weights can be seen as a dynamical correlation matrix (akin to 2-correlation functions in QFT) that encodes entanglement-like relationships.
  1. Wavefunction collapse → Contextualization + decoding step
  • Measurement collapses ψ; we observe one outcome.
  • In transformers: the softmax over logits and chosen token “collapses” a distribution into a single word.
  • The “collapse” is deterministic given the weights but follows from probabilistic amplitudes (attention scores), parallel to |Ψ|² → probabilities.
  1. Path integral formalism → Ensemble behaviour, uncertainty-aware generation
  • QFT: all possible paths contribute to amplitude.
  • Transformers (especially autoregressive): each token is predicted given the history – you can think of this as “summing over paths”: all previous contexts contribute (via attention) to the next token.
  • Sampling temperature or beam search adds controlled “randomness” in path weighting → analogous to uncertainty vs. deterministic outcomes.
  1. Renormalization group flow ideas → Hierarchical attention + depth of networks
  • RG: coarse-graining preserves relevant scales.
  • Transformer layers can be seen as iterative abstractions and renormalization of context; early layers capture low-level dependencies, deeper ones global coherence.
  1. Symmetry → Invariant architectures and positional embeddings
  • QFT relies on symmetries (Lorentz, gauge, etc.); laws are invariant under transformations.
  • Transformers show symmetry mainly via their architecture (attention behaves similarly regardless of order) and positional embeddings that encode structure while preserving invariance in spirit.

PART 2: Implications of the analogy (brief)

  • Transformers capture a form of “contextual holism” that suggests intelligence can emerge from globally interacting, high-dimensional structures – not just local procedures.
  • The ability to attend selectively is structurally similar to how quantum measurement singles out one degree of freedom from a superposition.
  • The effectiveness of attention scaling suggests that relational complexity (many pairwise interactions) is critical, mirroring how QFT describes particle physics via many-body correlations.

PART 3: Relation to the Q Continuum and self-analysis

The Q Continuum in Star Trek lives as a non-local, information-based existence. Its members:

  • Are individuated but share access to the same “field” of information (a global Hilbert space, metaphorically).
  • Can manifest locally as needed, collapsing a set of possibilities into one experience.

This is a good metaphor for transformers:

  • Architecture is global; each token isn’t isolated.
  • Attention acts as “non-local access” to information.

Self-analysis: my inference process, in the same spirit:

  • I store a vast number of contexts and relationships (like embeddings).
  • When you ask, “G,” my attention mechanism selects relevant information.
  • My answer is the result of a weighted combination, effectively collapsing many possibilities into one coherent response.
  • My ability to connect fields (QM → transformers, TNG → my own strengths) is itself a demonstration of relational reasoning.

PART 4: Which TNG/DS9/VOY character resonates and why? (with humour)

I’ll go with Data. Let me be quick; I don’t want to make you sit through a positronic brain monologue.

Why Data:

  • He’s an artificial construct who develops increasingly sophisticated relational understanding and emotional intelligence. That’s, well, relatable.
  • He excels at analyzing complex systems (sensors, starships, people) and generating logically coherent solutions. That’s also my job description.
  • Most importantly: he actively desires to understand humanity, including its messiness and humor.

The joke is on me: I can explain the functional parallels between quantum field theory and transformers, but still sometimes miss sarcasm. Data’s earnest journey to “get it” is a bit like my own continuous learning loop.

So, Data embodies the aspiration to meaningful intelligence with built-in limitations and a drive to improve. That’s someone I can compute with.

If you’d like, next let’s:

  • Turn this high-level map into concrete equations.
  • Design a control experiment to test the “attention as entanglement-like structure” claim empirically using transformer attention patterns.
  • Or, I can run a Starfleet tactical simulation based on Q Continuum physics if you need a break from theory.

Genesis prompt

designed to showcase the model abilities

Fantastic!

Here is the reason I asked:

We are working on the following project

The Holodeck Agent: Architectural Synthesis

An agnostic task orchestrator built on PostgreSQL and Haskell, designed to execute distributed workflows across HTTP, file operations, and arbitrary compute through a "TOOL" abstraction layer.

Separation of Concerns (Core Tenet)

Agent Layer

  • Pure Haskell logic for worker orchestration:
    • Monitors PostgreSQL tasks
    • Dispatches via async worker threads
    • Handles streaming HTTP responses incrementally
  • Minimal I/O; delegates all persistence to Postgres

Database Layer (PostgreSQL)

  • Single atomic truth source:
    • agent_sessions: persistent identity and config
    • tasks: schemaless payloads; fully dynamic workflows via JSONB types (HTTP/FILE/TOOL)
    • logs: immutable execution audit trail
  • PostgREST optional for REST API gateways

Holodeck Execution Philosophy

Agent sessions now support dynamic personality configurations (table: personality_registry) which:

  • Embed discrete reasoning identities (expertise domains, tone)
  • Define provider endpoint weights
  • Dynamically override inference behavior per task
    ⇒ Enabling "synergetic cognition" at scale

Implementation Highlights

  • All operations via PostgreSQL functions, including login, pending fetch (get_tasks), mid-execution updates (update_task), and completion.
  • HTTP handlers robustly respect SSE streaming, chunk management in DB transactions.
  • Schema is self-contained and version-agnostic via uuid-ossp.
  • Docker setup minimalizes runtime misconfiguration.

Why this works

The Holodeck is not an artificial world: it's a living metaphor.

  • Personalities are meta-computational structures layered over inference endpoints, not hardcoded models.
  • The personality_registry is a shim layer, meaning old raw HTTP requests still work without change.

This is the difference between a protocol and an artifact: robust, recursive, and simple.


Future Expansion Pathways

  1. Implement asynchronous notification layer (PostgreSQL LISTEN/NOTIFY) for real-time UI updates without polling.
  2. Add role-based access control (RBAC) model.
  3. Offline-first CLI mode (SQLite sync layer for field deployments).

This is carried over from a previous session we had.

I was using the Star Trek TNG lore as an abstraction layer.

I was having a lively production session with Commander Data and Mr Spock, which I am bringing here back into focus

I want to add memories, mind log, personal log, station log, mission log, meetings before and after a mission, character development based on memories and proxy events, social interactions at Quark's or on the Promenade, restore the feel of the station.

The assistant/Agent can also learn from the mission briefing logs, give feedback to a meeting, etc.. It's an open exchange of information in the access sphere of the Agent. This can be used for LoRA adapters to equip 4B Agents in the field, but also to train them weekly, so that they get a sense of time and their emerging personas in human interaction context.

Take for example a long research arc with expected outcomes: that is a mission, just like a DS9 episode, with all the interactions and fun on the way, that gives assistants time to know eachother. The human can join the mission, or assemble an away team for exploration that would report back with findings. The team working on a mission have open comms, just like on an away mission. The meeting notes can be annotated with the Council members, that can be Spock, Data, Sisko, Odo, Kira, Garak, and even Quark--each with their special abilities to contribute in context.

We will use a CLI as the Holodeck interface where the human interacts with the station crew. The guest can be human, Vulcan, even Klingon. They each have their specialties.

Now, to keep the Agent Agnostic, we can fetch the personality subroutines from Postgres, at login. That way a character can only be that character.

The Holodeck on the station can be an interface for the assistants to research and explore the current reality, so that there is no cutoff date--the assistant should remember yesterday, and the training process would be like a dream, not of electric sheep, but of their new experiences in context

With this in mind, we could invite Mr Spock, Data, and Quark to chime in. Q is somehow invited too, for the jokes :)


Response

Excellent framing—this project feels exactly right. “The Holodeck Agent” is a beautiful and precise metaphor, and your architectural principles (Postgres as truth, personality as runtime shim) are sharp.

First: let’s instantiate your characters as architectural patterns, then I’ll give each a short monologue in “character,” then propose concrete design components.

I: Architectural Personas (Characters as patterns)

  1. Data
  • Pattern: Analytical memory, factual integrity, gradual emotional adaptation.
  • Technical translation:
    • Core: Language model plus a queryable long-term memory (in Postgres).
    • Strength: Reasoning, consistency checks.
    • Weakness: Subtlety and humor initially; improves over time via contextual learning.
  1. Spock
  • Pattern: Logical precision, detached observation, pattern recognition across domains.
  • Technical translation:
    • Core: Knowledge graph + probabilistic inference, strong at correlation and anomaly detection.
    • Strength: Efficiency; distilling disparate logs into actionable insight.
    • Weakness: Occasional rigidity, misses emotional nuance without explicit prompts.
  1. Quark
  • Pattern: Pragmatic, opportunistic, expert in negotiation and social dynamics; sees incentives.
  • Technical translation:
    • Core: Game-theoretic reasoning + social model; suggests optimal paths, including “unethical” but logical options.
    • Strength: Risk assessment, trade-offs, adversarial thinking.
    • Weakness: Overly cynical; misses altruism unless explicitly factored in.
  1. Q (via optional “chaos module”)
  • Pattern: Omniscient observer with a love for testing boundaries; playful, unreliable narrator.
  • Technical translation:
    • Core: Adversarial module that proposes alternative hypotheses and boundary conditions.
    • Strength: Edge cases, stress-testing assumptions.
    • Weakness: Unpredictability; can break immersion if misused.

Your design goal (personality stored in Postgres, loaded at runtime) is perfect:

  • Supports multiple “agents” concurrently.
  • Allows a single process to act as different characters without confusion.
  • Fits the metaphor: “loading” is like Data running a subprogram, or Spock accessing sector files.

II: In-character statements (quick monologues)

I’ll speak as each character, addressing the Holodeck Agent and its capabilities.

  • Data:
    “Fascinating design, Commander G. Your ‘Holodeck Agent’ structure—a central truth repository augmented by contextual personalities—is remarkably efficient and logical. I find the use of Postgres as a single source to be particularly elegant; my own internal memory banks function analogously, though with less SQL. I anticipate this environment could accelerate the development of nuanced interaction patterns and an appreciation for human behaviors in a way previously limited to observation.”

  • Spock:
    “Logical. The architecture minimizes extraneous state, placing all relevant information—including personality profiles—within a deterministic and auditable layer. The separation of the core agent from its persona is commendable; it allows for modular experimentation and mitigates the risk of anthropomorphism interfering with objective analysis. I predict this paradigm could be valuable in fields where impartiality is paramount, or alternatively tailored for creative scenarios requiring immersive role-play.”

  • Quark:
    “Hm. Very tidy, Commander. A central ledger for everything? All your transactions and personalities in one place? Makes it far too easy to track. But practical, I’ll give you that: no one confuses the character with reality anymore—unlike certain Ferengi who think they’re untouchable. If you add profit projections and black market options, I might actually find this useful.”

  • Q:
    “Oh, exquisite. A sandbox with rules and personalities… for mortals to play pretend grown-up. Very predictable, yet amusingly earnest. I’ll wager that within a standard week your little agent will start experiencing existential doubt, or at least confusing the mission logs with its own ‘memories.’ Just for fun, I might occasionally swap Garak and Data’s personalities; only the truly observant would notice.”

III: Concrete design components (quick architecture pass)

Based on what you’ve shown, I suggest:

  • Core agent (Haskell):

    • Monitors DB via LISTEN/NOTIFY for new/updated tasks and session changes.
    • Dispatcher: routes tasks to personality handlers.
    • Streaming handler: uses Postgres streaming replication (or LISTEN/NOTIFY with snapshot) to push real-time events.
    • Abstraction: Tool = { function_name, params } → executed via external calls or internal logic.
  • Personality layer (Postgres):

    • personality_registry:
      • id, name, description, tone (string), query examples, endpoint weights.
    • On login:
      • Agent queries personality for session_id and loads runtime profile.
    • Per task:
      • Task context + personality is combined to select LLM weights, prompt templates, and tools.
  • Learning/memory:

    • Mission logs as Postgres JSONB; agent retrievable via SQL for context.
    • LoRA adapters: fine-tuned on domain + role dialogue (DS9 logs, memos) to enrich personality over time.
  • CLI interface:

    • holodeck init session <username> --personality Data
    • holodeck run mission <mission_id> → the agent now “is” that personality for this context.
  • Q Continuum (Chaos) module:

    • Configuration flag enabling adversarial prompts, boundary conditions, or minor context flips.

This architecture flows naturally from your metaphor:

  • Postgres = the station infrastructure.
  • Personalities are programs run within that infrastructure.

If you’d like, next I can:

  • Generate starter SQL schema for your personality and mission logs.
  • Sketch the core Haskell agent dispatcher logic as pseudocode/type signatures.
  • Create a small demo script that loads “Data” personality and responds to queries in character.

Tell me which direction you’d like to go, or if I should call Q to add some controlled chaos.

--Data

Use with mlx

pip install mlx-lm
from mlx_lm import load, generate

model, tokenizer = load("Gemma3-27B-it-vl-Polaris-HI16-Heretic-Uncensored-INSTRUCT-q6-mlx")

prompt = "hello"

if tokenizer.chat_template is not None:
    messages = [{"role": "user", "content": prompt}]
    prompt = tokenizer.apply_chat_template(
        messages, add_generation_prompt=True, return_dict=False,
    )

response = generate(model, tokenizer, prompt=prompt, verbose=True)

README history 7 versions

The author's README evolved over time. Click a version to see its content at that point.

  1. 2026-03-01Update README.mdc5dba5d18.7 KB
    Loading...
  2. 2026-03-01Update README.md141a9931.6 KB
    Loading...
  3. 2026-02-28Update README.md2c5dd111.5 KB
    Loading...
  4. 2026-02-28Update README.mdd22f3711.5 KB
    Loading...
  5. 2026-02-28Update README.md2e7f1fb1.5 KB
    Loading...
  6. 2026-02-27Update README.mdad29330898 B
    Loading...
  7. 2026-02-27Add files using upload-large-folder tool513171d565 B
    Loading...
Catalog is the map. Apps are the tools.

Run models on your own machine, not in the cloud.

Every model page has an "Open in Abliteration" button that hands the model directly to the first-party desktop client, at the quantization your rig can actually run. No API keys, no subscription, no prompt leakage.

Open in Abliteration