SOLARized-GraniStral-14B_1902_YeAM-HCT

SOLARized-GraniStral-14B_1902_YeAM-HCT (Beta)

Table of Contents

• RU
• EN
• License

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-бэкбон

Карта вливания (что во что вливалось)

Почему именно эти доноры (плюсы / минусы)

Что лежит в репозитории

• 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-2512
• upstage/SOLAR-10.7B-v1.0
• ibm-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.cpp is 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)

Donor rationale (strengths / tradeoffs)

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-2512
• Upstage/SOLAR-10.7B-v1.0
• ibm-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.cpp is tokenizer.ggml.pre = tekken and [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.