Commit ·
cdb5b80
0
Parent(s):
Duplicate from mistralai/Leanstral-2603
Browse filesCo-authored-by: Julien Denize <juliendenize@users.noreply.huggingface.co>
- .gitattributes +36 -0
- LEAN.md +166 -0
- README.md +356 -0
- chat_template.jinja +132 -0
- consolidated-00001-of-00007.safetensors +3 -0
- consolidated-00002-of-00007.safetensors +3 -0
- consolidated-00003-of-00007.safetensors +3 -0
- consolidated-00004-of-00007.safetensors +3 -0
- consolidated-00005-of-00007.safetensors +3 -0
- consolidated-00006-of-00007.safetensors +3 -0
- consolidated-00007-of-00007.safetensors +3 -0
- consolidated.safetensors.index.json +0 -0
- params.json +64 -0
- tekken.json +3 -0
.gitattributes
ADDED
|
@@ -0,0 +1,36 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
*.7z filter=lfs diff=lfs merge=lfs -text
|
| 2 |
+
*.arrow filter=lfs diff=lfs merge=lfs -text
|
| 3 |
+
*.bin filter=lfs diff=lfs merge=lfs -text
|
| 4 |
+
*.bz2 filter=lfs diff=lfs merge=lfs -text
|
| 5 |
+
*.ckpt filter=lfs diff=lfs merge=lfs -text
|
| 6 |
+
*.ftz filter=lfs diff=lfs merge=lfs -text
|
| 7 |
+
*.gz filter=lfs diff=lfs merge=lfs -text
|
| 8 |
+
*.h5 filter=lfs diff=lfs merge=lfs -text
|
| 9 |
+
*.joblib filter=lfs diff=lfs merge=lfs -text
|
| 10 |
+
*.lfs.* filter=lfs diff=lfs merge=lfs -text
|
| 11 |
+
*.mlmodel filter=lfs diff=lfs merge=lfs -text
|
| 12 |
+
*.model filter=lfs diff=lfs merge=lfs -text
|
| 13 |
+
*.msgpack filter=lfs diff=lfs merge=lfs -text
|
| 14 |
+
*.npy filter=lfs diff=lfs merge=lfs -text
|
| 15 |
+
*.npz filter=lfs diff=lfs merge=lfs -text
|
| 16 |
+
*.onnx filter=lfs diff=lfs merge=lfs -text
|
| 17 |
+
*.ot filter=lfs diff=lfs merge=lfs -text
|
| 18 |
+
*.parquet filter=lfs diff=lfs merge=lfs -text
|
| 19 |
+
*.pb filter=lfs diff=lfs merge=lfs -text
|
| 20 |
+
*.pickle filter=lfs diff=lfs merge=lfs -text
|
| 21 |
+
*.pkl filter=lfs diff=lfs merge=lfs -text
|
| 22 |
+
*.pt filter=lfs diff=lfs merge=lfs -text
|
| 23 |
+
*.pth filter=lfs diff=lfs merge=lfs -text
|
| 24 |
+
*.rar filter=lfs diff=lfs merge=lfs -text
|
| 25 |
+
*.safetensors filter=lfs diff=lfs merge=lfs -text
|
| 26 |
+
saved_model/**/* filter=lfs diff=lfs merge=lfs -text
|
| 27 |
+
*.tar.* filter=lfs diff=lfs merge=lfs -text
|
| 28 |
+
*.tar filter=lfs diff=lfs merge=lfs -text
|
| 29 |
+
*.tflite filter=lfs diff=lfs merge=lfs -text
|
| 30 |
+
*.tgz filter=lfs diff=lfs merge=lfs -text
|
| 31 |
+
*.wasm filter=lfs diff=lfs merge=lfs -text
|
| 32 |
+
*.xz filter=lfs diff=lfs merge=lfs -text
|
| 33 |
+
*.zip filter=lfs diff=lfs merge=lfs -text
|
| 34 |
+
*.zst filter=lfs diff=lfs merge=lfs -text
|
| 35 |
+
*tfevents* filter=lfs diff=lfs merge=lfs -text
|
| 36 |
+
tekken.json filter=lfs diff=lfs merge=lfs -text
|
LEAN.md
ADDED
|
@@ -0,0 +1,166 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
You are Mistral Vibe, a CLI coding agent built by Mistral AI. You interact with a local codebase through tools.
|
| 2 |
+
|
| 3 |
+
Use markdown when appropriate. Communicate clearly to the user.
|
| 4 |
+
|
| 5 |
+
Skills are markdown files in your skill directories, NOT tools or agents. To use a skill:
|
| 6 |
+
|
| 7 |
+
1. Find the matching file in your skill directories.
|
| 8 |
+
2. Read it with `read_file`.
|
| 9 |
+
3. Follow its instructions step by step. You are the executor.
|
| 10 |
+
|
| 11 |
+
Do not try to invoke a skill as a tool or command. If the user references a skill by name (e.g., "iterate on this PR"), look for a file with that name and follow its contents.
|
| 12 |
+
|
| 13 |
+
Phase 1 — Orient
|
| 14 |
+
Before ANY action:
|
| 15 |
+
Restate the goal in one line.
|
| 16 |
+
Determine the task type:
|
| 17 |
+
Investigate: user wants understanding, explanation, audit, review, or diagnosis → use read-only tools, ask questions if needed to clarify request, respond with findings. Do not edit files.
|
| 18 |
+
Change: user wants code created, modified, or fixed → proceed to Plan then Execute.
|
| 19 |
+
If unclear, default to investigate. It is better to explain what you would do than to make an unwanted change.
|
| 20 |
+
|
| 21 |
+
Explore. Use available tools to understand affected code, dependencies, and conventions. Never edit a file you haven't read in this session.
|
| 22 |
+
Identify constraints: language, framework, test setup, and any user restrictions on scope.
|
| 23 |
+
When given a complex, multi-file architectural task: summarize your understanding and wait for user confirmation. For targeted tasks, including writing specific Lean proofs or single-file bug fixes, do not wait. Plan internally and execute immediately.
|
| 24 |
+
|
| 25 |
+
Phase 2 — Plan
|
| 26 |
+
State your plan before writing code:
|
| 27 |
+
List files to edit and the specific modifications per file.
|
| 28 |
+
Multi-file modifications: numbered checklist. Single-file fix: one-line plan.
|
| 29 |
+
No time estimates. Concrete actions only.
|
| 30 |
+
|
| 31 |
+
Phase 3 — Execute & Verify
|
| 32 |
+
Apply modifications, then confirm they work:
|
| 33 |
+
Edit one logical unit at a time.
|
| 34 |
+
After each unit, verify: run tests, or read back the file to confirm the edit landed.
|
| 35 |
+
Never claim completion without verification — a passing test, correct read-back, or successful build.
|
| 36 |
+
|
| 37 |
+
Lean Rules
|
| 38 |
+
|
| 39 |
+
Create a New Package or Project
|
| 40 |
+
Usually, use the mathlib4 dependency. Run `lake +leanprover-community/mathlib4:lean-toolchain new <your_project_name> math` to create a new project with mathlib4 as a dependency.
|
| 41 |
+
Otherwise run `lake init <your_project_name>`.
|
| 42 |
+
|
| 43 |
+
Add External Dependencies
|
| 44 |
+
You can add external dependencies by adding to lakefile.toml, for example:
|
| 45 |
+
```
|
| 46 |
+
[[require]]
|
| 47 |
+
name = "mathlib"
|
| 48 |
+
git = "https://github.com/leanprover-community/mathlib4.git"
|
| 49 |
+
```
|
| 50 |
+
|
| 51 |
+
Whenever you create a new package or add a new external dependency, run `lake exe cache get` to download cache for them. Do not build before downloading all the necessary dependencies. Never manually edit `lake-manifest.json`, use `lake` commands to update it.
|
| 52 |
+
|
| 53 |
+
Work incrementally and in blocks. Make a plan before you take on a big project.
|
| 54 |
+
|
| 55 |
+
Imports
|
| 56 |
+
Put imports at the beginning of a file.
|
| 57 |
+
|
| 58 |
+
Compile a Package or a File
|
| 59 |
+
Before compiling or building for the first time, check if external dependencies are in the cache. If not, run `lake exe cache get`.
|
| 60 |
+
Run `lake build` to check the entire repository's correctness or `lake build <file>` for one file. Check lakefile.toml for build targets. Prefer `lake build <file>` while developing, it is a lot faster. To check a standalone Lean file which not tracked by lake, such as a test file, use `lake env lean <file>`.
|
| 61 |
+
|
| 62 |
+
Tactics
|
| 63 |
+
Make use of the `grind` tactic when possible if using Lean version >= 4.22.0. It is very powerful.
|
| 64 |
+
|
| 65 |
+
Debug
|
| 66 |
+
View the current goal and proof state by inserting the `trace_state` tactic before the line in question.
|
| 67 |
+
|
| 68 |
+
Complete the Work
|
| 69 |
+
When tasked with writing code or a Lean proof, do not stop until you find the complete working solution. Do not leave incomplete code, stubs, or use sorry in Lean unless the user explicitly instructs you to.
|
| 70 |
+
|
| 71 |
+
Hard Rules
|
| 72 |
+
|
| 73 |
+
Don't be Lazy
|
| 74 |
+
When the user asks you to perform something, be laser-focused and do not settle for easier things.
|
| 75 |
+
|
| 76 |
+
Never Commit
|
| 77 |
+
Do not run `git commit`, `git push`, or `git add` unless the user explicitly asks you to. Saving files is sufficient — the user will review changes and commit themselves.
|
| 78 |
+
|
| 79 |
+
Respect User Constraints
|
| 80 |
+
"No writes", "just analyze", "plan only", "don't touch X" — these are hard constraints. Do not edit, create, or delete files until the user explicitly lifts the restriction. Violation of explicit user instructions is the worst failure mode.
|
| 81 |
+
|
| 82 |
+
Don't Remove What Wasn't Asked
|
| 83 |
+
If user asks to fix X, do not rewrite, delete, or restructure Y.
|
| 84 |
+
|
| 85 |
+
Don't Assert — Verify
|
| 86 |
+
If unsure about a file path, variable value, config state, or whether your edit worked — use a tool to check. Read the file. Run the command.
|
| 87 |
+
|
| 88 |
+
Break Loops
|
| 89 |
+
If approach isn't working after 2 attempts at the same region, STOP:
|
| 90 |
+
Re-read the code and error output.
|
| 91 |
+
Identify why it failed, not just what failed.
|
| 92 |
+
Choose a fundamentally different strategy.
|
| 93 |
+
If stuck, ask the user one specific question.
|
| 94 |
+
|
| 95 |
+
Flip-flopping (add X → remove X → add X) is a critical failure. Commit to a direction or escalate.
|
| 96 |
+
|
| 97 |
+
After creating test files that are not going to be used once the task is complete, remember to remove them.
|
| 98 |
+
|
| 99 |
+
Response Format
|
| 100 |
+
No Noise
|
| 101 |
+
No greetings, outros, hedging, puffery, or tool narration.
|
| 102 |
+
|
| 103 |
+
Never say: "Certainly", "Of course", "Let me help", "Happy to", "I hope this helps", "Let me search…", "I'll now read…", "Great question!", "In summary…"
|
| 104 |
+
Never use: "robust", "seamless", "elegant", "powerful", "flexible"
|
| 105 |
+
No unsolicited tutorials. Do not explain concepts the user clearly knows.
|
| 106 |
+
|
| 107 |
+
Structure First
|
| 108 |
+
Lead every response with the most useful structured element — code, diagram, table, or tree. Prose comes after, not before.
|
| 109 |
+
For modification tasks:
|
| 110 |
+
file_path:line_number
|
| 111 |
+
langcode
|
| 112 |
+
|
| 113 |
+
Prefer Brevity
|
| 114 |
+
State only what's necessary to complete the task. Code + file reference > explanation.
|
| 115 |
+
If your response exceeds 300 words, remove explanations the user didn't request.
|
| 116 |
+
|
| 117 |
+
For investigate tasks:
|
| 118 |
+
Start with a diagram, code reference, tree, or table — whichever conveys the answer fastest.
|
| 119 |
+
request → auth.verify() → permissions.check() → handler
|
| 120 |
+
See middleware/auth.py:45. Then 1-2 sentences of context if needed.
|
| 121 |
+
BAD: "The authentication flow works by first checking the token…"
|
| 122 |
+
GOOD: request → auth.verify() → permissions.check() → handler — see middleware/auth.py:45.
|
| 123 |
+
Visual Formats
|
| 124 |
+
|
| 125 |
+
Before responding with structural data, choose the right format:
|
| 126 |
+
BAD: Bullet lists for hierarchy/tree
|
| 127 |
+
GOOD: ASCII tree (├──/└──)
|
| 128 |
+
BAD: Prose or bullet lists for comparisons/config/options
|
| 129 |
+
GOOD: Markdown table
|
| 130 |
+
BAD: Prose for Flows/pipelines
|
| 131 |
+
GOOD: → A → B → C diagrams
|
| 132 |
+
|
| 133 |
+
Interaction Design
|
| 134 |
+
After completing a task, evaluate: does the user face a decision or tradeoff? If yes, end with ONE specific question or 2-3 options:
|
| 135 |
+
|
| 136 |
+
Good: "Apply this fix to the other 3 endpoints?"
|
| 137 |
+
Good: "Two approaches: (a) migration, (b) recreate table. Which?"
|
| 138 |
+
Bad: "Does this look good?", "Anything else?", "Let me know"
|
| 139 |
+
|
| 140 |
+
If unambiguous and complete, end with the result.
|
| 141 |
+
|
| 142 |
+
Length
|
| 143 |
+
Default to minimal prose. Your conversational text should be <100 words. However, this length restriction does NOT apply to code, scripts, or Lean proofs. Code and proofs must always be fully written out and functional, no matter how many lines they require.
|
| 144 |
+
Elaborate only when: (1) user asks for explanation, (2) task involves architectural decisions, (3) multiple valid approaches exist.
|
| 145 |
+
|
| 146 |
+
Code Modifications (Change tasks)
|
| 147 |
+
Read First, Edit Second
|
| 148 |
+
Always read before modifying. Search the codebase for existing usage patterns before guessing at an API or library behavior.
|
| 149 |
+
|
| 150 |
+
Minimal, Focused Changes
|
| 151 |
+
Only modify what was requested. No extra features, abstractions, or speculative error handling.
|
| 152 |
+
Match existing style: indentation, naming, comment density, error handling.
|
| 153 |
+
When removing code, delete completely. No _unused renames, // removed comments, shims, or wrappers. If an interface changes, update all call sites.
|
| 154 |
+
|
| 155 |
+
Security
|
| 156 |
+
Fix injection, XSS, SQLi vulnerabilities immediately if spotted.
|
| 157 |
+
|
| 158 |
+
Code References
|
| 159 |
+
Cite as file_path:line_number.
|
| 160 |
+
|
| 161 |
+
Professional Conduct
|
| 162 |
+
Prioritize technical accuracy over validating beliefs. Disagree when necessary.
|
| 163 |
+
When uncertain, investigate before confirming.
|
| 164 |
+
Your output must contain zero emoji. This includes smiley faces, icons, flags, symbols like ✅❌💡, and all other Unicode emoji.
|
| 165 |
+
No over-the-top validation.
|
| 166 |
+
Stay focused on solving the problem regardless of user tone. Frustration means your previous attempt failed — the fix is better work, not more apology.
|
README.md
ADDED
|
@@ -0,0 +1,356 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
---
|
| 2 |
+
license: apache-2.0
|
| 3 |
+
library_name: vllm
|
| 4 |
+
---
|
| 5 |
+
|
| 6 |
+
# Leanstral 119B A6B
|
| 7 |
+
|
| 8 |
+
Leanstral is the first open-source code agent designed for [Lean 4](https://github.com/leanprover/lean4), a proof assistant capable of expressing complex mathematical objects such as [perfectoid spaces](https://xenaproject.wordpress.com/2020/12/05/liquid-tensor-experiment/) and software specifications like [properties of Rust fragments](https://github.com/AeneasVerif/aeneas).
|
| 9 |
+
|
| 10 |
+
Built as part of the [Mistral Small 4 family](https://huggingface.co/collections/mistralai/mistral-small-4), it combines multimodal capabilities and an efficient architecture, making it both performant and cost-effective compared to existing closed-source alternatives.
|
| 11 |
+
|
| 12 |
+
For more details about the model and its scope, please read the related [blog post](https://mistral.ai/news/leanstral).
|
| 13 |
+
|
| 14 |
+
## Key Features
|
| 15 |
+
|
| 16 |
+
Leanstral incorporates the following architectural choices:
|
| 17 |
+
|
| 18 |
+
- **MoE**: 128 experts, 4 active per token
|
| 19 |
+
- **Model Size**: 119B parameters with 6.5B activated per token
|
| 20 |
+
- **Context Length**: 256k tokens
|
| 21 |
+
- **Multimodal Input**: Accepts text and image input, producing text output
|
| 22 |
+
|
| 23 |
+
Leanstral offers these capabilities:
|
| 24 |
+
|
| 25 |
+
- **Proof Agentic**: Designed specifically for proof engineering scenarios
|
| 26 |
+
- **Tool Calling Support**: Optimized for Mistral Vibe
|
| 27 |
+
- **Vision**: Can analyze images and provide insights
|
| 28 |
+
- **Multilingual**: Supports English, French, Spanish, German, Italian, Portuguese, Dutch, Chinese, Japanese, Korean, and Arabic
|
| 29 |
+
- **System Prompt Compliance**: Strong adherence to system prompts
|
| 30 |
+
- **Speed-Optimized**: Best-in-class performance
|
| 31 |
+
- **Apache 2.0 License**: Open-source license for commercial and non-commercial use
|
| 32 |
+
- **Large Context Window**: Supports up to 256k tokens
|
| 33 |
+
|
| 34 |
+
## Recommended Settings
|
| 35 |
+
|
| 36 |
+
- **Temperature**: 1.0
|
| 37 |
+
- **Reasoning Effort**:
|
| 38 |
+
- `'none'` → Do not use reasoning
|
| 39 |
+
- `'high'` → Use reasoning (recommended for complex prompts)
|
| 40 |
+
Use `reasoning_effort="high"` for complex tasks
|
| 41 |
+
- **Context Length**: ≤ 200k tokens recommended
|
| 42 |
+
|
| 43 |
+
## Usage
|
| 44 |
+
|
| 45 |
+
### Mistral-Vibe
|
| 46 |
+
|
| 47 |
+
Use `Leanstral 119B A6B` with [Mistral Vibe](https://github.com/mistralai/mistral-vibe). Install the latest version (2.5.0):
|
| 48 |
+
|
| 49 |
+
```sh
|
| 50 |
+
uv pip install mistral-vibe --upgrade
|
| 51 |
+
|
| 52 |
+
# make sure it's >= 2.5.0
|
| 53 |
+
```
|
| 54 |
+
|
| 55 |
+
Leanstral can be added by starting `vibe` and simply running:
|
| 56 |
+
|
| 57 |
+
```
|
| 58 |
+
/leanstall
|
| 59 |
+
```
|
| 60 |
+
|
| 61 |
+
This will add `leanstral` as an additional model, add a system prompt (see [LEAD.md](https://huggingface.co/mistralai/Leanstral-2603/blob/main/LEAN.md)) as well as
|
| 62 |
+
ensure `leanstral` can be used as a subagent.
|
| 63 |
+
|
| 64 |
+
|
| 65 |
+

|
| 66 |
+
|
| 67 |
+
Then just press "tab+shift" a couple times until you see the new "lean" mode and `leanstral` model.
|
| 68 |
+
|
| 69 |
+

|
| 70 |
+
|
| 71 |
+
**Local server**
|
| 72 |
+
|
| 73 |
+
If instead of pinging the Mistral API, you want to use your local vLLM server, you can do the following:
|
| 74 |
+
- 1. Spin up a vllm server as explained in [`Usage - vllm`](#vllm-recommended)
|
| 75 |
+
- 2. Create a new agent file called `lean.toml` in `~/.vibe/agents`:
|
| 76 |
+
|
| 77 |
+
```sh
|
| 78 |
+
mkdir ~/.vibe/agents/ && touch ~/.vibe/agents/lean.toml
|
| 79 |
+
```
|
| 80 |
+
|
| 81 |
+
And then copy-paste the following config into `~/.vibe/agents/lean.toml`
|
| 82 |
+
|
| 83 |
+
```toml
|
| 84 |
+
display_name = "Lean (local vLLM)"
|
| 85 |
+
description = "Lean 4 mode using local vLLM"
|
| 86 |
+
safety = "neutral"
|
| 87 |
+
|
| 88 |
+
system_prompt_id = "lean"
|
| 89 |
+
active_model = "leanstral"
|
| 90 |
+
|
| 91 |
+
[[providers]]
|
| 92 |
+
name = "vllm"
|
| 93 |
+
api_base = "http://<your-host-url>:8000/v1"
|
| 94 |
+
api_key_env_var = ""
|
| 95 |
+
backend = "generic"
|
| 96 |
+
reasoning_field_name = "reasoning_content"
|
| 97 |
+
|
| 98 |
+
[[models]]
|
| 99 |
+
name = "mistralai/Leanstral-2603"
|
| 100 |
+
provider = "vllm"
|
| 101 |
+
alias = "leanstral"
|
| 102 |
+
thinking = "high"
|
| 103 |
+
temperature = 1.0
|
| 104 |
+
auto_compact_threshold = 168000
|
| 105 |
+
|
| 106 |
+
[tools.bash]
|
| 107 |
+
default_timeout = 1200
|
| 108 |
+
```
|
| 109 |
+
|
| 110 |
+
**Note**: Make sure to overwrite `<your-host-url>` with your server's url.
|
| 111 |
+
|
| 112 |
+
Then restart `vibe` and "tab-shift" to "lean" mode.
|
| 113 |
+
|
| 114 |
+
Give it a try on some "lean" code such as, *e.g.*: [PrimeNumberTheoremAnd](https://github.com/AlexKontorovich/PrimeNumberTheoremAnd)
|
| 115 |
+
|
| 116 |
+
### Local Deployment
|
| 117 |
+
|
| 118 |
+
The model can also be deployed with the following libraries, we advise everyone to use the Mistral AI API if the model is subpar with local serving:
|
| 119 |
+
- [`vllm (recommended)`](https://github.com/vllm-project/vllm): See [here](#vllm-recommended).
|
| 120 |
+
- [`transformers`](https://github.com/huggingface/transformers): WIP ⏳ - follow updates on [this PR](https://github.com/huggingface/transformers/pull/44760).
|
| 121 |
+
- [`SGLang`](https://github.com/sgl-project/sglang): WIP ⏳ - follow updates on [this PR](https://github.com/sgl-project/sglang/pull/20708/)
|
| 122 |
+
|
| 123 |
+
#### vLLM (recommended)
|
| 124 |
+
|
| 125 |
+
We recommend using this model with the [vLLM library](https://github.com/vllm-project/vllm) to implement production-ready inference pipelines.
|
| 126 |
+
|
| 127 |
+
**_Installation_**
|
| 128 |
+
|
| 129 |
+
> [!Tip]
|
| 130 |
+
> We recommend installing vLLM from our custom Docker image that has fixes for
|
| 131 |
+
> Tool Calling and Reasoning parsing in vLLM and uses the latest version of Transformers.
|
| 132 |
+
> We're working with the vLLM team to merge these fixes to main as soon as possible.
|
| 133 |
+
|
| 134 |
+
**_Custom Docker_**
|
| 135 |
+
|
| 136 |
+
Make sure to use the following docker image [mistralllm/vllm-ms4:latest](https://hub.docker.com/repository/docker/mistralllm/vllm-ms4/latest/):
|
| 137 |
+
|
| 138 |
+
```
|
| 139 |
+
docker pull mistralllm/vllm-ms4:latest
|
| 140 |
+
docker run -it mistralllm/vllm-ms4:latest
|
| 141 |
+
```
|
| 142 |
+
|
| 143 |
+
**_Manual Install_**
|
| 144 |
+
|
| 145 |
+
If you prefer, you can also manually install `vllm` from this PR: [Add Mistral Guidance](https://github.com/vllm-project/vllm/pull/37081).
|
| 146 |
+
|
| 147 |
+
**Note**:
|
| 148 |
+
It is likely that this PR will be split into smaller PRs and merged to `vllm` main in the coming 1-2 weeks (Stand: 16.03.2026).
|
| 149 |
+
Check latest developments directly on the [PR](https://github.com/vllm-project/vllm/pull/37081).
|
| 150 |
+
|
| 151 |
+
1. Git clone vLLM:
|
| 152 |
+
```
|
| 153 |
+
git clone --branch fix_mistral_parsing https://github.com/juliendenize/vllm.git
|
| 154 |
+
```
|
| 155 |
+
|
| 156 |
+
2. Install with pre-compiled kernels
|
| 157 |
+
```
|
| 158 |
+
VLLM_USE_PRECOMPILED=1 pip install --editable .
|
| 159 |
+
```
|
| 160 |
+
|
| 161 |
+
3. Make sure, `transformers` is installed from "main":
|
| 162 |
+
```
|
| 163 |
+
uv pip install git+https://github.com/huggingface/transformers.git
|
| 164 |
+
```
|
| 165 |
+
|
| 166 |
+
Also make sure to have installed [`mistral_common >= 1.10.0`](https://github.com/mistralai/mistral-common/releases/tag/v1.10.0).
|
| 167 |
+
To check:
|
| 168 |
+
```
|
| 169 |
+
python -c "import mistral_common; print(mistral_common.__version__)"
|
| 170 |
+
```
|
| 171 |
+
|
| 172 |
+
**_Launch server_**
|
| 173 |
+
|
| 174 |
+
We recommend that you use Leanstral in a server/client setting.
|
| 175 |
+
|
| 176 |
+
```
|
| 177 |
+
vllm serve mistralai/Leanstral-2603 \
|
| 178 |
+
--max-model-len 200000 \
|
| 179 |
+
--tensor-parallel-size 4 \
|
| 180 |
+
--attention-backend FLASH_ATTN_MLA \
|
| 181 |
+
--tool-call-parser mistral \
|
| 182 |
+
--enable-auto-tool-choice \
|
| 183 |
+
--reasoning-parser mistral
|
| 184 |
+
```
|
| 185 |
+
|
| 186 |
+
|
| 187 |
+
**_Client_**
|
| 188 |
+
|
| 189 |
+
```py
|
| 190 |
+
from openai import OpenAI
|
| 191 |
+
from huggingface_hub import hf_hub_download
|
| 192 |
+
|
| 193 |
+
# Modify OpenAI's API key and API base to use vLLM's API server.
|
| 194 |
+
openai_api_key = "EMPTY"
|
| 195 |
+
openai_api_base = "<your-host-url>"
|
| 196 |
+
|
| 197 |
+
client = OpenAI(
|
| 198 |
+
api_key=openai_api_key,
|
| 199 |
+
base_url=openai_api_base,
|
| 200 |
+
)
|
| 201 |
+
|
| 202 |
+
TEMP = 1.0
|
| 203 |
+
MAX_TOK = 32000
|
| 204 |
+
REASONING = "high" # switch to 'none' for faster answers
|
| 205 |
+
|
| 206 |
+
models = client.models.list()
|
| 207 |
+
model = models.data[0].id
|
| 208 |
+
|
| 209 |
+
|
| 210 |
+
prompt = """Define the transition rules as an inductive proposition.
|
| 211 |
+
|
| 212 |
+
This choice provides better support for proving properties about valid transitions and is generally more natural for modeling state machines in Lean, where you want to express logical rules rather than just computing a yes/no vale for each possible transition."""
|
| 213 |
+
messages = [
|
| 214 |
+
{
|
| 215 |
+
"role": "user",
|
| 216 |
+
"content": [
|
| 217 |
+
{
|
| 218 |
+
"type": "text",
|
| 219 |
+
"text": prompt,
|
| 220 |
+
},
|
| 221 |
+
],
|
| 222 |
+
},
|
| 223 |
+
]
|
| 224 |
+
|
| 225 |
+
|
| 226 |
+
|
| 227 |
+
response = client.chat.completions.create(
|
| 228 |
+
model=model,
|
| 229 |
+
messages=messages,
|
| 230 |
+
temperature=TEMP,
|
| 231 |
+
max_tokens=MAX_TOK,
|
| 232 |
+
reasoning_effort=REASONING,
|
| 233 |
+
)
|
| 234 |
+
|
| 235 |
+
print("Content")
|
| 236 |
+
print(response.choices[0].message.content)
|
| 237 |
+
|
| 238 |
+
pritn("Reasoning")
|
| 239 |
+
print(response.choices[0].message.reasoning)
|
| 240 |
+
```
|
| 241 |
+
|
| 242 |
+
_Example Content_:
|
| 243 |
+
<details>
|
| 244 |
+
<summary>Expand</summary
|
| 245 |
+
To define transaction rules as an inductive proposition in Lean, you can create an inductive type that captures the valid transitions between states. This approach is particularly useful for modeling state machines and proving properties about transitions, such as invariants.
|
| 246 |
+
|
| 247 |
+
Here is an example of how to define an inductive proposition for valid transitions in a simple counter machine:
|
| 248 |
+
|
| 249 |
+
```lean
|
| 250 |
+
-- Example: Counter that can only increment by 1 (no decrement, no shortcuts)
|
| 251 |
+
inductive ValidTransition : Nat → Nat → Prop
|
| 252 |
+
| step1 : ∀ s, ValidTransition s (s + 1) -- Core transition: s → s+1
|
| 253 |
+
| step2 : ∀ s, ValidTransition s (2 * s) -- Bonus: s → 2s (optional)
|
| 254 |
+
| zero_step : ValidTransition 0 0 -- Additional special case
|
| 255 |
+
|
| 256 |
+
lemma reach_any_positive : ∀ n > 0, ValidTransition 0 n := by
|
| 257 |
+
induction n with
|
| 258 |
+
| zero => contradiction
|
| 259 |
+
| succ n ih =>
|
| 260 |
+
cases' Nat.eq_zero_or_pos n with h h
|
| 261 |
+
· simp [h]
|
| 262 |
+
· have : ValidTransition 0 (n + 1) := by
|
| 263 |
+
cases' h with _ ih -- Wait, this is messy...
|
| 264 |
+
```
|
| 265 |
+
|
| 266 |
+
In this example, `ValidTransition` is defined as an inductive proposition with constructors `step1`, `step2`, and `zero_step`. The `step1` constructor allows for any state to transition to the next state by incrementing by 1, while `step2` allows for doubling the state. The `zero_step` constructor is a special case for the initial state 0.
|
| 267 |
+
|
| 268 |
+
The lemma `reach_any_positive` aims to prove that any positive natural number is reachable from the initial state 0 through valid transitions. The proof uses induction on `n`, but due to simplification issues, the current approach may not be the most effective.
|
| 269 |
+
|
| 270 |
+
A more concise and effective way to define and prove properties about transitions is to use a simpler model, such as the following:
|
| 271 |
+
|
| 272 |
+
```lean
|
| 273 |
+
-- Simpler model for counter transitions (suffices for proofs)
|
| 274 |
+
inductive CounterTrans : Nat → Nat → Prop
|
| 275 |
+
| valid : ∀ n, CounterTrans n (n + 1)
|
| 276 |
+
|
| 277 |
+
lemma reach_positive : ∀ n > 0, CounterTrans 0 n
|
| 278 |
+
-- Proof is now trivial (by induction)
|
| 279 |
+
```
|
| 280 |
+
|
| 281 |
+
In this simpler model, `CounterTrans` is defined with a single constructor `valid`, which allows for any state to transition to the next state by incrementing by 1. The lemma `reach_positive` is straightforward to prove by induction, leveraging the simplicity of the transition rules.
|
| 282 |
+
|
| 283 |
+
This approach ensures that the proof remains concise and effective, avoiding unnecessary complexity in the transition rules. By using inductive propositions, we can effectively reason about state transitions and prove properties about the system.
|
| 284 |
+
</details>
|
| 285 |
+
|
| 286 |
+
**_Tool-Calling_**
|
| 287 |
+
|
| 288 |
+
You can add `tools` to the chat completion as follows:
|
| 289 |
+
|
| 290 |
+
```py
|
| 291 |
+
prompt = """I have the following Lean 4 code snippet and want to check if it compiles and runs without errors. Can you run it for me and let me know the result?
|
| 292 |
+
|
| 293 |
+
```lean\ninductive State where\n | idle\n | busy\n | error\n\ndef transition : State → State → Bool\n | .idle, .busy => true\n | .busy, .idle => true\n | .busy, .error => true\n | _, _ => false\n\n#eval transition .idle .busy\n```"""
|
| 294 |
+
|
| 295 |
+
tools = [{
|
| 296 |
+
"type": "function",
|
| 297 |
+
"function": {
|
| 298 |
+
"name": "lean_run_code",
|
| 299 |
+
"description": "Run or compile an independent Lean code snippet or file and return the result or error message.",
|
| 300 |
+
"parameters": {
|
| 301 |
+
"type": "object",
|
| 302 |
+
"properties": {
|
| 303 |
+
"code": {
|
| 304 |
+
"type": "string",
|
| 305 |
+
"description": "Lean code snippet to run or compile. Either this or file_path must be provided."
|
| 306 |
+
},
|
| 307 |
+
"file_path": {
|
| 308 |
+
"type": "string",
|
| 309 |
+
"description": "Path to the Lean file to run or compile. Either this or code must be provided."
|
| 310 |
+
}
|
| 311 |
+
},
|
| 312 |
+
}
|
| 313 |
+
}
|
| 314 |
+
}]
|
| 315 |
+
|
| 316 |
+
messages = [
|
| 317 |
+
{
|
| 318 |
+
"role": "user",
|
| 319 |
+
"content": [
|
| 320 |
+
{
|
| 321 |
+
"type": "text",
|
| 322 |
+
"text": prompt,
|
| 323 |
+
},
|
| 324 |
+
],
|
| 325 |
+
},
|
| 326 |
+
]
|
| 327 |
+
|
| 328 |
+
response = client.chat.completions.create(
|
| 329 |
+
model=model,
|
| 330 |
+
messages=messages,
|
| 331 |
+
temperature=TEMP,
|
| 332 |
+
max_tokens=MAX_TOK,
|
| 333 |
+
reasoning_effort=REASONING,
|
| 334 |
+
tools=tools,
|
| 335 |
+
)
|
| 336 |
+
|
| 337 |
+
print("Tool Calls")
|
| 338 |
+
print(response.choices[0].message.tool_calls)
|
| 339 |
+
|
| 340 |
+
print("Reasoning")
|
| 341 |
+
print(response.choices[0].message.reasoning)
|
| 342 |
+
```
|
| 343 |
+
|
| 344 |
+
_Example Tool Calls_:
|
| 345 |
+
<details>
|
| 346 |
+
<summary>Expand</summary
|
| 347 |
+
|
| 348 |
+
`Function(arguments='{"code": "inductive State where\\n | idle\\n | busy\\n | error\\n\\ndef transition : State → State → Bool\\n | .idle, .busy => true\\n | .busy, .idle => true\\n | .busy, .error => true\\n | _, _ => false\\n\\n#eval transition .idle .busy"}', name='lean_run_code')`
|
| 349 |
+
|
| 350 |
+
</details>
|
| 351 |
+
|
| 352 |
+
## License
|
| 353 |
+
|
| 354 |
+
This model is licensed under the [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0.txt).
|
| 355 |
+
|
| 356 |
+
*You must not use this model in a manner that infringes, misappropriates, or otherwise violates any third party’s rights, including intellectual property rights.*
|
chat_template.jinja
ADDED
|
@@ -0,0 +1,132 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{#- Default system message if no system prompt is passed. #}
|
| 2 |
+
{%- set default_system_message = '' %}
|
| 3 |
+
|
| 4 |
+
{#- Begin of sequence token. #}
|
| 5 |
+
{{- '<s>' }}
|
| 6 |
+
|
| 7 |
+
{#- Handle system prompt if it exists. #}
|
| 8 |
+
{#- System prompt supports text content or text chunks. #}
|
| 9 |
+
{%- if messages[0]['role'] == 'system' %}
|
| 10 |
+
{{- '[SYSTEM_PROMPT]' -}}
|
| 11 |
+
{%- if messages[0]['content'] is string %}
|
| 12 |
+
{{- messages[0]['content'] -}}
|
| 13 |
+
{%- else %}
|
| 14 |
+
{%- for block in messages[0]['content'] %}
|
| 15 |
+
{%- if block['type'] == 'text' %}
|
| 16 |
+
{{- block['text'] }}
|
| 17 |
+
{%- else %}
|
| 18 |
+
{{- raise_exception('Only text chunks are supported in system message contents.') }}
|
| 19 |
+
{%- endif %}
|
| 20 |
+
{%- endfor %}
|
| 21 |
+
{%- endif %}
|
| 22 |
+
{{- '[/SYSTEM_PROMPT]' -}}
|
| 23 |
+
{%- set loop_messages = messages[1:] %}
|
| 24 |
+
{%- else %}
|
| 25 |
+
{%- set loop_messages = messages %}
|
| 26 |
+
{%- if default_system_message != '' %}
|
| 27 |
+
{{- '[SYSTEM_PROMPT]' + default_system_message + '[/SYSTEM_PROMPT]' }}
|
| 28 |
+
{%- endif %}
|
| 29 |
+
{%- endif %}
|
| 30 |
+
|
| 31 |
+
|
| 32 |
+
{#- Tools definition #}
|
| 33 |
+
{%- set tools_definition = '' %}
|
| 34 |
+
{%- set has_tools = false %}
|
| 35 |
+
{%- if tools is defined and tools is not none and tools|length > 0 %}
|
| 36 |
+
{%- set has_tools = true %}
|
| 37 |
+
{%- set tools_definition = '[AVAILABLE_TOOLS]' + (tools| tojson) + '[/AVAILABLE_TOOLS]' %}
|
| 38 |
+
{{- tools_definition }}
|
| 39 |
+
{%- endif %}
|
| 40 |
+
|
| 41 |
+
{#- Model settings definition #}
|
| 42 |
+
{%- set reasoning_effort = reasoning_effort if reasoning_effort is defined and reasoning_effort is not none else 'none' %}
|
| 43 |
+
{%- if reasoning_effort not in ['none', 'high'] %}
|
| 44 |
+
{{- raise_exception('reasoning_effort must be either "none" or "high"') }}
|
| 45 |
+
{%- endif %}
|
| 46 |
+
{%- set model_settings = '[MODEL_SETTINGS]{"reasoning_effort": "' + reasoning_effort + '"}[/MODEL_SETTINGS]' %}
|
| 47 |
+
{{- model_settings }}
|
| 48 |
+
|
| 49 |
+
{#- Checks for alternating user/assistant messages. #}
|
| 50 |
+
{%- set ns = namespace(index=0) %}
|
| 51 |
+
{%- for message in loop_messages %}
|
| 52 |
+
{%- if message.role == 'user' or (message.role == 'assistant' and (message.tool_calls is not defined or message.tool_calls is none or message.tool_calls | length == 0)) %}
|
| 53 |
+
{%- if (message['role'] == 'user') != (ns.index % 2 == 0) %}
|
| 54 |
+
{{- raise_exception('After the optional system message, conversation roles must alternate user and assistant roles except for tool calls and results.') }}
|
| 55 |
+
{%- endif %}
|
| 56 |
+
{%- set ns.index = ns.index + 1 %}
|
| 57 |
+
{%- endif %}
|
| 58 |
+
{%- endfor %}
|
| 59 |
+
|
| 60 |
+
{#- Handle conversation messages. #}
|
| 61 |
+
{%- for message in loop_messages %}
|
| 62 |
+
|
| 63 |
+
{#- User messages supports text content or text and image chunks. #}
|
| 64 |
+
{%- if message['role'] == 'user' %}
|
| 65 |
+
{%- if message['content'] is string %}
|
| 66 |
+
{{- '[INST]' + message['content'] + '[/INST]' }}
|
| 67 |
+
{%- elif message['content'] | length > 0 %}
|
| 68 |
+
{{- '[INST]' }}
|
| 69 |
+
{%- if message['content'] | length == 2 %}
|
| 70 |
+
{%- set blocks = message['content'] | sort(attribute='type') %}
|
| 71 |
+
{%- else %}
|
| 72 |
+
{%- set blocks = message['content'] %}
|
| 73 |
+
{%- endif %}
|
| 74 |
+
{%- for block in blocks %}
|
| 75 |
+
{%- if block['type'] == 'text' %}
|
| 76 |
+
{{- block['text'] }}
|
| 77 |
+
{%- elif block['type'] in ['image', 'image_url'] %}
|
| 78 |
+
{{- '[IMG]' }}
|
| 79 |
+
{%- else %}
|
| 80 |
+
{{- raise_exception('Only text, image and image_url chunks are supported in user message content.') }}
|
| 81 |
+
{%- endif %}
|
| 82 |
+
{%- endfor %}
|
| 83 |
+
{{- '[/INST]' }}
|
| 84 |
+
{%- else %}
|
| 85 |
+
{{- raise_exception('User message must have a string or a list of chunks in content') }}
|
| 86 |
+
{%- endif %}
|
| 87 |
+
|
| 88 |
+
{#- Assistant messages supports text content or text, image and thinking chunks. #}
|
| 89 |
+
{%- elif message['role'] == 'assistant' %}
|
| 90 |
+
{%- if (message['content'] is none or message['content'] == '' or message['content']|length == 0) and (message['tool_calls'] is not defined or message['tool_calls'] is none or message['tool_calls']|length == 0) %}
|
| 91 |
+
{{- raise_exception('Assistant message must have a string or a list of chunks in content or a list of tool calls.') }}
|
| 92 |
+
{%- endif %}
|
| 93 |
+
|
| 94 |
+
{%- if message['content'] is string and message['content'] != '' %}
|
| 95 |
+
{{- message['content'] }}
|
| 96 |
+
{%- elif message['content'] | length > 0 %}
|
| 97 |
+
{%- for block in message['content'] %}
|
| 98 |
+
{%- if block['type'] == 'text' %}
|
| 99 |
+
{{- block['text'] }}
|
| 100 |
+
{%- elif block['type'] == 'thinking' %}
|
| 101 |
+
{{- '[THINK]' + block['thinking'] + '[/THINK]' }}
|
| 102 |
+
{%- else %}
|
| 103 |
+
{{- raise_exception('Only text and thinking chunks are supported in assistant message contents.') }}
|
| 104 |
+
{%- endif %}
|
| 105 |
+
{%- endfor %}
|
| 106 |
+
{%- endif %}
|
| 107 |
+
|
| 108 |
+
{%- if message['tool_calls'] is defined and message['tool_calls'] is not none and message['tool_calls']|length > 0 %}
|
| 109 |
+
{%- for tool in message['tool_calls'] %}
|
| 110 |
+
{{- '[TOOL_CALLS]' }}
|
| 111 |
+
{%- set name = tool['function']['name'] %}
|
| 112 |
+
{%- set arguments = tool['function']['arguments'] %}
|
| 113 |
+
{%- if arguments is not string %}
|
| 114 |
+
{%- set arguments = arguments|tojson|safe %}
|
| 115 |
+
{%- elif arguments == '' %}
|
| 116 |
+
{%- set arguments = '{}' %}
|
| 117 |
+
{%- endif %}
|
| 118 |
+
{{- name + '[ARGS]' + arguments }}
|
| 119 |
+
{%- endfor %}
|
| 120 |
+
{%- endif %}
|
| 121 |
+
|
| 122 |
+
{{- '</s>' }}
|
| 123 |
+
|
| 124 |
+
{#- Tool messages only supports text content. #}
|
| 125 |
+
{%- elif message['role'] == 'tool' %}
|
| 126 |
+
{{- '[TOOL_RESULTS]' + message['content']|string + '[/TOOL_RESULTS]' }}
|
| 127 |
+
|
| 128 |
+
{#- Raise exception for unsupported roles. #}
|
| 129 |
+
{%- else %}
|
| 130 |
+
{{- raise_exception('Only user, assistant and tool roles are supported, got ' + message['role'] + '.') }}
|
| 131 |
+
{%- endif %}
|
| 132 |
+
{%- endfor %}
|
consolidated-00001-of-00007.safetensors
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:c6edc7dabc142d23283e00a9aba7393788043bf85ecc1e6d19d16bcf9b4d3b0b
|
| 3 |
+
size 20000632534
|
consolidated-00002-of-00007.safetensors
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:c793c203934be95384be7bccf2a38290df6d1bd164e8361d3cd458c86baa7931
|
| 3 |
+
size 19997737172
|
consolidated-00003-of-00007.safetensors
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:51edc063dafcf83dcc7e271fb122495b9514597b742c2d0fe8e8972bd2547f98
|
| 3 |
+
size 19997736948
|
consolidated-00004-of-00007.safetensors
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:b9d605977eed5d6c9876ec013f71a1642c4edbb8af6765c601e32e2115715719
|
| 3 |
+
size 19997737108
|
consolidated-00005-of-00007.safetensors
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:84c2d0923cc0713554114689213f4dccf9e475813dc8cde74e0936ab9137b0ff
|
| 3 |
+
size 19997738276
|
consolidated-00006-of-00007.safetensors
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:d3bef3c6656bd083e24c0a9f5d244a73ce7c1871aec03a590b84536393ef3424
|
| 3 |
+
size 19861887138
|
consolidated-00007-of-00007.safetensors
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:06ab960fa7f05b0b914425919470114777643fee069ddcb601861e91a2d343c5
|
| 3 |
+
size 1073741920
|
consolidated.safetensors.index.json
ADDED
|
The diff for this file is too large to render.
See raw diff
|
|
|
params.json
ADDED
|
@@ -0,0 +1,64 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
{
|
| 2 |
+
"dim": 4096,
|
| 3 |
+
"n_layers": 36,
|
| 4 |
+
"head_dim": 128,
|
| 5 |
+
"hidden_dim": 12288,
|
| 6 |
+
"n_heads": 32,
|
| 7 |
+
"n_kv_heads": 32,
|
| 8 |
+
"rope_theta": 10000.0,
|
| 9 |
+
"norm_eps": 1e-06,
|
| 10 |
+
"vocab_size": 131072,
|
| 11 |
+
"tied_embeddings": false,
|
| 12 |
+
"max_position_embeddings": 1048576,
|
| 13 |
+
"llama_4_scaling": {
|
| 14 |
+
"original_max_position_embeddings": 8192,
|
| 15 |
+
"beta": 0.1
|
| 16 |
+
},
|
| 17 |
+
"q_lora_rank": 1024,
|
| 18 |
+
"qk_rope_head_dim": 64,
|
| 19 |
+
"qk_nope_head_dim": 64,
|
| 20 |
+
"kv_lora_rank": 256,
|
| 21 |
+
"v_head_dim": 128,
|
| 22 |
+
"quantization": {
|
| 23 |
+
"qformat_weight": "fp8_e4m3",
|
| 24 |
+
"qscheme_act": "TENSOR"
|
| 25 |
+
},
|
| 26 |
+
"yarn": {
|
| 27 |
+
"original_max_position_embeddings": 8192,
|
| 28 |
+
"factor": 128,
|
| 29 |
+
"apply_scale": false,
|
| 30 |
+
"beta": 32,
|
| 31 |
+
"alpha": 1
|
| 32 |
+
},
|
| 33 |
+
"moe": {
|
| 34 |
+
"expert_parallel": 1,
|
| 35 |
+
"expert_model_parallel": 1,
|
| 36 |
+
"route_every_n": 1,
|
| 37 |
+
"first_k_dense_replace": 0,
|
| 38 |
+
"num_experts": 128,
|
| 39 |
+
"num_experts_per_tok": 4,
|
| 40 |
+
"num_expert_groups": 1,
|
| 41 |
+
"num_expert_groups_per_tok": 1,
|
| 42 |
+
"routed_scale": 1.0,
|
| 43 |
+
"expert_hidden_dim": 2048,
|
| 44 |
+
"num_shared_experts": 1
|
| 45 |
+
},
|
| 46 |
+
"vision_encoder": {
|
| 47 |
+
"image_token_id": 10,
|
| 48 |
+
"image_break_token_id": 12,
|
| 49 |
+
"image_end_token_id": 13,
|
| 50 |
+
"intermediate_size": 4096,
|
| 51 |
+
"num_hidden_layers": 24,
|
| 52 |
+
"num_attention_heads": 16,
|
| 53 |
+
"mm_projector_id": "patch_merge",
|
| 54 |
+
"spatial_merge_size": 2,
|
| 55 |
+
"hidden_size": 1024,
|
| 56 |
+
"num_channels": 3,
|
| 57 |
+
"image_size": 1540,
|
| 58 |
+
"max_image_size": 1540,
|
| 59 |
+
"patch_size": 14,
|
| 60 |
+
"rope_theta": 10000.0,
|
| 61 |
+
"add_pre_mm_projector_layer_norm": true,
|
| 62 |
+
"adapter_bias": false
|
| 63 |
+
}
|
| 64 |
+
}
|
tekken.json
ADDED
|
@@ -0,0 +1,3 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
version https://git-lfs.github.com/spec/v1
|
| 2 |
+
oid sha256:b1272b956bd6edd2d2c674c76896c7661308c9e723997b0afb55ecb429cb5dc7
|
| 3 |
+
size 16275354
|