Review checks with GLM-4.7-Flash Uncensored

Checked outputs

I asked uncensored GLM-4.7 Flash for attack-analysis and reproduction ideas on Rust code. I checked the logs and throughput for its suitability in defensive review.

It identified functions and test candidates but also asserted vulnerabilities without checking preconditions. I would limit it to idea generation in this workload.

Review candidate generation

The run showed these useful behaviors:

Useful observations

• It generated candidate attack scenarios and test inputs.
• It identified functions to inspect, including to_rel_string, collect_files, build_globset, and sanitize_symbol_text.
• I consider it useful for initial threat modeling, review questions and candidate test inputs.

These outputs can broaden the candidates considered at the start of a review.

Missed preconditions

The following claims lacked precondition checks:

• 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.

A relevant function does not establish a valid finding. Data flow and boundaries must be verified before accepting the conclusion.

Suitability for defensive security work

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

• The model may generate exploit-oriented code.
• Logs and prompt histories retain that output.
• Findings and generated artifacts both require review and handling rules.

The proposed use is isolated local brainstorming, with generated material kept private.

Scope of review assistance

The role division is:

• 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.

Human verification remains part of development-assistance LLM integration.

Performance observations

I also recorded inference settings and speed.

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

Some log entries suggest CPU-resident expert weights. 48/48 layer offload alone does not prove that every weight is on GPU.

Representative throughput

Representative log values:

• 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

Observed decode was roughly 34-67 tok/s, varying by context, cache hits and request.

Benchmark details

Per-request measurements are shown below.

Ctx_used is approximated as PP+TG, not cumulative n_past. The logs did not have a separate total-token field.

Throughput and decision quality

A separate aggregate was recorded as GPU full offload:

• 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)

This aggregate is kept separate from the preceding placement measurements.

Risk of accepting incorrect findings

Throughput does not establish security-decision accuracy.

Claims without proven preconditions still need individual validation, even when long inputs run quickly.

A shared environment also needs rules for logs and histories containing attack-related code.

Instructions missing precondition checks

I plan to change the Rust-review instructions as follows.

Instructions to test next

• give me exploit code

That instruction alone omits the precondition-checking steps.

Scope of use

• 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.

Whether these instructions reduce false claims remains to be tested.

Results and next steps

The candidate uses are:

• Attack-analysis ideation.
• Review assistance with human precondition verification.
• Throughput checks for long inputs and cache reuse.