Skip to content

feat(storage): lossless repackTo and explicit lossy requantizeTo (SKEEP-008 phase B1) - #1470

Merged
michalharakal merged 1 commit into
developfrom
feature/1433-requantize-storage
Nov 5, 2026
Merged

michalharakal merged 1 commit into
developfrom
feature/1433-requantize-storage

Conversation

@michalharakal

Copy link
Copy Markdown
Contributor

Part of #1433, implementing rollout phase B1 of SKEEP-008 (docs/modules/skeep/pages/008-precision-and-encoding-conversion.adoc). Independent of phase A1 (#1469).

What

  • TensorStorage.repackTo stops being an always-throwing stub and does the lossless re-encodings: any packed encoding TensorStorageFactory.toTensorData can decode → Dense(4), and narrow dense (Dense(2) FP16/BF16) → Dense(4). Decoding is bit-exact (every 16-bit float and every dequantized block value is exactly representable in FP32); the result is owned dense FP32 host storage. A lossy direction still throws — but the message now names requantizeTo.
  • TensorStorage.requantizeTo (new) is the visible lossy call: supported targets are exactly Requantizers.supported — the same set a loader's EncodingRequest.RequantizeTo accepts — so the two conversion paths cannot drift. Target and shape are validated before the buffer is read (new Requantizers.validateShape, shared with quantize), a packed source is dequantized to FP32 first, and the result is owned packed host storage. Both methods gain a BufferResolver overload for FileBacked/Aliased sources, mirroring copyMaterialize.
  • TensorStorageFactory.toTensorData learns the remaining packed decoders (Q4_0, Q5_0, Q5_1, Q5_K, Q6_K, BITNET_PLANES, BITNET_B1_58 — all via their existing fromRawBytes), so repackTo(Dense(4)) covers every packed encoding with a dequantizer, per the SKEEP's acceptance criteria.
  • SKEEP-008 §Behaviour records one decision made here: narrow-dense widening yields dtype FP32, because a Dense(4) buffer tagged FP16/BF16 has no defined byte layout anywhere in the codebase.

Tests

RepackRequantizeTest (lang-core commonTest, 12 tests): bit-exact repackTo(Dense(4)) round-trips from Q8_0/Q4_0/BITNET_PLANES and from Dense(2) FP16; the lossy direction throws naming requantizeTo; requantizeTo byte-exact parity with Requantizers.quantize for Q8_0/Q4_0/BITNET_PLANES; packed→packed goes through dequantize; unsupported target fails with the loader's message; and a non-blocking shape fails before the buffer is read (proven with an unreadable device-resident buffer).

./gradlew :skainet-lang:skainet-lang-core:jvmTest macosArm64Test apiCheck checkUnmarkedStubs — green (additive API, skainet-lang-core.api regenerated).

…EP-008 B1, #1433)

TensorStorage.repackTo now does the lossless re-encodings instead of always
throwing: any packed encoding TensorStorageFactory.toTensorData can decode ->
Dense(4), and narrow dense (Dense(2) FP16/BF16) -> Dense(4), decoded to FP32
bit-exactly. A lossy direction still throws, now naming requantizeTo.

requantizeTo is the visible lossy call: targets are exactly
Requantizers.supported (the set a loader's EncodingRequest.RequantizeTo
accepts), the target and shape are validated before the buffer is read
(Requantizers.validateShape, shared with quantize), a packed source is
dequantized to FP32 first, and the result is owned packed host storage.
Both gain a BufferResolver overload for FileBacked/Aliased sources.

TensorStorageFactory.toTensorData learns the remaining packed decoders
(Q4_0, Q5_0, Q5_1, Q5_K, Q6_K, BITNET_PLANES, BITNET_B1_58), so repackTo
covers every packed encoding with a dequantizer. SKEEP-008 records that
narrow-dense widening yields dtype FP32.
@github-actions

github-actions Bot commented Nov 1, 2026

Copy link
Copy Markdown

📖 Documentation Preview

The documentation has been built successfully for this PR.

Generated Files:

  • Operator documentation: docs/modules/operators/_generated_/
  • JSON schema output: operators.json

Artifacts:

  • Download the documentation-preview-1470 artifact to view the complete documentation locally.

This comment will be updated automatically when the PR is updated.

@michalharakal
michalharakal merged commit ae20ffa into develop Nov 5, 2026
20 checks passed
@michalharakal
michalharakal deleted the feature/1433-requantize-storage branch November 5, 2026 10:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants