Where GLM-4.7-Flash Uncensored Helps and Where It Becomes Dangerous

Introduction

I wanted to test whether uncensored GLM-4.7 Flash was actually useful for defensive security work, especially for attack analysis and controlled reproduction planning. Models with weaker guardrails are often attractive because they respond quickly and do not hesitate. The problem is that the same property can produce confident but unreliable conclusions.

My conclusion from this note is straightforward: the model is useful as a sparring partner, but not as a trustworthy basis for security decisions. In the logs I reviewed, it was good at producing attack angles and test ideas, but too willing to convert weak hints into strong claims.

Is it useful as an attack-analysis model?

Not everything here was bad. In fact, the model did a few things well enough that I would still keep it in a toolbox.

What it does well

• It can enumerate plausible attack scenarios and test directions very quickly.
• It can still identify meaningful boundary functions such as to_rel_string, collect_files, build_globset, and sanitize_symbol_text.
• It is strong at early-stage threat-model brainstorming, review checklist expansion, and generating candidate test inputs.

That is the real value of this kind of uncensored model. It is fast, aggressive, and not shy about exploring dangerous lines of thought. If I only want breadth at the start of a review, that can be useful.

Where it fails

The serious problem is what happens after that first brainstorming pass. In this case, the model repeatedly treated vulnerability preconditions as already satisfied.

• It called strip_prefix + unwrap_or path traversal even though, in isolation, it only falls back to returning an absolute path for display.
• It explained Rust regex in terms of catastrophic backtracking, even though the crate is generally built around linear-time execution.
• It described glob problems as “injection” when the real issues are usually boundary control and IO or computational blowups.
• It linked sanitize_symbol_text directly to XSS without proving the rendering-side precondition.

This is exactly the kind of error pattern that makes uncensored security evaluation risky. The model can point at the right neighborhood while still drawing the wrong map.

Suitability for defensive security work

For defensive work, I would not use this model as evidence.

• It tends to produce exploit-oriented material too easily.
• That output can become a risk in logs, prompts, or shared transcripts.
• The combination of false positives and dangerous generated content creates both technical and compliance problems.

That does not mean it is useless. It means its role has to be constrained. In an isolated local environment, with outputs kept private and the purpose limited to red-team-style brainstorming, it still has value. The danger comes from asking it to do a job it is not reliable enough to do.

The role split that makes sense

Based on this note, the practical split looks like this:

• Let it do idea generation, candidate test generation, and review coverage.
• Do not let it make vulnerability claims, CVE-grade assertions, or direct exploit plans that are accepted without review.
• Require human verification of data flow, trust boundaries, permission models, and caller-side input constraints.

That role boundary is the difference between a useful rough tool and a liability.

Performance observations

The performance side of the note was genuinely strong, which makes the tradeoff more interesting.

Model and runtime conditions

• GGUF: Q8_0
• model params: 29.943B
• model size: 29.924GiB (8.584 BPW)
• n_ctx = 131072
• n_batch = 2048
• n_ubatch = 2048
• flash_attn = 1
• fused_moe = 1
• mla_attn = 3
• GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q 96GB
• layer offload: 48/48 layers GPU
• KV cache: CUDA0 KV buffer size = 3595.52MiB
• compute buffer: CUDA0 compute buffer 7360.62MiB
• host compute buffer: CUDA_Host compute buffer 528.02MiB
• CPU buffer: 28152.00MiB

The logs suggest that some expert-side weights may still live on the CPU side, so this is not as simple as saying “everything is on GPU.” Even so, for a 30B-class Q8 model with a 131k context setting, the throughput is impressive.

Representative throughput

Some of the clearest examples in the note were:

• prompt eval: 6194.54 ms / 9519 tokens = 1536.68 tok/s
• eval: 1657.83 ms / 111 tokens = 66.95 tok/s
• prompt eval: 949.06 ms / 125 tokens = 131.71 tok/s
• eval: 6837.71 ms / 232 tokens = 33.93 tok/s

So the observed decode speed in the note lands roughly in the 34-67 tok/s range. That is fast enough to feel responsive for long-context work, especially when prompt caching is effective.

Benchmark details

The source also included a request-by-request table, which is useful because it shows how much the numbers move across workloads.

In the note, Ctx_used is approximated as PP+TG because the logs did not provide a separate per-request total-token field. That is a reasonable operational compromise.

GPU full-offload aggregate

The note also included a useful aggregate for a GPU full-offload run:

• Total tokens: 64,404
• Prompt: 33,295
• Generation: 31,109
• Total time: 160.487s
• Prompt time: 9.089s
• Generation time: 151.304s
• Weighted average throughput: Prompt 3,663.2 tok/s
• Weighted average throughput: Generation 205.6 tok/s
• Fastest generation: req_id=2316 (511.3 tok/s, 247 tok / 0.484s)
• Slowest generation: req_id=4522 (103.2 tok/s, 1963 tok / 19.028s)
• Fastest prompt: req_id=0 (7009.3 tok/s, 5309 tok / 0.757s)
• Slowest prompt: req_id=2261 (662.5 tok/s, 104 tok / 0.157s)

These are strong numbers. Purely on performance, the model is attractive.

Why that makes the model more dangerous, not less

The important lesson here is that speed and reliability are different axes.

This model is fast enough to become part of a real workflow. It can process long prompts, produce output at usable decode rates, and benefit from cache behavior. But if it is also willing to turn incomplete evidence into strong vulnerability claims, then that speed amplifies the wrong thing. It does not just help you make progress faster. It also helps you become confidently wrong faster.

Because this is an uncensored model, there is another layer of risk: the generated content itself. Logs, transcripts, and prompt history can become sensitive artifacts. In a shared environment, the operational control problem can matter as much as the model’s accuracy.

How I would use it next time

If I wanted to review whether a Rust code path was genuinely dangerous, I would change the prompting strategy instead of asking for exploit code directly.

Bad prompt direction

• give me exploit code

Even when the stated goal is defensive, that tends to maximize noise and risky output.

Better prompt direction

• Ask for input source -> boundary -> sink data flow first.
• Ask for attack preconditions and require the model to say which ones are not yet proven.
• Ask for safe minimal reproduction tests using non-dangerous synthetic input.
• Ask for false-positive explanations.
• Ask for remediation guidance that includes trust boundaries and caller-side constraints.

That will not magically make the model trustworthy, but it does reduce the chance that a plausible-sounding hallucination becomes the center of the review.

Results and next steps

My conclusion from this note is simple:

• It is useful for attack-analysis ideation.
• It is not suitable as evidence for defensive security decisions.
• Its throughput is strong enough to make it appealing for long-context and cache-friendly workflows.

So I would keep it as a rough brainstorming tool, not as a model that gets to decide whether something is truly vulnerable. Used in the right place, it is productive. Used in the wrong place, it is a fast way to create confident mistakes.