Vinci-Cyber-8B-1.0-GGUF

GGUF distributions of SimpleDirect’s Canadian-developed, open-weight infrastructure-security model.

This repository provides GGUF conversions of Vinci-Cyber-8B-1.0, the defensive infrastructure-as-code adaptation developed by SimpleDirect, a Canadian AI lab, from IBM Granite 4.1 8B. The intended application is human-reviewed security work on infrastructure you own or are authorized to assess.

The full-weight model’s training centres on repair, no-change, and recovery examples. These are intended behaviours, not guarantees of correct or safe operation.

Model lineage

The immediate source is Vinci-Cyber-8B-1.0. Its underlying parent is IBM Granite 4.1 8B, pinned to revision 1504002f650e656a0a3789d99574df12e3e94ed0.

Consult the full-weight model card for the training method, checkpoint identity, data-release limits, and evaluation limitations. Measurements made through other inference paths must not be treated as independently measured results for these GGUF files.

Artifact availability is not a performance claim

🔴 Historical GGUF evaluation scores are not published as release measurements, because two of the seven things a per-tier score has to bind were never recorded. The llama.cpp runtime/build identity that produced them was never captured — the evaluation drove llama-server, which emits no startup banner — and no run identifier was minted for the evaluation. The other five (artifact digest, run date, evaluator digest, prompt-set digest, result) are bound for all four tiers. They therefore do not meet this release's provenance requirements. Treat the quantized artifacts here as unmeasured until they are evaluated under a fully captured runtime. This is a provenance defect: it is not a declaration that the measurements were false or invalidated, nor that they are validated, nor that the artifacts are poor.

Separately, and for a different reason, the underlying infrastructure-as-code capability claims rest on a scorer that is not yet independently qualified. Those figures are published on the full-weight card with that status attached, and a rescore under the repaired scorer is pending. Scorer qualification would not by itself restore the withheld GGUF figures, because it cannot reconstruct a runtime identity that was never recorded.

The artifacts may be distributed subject to their normal artifact gates while those claims remain withheld. This card publishes no per-tier score, no quality ranking between tiers, no recommended tier, and no parity guarantee for the artifacts in this repository; the general-capability figures it now carries were measured on the unquantized bf16 source weights, and are not per-tier measurements of any file here. A file’s presence does not establish its security performance or compatibility with a particular application.

Why its 30B sibling does publish per-tier figures. The 30B GGUF card reports a per-tier KL characterization because that evaluation captured the llama.cpp build identity that this one did not. The difference is a provenance difference, not a quality difference between the two model families.

Use the repository's actual published file inventory to identify an artifact, and verify its digest against the table below before use. Test it with a runtime that supports both GGUF and the Granite architecture.

file	bytes	sha256
Vinci-Cyber-8B-1.0-F16.gguf	16,765,334,048	621c787bef9e2d866cb0f6c3e5f54ec489cacdb84ab59875d789e2b97d20a395
Vinci-Cyber-8B-1.0-Q8_0.gguf	8,908,878,368	fc591c63ed272e2da08add6c1278a0c2040c5687306b0069acba1a7b2b18f6ba
Vinci-Cyber-8B-1.0-Q5_K_M.gguf	5,971,292,704	216f4b37fa0165b89b8e23141284c3c85998d280afbe63340ea5105152dba1c9
Vinci-Cyber-8B-1.0-Q4_K_M.gguf	5,116,703,264	373db3fc27724f764c788a0f0a06053869a53cf5462a798eec0e4ab9e291bea2

These digests are the repository's own published LFS values, read from the repository itself. A matching digest establishes that you received the bytes we published; it establishes nothing about a tier's quality, which remains unmeasured for the reason stated above. No particular runtime/version combination or hardware-memory requirement is established by this card.

General-capability benchmarks (measured on the unquantized weights)

🔴 None of the numbers below were measured on any GGUF file in this repository. They were measured on the unquantized safetensors of Vinci-Cyber-8B-1.0, snapshot 1b768e4bf796f6c9ade43d7407b772384f3eab0c, in bfloat16 through transformers. The four quantized artifacts published here — Vinci-Cyber-8B-1.0-F16.gguf, Vinci-Cyber-8B-1.0-Q8_0.gguf, Vinci-Cyber-8B-1.0-Q5_K_M.gguf, and Vinci-Cyber-8B-1.0-Q4_K_M.gguf — have not been evaluated on these tasks. Quantization shifts scores. Do not read this table as a measurement of any file in this repository.

lm-evaluation-harness 0.4.11, 0-shot except GSM8K at 5-shot, seed 0, bfloat16, batch size 8, single H200. Subject snapshot 1b768e4bf796f6c9ade43d7407b772384f3eab0c; base ibm-granite/granite-4.1-8b. Every cell was run two to four times on both models, and GSM8K six times on each, so each difference is judged against the run-to-run variation of that exact pair.

Benchmark	Metric	Vinci-Cyber-8B-1.0 (bf16)	granite-4.1-8b (bf16)	Difference
ARC-Challenge	acc_norm	0.6109	0.5998	+0.0111
WinoGrande	acc	0.7388	0.7348	+0.0036
MMLU	acc	0.7191	0.7177	+0.0014
PIQA	acc_norm	0.7965	0.7954	+0.0011
HellaSwag	acc_norm	0.8125	0.8152	−0.0027
GSM8K (5-shot)	exact_match, strict-match	0.8915	0.9017	−0.0102

The GSM8K cells are the mean of six runs per model. The other five rows are representative single values.

Cyber training redistributed general capability rather than preserving it: four benchmarks up, two down.

HellaSwag is a confirmed regression — about 30 items of 10,042. A pre-registered confirmatory test on the 39,905-item HellaSwag training split — four times the evaluation pool, and registered before the run — reproduced it at −0.32 percentage points, p = 5.2e-09, with a paired 90% interval of [−0.41, −0.23]. A negative control registered alongside it, the same test applied to the 30B pair on the identical items, stayed null, so the procedure is not manufacturing the effect.

Neither ARC-Challenge nor MMLU is an established gain. A paired item-level test — exact McNemar over the items both models answered, aligned per question — put ARC-Challenge at p = 0.019 across 1,172 items and MMLU at p = 0.28 across 14,042 items. A pre-registered confirmatory test on 1,418 held-out ARC-Challenge items then returned +0.56 percentage points at p = 0.20, with a 90% interval spanning zero: the exploratory estimate had been selected because it was large, and it halved on fresh items. ARC-Challenge is therefore a direction, not a demonstrated gain, and MMLU is not a gain at all. Run-to-run reproduction is not evidence of a real difference here: under greedy decoding on a fixed item set, every arm reproduces its score exactly whatever its true accuracy, so identical repeat runs measure the harness, not the models. PIQA is marginal — a 2-item difference against a 1-item spread.

GSM8K is a second regression. Six 5-shot runs per model: this model scored 0.8969, 0.8878, 0.8893, 0.8908, 0.8939 and 0.8901, a range of 0.8878 to 0.8969; the base scored 0.9014, 0.8999, 0.9037, 0.9007, 0.9037 and 0.9007, a range of 0.8999 to 0.9037. Every run of this model sits below every run of the base, and the mean gap is 0.0102, about 13 items of 1319. A paired item-level test over the 1,319 questions both models answered — exact McNemar, aligned per question — gives 41 disagreements, 28 where the base is right and this model wrong against 13 the other way, p = 0.027. That paired test, not the separation of the run ranges, is what supports the regression; it does not survive correction for the twelve model-by-task comparisons run across both model sizes.

Correction. An earlier revision of this section excluded GSM8K, on the grounds that this model's run-to-run variation exceeded its gap to the base. That test was wrong: one arm's spread is not the yardstick for the gap between arms. It was replaced by a comparison of whether the two arms' score ranges overlap, and six runs per arm show no overlap. That replacement has since been superseded too — under greedy decoding repeated runs reproduce almost exactly, so non-overlapping ranges show reproducibility rather than a real difference. The paired test above is what now supports the decline, and GSM8K is recorded above as a decline. The two runs cited in that earlier revision, 0.8969 and 0.8878, are the first two of the six listed here; no measurement is withdrawn, only the reasoning applied to it. These GSM8K runs are bf16 source-model measurements like every other number in this section, and no GGUF file in this repository was evaluated on this task.

These figures describe the bf16 source model, not any quant here, and they are evidence about this checkpoint only. The 30B sibling measured on the same contract showed no regression, so neither result generalises to the training recipe.

Run configuration and per-run outputs: getsimpledirect/vinci-gpu-research, model-scouting/eval-matrix-20260920/.

Responsible deployment

Conceptual intended workflow, not a measured reliability result or an autonomous deployment loop. Validate and review both proposed changes and no-change decisions.

Evaluate in a sandbox. Independently validate and review proposed configuration changes, and require approval before applying them. Do not give the model unrestricted production access. Self-hosting alone does not guarantee privacy, security, data residency, or compliance.

Licence and attribution

These are modified derivative distributions under Apache-2.0. Carry the full licence and applicable attribution and modification notices with redistributed copies. These licensing terms do not extend to the private specialization corpus.

IBM developed the Granite parent. Vinci / SimpleDirect developed the specialization and GGUF distribution. No IBM or Government of Canada endorsement is implied.

Claims reviewed as of September 21, 2026; the latest measurement reported here is the general-capability matrix of September 20, 2026. This card’s artifact-specific claims require review against the exact GGUF repository revision being published.