/ Модель

Характеристики

Лицензия
Apache 2.0
Базовая модель
K2-Horizon-MoVA-36B-A4B-DERISKED-BF16
Опубликована
24 сен 2026

K2-Horizon-MoVA-36B-A4B-DERISKED-GGUF

Генерация текстаТекст → текст3 профессии

Квантованная GGUF-версия MoE-модели K2-Horizon для генерации текста и диалогов на английском языке.

3 222скачиваний за 30 дней1лайквеса обновлены26 сен 2026

Бенчмарки

Как модель справилась с задачами пользователей ailist и что о ней публикуют открытые лидерборды

Публичные оценки

Из открытых лидербордов. Сравнивайте результаты одного теста при одинаковых условиях — отсутствие оценки не значит, что модель хуже.

В подключённых источниках результатов для этой модели пока нет.

Что умеет модель

Описание составлено по карточке модели и метаданным Hugging Face

K2-Horizon-MoVA-36B-A4B-DERISKED-GGUF — набор GGUF-квантований модели Blackfrost-AI, подготовленный автором репозитория freakyskittle для запуска в llama.cpp и совместимых движках. Основа — Blackfrost-AI/K2-Horizon-MoVA-36B-A4B-DERISKED-BF16, поведенческая производная модели IFM/K2-Horizon-MoVA-36B-A4B. Архитектура k2-horizon сочетает 48 слоёв: 3 плотных и 45 MoE; всего 36 млрд параметров, около 4 млрд активны на токен. Для инференса в памяти должны помещаться все веса. Доступны варианты с разной точностью, включая IQ3_M и семейство Q4; размер и качество зависят от квантования.

Модель предназначена для генерации текста в диалоговом шаблоне. Карточка заявляет английский язык; специальная область применения не обозначена. Контекст в README упоминается в сценарии запуска на 262 144 токена с oxidize-c и сжатым KV-кэшем, но это не подтверждает поддержку такого контекста во всех вариантах и движках. Для загрузки архитектуры нужен форк IFM llama.cpp; стандартный llama.cpp не поддерживает k2-horizon. Шаблон чата требует параметра --jinja. По тестам автора, TQ1_0 и TQ2_0 не дают читаемого текста; часть файлов не проверялась. Лицензия — Apache-2.0.

Сценарии применения

  • генерация ответов в англоязычном чате
  • продолжение заданного текста
  • локальный инференс GGUF-модели на CPU или GPU
  • эксперименты с MoE-моделью K2-Horizon

Ограничения

Для запуска k2-horizon требуется форк IFM llama.cpp; стандартный llama.cpp эту архитектуру не загружает, а шаблон чата требует --jinja. TQ1_0 и TQ2_0 дают нечитаемый вывод, часть вариантов не тестировалась; измерения скорости в карточке не являются сопоставимыми бенчмарками.

Для каких профессий подходит3

Разделы каталога профессий, в задачах которых используется эта модель

Все профессии

Карточка модели

README от автора на Hugging Face, как он его опубликовал

Открыть на Hugging Face

K2-Horizon-MoVA-36B-A4B-DERISKED GGUF

TQ1_0 and TQ2_0 do not produce readable text. Every other quant that was generation-tested does. Files with "not tested" in the table have been uploaded and not checked.

GGUF conversions of Blackfrost-AI/K2-Horizon-MoVA-36B-A4B-DERISKED-BF16. The source is a weight-level behavioral derivative of IFM/K2-Horizon-MoVA-36B-A4B. DERISKED is the Blackfrost research label. It is not a claim of safety, zero refusals, or unchanged benchmark scores.

Upstream llama.cpp cannot load k2-horizon. Build the IFM fork at 42adf01:

https://github.com/MBZUAI-IFM/llama.cpp/tree/model/K2Horizon

Generation tests

Same prompt every time: The capital of France is, temperature 0, --jinja. Host: Ryzen 6850H / Radeon 680M. Fork build b1-42adf01. GGML_VK_DISABLE_ASYNC=1 on the Vulkan run.

FileSizeReadableHow it was run
IQ3_M15.4 GiBYesVulkan, -ngl 99, 7.1 tok/s
IQ4_XS18.9 GiBYesCPU, 12.9 tok/s
IQ4_NL19.9 GiBYesCPU, 0.3 tok/s while other jobs were on the box
Q4_K_M20.9 GiBYesCPU. -ngl 99 on this GPU hit ErrorDeviceLost after a full-offload attempt
Q5_K_M24.7 GiBYesCPU, 2.3 tok/s
Q6_K28.7 GiBYesCPU, 0.5 tok/s
Q8_037.1 GiBYesCPU, 0.4 tok/s
TQ1_08.0 GiBNoVulkan, ~9 tok/s, word salad
TQ2_09.6 GiBNoVulkan, ~14 tok/s, word salad
Q4_K_S19.9 GiBNot testedUploaded
Q4_019.8 GiBNot testedUploaded
Q4_122.0 GiBNot testedUploaded
MXFP4_MOE20.3 GiBNot testedUploaded. MoE tensors are MXFP4
Q4_K_DYN21.2 GiBNot testedMixed 4-bit, not an official Unsloth quant

A readable sample (IQ4_XS):

[Start thinking]
1.  **Analyze the User's Request:**
    *   The user

Q5_K_M opened the same way: Analyze the User's Request: The user's query is ". The ternary files did not. They repeated loose words with no sentence.

CPU speeds above are not a benchmark. Several of those runs shared the machine with quantization. IQ3_M is the quant that actually ran on the 680M GPU. Q8_0, Q6_K, and Q5_K_M refused -ngl 99 with failed to fit params to free device memory.

Routers (attn_v_gate) stay F32. No imatrix was used. The imatrix pass exited during load.

Q4_K_DYN keeps the output tensor and attention projections at Q6_K, token embeddings at Q5_K, and routers at F32. Everything else is Q4_K_M. This fork has no Unsloth Dynamic quant type.

Run

git clone --branch model/K2Horizon https://github.com/MBZUAI-IFM/llama.cpp
cd llama.cpp
git checkout 42adf01
cmake -B build -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build -j --target llama-server llama-cli
GGML_VK_DISABLE_ASYNC=1 ./build/bin/llama-server \
  -m K2-Horizon-MoVA-36B-A4B-DERISKED-IQ3_M.gguf \
  -ngl 99 -c 4096 -fa on --jinja \
  --temp 1.0 --top-p 0.95 \
  --host 0.0.0.0 --port 8082

The chat template is custom. llama.cpp applies it only with --jinja. Upstream sampling is temperature 1.0, top_p 0.95, reasoning effort high. Thinking is wrapped in <ifm|think>.

GGML_VK_DISABLE_ASYNC=1 matters on the 680M. Async Vulkan uploads have produced ? / NaN garbage on this GPU for other models.

If Windows prints Failed to process regex, the MSVC regex engine is rejecting the tokenizer pattern. Use the same fork on Linux.

Architecture

PropertyValue
Architecturek2-horizon
Parameters36B total, about 4B active per token
Layers48 (3 dense, then 45 MoE)
Hidden size2560
Heads32 query / 8 KV, head dim 128
MoE100 routed experts, 8 active, 1 shared expert
MoVA64 value experts, 4 active, on the MoE layers
Expert FFN768
Dense FFN6144
Context524288 native. A 680M-class box cannot serve that window.
Vocab250624, untied embeddings
Rope theta10000000
Routersigmoid, top-k weights normalized, scale 2.5
Normgrouped RMSNorm, 2 groups, eps 1e-6

All 36B weights have to sit in RAM or VRAM. "4B active" is the compute per token, not the file size.

MTP head and oxidize-c (262K context)

Short version: the MTP head works, but it does not make decoding faster. On the test box, plain decode was faster in every case measured. It is published for research and for anyone who wants to improve the verify path. For speed, use the plain IQ3_M file with oxidize-c and compressed KV (commands below).

Files

FileWhat it is
mtp/mtp-K2-Horizon-MoVA-36B-A4B-DERISKED-Q8_0.ggufSidecar holding only the MTP head (Q8_0, 98 MiB). It is loaded next to K2-Horizon-MoVA-36B-A4B-DERISKED-IQ3_M.gguf.
K2-Horizon-MoVA-36B-A4B-DERISKED-IQ3_M-MTP.ggufIQ3_M with the same head merged in as blk.48 (block_count 49, nextn_predict_layers 1). 15.53 GiB, sha256 e026b046aa1396f3de016ba63ce1c9bc73101212fc771a9290d59ba688099956.
mtp/k2-mtp-head.safetensors, mtp/SPEC.md, mtp/train_eval.jsonHead weights before quantization, the normative forward-pass spec, and the offline eval.

The head is a single DeepSeek-V3-style "nextn" layer (one dense K2 block plus eh_proj / enorm / hnorm / shared_head_norm). It reuses the target's token_embd and output. It was trained on hidden states from this IQ3_M target; mtp/SPEC.md has the details.

The merged file contains the 798 IQ3_M tensors byte-for-byte unchanged, followed by the 14 head tensors copied byte-for-byte from the sidecar. The only changed metadata key is block_count (48 → 49); the nextn_* keys were added.

Runtime support

  • The head runs only in oxidize-c, the C11 engine on branch feat/oxidize-c-k2-horizon of the oxidize repository (github.com/Zapdev-labs/oxidize). When this was written, that branch had not yet been pushed publicly.
  • The llama.cpp K2 fork (model/K2Horizon) and stock llama.cpp cannot use the MTP layer. For llama.cpp, use the plain K2-Horizon-MoVA-36B-A4B-DERISKED-IQ3_M.gguf, not the -MTP file.
  • In oxidize-c, MTP is opt-in with --mtp (greedy only, default 1 draft token). Without --mtp, the merged file decodes exactly like the plain IQ3_M file, with the head left unused.
make -C oxidize-c            # AVX2 CPU build
# merged file
./oxidize-c/oxidize-c --model K2-Horizon-MoVA-36B-A4B-DERISKED-IQ3_M-MTP.gguf --threads 8 --mtp --prompt "..."
# or: plain IQ3_M + sidecar
./oxidize-c/oxidize-c --model K2-Horizon-MoVA-36B-A4B-DERISKED-IQ3_M.gguf \
  --mtp-model mtp/mtp-K2-Horizon-MoVA-36B-A4B-DERISKED-Q8_0.gguf --threads 8 --mtp --prompt "..."

Measured MTP results

Host: Ryzen 7 6850H (8 cores / 16 threads, AVX2), 23 GB RAM, CPU only, 8 threads, --ctx 262144 with RQ-compressed KV, greedy, 128 generated tokens. Speed is relative to plain oxidize-c decode on the same prompt.

PromptDraft acceptance (1 draft token)Speed, 1 draft tokenSpeed, 2 draft tokens
chat26%0.68×0.51×
code65%0.88×0.76×
prose38%0.74×0.59×
chat, 4K-token prompt27%0.65×0.49×
code, 4K-token prompt22%0.66×0.50×
prose, 4K-token prompt25%0.68×0.50×
  • CLI run at --ctx 262144: 7.6–7.8 tok/s with --mtp (26% accepted), against 11.2–11.6 tok/s without it.
  • Why MTP loses: one verify step costs about 1.7× a single decode step (about 150 ms against 88 ms). At the acceptance rates above, that never pays back.
  • Offline eval (mtp/train_eval.json): top-1 agreement with the target of 38.7%, and an expected accepted length of 0.54 tokens at 2 draft tokens.
  • Output: the MTP output matches plain decode for the first 32–45 tokens and can then drift. Batched and single-row matmuls round differently, so the drift is expected.

Recommended: oxidize-c at 262K context, no MTP

./oxidize-c/oxidize-c --model K2-Horizon-MoVA-36B-A4B-DERISKED-IQ3_M.gguf \
  --ctx 262144 --threads 8 --prompt "..."

At --ctx 262144, oxidize-c automatically picks RQ-compressed KV: 3-bit keys and values, an exact window over the most recent 1024 positions, and 4 sink tokens. --kv rq selects it explicitly. The KV cache is allocated lazily and costs about 38 KB per filled token.

Decode speed in tok/s, same host, 8 threads:

Context depthoxidize-c, RQ KVoxidize-c, q8 KVllama.cpp K2 fork, best KV type (-fa 1)
011.0–11.611.011.5–11.7
4K, real prompt9.0–9.79.27.58 (q4_0 KV, 16 threads)
32K (synthetic fill)6.4–6.64.1not measured (did not finish)
131K (synthetic fill)2.7–3.0——
  • Depth 0: oxidize-c and llama.cpp are level.
  • 4K, real prompt: oxidize-c is about 1.2× faster than llama.cpp's best setting.
  • 32K: RQ is about 1.6× faster than q8 KV. Decode still slows a lot as the context fills.
  • Prefill in the 262K CLI run was 14.7 tok/s.
  • Memory:
    • The 262K CLI launch peaked at 15.9 GB RSS with no swap. Nearly all of that is the memory-mapped weights; anonymous memory was 118 MB.
    • A completely full 262K RQ cache would need about 10 GB on top of about 16.5 GB of weights. A 23 GB machine can therefore fill roughly 130K tokens before weights start being evicted.
  • Shorter contexts: below --ctx 8192 the default KV type is f32, which is the slowest option. Pass --kv q8: at a real 4K depth it gave 9.2 tok/s, against 7.4 tok/s for f32.

License

Apache-2.0, same as the source card. See LICENSE. Architecture, tokenizer, and chat template remain IFM's. The checkpoint weights are the Blackfrost derivative. This repository only repackages those weights as GGUF.

Lineage

IFM/K2-Horizon-MoVA-36B-A4B@7730b92d1b574e04663b04023d5d6fa83475432f
└── Blackfrost-AI/K2-Horizon-MoVA-36B-A4B-DERISKED-BF16
    └── freakyskittle/K2-Horizon-MoVA-36B-A4B-DERISKED-GGUF

Как запустить

На своей GPU в ailist. Цена — по текущим предложениям провайдеров

GPU в ailist

Универсальный рантайм

Нельзя запустить

В репозитории нет config.json: не понять архитектуру модели.

Ревизия весов
05ff70f

0 моделей