Skip to content

[RNE Rewrite] feat(models): point LLM constants at the re-published artifacts - #1385

Open
msluszniak wants to merge 1 commit into
rne-rewritefrom
@ms/smollm2-int8-variants
Open

[RNE Rewrite] feat(models): point LLM constants at the re-published artifacts#1385
msluszniak wants to merge 1 commit into
rne-rewritefrom
@ms/smollm2-int8-variants

Conversation

@msluszniak

@msluszniak msluszniak commented Aug 26, 2026

Copy link
Copy Markdown
Member

Description

Points the LLM model constants at the re-published artifacts from export-scripts MR !16, which reconciles every LLM config against what is actually on the Hub and fixes the recipes that were wrong. All four families are re-exported and published.

family change status
smollm2 (135m, 360m, 1_7b) Ships one 8da8w file per size; bf16 and 8da4w are dropped because int8 is smaller, faster and answers better at every size. landed
hammer2.1 (0_5b, 1_5b, 3b) Re-export so all six files carry get_eos_ids [151645, 151643]; the bf16 builds currently emit <|im_end|> as visible text. landed
qwen2.5 3b Re-export so 8da4w stops on <|im_end|> like every other qwen2.5 file, rather than <|endoftext|>. landed
lfm2.5-text (350m, 1_2b) Re-export at the group size the quantization sweep picked, which the published 8da4w files predate. landed

Every LLM config also gains the corrected get_n_layers (it was null in all 15) and the real 2047 sequence dim, but those are config-side and need no constant change here.

Introduces a breaking change?

  • Yes
  • No

Type of change

  • Bug fix (change which fixes an issue)
  • New feature (change which adds functionality)
  • Documentation update (improves or adds clarity to existing documentation)
  • Other (chores, tests, code style improvements etc.)

Tested on

  • iOS
  • Android

Testing instructions

Related issues

Export side: export-scripts MR !16.

Checklist

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have updated the documentation accordingly
  • My changes generate no new warnings

Additional notes

Do not merge until every family's artifacts are published: the new filenames do not exist at the version tag yet, so a premature merge 404s.

@msluszniak msluszniak changed the title feat(llm): ship one int8 smollm2 variant per size feat(llm): point model constants at the re-published LLM artifacts Aug 26, 2026
@msluszniak
msluszniak marked this pull request as draft August 26, 2026 12:23
@msluszniak msluszniak self-assigned this Aug 26, 2026
@msluszniak msluszniak added model Issues related to exporting, improving, fixing ML models performance Related to all issues and tasks focused on improving performance labels Aug 26, 2026
@msluszniak msluszniak changed the title feat(llm): point model constants at the re-published LLM artifacts [RNE Rewrite] feat(models): point LLM constants at the re-published artifacts Aug 26, 2026
smollm2 now publishes a single `8da8w` file per size instead of a bf16 and an
`8da4w` one. The removed variants are not worth a download:

- The published `8da4w` files at 135m/360m were barely quantized: an unset
  group_size fell back to 128, and dims 576/960 are not divisible by it, so they
  shipped larger than bf16 and produced nonsense on device.
- bf16 is dominated on every axis. At 360m int8 is 0.412 GB / 106 tok/s /
  649 MiB against bf16's 0.725 GB / 11 tok/s / 935 MiB, with matching answers.
  At 1_7b bf16 decodes at 1.5-1.9 tok/s, which is not usable.
- At 1_7b the published `8da4w` loses to the 360m int8 build on 5 of 10 prompts
  (degenerate repetition, and list-vs-tuple semantics stated backwards) while
  being 2.5x the download, so 4-bit is dropped there too.

The 360m and 1.7B files were verified end to end in apps/nlp against locally
served copies of exactly what is being published.

Requires the matching re-export, published under the same version tag.
@msluszniak
msluszniak force-pushed the @ms/smollm2-int8-variants branch from aeec673 to a8470e1 Compare August 26, 2026 13:43
@msluszniak
msluszniak marked this pull request as ready for review August 26, 2026 17:06
@msluszniak
msluszniak requested a review from barhanc August 26, 2026 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

model Issues related to exporting, improving, fixing ML models performance Related to all issues and tasks focused on improving performance

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant