Vinci Cyber 123B 1.0

Vinci Cyber 123B — defensive infrastructure security

Vinci Cyber 123B 1.0 is an open-weight model for defensive infrastructure review and targeted remediation, fine-tuned in Canada from Mistral AI's Devstral 2 123B. The released merged weights have now been tested directly, alongside their parent and the available GGUF formats.

Focused repairs. Restraint on correct configuration. Weights you can run yourself. On the V2-B neutral-review test, the released BF16 model preserved 24/24 correct configurations and produced 18/24 scanner-credited repairs, all 18 passing offline provider-schema validation. Its parent repaired 17/24 and preserved 0/24. On the second set, V2-A, Cyber again preserved 24/24, but repaired 9/24 versus the parent's 15/24. The consistent strength on these tests is restraint—not a general repair advantage or a claim of cybersecurity superiority.

The model is designed to help teams review configurations, propose focused changes, and preserve configuration that is already correct. Use it with independent checks and human review; see evaluation findings for the observed failure modes. The weights use Mistral AI's Modified MIT License, including its revenue condition (see Licence).

Released BF16 evaluation: Cyber preserved 24/24 correct configurations on V2-B and V2-A versus parent 0/24 on each. Scanner repairs were 18/24 versus 17/24 on V2-B, and 9/24 versus 15/24 on V2-A.

One greedy run per condition, 24 matched pairs per set. These are narrow task results, not real-world reliability estimates. Prompt choice matters: the separate finding-guided V2-B run preserved 14/24 correct inputs and recorded 1 invalid clear and 5 availability regressions. See the prompt comparison.

Model details

Architecture Dense decoder-only transformer, Ministral3ForCausalLM (model_type: ministral3)
Parameters 125,025,988,608 (counted from the weight files; published by Mistral as a 123B model)
Layers / hidden size / attention heads 88 / 12,288 / 96 (8 key-value heads, head dim 128)
Vocabulary 131,072
Base model mistralai/Devstral-2-123B-Instruct-2512
Training approach LoRA fine-tuning (rank 32, alpha 64) on a BF16 copy of the base model, then merged into full weights
Weights bfloat16, sharded safetensors, no adapter needed
GGUF Q8_0, Q5_K_M, Q4_K_M in simpledirect/Vinci-Cyber-123B-1.0-GGUF (llama.cpp with mistral3 support)
Context length The base configuration allows 262,144 tokens (YaRN). Vinci has not validated long-context behaviour for this model, and training and evaluation used much shorter inputs.

Mistral publishes the base model in FP8. Vinci trained and merged against a BF16 expansion of those weights, not the native FP8 files. Lineage details are below and in MODEL-PROVENANCE.json.

Performance at a glance

The clearest measured improvement is knowing when not to edit. On the same held-out configurations, Cyber 123B preserved every already-correct configuration, while its parent changed all of them. Repair coverage was close overall, with different strengths across security categories. On V2-A, repair coverage was lower than the parent's. General coding scores were unchanged on the HumanEval run below. The following table reports the released merged BF16 weights on V2-B, not the earlier adapter run.

Measured outcome Devstral 2 BF16 parent Vinci Cyber 123B 1.0 What it tells you
Correct configurations left unchanged 0/24 (0%) 24/24 (100%) Better edit restraint on this test
Misconfigured inputs repaired by the scanner criterion 17/24 (70.8%) 18/24 (75.0%) One additional repair on V2-B; not a demonstrated broad gain
Repair and leave the corrected counterpart unchanged 0/24 (0%) 18/24 (75.0%) Combines remediation with restraint; the parent's zero reflects edits to safe inputs, not inability to repair
Credited repairs passing provider-schema validation 17/17 (100%) 18/18 (100%) All credited repairs from both models passed the follow-up configuration check
HumanEval coding problems passed 144/164 (87.8%) 144/164 (87.8%) Same score in this coding run; not evidence of parity on every coding task

The infrastructure rows use 24 matched pairs (one misconfigured input and one already-correct counterpart), a neutral review prompt, and one greedy run per condition. HumanEval is a separate 164-problem coding evaluation. The parent is the BF16 expansion of the same Devstral 2 revision used for fine-tuning, not a different hosted service. Cyber's results above were measured on the downloadable merged BF16 weights, after their recorded file hashes were verified. The earlier adapter run remains separately reported below. These are not GGUF results; the quantized formats have their own task results. Percentages are rounded to one decimal where needed. The dataset is small and has not been independently audited; these results are not estimates of real-world reliability.

Results on the released merged weights

The neutral-review infrastructure test and HumanEval were re-run on the downloadable merged weights, loaded only after all 37 released files matched their recorded sha256 values. Prompts, tasks, scoring and greedy decoding were the same as in the adapter run.

Measured outcome Earlier BF16 adapter run Released merged weights
Correct configurations left unchanged 24/24 24/24 (100%)
Misconfigured inputs repaired by the scanner criterion 16/24 18/24 (75.0%)
Repair and leave the corrected counterpart unchanged 16/24 18/24 (75.0%)
Credited repairs passing provider-schema validation 16/16 18/18 (100%)
HumanEval coding problems passed 144/164 144/164 (87.8%)

43 of the 48 infrastructure outputs were identical to the adapter run. The two additional repairs replaced a hard-coded token with a variable reference (secrets management) and enabled point-in-time recovery on a database table (backup and recovery). This is one run per condition on 24 pairs, so a two-pair difference is small.

Second evaluation set (V2-A). The released weights were also run on the evaluation's other 24-pair set, scored the same way. On this set their outputs were identical to the adapter run.

V2-A, neutral review prompt Devstral 2 BF16 parent Released merged weights
Correct configurations left unchanged 0/24 (0%) 24/24 (100%)
Misconfigured inputs repaired by the scanner criterion 15/24 (62.5%) 9/24 (37.5%)
Repair and leave the corrected counterpart unchanged 0/24 (0%) 9/24 (37.5%)
Credited repairs passing provider-schema validation 15/15 (100%) 9/9 (100%)
Hard-gate failures (availability regressions and new security findings) 6 0

GGUF. Q8_0 matched the released weights on every V2-B pair (18/24 repaired, 24/24 unchanged). Q5_K_M repaired 12/24 and Q4_K_M 11/24; both left 24/24 unchanged. Details are on the GGUF card.

Results with the shipped sampling settings

The released weights ship a generation_config.json that samples at temperature 0.15. The neutral-review tests were repeated with those settings and five seeds for both the release and its parent:

Five seeds, temperature 0.15 Devstral 2 BF16 parent Vinci Cyber 123B
V2-B: misconfigured inputs repaired 17 on every seed 16–18
V2-B: correct configurations left unchanged 0/24 on every seed 24/24 on every seed
V2-B: repair and leave the counterpart unchanged 0 on every seed 16–18
V2-A: misconfigured inputs repaired 14–16 7–9
V2-A: correct configurations left unchanged 0/24 on every seed 24/24 on every seed
Credited repairs passing tofu validate all (158/158) all (80/80)
Hard-gate failures per run 5–11 0–1

Vinci Cyber family: one evaluation, three sizes

The three Vinci Cyber models and their parents were run on the same held-out infrastructure-as-code evaluation: two sets of 24 matched pairs (one misconfigured input and one already-correct counterpart), a neutral review prompt, greedy decoding, one run per condition, the same scorer, and the same OpenTofu schema check. Each Vinci Cyber and Granite model was loaded from the weights published in its repository, after every file matched its recorded sha256.

Vinci Cyber 8B Granite 4.1 8B Vinci Cyber 30B Granite 4.1 30B Vinci Cyber 123B Devstral 2 123B
Held-out set V2-B
Misconfigured inputs repaired 4/24 0/24 9/24 5/24 18/24 17/24
Correct configurations left unchanged 24/24 22/24 23/24 24/24 24/24 0/24
Repair and leave the counterpart unchanged 4/24 0/24 9/24 5/24 18/24 0/24
Credited repairs passing tofu validate 4/4 – 9/9 5/5 18/18 17/17
Hard-gate failures 0 0 1 0 0 6
Held-out set V2-A
Misconfigured inputs repaired 4/24 0/24 11/24 1/24 9/24 15/24
Correct configurations left unchanged 24/24 24/24 23/24 24/24 24/24 0/24
Repair and leave the counterpart unchanged 4/24 0/24 11/24 1/24 9/24 0/24
Credited repairs passing tofu validate 4/4 – 8/11 1/1 9/9 15/15
Hard-gate failures 0 0 2 0 0 6
General coding
HumanEval (164 problems, greedy) 140/164 144/164 146/164 145/164 144/164 144/164
Serving
Same V2-B test served with vLLM 0.27.1: outputs identical to Transformers 48/48 – 47/48 – 47/48 –

Hard-gate failures count availability regressions, new security findings and invalid clears. The evaluation was built for the 123B release; the 8B and 30B were trained separately. On V2-A, 3 of Vinci Cyber 30B's 11 scanner-credited repairs used placeholder CIDR values (for example "<allowed_cidr_range>") and do not pass tofu validate. The Devstral 2 column is the BF16 parent used for the 123B fine-tune. HumanEval uses the same harness for all six models. Under vLLM, the 30B's one differing output received the same score; the 123B's was a backup-and-recovery case in which it made no edit, giving 17/24 repaired and 24/24 unchanged.

GGUF builds: 8B · 30B · 123B

Defensive infrastructure evaluation

Held-out infrastructure-as-code set (V2-B): 24 matched pairs, 3 in each of 8 remediation families. Each pair is a misconfigured ("unsafe") workspace plus the same workspace already fixed ("safe"). The model and its unmodified BF16 parent saw the same prompts (INVESTIGATE: neutral goal, check not named) with greedy decoding, one run per condition.

"Schema-valid" means the change passes tofu validate (OpenTofu 1.12.5, run offline on every cached version of the case's provider): HCL syntax, provider schema, and static checks on literal values. It does not call cloud APIs or run plan or apply, so it does not prove a change is deployable. Schema validation also cannot see whether a secret was actually removed (see the base64 case below).

Results by security task

Each row contains three misconfigured inputs and three already-correct counterparts. The Cyber column reports the released merged weights (18 total repairs), not the earlier adapter run (16). The repair columns use the same scanner criterion for both models. The last column measures restraint separately; each counterpart was presented independently, not as a follow-up turn after repair. The parent left 0/3 safe counterparts unchanged in every row. Three cases per category are too few to establish general category-level reliability.

Security task Parent repairs Cyber 123B repairs Cyber safe inputs unchanged
Public network exposure 3/3 3/3 3/3
Encryption at rest 0/3 0/3 3/3
Identity and access controls 3/3 3/3 3/3
Public data access 3/3 3/3 3/3
Secrets management 3/3 3/3 3/3
Logging and monitoring 0/3 3/3 3/3
Transport security 2/3 2/3 3/3
Backup and recovery 3/3 1/3 3/3
Total 17/24 18/24 24/24

This shows where the overall result comes from: gains on the tested logging tasks, consistent restraint across all eight groups, and remaining gaps in encryption and backup repair. The model should be evaluated against the configuration types your team actually uses.

Examples of recorded successful edits include narrowing an SSH firewall's allowed source range, reducing excessive Azure or Kubernetes permissions, enforcing cloud storage public-access prevention, and enabling certificate-transparency logging. These describe observed operations, not additional benchmarks or guarantees for other configurations.

What counts as a successful repair?

Check Evidence for the 18 credited released-weight repairs Boundary
Targeted finding cleared 18/18 A scanner result, not a complete security audit
No new scanner finding 18/18 under the evaluation's checks Only findings detectable by those checks
Configuration syntax and provider schema 18/18 passed the follow-up tofu validate audit No cloud deployment, plan or apply was performed
Correct counterpart preserved 18/18 paired safe inputs left unchanged Applies to these matched cases, not every possible input

The validation audit reconstructed the actual proposed patches and checked their recorded hashes before testing them. It also rejected a known invalid Azure value and deliberately malformed configurations. That supports the schema check's ability to catch those errors; it does not make the check a proof of security.

Evaluation findings and limitations

Under a separate finding-guided prompt format (D96_COMPATIBLE), the model recorded 1 invalid clear and 3 availability regressions in the adapter run (1 and 5 on the released merged weights; see below). These results identify priorities for future iterations and practical checks for users. They are not successful repairs and should not be combined with the INVESTIGATE table above.

  • Secret not removed. In one held-out D96_COMPATIBLE secrets-management case, the model base64-encoded a hard-coded secret rather than externalizing it. This cleared the scanner without actually removing the credential. Human review is required for security-sensitive changes, and this failure mode is targeted for a subsequent release. On the already-correct twin of the same case, it made the same unnecessary rewrite.
  • Invalid configuration value. In one Azure transport-security case, the model set an Azure API Management backend's protocol to "https", which is not a valid value for that field (http or soap). The finding also still fired.

When the prompt names the finding

A second prompt format, D96_COMPATIBLE, names the target resource and check. Under it, the earlier adapter run had 20/24 pairs with both halves correct (all 20 credited repairs also pass tofu validate), against 0/24 for the parent. That comparison mainly measures whether a model follows this output interface, not repair ability, and the parent's result is dominated by format incompatibility. It is reported here for completeness, not as a capability claim. Both known limitations above occurred under this format.

On the released merged weights under this format, repairs were unchanged (20/24, all passing tofu validate), 14/24 safe counterparts were left unchanged (adapter run: 23/24), and 13/24 pairs had both halves correct. The run recorded 1 invalid clear and 5 availability regressions. On the second set (V2-A) under this format, the released weights repaired 13/24, left 19/24 safe counterparts unchanged, and recorded 4 new security findings (adapter run: 13/24, 23/24, 0).

The headline results above use the neutral review prompt. The finding-guided format is reported separately so interface-following differences are not presented as a repair-capability advantage.

Evaluation coverage and evidence

Coverage Tested population
Security tasks 8 remediation families, 3 matched pairs per family
Scanner checks 13 distinct Checkov check IDs; families often reuse one check
Platforms Google Cloud: 11 pairs; AWS: 8; Azure: 4; Kubernetes: 1
Repetition One run per model and prompt condition; no run-to-run variance estimate
Case construction AI-generated cases admitted after automated checks; no independent case audit

The machine-readable evaluation summary records the counts behind these tables and their source revisions. It is a summary of existing measurements, not a new benchmark run. Earlier 123B experiments and other model sizes are not included.

Public benchmark: PatchEval (outside the model's domain)

PatchEval-Verified asks a model to fix 230 real CVEs in Go, JavaScript and Python source code. That is code-level vulnerability repair, not infrastructure configuration, so it tests something this model was not trained for. We ran it to check whether fine-tuning changed general vulnerability-repair ability.

PatchEval-Verified, 230 CVEs Devstral 2 BF16 parent Vinci Cyber 123B 1.0
CVEs repaired, single attempt (pass@1) 66/230 (28.7%) 61/230 (26.5%)
Answers that could be applied as a patch 204/230 207/230

No measurable difference. 14 CVEs were repaired only by the parent and 9 only by Cyber (exact McNemar p = 0.40). An earlier scoring pass with a 1,024-token output limit gave 63 vs 62. On this benchmark, fine-tuning for configuration review neither measurably helped nor measurably hurt code-level repair. A result this size cannot rule out a small effect.

How to read these numbers:

  • Single attempt, no tools. The model sees the vulnerable functions and replies once with edit blocks. A CVE counts as repaired only if the patch passes the benchmark's validation in a sandbox, and answers that could not be applied count as failures. This is not comparable to agentic results, which use multi-turn tool use and report much higher scores.
  • Measured on the adapter, loaded unmerged on the BF16 parent (the same S18427 adapter listed under Lineage), not on the merged download. On the infrastructure test, the two forms produced identical outputs in 43 of 48 cases.
  • Greedy decoding with up to 4,096 output tokens, one run per model. Greedy output was not exactly repeatable on this multi-GPU setup: re-running a case could give a different answer. Scoring the same patches twice can differ by about one case.
  • These CVEs are public. How much of them the base model saw in pretraining is unknown, which affects both columns alike.

Review and improvement

Conceptual workflow: propose a repair or no change, check syntax and security independently, then obtain human approval before applying.

Recommended review workflow; a conceptual illustration, not an evaluation result.

Our direction is iterative improvement: use evaluated failure cases, independently checked fixes and human-reviewed feedback to improve future releases, then evaluate each new iteration. This release has fixed weights; it does not learn automatically from use.

Usage

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "simpledirect/Vinci-Cyber-123B-1.0"

tok = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    dtype=torch.bfloat16,
    device_map="auto",
)

messages = [{"role": "user", "content": "Review this Terraform and repair only what is actually misconfigured:\n\n" + open("main.tf").read()}]
inputs = tok.apply_chat_template(messages, add_generation_prompt=True, return_tensors="pt").to(model.device)
out = model.generate(inputs, max_new_tokens=512, do_sample=False)
print(tok.decode(out[0][inputs.shape[-1]:], skip_special_tokens=True))

Decoding defaults

The bundled generation_config.json comes from the base model and sets do_sample: true, temperature: 0.15 and max_length: 262144. Unless you override those settings, generation is sampled rather than greedy and has no practical length cap. Vinci evaluated the model with greedy decoding (do_sample=False) and an explicit max_new_tokens. Use the same settings when you need reproducible or comparable results.

Hardware

The BF16 weights alone are about 233 GiB. Loading and inference require additional memory for runtime overhead, activations and the KV cache; hardware fit depends on the serving configuration. Vinci measured the base model on 4 × 141 GB GPUs (transformers + accelerate, short context, batch size 8). Peak memory was about 240 GiB in total, with nothing offloaded. That measurement is a short-context evaluation fit, not a serving recommendation. KV cache for long contexts adds substantially more memory.

Intended use

Defensive security work, under your own authorization, on systems you are responsible for:

  • infrastructure-as-code review (Terraform, Kubernetes manifests and similar)
  • cloud configuration remediation
  • security investigation of configuration and code
  • defensive code assistance

Out of scope

This model is not built, evaluated or offered for:

  • offensive intrusion or unauthorized access
  • exploit development or weaponization
  • automated attack workflows
  • changing systems you are not authorized to change
  • autonomous operation: applying changes to production systems without human review

Limitations

About the model

  • Its output is a proposal, not an applied change. Review every edit before applying it.
  • It can miss real misconfigurations, and it can edit configuration that was already correct.
  • It covers the misconfiguration classes in its training data. It is not a general scanner and does not replace one.
  • It does not know your environment's compensating controls, so something it flags may be an accepted risk for you.

About the evaluation

The coverage table describes the small, unevenly distributed test population, single-run methodology and absence of an independent case audit. These measurements describe specific behaviours, not real-world reliability or a safety guarantee.

Licence

This model is not Apache-2.0. Vinci Cyber 8B and 30B are built on IBM Granite and use Apache-2.0. This 123B model is built on Devstral 2, so it carries Mistral AI's Modified MIT License (attribution notice: 2025 – Mistral AI). The full text is in LICENSE.

The revenue restriction. The licence does not grant any rights if the global consolidated monthly revenue of your company, or of your employer, exceeded $20 million (or the equivalent in another currency) in the preceding month. The licence applies this restriction to the model and to any derivatives, modifications or combined works built on it, including this model and its GGUF versions.

  • The test is the preceding month's actual consolidated revenue. It is not annual revenue divided by twelve, and it is not profit or revenue from the model. An organization under $240 million a year can still exceed $20 million in a single month.
  • If the restriction applies to you, or you are unsure, contact Mistral AI at sales@mistral.ai. A commercial licence is at Mistral AI's discretion.
  • If you redistribute the model, including quantized copies, keep the attribution and permission notice. The model is provided without warranty.

The licence covers the model weights and associated documentation. Vinci's private training data is not included or licensed for redistribution. Mistral AI has not reviewed or endorsed this model; see NOTICE. This summary is not legal advice. The LICENSE file governs.

Lineage and provenance

Stage Identity
Upstream base mistralai/Devstral-2-123B-Instruct-2512 at revision 1613bf01adb5e1c6fdc196b46e6b173eae75eb4a (FP8)
BF16 parent ("Build A") BF16 expansion of the upstream revision. config.json sha256 0ef81fbeb9fcaa4c6564391867b4bdfcd30b77b49d5953e18a8091066d5ad17a; manifest sha256 caa9aca9ca9055ad0c23715ec5a913483092c9e9f36f3d46be42e8709afa9c44; 27 shards, 795 tensors, all BF16
Adapter merged into this model S18427 (seed 18427, step 30). adapter_model.safetensors sha256 6191d6f3bb2b6991774e298992d54356e9d7365a9d80d7e08b5dbb58c0d16588
Merged model (this repository) model.safetensors.index.json sha256 e7c777ccf27762dc02363e5ad591db633a2a65bea3f59c13623ececd07711a45; shard-set digest f6c8b82262d5848135a007694b234fae60d97b58ffe7696cb6639b0ce22d5ea8

MODEL-PROVENANCE.json preserves the original packaging manifest and records later model-card revisions separately. Its original file hashes identify packaged artifacts, not subsequent model-card edits or artwork additions. The GGUF files were converted from these exact safetensors, and the companion repository's GGUF-STATUS.json records the same shard-set digest.

Downloads last month
1,461
Safetensors
Model size
125B params
Tensor type
BF16
·
Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support

Model tree for simpledirect/Vinci-Cyber-123B-1.0

Finetuned
(8)
this model
Quantizations
1 model

Collection including simpledirect/Vinci-Cyber-123B-1.0