SOLARized-GraniStral-14B_1902_YeAM-HCT (Beta)
Table of Contents
RU
SOLARized-GraniStral-14B_1902_YeAM-HCT — экспериментальный beta-мердж на базе официальной Ministral-3-14B-Instruct-2512 (text+vision), в который дополнительно «влиты» SOLAR и IBM Granite.
Цель этого репозитория — дать рабочий артефакт:
- базовая модель именно Instruct (не Base)
- мультимодальность (Pixtral vision) сохранена
- конверсия в GGUF для
llama.cppработает корректно и не «добавляет» literal-служебные токены вроде[/INST]
Что можно ожидать
- База — сильный instruction-following от Ministral Instruct, а SOLAR и Granite добавляют свой «почерк» (стиль/логика/устойчивость на части задач).
- Мердж делался с прицелом на практическую работоспособность, а не “просто смешать веса”.
- Это beta: соотношения и «значимость» доноров ещё будут доводиться.
Зачем такой микс (в двух словах)
Цель не в том, чтобы “заменить” Ministral, а чтобы обогатить его:
- сохранить сильное instruct-поведение, знания и мультимодальный стек от Ministral
- добавить донорские качества там, где они реально сильны
- избежать стерильного “base+base” за счёт опоры на instruct-бэкбон
Карта вливания (что во что вливалось)
| Компонент | Роль в мердже | Зачем он здесь |
|---|---|---|
mistralai/Ministral-3-14B-Instruct-2512 |
Бэкбон | Сильный instruct, современный чат-формат и Pixtral vision стек. |
Upstage/SOLAR-10.7B-v1.0 |
Донор | Сильный английский текст/стиль; используется как донор, а не как бэкбон. |
ibm-granite/granite-3.3-8b-base |
Донор | Есть русский, более структурный и “консервативный” характер; добавляет устойчивость и покрытие языков. |
Почему именно эти доноры (плюсы / минусы)
| Модель | Что хотим забрать | Какие минусы принимаем | Как используется |
|---|---|---|---|
| SOLAR | Хороший английский, “писательский” стиль, часто чёткие объяснения | Русский не лучший; характер может быть сухим | Вливается в instruct-бэкбон, чтобы добавить «фактуру» без потери выравнивания |
| Granite | Русский лучше, чем у многих базовых чекпоинтов; аккуратность/структура | Может быть суховат и осторожен; base-характер | Донор для стабильности (языки + структура) |
| Ministral Instruct | Alignment, следование инструкциям, нативный чат-формат, мультимодальность | Любой один бэкбон имеет ограничения по “тону” | Остаётся якорем; доноры накладываются поверх |
Что лежит в репозитории
config.json,params.json: конфиг модели (текст + vision).tokenizer.json,tekken.json,tokenizer_config.json: токенизатор (Tekken).chat_template.jinja,SYSTEM_PROMPT.txt: форматирование чата.model-000**-of-00014.safetensors+model.safetensors.index.json: шардированные веса.*_Q*.gguf: готовый GGUF.
Базовые модели
mistralai/Ministral-3-14B-Instruct-2512upstage/SOLAR-10.7B-v1.0ibm-granite/granite-3.3-8b-base
Что такое YeAM-HCT
YeAM-HCT — это пайплайн мерджа, ориентированный на управляемое смешивание и устойчивость. Этот beta-релиз — подтверждение, что мердж получился цельный и пригодный для использования.
Быстрый старт
Transformers (текст)
Запуск — стандартный для Mistral3/Pixtral-подобных чекпоинтов.
vLLM
Для корректной токенизации обычно лучше использовать mistral-common и соответствующий режим токенизатора.
GGUF / llama.cpp
Эта модель конвертится в GGUF для llama.cpp.
- Если модель начинает печатать literal
[/INST], это почти всегда метаданные токенизатора (pretok/token types). - Ожидаемая конфигурация:
tokenizer.ggml.pre = tekken, а[INST]/[/INST]размечены как CONTROL.
Для мультимодальности в llama.cpp обычно нужен GGUF модели плюс отдельный mmproj GGUF (projector).
Важно: мультимодальность llama.cpp для Pixtral/Mistral3 сейчас активно меняется. На практике качество понимания изображения может быть некорректным, даже если HF/Transformers даёт правильный ответ.
Планируемые вариации
Дальше будут разные варианты, отличающиеся:
- процентом «влития» донорских моделей
- относительной значимостью / весами доноров
Идея — выпускать небольшой набор понятных, маркированных вариантов, а не один постоянно «плавающий» файл.
Известные ограничения
- Beta-смешивание: часть сценариев может быть хуже базового Instruct.
- Длинный контекст и мультимодальность тяжёлые по ресурсам; настройки квантования/сервинга критичны.
EN
SOLARized-GraniStral-14B_1902_YeAM-HCT is an experimental beta merge built on top of the official Ministral-3-14B-Instruct-2512 (text+vision) checkpoint, with additional capabilities blended in from SOLAR-10.7B-v1.0 and IBM Granite-3.3-8b-base.
This repository is meant to be a practical, working artifact:
- the base is Instruct (not Base)
- multimodal (Pixtral vision stack) is preserved
- GGUF conversion for
llama.cppis supported without emitting literal service tokens like[/INST]
What you can expect
- A strong instruction-following base (Ministral Instruct) with additional style / reasoning “color” coming from SOLAR and Granite.
- A merge that is intended to be usable, not just a weight soup: the release is built around “does it actually run end-to-end” as a requirement.
- This is a beta: the blend ratios and donor significance are still being iterated.
Why this mix exists (high level)
The intent is not to "replace" Ministral, but to enrich it:
- keep the solid instruct behavior and multimodal stack from Ministral
- pull in donor traits where they are known to be strong
- avoid producing a sterile “base-on-base” model by anchoring everything in an instruct-tuned backbone
Blend map (what went into what)
| Component | Role in the merge | Why it is here |
|---|---|---|
mistralai/Ministral-3-14B-Instruct-2512 |
Backbone | Strong instruct alignment, modern tool/chat formatting, and the Pixtral vision stack. |
Upstage/SOLAR-10.7B-v1.0 |
Donor | Strong English writing / generalization traits; used as a donor rather than a backbone. |
ibm-granite/granite-3.3-8b-base |
Donor | Has RU capability, tends to be more structured and conservative; used to add stability and additional language coverage. |
Donor rationale (strengths / tradeoffs)
| Model | Strengths we want | Tradeoffs we accept | How it is used |
|---|---|---|---|
| SOLAR | Fluent English, good “writer” vibe, often strong at crisp explanation | RU is not the strongest; style can feel dry/neutral | Blended into the instruct backbone to add texture without losing alignment |
| Granite | Better RU coverage than many base LLaMA-family checkpoints; tends to be orderly/consistent | Can be dry and conservative; base-style | Used as a stabilizing donor (language coverage + structure) |
| Ministral Instruct | Alignment, instruction following, native chat formatting, multimodal | Any single backbone has its own “tone” limits | Remains the anchor; donors are layered onto it |
Files in this repo
config.json,params.json: model configuration (text + vision).tokenizer.json,tekken.json,tokenizer_config.json: tokenizer assets (Tekken).chat_template.jinja,SYSTEM_PROMPT.txt: chat formatting assets.model-000**-of-00014.safetensors+model.safetensors.index.json: HF checkpoint shards.*_Q*.gguf: a ready GGUF build.
Base models
mistralai/Ministral-3-14B-Instruct-2512Upstage/SOLAR-10.7B-v1.0ibm-granite/granite-3.3-8b-base
What is YeAM-HCT
YeAM-HCT is a merge pipeline focused on controlled mixing and stability. This beta release is a proof that the merge is coherent and usable end-to-end.
Quickstart
Transformers (text)
Use your standard transformers workflow for Mistral3/Pixtral-style checkpoints.
vLLM
This family typically works best with Mistral tokenization (mistral-common). When serving via vLLM, prefer the Mistral tokenizer mode.
GGUF / llama.cpp notes
This model can be exported to GGUF for llama.cpp.
- If you see literal service tokens like
[/INST]in output, it is almost always a tokenizer metadata issue (token types / pretok). - The intended configuration for
llama.cppistokenizer.ggml.pre = tekkenand[INST]/[/INST]marked as CONTROL token types.
For multimodal usage in llama.cpp, expect a model GGUF plus a separate mmproj GGUF (projector).
Important: llama.cpp multimodal support for Pixtral/Mistral3 is under heavy development. In practice, image understanding quality may be incorrect even when HF/Transformers works correctly.
Planned variants
Future releases will include multiple variants with different:
- percentage of blended-in donor models
- relative significance / weighting of each donor
The goal is to publish a small set of clearly labeled variants rather than one constantly changing file.
Known limitations
- Beta blend: don’t assume every domain improves simultaneously; some prompts may regress compared to the base Instruct.
- Long-context and multimodal workloads are heavy; quantization/serving settings matter.
License
Apache-2.0. Base model licenses apply for the corresponding upstream artifacts.
- Downloads last month
- 172
