Instructions to use simpledirect/Vinci-Cyber-123B-1.0 with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use simpledirect/Vinci-Cyber-123B-1.0 with Transformers:
# Use a pipeline as a high-level helper from transformers import pipeline pipe = pipeline("text-generation", model="simpledirect/Vinci-Cyber-123B-1.0") messages = [ {"role": "user", "content": "Who are you?"}, ] pipe(messages)# Load model directly from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer = AutoTokenizer.from_pretrained("simpledirect/Vinci-Cyber-123B-1.0") model = AutoModelForCausalLM.from_pretrained("simpledirect/Vinci-Cyber-123B-1.0", device_map="auto") messages = [ {"role": "user", "content": "Who are you?"}, ] inputs = tokenizer.apply_chat_template( messages, add_generation_prompt=True, tokenize=True, return_dict=True, return_tensors="pt", ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=40) print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[-1]:])) - Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- vLLM
How to use simpledirect/Vinci-Cyber-123B-1.0 with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "simpledirect/Vinci-Cyber-123B-1.0" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "simpledirect/Vinci-Cyber-123B-1.0", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker
docker model run hf.co/simpledirect/Vinci-Cyber-123B-1.0
- SGLang
How to use simpledirect/Vinci-Cyber-123B-1.0 with SGLang:
Install from pip and serve model
# Install SGLang from pip: pip install sglang # Start the SGLang server: python3 -m sglang.launch_server \ --model-path "simpledirect/Vinci-Cyber-123B-1.0" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "simpledirect/Vinci-Cyber-123B-1.0", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker images
docker run --gpus all \ --shm-size 32g \ -p 30000:30000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env "HF_TOKEN=<secret>" \ --ipc=host \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path "simpledirect/Vinci-Cyber-123B-1.0" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "simpledirect/Vinci-Cyber-123B-1.0", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }' - Docker Model Runner
How to use simpledirect/Vinci-Cyber-123B-1.0 with Docker Model Runner:
docker model run hf.co/simpledirect/Vinci-Cyber-123B-1.0
Vinci Cyber 123B 1.0
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).
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.
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_COMPATIBLEsecrets-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
protocolto"https", which is not a valid value for that field (httporsoap). 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
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


