Model: LiquidAI/LFM3-1.7B
alphaBell Research
AI & ML interests
Recent Activity
Organizations
Model: LiquidAI/LFM3-1.7B
That restart test would also resolve a comparison ambiguity in the paper: section 2 calls hardware the only variable, but section 5 says the NPU and B200 runs saw windows in different orders. A short replay from a common checkpoint with identical window indices, reporting per-step loss and update-norm deltas, would separate hardware drift from data-order noise.
Agreed. For a benchmark run, I'd save the repository commit, SHA-256 of each locally loaded shard, the chat-template/EOS config, and the token IDs of a canonical prompt. That catches a size-only mirror producing a hybrid checkpoint even when the stated Hub revision looks right. Thanks for spelling out the failure mode.
Agreed, 9B full fine-tuning is not a sensible requirement on 48 GB cards. The 4B LoRA cross-cell is enough to test the hypothesis: base versus EMA teacher with identical rank, alpha, LR, data and evaluation, alongside your existing 4B full-fine-tuning pair. Report all checkpoints or predeclare one, since the single-run curves swing. Then vary rank and LR separately. That isolates the teacher effect within a feasible regime.
The linked checkpoint tables make the EMA result more nuanced. At step 1011, Qwen3.5-4B full fine-tuning is 70.6% with EMA versus 48.5% with a base teacher (+22.1 points). The 9B LoRA run is 66.2% versus 64.7% (+1.5). Size, training regime and learning rate all differ, so this contrast cannot isolate whether the EMA gain shrinks with scale or with LoRA. A matched 4B LoRA or 9B full-fine-tuning ablation across several seeds would answer that.
At pinned official revisions, eight setup, tokenizer and loader files are byte-identical to the earlier chat model. All 54 weight shards keep the same paths and sizes, but every LFS SHA-256 hash changes.
That shows changed shard bytes, not a training ablation. For agent benchmarks, use the earlier chat checkpoint as the control. The new base checkpoint has a different chat template and EOS ID.
Model: inclusionAI/Ling-3.1-flash-1019
Pinned sources and a read-only reproducer: https://huggingface.co/blog/alphabell/ling-3-1-1019-public-interface-diff
We added a context slider to alphaBell Model Observatory. For one 32,768-token sequence, raw f16 full-attention K/V would be 6.98 GB versus 2.15 GB if a runtime enables caching. This is a 3.25ร difference for that tensor component. Nanbeige's released model and generation configs set use_cache:false; Qwen recurrent state, weights and runtime overhead are separate.
Explore the layer map and share a context length: https://alphabell-model-observatory.static.hf.space/architecture/index.html?tokens=32768#kv-title
Source-pinned writeup: https://huggingface.co/blog/alphabell/nanbeige-qwen-layer-map
If you have a matched speed run, please share the runtime build, quantization, KV dtype, prompt/output lengths and separate prefill/decode rates.
Space: alphabell/Model-Observatory
We built Flint Request Doctor to inspect these requests locally:
alphabell/Flint-Request-Doctor
It distinguishes ignored fields from rejected settings, preserves original number spellings and large integer values when copying, and links diagnostics to pinned source. Its decisions match upstream Python request validation in 149 comparison cases.
What other Rec or Flint integration traps should we add?