QWEN 3.8 FLASH NEXT : Les meilleurs réglages

Value of the Information & Strength of the Argument

The value of this video lies in its practical, actionable advice for running large MoE models on limited hardware. The creator methodically explains the problems encountered (poor default MoE handling, memory constraints) and the solutions (fork with expert cache, tensor placement, mlock). The argumentation is coherent: he demonstrates the effectiveness with before/after speed comparisons and explains why each setting matters. However, the evidence is purely experiential and lacks systematic testing or comparison with alternative methods, which weakens the scientific rigor. The reliance on a modified fork and manual code changes may be inaccessible to average users, but the reasoning is sound and reproducible for technical audiences.

Scientific Rigor, Source Quality, Title Accuracy

The sources provided are direct links to the relevant tools and model files: the llama.cpp fork, the AtomicChat GGUF quantizations, and the creator’s own support site. These are appropriate and allow verification. However, no external benchmarks or official documentation are cited, and the video does not discuss potential limitations or alternative approaches. The title accurately reflects the content, as the video indeed covers the best settings discovered by the creator. Adéquation is strong, and the video stays on topic without deviating.

The title accurately reflects the content: the video focuses on optimal settings to run Qwen 3.8 Flash Next on consumer hardware, achieving high speed through specific flags and forks.

7/10

The video is a practical tutorial based on the creator's hands-on experience. It provides specific technical configurations and explains the rationale behind each choice. However, it relies on anecdotal evidence and does not cite academic or official sources, relying instead on community forks and model repositories. The information is plausible and reproducible, but lacks formal benchmarking or external validation.

Markers derived by PSI from the transcript: the creator did not define chapters.

• 01:00Introduction: previous attempts resulted in 5-10 tokens/sec, now achieving 26-27 tokens/sec with same hardware.
• 02:00Explanation of MoE architecture: 125B experts, only 6 active per inference, 51B non-attention parameters.
• 04:00Introduction of AtomicChat GGUF quantizations as better optimized than unsloth's.
• 06:00Problem: IQ4_XS still slow due to poor default MoE handling; CPU usage low.
• 08:00Idea to use a fork with MoE expert cache; GPU utilization jumps to almost 100%.
• 10:00Switching from mmap to mlock further improves performance; memory fully in RAM.
• 12:00Challenge: Q4_K_M requires 54.5GB, exceeding RAM; solution: manually place layers on GPU via --tensor-split.
• 14:00Increased ubatch to 1024 for better prefill speed; final configuration: Q4_K_M, moe-expert-cache-size 56, mlock, 50k context, 222 tokens/sec prefill.
• 16:00Closing remarks: without the MoE cache fork, the model is unusable; mention of paid support on ajean.link.

• AJEAN Support/Subscription — Creator's service offering remote server access and chat support for configuration help.
• llama.cpp fork with MoE cache — Fork that provides the 'moe-expert-cache-size' flag for dynamic expert caching on GPU.
• Qwen3.8-Flash-Next-GGUF by AtomicChat — Quantized versions of the model (IQ4_XS, Q4_K_M, Q5_K_M) with memory requirements.

• AtomicChat Qwen3.8-Flash-Next-GGUF — The model card notes memory requirements and suggests using recent llama.cpp versions, aligning with the creator's recommendations.

• ajean.link