[Feature]: Log a per-request timing summary for every request, streamed or not #841

Summary

Please write a short timing summary to the flm serve log for every request: prompt tokens, generated tokens, prefill and decode durations. Write it whether or not the request streams, and whatever stream_options it sets.

Current behavior

The server log is the only place a tool on the host can watch flm serve's throughput without sitting between the client and the server. Today the timings reach the log only by accident:

• Streamed requests (≤ 1.0.6): the log echoes the final ChatCompletionChunk, and its usage holds the timings:

  ChatCompletionChunk: {..., "usage":{"prompt_tokens":11,"completion_tokens":10, ... "prefill_duration_ttft":2.65,"decoding_duration":0.94, ...}}
  

• Non-streamed requests (1.0.6): the timings are only in the HTTP response. The log shows the request body, Start prefill..., Prefill chunk 1/1 with 11 tokens, Start generating..., Model RAW Output: and NPU Lock Released!, but no token counts for the output and no durations.

• Streamed requests (1.0.10): since usage is sent only when the client sets stream_options: {"include_usage": true} (which matches OpenAI, so it's a good change), I'd expect the echoed final chunk to carry no usage for most clients either. I haven't run 1.0.10 to confirm what it logs.

So from 1.0.10 on, whether the server's own log records a request's speed depends on how the client asked. An operator generally can't change that, for example when the client is an editor, an agent framework or an eval harness.

Proposal

After each request finishes, write one line to the server log built from the usage the server already computes, independent of the API response. For example:

[FLM]  Request done: prompt 11 tokens (prefill 2.656 s, 4.14 tok/s), generated 10 tokens (decode 0.947 s, 10.55 tok/s), kv 21/32768

A stable prefix makes it easy to grep and to parse. llama.cpp's server does something similar: its per-request print_timing lines (prompt eval time = …, eval time = …) appear for every request, streamed or not.

A /metrics (Prometheus) or /v1/stats endpoint would also work, but the log line is the smaller change and needs no polling.

Environment

• FastFlowLM 1.0.6 (Linux, flm serve), checked against the 1.0.10 release notes
• Model: qwen3.6-moe:35b-a3b