feat: add repetition_penalty support for MLLM path

[janhilgard]

Summary

• MLLM scheduler previously ignored the repetition_penalty parameter from API requests — tokens were sampled without any penalty, leading to excessive repetition in some models
• Adds per-request logits processors built from repetition_penalty via mlx_lm.sample_utils.make_logits_processors, applied in _step() before sampling
• Propagates repetition_penalty from SamplingParams through BatchedEngine → MLLMScheduler → MLLMBatchRequest → MLLMBatchGenerator
• Handles filter() and extend() for logits processors to support continuous batching lifecycle

Test plan

• Send request with repetition_penalty: 1.1 to an MLLM server, verify reduced repetition
• Send request without repetition_penalty, verify default behavior unchanged
• Verify [rep_penalty] log message appears when penalty is active
• Concurrent requests with different penalties should each apply their own processor

🤖 Generated with Claude Code

[Thump604]

@waybarrios, @janhilgard: brief note. This PR is the MLLM-path counterpart to my #213, which adds top_k, min_p, presence_penalty, and repetition_penalty to the LLM and SimpleEngine paths. Together you get full sampling-param coverage across all engine modes (SimpleEngine LLM, SimpleEngine MLLM, BatchedEngine, BatchedEngine MLLM scheduler).

No conflict between the two PRs at the file level (different scheduler paths). Both should land. Mergeable on current main.

[janhilgard]

@Thump604 Good call — I've expanded the PR to support all 4 sampling parameters in the MLLM path:

Parameter	Implementation	MLLM support
repetition_penalty	logits processor (existing)	✅
presence_penalty	logits processor via make_logits_processors()	✅ new
top_k	per-request sampler via make_sampler()	✅ new
min_p	per-request sampler via make_sampler()	✅ new

Architecture:

• presence_penalty uses the same make_logits_processors() pattern as repetition_penalty — both are logits processors that modify logits based on token history
• top_k and min_p require per-request samplers (different requests in a batch can have different values), so I added a samplers field to MLLMBatch with full filter()/extend() support for continuous batching
• When a request uses default values (top_k=0, min_p=0.0, presence_penalty=0.0), no extra processors or samplers are created — zero overhead for standard requests

Files changed:

• request.py — added presence_penalty to SamplingParams
• mllm_batch_generator.py — MLLMBatchRequest fields, MLLMBatch.samplers, _process_prompts, _step
• mllm_scheduler.py — propagate new params through add_request and _schedule_waiting
• engine/batched.py — pass new params through generate/stream_generate

Together with your #213, this gives full sampling-param coverage across all engine modes. No conflicts at the file level (your PR touches LLM/SimpleEngine/server.py, this one touches MLLM path).

[Thump604]

Nice expansion. The architecture split — logits processors for the history-dependent penalties (repetition_penalty, presence_penalty) vs per-request samplers for the distribution-shape parameters (top_k, min_p) — matches the constraint that batched inference needs per-request sampler state while logits processors are a single stack. The zero-overhead default path (no sampler creation when all params are default) keeps batched throughput unchanged for the 99% case.

Confirmed this lands independently of #213 — they touch disjoint files (mllm_batch_generator.py / mllm_scheduler.py / batched.py vs llm.py / simple.py / server.py). Between the two, every engine mode gets full sampling param coverage.

Approving.