Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Phase 4 readiness: validate DSL Qwen output against HF reference on real GGUFs

Đang mở
  • Có gì không ổn?
#118 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

  • #119 của @michalharakal — đã đóng, không merge

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
huggingface, kotlin
Lĩnh vực
machine-learning, testing-qa

Hướng nghiên cứu

Start with tests/smoke/smoke-models.json and the existing tests/smoke/ harness to see how models are selected and run. Add a smoke comparison for the Qwen3-1.7B-Q8_0 GGUF on the DSL path, using a fixed prompt and temperature 0; choose either a checked-in Transformers reference fixture or a live llama.cpp reference. Done means the first N greedy tokens agree and top-K probability KL divergence is below the chosen threshold.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Replaces #114 with a focused scope. Phase-4 readiness gate before swapping the CLI Qwen branch from LlamaRuntime to OptimizedLLMRuntime + qwenNetwork().

Why this gate, not synthetic parity

The original #114 framed readiness as "DSL ↔ legacy LlamaRuntime numerical parity on identical synthetic weights". That framing has two problems:

  1. Legacy gets deleted in Phase 4. Once LlamaRuntime is gone, DSL-vs-legacy parity is permanently moot. Optimising for it is debt.
  2. Neither path is the source of truth. The real correctness reference is HuggingFace transformers (or llama.cpp) running the same Qwen3 GGUF — that's what users compare against. Synthetic-weight equivalence between two of our paths only tells us they're internally consistent, not that either is correct.

So the right gate is: DSL Qwen, fed a real Qwen3 GGUF, produces output that matches an HF reference within tolerance. The legacy path is allowed to disagree; if DSL matches HF and legacy doesn't, legacy was the wrong one all along.

Scope

Add an HF-reference smoke comparison to tests/smoke/ that:

  1. Takes a Qwen3-1.7B-Q8_0 GGUF (per existing tests/smoke/smoke-models.json), runs it through kllama-cli on the DSL path (after Phase 4) for a fixed prompt at temperature 0.
  2. Captures top-K next-token IDs / probabilities at each step.
  3. Compares against an external reference for the same prompt:
    • Option A: pre-computed reference logged via transformers Python script, checked into the repo as a fixture.
    • Option B: live comparison via llama.cpp CLI invocation (more setup, more runtime).

Pass criterion: top-1 token agrees with reference for the first N greedy steps (e.g. N=8); top-K probability KL-divergence below threshold.

Out of scope

  • DSL-vs-legacy LlamaRuntime numerical parity (the original #114 question). The fixes from #116 (RoPE NEOX) and #117 (QK-norm eps) shipped because they're independently correct, not because they close synthetic parity. Synthetic divergence remains (max |Δ| = 49.26 at pos 0 on the parity probe), root cause unknown — and that's fine, the ship gate now sits elsewhere.
  • Quantized parity. Phase 1B.2 (#113) already smoke-tested Q8 round-trip equivalence inside the DSL path. HF reference comparison can also be FP32-only initially.

Phase 4 — blocked on this gate

Phase 4 (CLI swap, delete LlamaRuntime family) should not merge until at least one greedy-token comparison passes against an HF reference on a real Qwen3 GGUF.

#52 was the other Phase-4 blocker; resolved by #115 (byte-level BPE).

Refs the closed #114, which has the historical investigation context.

Ngôn ngữ chính
Kotlin
Star
8
Fork
3
Merge trung bình
1 ngày 16 giờ
Pull request đã merge (30 ngày)
48

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SKaiNET-developers/SKaiNET-transformers

Tất cả issue của SKaiNET-developers/SKaiNET-transformers

Issue tương tự

Thêm issue về Kotlin

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.