nokia-applied-research/AnyJev

I'd like to take the help-wanted slot from ROADMAP.md: anyjev/calibrate/binning.py, an L1 alternative with a unit test on synthetic logits where the answer is known. Plan A histogram-binning calibrator that maps the [N, K] L0 probabilities to calibrated [N, K] probabilities, fit on a labelled calibration set. Equal-mass bins, with a minimum count per bin for the 100–500-label regime. Follows the interface of TemperatureScaler in calibrate/posthoc.py: fit(probs, labels), apply(probs), to_dict() / from_dict(). Numpy only. Tests A unit test on synthetic logits where the correct answer is known analytically , a constructed calibration set with a known accuracy per bin. Plus checks that outputs sum to 1, degenerate inputs are handled, and to_dict / from_dict round-trips. Questions in docs it says L1 does not change the ranking. Should binning keep that guarantee? do a bench regression should add alongside the unit test. Is that expected for this slot, or is the unit test enough Should

Hi! I'd like to contribute a llama.cpp backend, which is listed as help wanted in the roadmap. Before writing code, I wanted to check that you're open to it and that the approach below fits what you have in mind. Design In-process, not llama-server over HTTP. The server returns only top-n logprobs, so a label token outside the top-n would be missing. In-process I can read the last-position logits for the full vocabulary and apply the log-softmax myself, which matches the contract in base.py exactly. Nothing is sampled. Tokenizer. The prompt is rendered and tokenized with the Hugging Face tokenizer (tokenizer_name=...), the same way VLLMBackend does it, and the ids are fed straight to llama.cpp. That way both backends see identical token ids. At startup the backend compares the HF and GGUF tokenizations of a probe string and raises if they differ, so a mismatched GGUF fails loudly instead of returning wrong numbers. Scope. Only next_token_logprobs in this PR. Prefix KV reuse (score_sha