Repository navigation
Conversation
|
🚫 PR 合入质量检查未通过,PR 已被禁止合入。 未通过项:
请按上述提示整改后,重新推送(push)或评论本 PR 即可触发再次检查。 |
Those backends report usage as details.generated_tokens instead of the OpenAI usage object, and the parsers dropped it, so every performance report showed zero output-token throughput. Also fix the default_perf fallback: Output initializes the counters to 0, so the "missing" checks never fired and the tokenizer fallback was dead code for any backend that did not report usage.
e48fedb to
8b7dcf3
Compare
|
🚫 PR 合入质量检查未通过,PR 已被禁止合入。 未通过项:
请按上述提示整改后,重新推送(push)或评论本 PR 即可触发再次检查。 |
|
Hi @Libotry @SJTUyh, could you take a look when you have time? #614 fixes #609 (custom Both come with unit tests. Thanks! |
|
C:/Program Files/Git/pr_check |
|
Hi @Libotry @SJTUyh, could you take a look when you have time? This fixes #616. The TGI / Triton / MindIE backends never parsed Evidence the services do return the count:
Note: as an external contributor I can't request reviewers from the UI — could a maintainer |
|
/pr_check 重检:PR body 已含 |
|
🚫 PR 合入质量检查未通过,PR 已被禁止合入。 未通过项:
请按上述提示整改后,重新推送(push)或评论本 PR 即可触发再次检查。 |
|
Hi @Libotry @Keithwwa @SJTUyh, a gentle nudge — this PR is ready for review. The issue analysis on #616 classified it as P1 (TGI/Triton/MindIE Input/Output Token Throughput is always 0 because the parsers drop details.generated_tokens). I've replied to the analysis on #616 covering the scope; happy to address any feedback. |
PR 描述
PR Type
Related Issue
Fixes #616
🔍 Motivation / 变更动机
TGI / Triton / MindIE 三个服务化后端都不解析 token 数量:
tgi_api.py:parse_text_response/parse_stream_responsetriton_api.py:parse_text_response/parse_stream_responsemindie_stream_api.py:parse_stream_response它们只写
output.content,从不设置output.input_tokens/output_tokens。后果是这三个后端的性能报告里 Input/Output Token Throughput 恒为 0,
generate_tokens_speed也是 0,只有延迟类指标可用。证据:仓库自带的 mock 服务其实一直在返回 token 数
(
tools/infer_serve_simulator/api/tgi_api.py:32-39、triton_api.py:28-33、mindie_origin.py:61-70的details.generated_tokens),说明是解析侧漏了。第二个问题在
summarizers/default_perf.py:154-162:本该"服务没上报就退回 tokenizer 估算"的兜底逻辑永远不触发。
Output.__init__把input_tokens/output_tokens初始化为 0,jsonl 里这两个键一定存在且不为
None,而判断写的是"键不存在或 is None"。于是任何未上报 usage 的后端在报告里都是 0 token,兜底形同虚设。
📝 Modification / 修改内容
BaseAPIModel._update_usage_from_details()(base_api.py):新增一个受保护的小工具,从
details.generated_tokens取输出 token 数(三个后端共用,避免三份重复代码)。parse_*_response调用该工具。TGI/MindIE 的details只出现在最后一帧;Triton 的
generated_tokens是累计值,直接赋值即可。default_perf.py:兜底判断改为"值缺失或<= 0才回退 tokenizer";output_tokens的回退额外要求prediction是字符串(多模态输出不会误入)。📐 Associated Test Results / 关联测试结果
新增/增强的用例:
test_tgi_api.py:文本响应、流式最后一帧、无details三种情况test_triton_api.py:文本响应、流式累计值(3 → 5)、无detailstest_mindie_stream_api.py:流式最后一帧、无detailstest_default_perf.py::test_calc_perf_data_success:原来output_tokens: 0只被断言"不报错",现在断言兜底后等于
len("test output")无。仅在服务返回
details.generated_tokens时补充计数;不改变请求格式。<= 0的兜底会让"服务确实返回 0 token 且 prediction 非空"的场景改用 tokenizer 估算,这是期望行为(0 与"未上报"在现有数据结构里无法区分)。
无(只是多读一个字段)。