Skip to content

test: compare Kolibri-1 with an F32 KV cache, no flash attention - #479

Merged
bernardladenthin merged 1 commit into
mainfrom
claude/hopeful-pascal-9jlbqb
Oct 7, 2026
Merged

bernardladenthin merged 1 commit into
mainfrom
claude/hopeful-pascal-9jlbqb

Conversation

@bernardladenthin

Copy link
Copy Markdown
Owner

Summary

  • The failure: the Publish run on main (37548623206) failed all three macOS arm64 jobs in "Run C++ unit tests". The one log read (macOS 15 Metal) shows Kolibri1.RenormalizedRoutingMatchesTheReference at 0.00628 against a tolerance of 0.00622.
  • The cause: this is not a defect of patch 0016. The test loaded the model with the default F16 KV cache and F16 flash attention, which round by up to ~1e-3 relative, as much as the tolerance.
    • Measured on x86-64, the three comparisons already sat close to it: 0.0034 / 0.0251 / 0.0055 against 0.0059 / 0.0359 / 0.0065.
    • Apple silicon tipped one over.
  • The fix: the reference is double precision and the test checks the graph's math, not the cache's precision.
    • The context now uses an F32 KV cache, no flash attention, and no op offload, so a Metal build stays on the CPU.
    • The deviation drops to under 1e-6 relative.
    • The tolerance is therefore tightened from 1e-3 to 1e-4, which still leaves a margin above 150x.
  • Only llama/src/test/cpp/test_kolibri1.cpp changes.

Test plan

  • 598/598 C++ tests locally (fresh configure, all 16 patches at b11457).
  • clang-format 23.1.3.
  • CI is green on this branch. The three macOS arm64 jobs are the proof; this was not runnable locally on Apple silicon.
  • Docs / CHANGELOG: not needed (test-only).

Related issues / PRs

Follow-up to #478.

Checklist

  • I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
  • My commits follow Conventional Commits (a scope prefix, test_kolibri1:, rather than a test: type)
  • No security-sensitive changes

🤖 Generated with Claude Code

https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2


Generated by Claude Code

The Publish run on main (37548623206) failed all three macOS arm64 jobs
on Kolibri1.RenormalizedRoutingMatchesTheReference: 0.00628 against a
tolerance of 0.00622. Not a defect of patch 0016 -- the test loaded the
model with the default F16 KV cache and F16 flash attention, which round
by up to ~1e-3 relative, as much as the tolerance. Measured on x86-64 the
same three comparisons sat at 0.0034/0.0251/0.0055 against 0.0059/
0.0359/0.0065; Apple silicon tipped one over.

The reference is double precision and the test is about the graph's
math, so the context now uses an F32 cache, no flash attention and no op
offload (a Metal build stays on the CPU). The deviation drops to under
1e-6 relative, so the tolerance is tightened from 1e-3 to 1e-4 and still
keeps a margin above 150x. 598/598 C++ tests locally.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
@bernardladenthin
bernardladenthin merged commit bc4f9ea into main Oct 7, 2026
10 of 14 checks passed

Copy link
Copy Markdown
Owner Author

Two checks are red on this PR, and neither is caused by its change:

  • Verify GPG signing key (no secrets printed)
  • Verify GPG signing key — Gradle/BouncyCastle path (no secrets printed)

Why: both jobs declare environment: maven-central. The annotation says Branch "refs/pull/479/merge" is not allowed to deploy to maven-central due to environment protection rules. The jobs end after 1 s, before any step runs.

This is expected: publish.yml documents it ("EXPECTED to go RED on refs where the secret is not delivered"), and the previous PR run of this branch (37548301409, #478) shows the same two failures.

What follows:

  • There is no fix to port. A re-run would be rejected the same way, because the policy decides, not the code.
  • The real test of this PR is the C++ suite on the three macOS arm64 jobs. The run is still waiting on the Start gate (environment startgate), which needs approval before those jobs start.

Generated by Claude Code

@bernardladenthin
bernardladenthin deleted the claude/hopeful-pascal-9jlbqb branch October 7, 2026 00:07
@claude

claude Bot commented Oct 7, 2026

Copy link
Copy Markdown

Code Review: test_kolibri1 Precision Fix

Summary

This PR tightens the Kolibri-1 numerical test by using F32 KV cache instead of F16 to match the double-precision reference implementation, eliminating precision-induced test failures on macOS.

Positive Findings ✅

  1. Sound rationale: Using F32 cache aligns the test's goal (verifying graph correctness, not cache precision) with its method. Clear explanation in comments.

  2. Appropriate tolerance adjustment:

    • Old: 1e-3 (failed at 0.00628 vs 0.00622 on macOS)
    • New: 1e-4 (measured deviation under 1e-6 relative, margin > 150x)
    • This is a deliberate tightening, not a loosening to hide issues
  3. Minimal, focused changes: Only test file modified; no production code affected.

  4. Well-documented code: Comments clearly explain:

    • Why F32 cache is needed (double reference = F32 cache)
    • Why flash attention is disabled
    • Why op_offload is false (GPU builds must stay on CPU)
    • Test purpose (graph math, not precision)
  5. Cross-platform correctness:

    • Measured on x86-64: 0.0034 / 0.0251 / 0.0055 against 0.0059 / 0.0359 / 0.0065 tolerances
    • Apple Silicon tipped one over → fix addresses root cause, not symptom
    • Enables consistent CI across platforms

Verification Notes

  • Test compiles locally: 598/598 C++ tests passing
  • Constants used (GGML_TYPE_F32, LLAMA_FLASH_ATTN_TYPE_DISABLED) are from llama.cpp headers (b11457)
  • type_k, type_v cache type constants already used elsewhere in test suite (test_tts_params.cpp)

No Issues Found

No security concerns, build issues, or code quality problems detected.

This PR fixes a transient test flake on Apple Silicon without introducing unnecessary loosening of test tolerances. Ready to merge.

@sonarqubecloud

sonarqubecloud Bot commented Oct 7, 2026

Copy link
Copy Markdown

This branch had an error being deployed

1 failed deployment
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