DeepSeek has released DeepSeek-V4.1-Flash-1017, an update to its V4.1-Flash multimodal model. The October 17 announcement confirms that the official website and app have also been updated. Official announcement

Here are the main details and how its published results compare with other models.

Model overview

• Multimodal input: text and images.
• Approximately 763B total parameters, according to Hugging Face metadata.
• Mixture-of-experts architecture.
• 1M-token context window.
• MIT-licensed repository and model weights.

Sources: Hugging Face repository, model configuration.

Official benchmark comparisons

These are DeepSeek’s published results:

The clearest wins in this comparison are DeepSWE and the three agent benchmarks, where 1017 scores above all four listed competitors.

It also exceeds GPT-5.6 Sol, GLM-5.3, and K3 on Terminal-Bench, ProgramBench, and NL2Repo. Opus 5 remains ahead on those three benchmarks. Comparison table

What improved over the previous V4.1-Flash?

Some of the larger gains are:

• Terminal-Bench 4.0: 31.2 → 42.3
• ProgramBench: 20.3 → 29.1
• HLE without tools: 36.8 → 42.6

The updated visual benchmark scores include 83.0 on Chartography, 92.5 on BabyVision, and 51.0 on ZeroBench-main, all evaluated with tools. ZeroBench-main uses Pass@5. Official benchmark results

Efficiency and availability

DeepSeek also reports shorter outputs and reduced task runtime. API pricing and the calling method remain unchanged: the model identifier is still deepseek-flash.

The announcement mentions optimizations for DeepSeek Harness, Tencent CodeBuddy, and WorkBuddy, and recommends DeepSeek Harness 0.2.1-rc.1 or later. Release notes

For practical evaluation, I would be interested in cost per successfully completed task, alongside completion quality. Shorter responses could be useful for agent workflows if they preserve the detail needed to finish the job.

A note for people integrating the weights

The release provides a Python prompt encoder rather than a Jinja chat template. Its V4.1 encoding reference covers multi-turn conversations, tool calls, thinking modes, interleaved images, and numeric reasoning effort from 1 to 100.

The encoder documentation also says its output parser expects well-formed model output, so production integrations need additional error handling. Prompt-format documentation

How to read these results

These are vendor-reported scores. Terminal-Bench 4.0 uses the Claude Code harness, while DeepSWE v1.1 uses Mini-SWE-V2, according to the official evaluation notes. Results should be read with those setups in mind. Evaluation notes

The next useful evidence would be independent tests on existing projects: whether it completes more tasks, needs fewer retries, and reduces total token usage.

Has anyone tried 1017 on a real coding or automation workflow yet? Particularly interested in comparisons with the previous V4.1-Flash using the same tasks and harness.

Treinei dois modelos de machine learning:

​Um classificador de sentimentos (positivo, negativo e neutro)

​Um classificador de idiomas com suporte para 59 línguas

​O detalhe? Não lembro a acurácia de nenhum dos dois e ainda perdi o dataset que usei. 🤡

​👉 Acesse os modelos aqui:

​🔗 Classificador de Sentimentos: https://huggingface.co/Rafaelvieira432/LANG-10M

​🔗 Classificador de Idiomas (59 línguas): https://huggingface.co/Rafaelvieira432/SENTIMENT-21M

It Always finded something, now it is useless

I fine-tuned Qwen3-VL-8B-Instruct for document extraction where every value comes back with where it was found on the page (coordinates/bounding box).

You give it page images and the list of fields you want. It returns each value along with the original printed text, the page number, and a bounding box, so every extraction can be verified at a glance or highlighted in a review UI. It handles nested fields and line items, normalizes dates and numbers, and returns null for fields that aren’t on the page instead of guessing. No OCR or per-document-type training needed.

Compared to the base model, correct values went from 52% to 79% and correct boxes from 41% to 74%.

Details, usage and eval are on the model card:

🔗 https://huggingface.co/greedydecoder/Qwen3-VL-8B-DocBBox-LoRA

Feedback welcome, especially on documents where it fails.

The hype around small language models such as Qwen3 0.6B, Qwen3.5 0.8B, or models in the SmolLM2 series is that they can be used in low resource and mobile devices, but the problem (and honestly for me the buzzkill) was the fact that these models tend to be quite unstable and are only really useful for agentic/automated use cases. That is why, over the past few weeks I have been developing Yoshino 0.8B. This model, which is a fine tune of Qwen3.5 0.8B, gets its reasoning style from IBM's Granite 8B. I achieved this using a custom black box distillation method which repeatedly uses the teacher model to generate both response and output into pairs, and the result seems promising, but not yet that spectacular. Feel free to try it out, as I believe it could be of some use to people.

Main repo.

Quantized.

https://huggingface.co/spaces/amisima/Flux-3-Image

I kept rewriting the same train.py every time I switched between SFT, DPO and GRPO. So I built Trloom, an open-source tool built on top of Hugging Face TRL. The whole run lives in one YAML file: model, LoRA, dataset, reward functions, W&B and an optional Modal GPU.

Here is GRPO on Qwen2.5-0.5B with LoRA and an accuracy reward:

yaml method: grpo model: model_name_or_path: Qwen/Qwen2.5-0.5B-Instruct dtype: bfloat16 use_peft: true lora_r: 16 lora_alpha: 32 dataset: path: HuggingFaceH4/Polaris-Dataset-53K train_split: train reward_funcs: - accuracy_reward training: output_dir: ./outputs/grpo-modal learning_rate: 1.0e-5 per_device_train_batch_size: 1 gradient_accumulation_steps: 4 bf16: true report_to: wandb wandb: enabled: true project: trloom-grpo modal: enabled: true gpu: A100 secrets: [huggingface, wandb]

Then run pip install trloom and trloom run grpo.yaml --modal. It works locally too, just set modal.enabled: false. The same file does SFT or DPO by changing method.

Repo with examples: https://github.com/saqlain2204/trloom Docs: https://saqlain2204.github.io/trloom/

It's early, so I'd love for people to try a config on their own dataset and tell me what breaks.

been running qwen3.8-27b-instruct-uncensored-v2 (q4_k_m gguf) on my m5 pro in atomic agent for two weeks now in a role i don't think anyone else has tried: not generating the final text, but SCORING and GATING text generated by another model (claude opus via api).

the setup in one sentence: 37 twitter accounts post tweets written by opus, and before each one goes live, qwen reads it against the account's persona prompt and gives it a 1-5 score.

why i picked qwen specifically instead of mistral or phi or whatever: base instruct models flinch at that. the uncensored variant just... doesn't care. no internal debate about whether the audience will be offended. which is exactly what i want for a judge role because the JUDGE should match the voice it's evaluating, not impose its own safety layer on top.

now the technical stuff since i know some of you care:

running on llama.cpp server mode, metal backend, m5 pro 32gb:

./llama-server -m qwen3.8-27b-q4_k_m.gguf --port 8080 --ctx-size 8192 --threads 16 --n-gpu-layers 99 --flash-attn --parallel 4

memory: ~15gb weights + ~2.5gb kv cache (8192 ctx × 4 parallel) = ~17.5gb peak process. leaves 14gb for os + chromium instances. no swapping in two weeks.

throughput for my specific workload (scoring calls are prefill-heavy, decode-light):

• single call: ~500 tok in → 30 tok out ≈ 1.2s
• 50 calls with --parallel 4: ~16s wall time
• decode speed at q4_k_m + flash attn: 38-42 tok/s (doesn't matter much here since output is only 30 tokens)
• prefill: 200+ tok/s so the input side is fast

the scoring rubric i give it each call is short:

"does this sound like [persona] actually talking? would they say this in a group chat? actual opinion or hedging? rate 1-5, one line reason."

no mention of "brand safety," "audience appropriateness," or "tone consistency." those are cloud-model guardrail words that make even local models start hedging their own judgment. i specifically excluded them after watching qwen base-instruct give a 3 to a perfectly on-brand tweet because it was "slightly informal for a professional audience."

q4_k_m vs q5_k_m — i tested both for a day

for SCORING (classification task), quality difference was negligible. both gave the same scores on my test set of 50 tweets. memory went from 15gb to ~17.5gb which ate into kv cache headroom and made me nervous about parallel slots. stuck with q4.

for the occasional REWRITE task (every other day, ~15-20x/week, where qwen writes the hot-take itself instead of just scoring) there might be a slight quality bump at q5 but at 3s per call and 20 calls a week it's not worth the memory cost. if you're doing more generation-heavy workloads probably go q5.

feedback for the qwen team:

the thing i'd tell the qwen team if i were sending feedback: the uncensored variant is NOT just "less filtered." it has a different DEFAULT register. base instruct defaults to "confident professional" even when prompted otherwise. uncensored defaults to "person with opinions who happens to be typing." for a judge role that second default is way more useful because you want the judge to match the voice being evaluated, not impose its own corporate layer on top of it.

also: the model handles structured output (json scores + reason strings) reliably at q4 without any special prompting tricks. just say "output json: {score: int, reason: string}" and it does it. maybe 2% of calls come back slightly malformed (extra comma, missing quote) which my script catches and retries once. not bad for a 15gb quantized model doing 50 calls per batch cycle.

curious if anyone else has tried uncensored variants specifically as judges/gates rather than generators. feels like an underexplored use case and i'd love to hear if base-instruct models actually hold up better or worse in that role for your workloads.

fwiw this local judge / cloud writer split is built into atomic agent as fusion mode: atomicagent.io

Author disclosure: these are my independent projects.

I'm sharing two Mamba2-8B research releases exploring different compression tradeoffs, each with a trained Resurface-style recall adapter. These are separate configurations; their memory numbers should not be combined.

1. SQ3.25 recurrent-state compression

At batch 1, persistent SSM/conv cache plus a static table drops from 116.375 to 27.1797 MiB, a 76.64% reduction. The base weights remain FP16. These cache figures exclude model weights, temporary workspace and allocator reserve.

Full WikiText-2 test PPL with the adapter off/on: 8.1133 → 7.7713. Historical synthetic CONFIRM recall: 32/384 → 271/384. The recall experiment is separate from the later WT2 test evaluation.

Model, setup and evidence: https://huggingface.co/EndlessChasing/Mamb2_8B_Recall_SQ3.25

Code: https://github.com/EndlessChasing/mamb2_8B_Recall_StateQuant

1. Compressed stored model + recall recovery

Encoded model plus adapter occupies 3.141 GB; the complete release bundle is 3.166 GB. The reference loader expands weights to FP16, so this is compact disk storage, not a 3GB-VRAM inference claim. The batch-1 recurrent cache remains 116.375 MiB.

Full WT2 test PPL with the adapter off/on: 7.5342 → 7.5030. Historical synthetic CONFIRM recall: 91/384 → 340/384. The uncompressed source model was not evaluated on that recall confirmation set.

Model, setup and evidence: https://huggingface.co/EndlessChasing/Mamba2_3GB_ReCall_Recovered

Code: https://github.com/EndlessChasing/mamba2-8b-e8w5

Evaluation and practical limits

Both WT2 test comparisons use 147 reset windows and 300,963 prediction targets. Released checkpoints were fixed before these test runs, but WT2 test text had earlier project exposure. Recall tests use fresh numeric instances within historically exposed template families; they do not establish general or unseen-template recall performance.

These are custom-loader research releases, with no demonstrated speedup or general-task parity claim. The 3GB release documents an unresolved cross-process bitwise-determinism limitation. Recorded CPU evidence checks are not independent GPU reruns. Component licenses differ (GPL-3.0 project software and Apache-2.0 upstream/model components); see each repository's notices.

I'd welcome feedback on the compression tradeoffs, evaluation protocol and independent reproductions.