[2026春季][T2-1-2]DiFanrui by DiFanrui · Pull Request #495 · InfiniTensor/InfiniLM

DiFanrui · 2026-07-12T03:10:04Z

伊里斯-赛题报告

摘要

本提交针对 InfiniLM 在 RTX 4090 24GB 上运行 Llama-3.1-8B-Instruct 的高并发与长文本服务场景进行调度优化。本组成员在调测过程中发现，原始调度在部分长输入或高并发 prefill/decode 交叠场景下会触发 cudaMalloc failed，使 RankWorker 停止并导致服务 unhealthy。改动将 prefill 与 decode 的 batch 上限拆分，并对真正的长输入实施保守保护，在保持小规模请求性能无明显下降的同时，提升高并发短输出场景吞吐，并消除已复现的长输入服务失效。

受当前可用硬件与模型存储条件限制，本次提交仅完成 8B 模型的完整测试矩阵与优化验证，未对 70B 模型给出实测结果。本文所有性能数据、截图和结论均以 8B 模型为准；调度策略本身不依赖 8B 特有结构，理论上可迁移到 70B 服务，但仍需要在具备足够显存、模型存储和多卡通信条件的环境中单独验证。

环境与复现

InfiniLM commit: 7c1efb5
模型: Llama-3.1-8B-Instruct
GPU: NVIDIA RTX 4090 24GB, TP=1
KV cache: --num-blocks 64, --block-size 256
测试工具：vllm bench serve
测试范围：官方 8B 测试矩阵，共 30 个点

并发数输入长度（tokens）输出长度（tokens）

1, 4 32, 256, 4096 256, 1024, 4096

16, 64 32, 256 256, 1024, 4096
说明：本节参数为本组在 RTX 4090 24GB 单卡环境下针对 8B 测试矩阵调测得到的稳定配置，并不宣称为所有硬件和模型上的全局最优配置。

关键参数选择：

--num-blocks 64：在 4090 24GB 上可稳定运行完整 8B 矩阵。
--max-batch-size 64：保留高并发请求的 admission 上限，实际 prefill/decode 批次由调度器环境变量进一步约束。
INFINILM_PREFILL_BATCH_CAP=8：限制 prefill 阶段瞬时显存峰值。
INFINILM_DECODE_BATCH_CAP=24：允许 decode 阶段使用更大的安全批次，提高输出吞吐。
INFINILM_LONG_CONTEXT_THRESHOLD=4096 与 INFINILM_LONG_CONTEXT_MAX_BATCH=1：对真正长输入请求进行保守保护。
INFINILM_DECODE_FIRST_WHEN_RUNNING=1：已有 decode 请求运行时延后新的长输入 prefill，避免长 prefill 与 decode 叠加触发 OOM。

反例参数：

num-blocks=80/96：服务可启动，但在长输入 forward 时触发 OOM。
block-size=128：触发 paged-attention/graph 编译失败。
仅降低全局 max-batch-size 到 2 或 3：仍不能稳定解决长输入卡点，说明问题不只是请求数，而是 prefill/decode 阶段显存压力不同。

复现启动命令：

export INFINILM_LONG_CONTEXT_THRESHOLD=4096
export INFINILM_LONG_CONTEXT_MAX_BATCH=1
unset INFINILM_LONG_CONTEXT_USE_TOTAL_LEN
export INFINILM_DECODE_FIRST_WHEN_RUNNING=1
export INFINILM_PREFILL_BATCH_CAP=8
export INFINILM_DECODE_BATCH_CAP=24

python python/infinilm/server/inference_server.py \
  --device nvidia --model=/root/autodl-tmp/models/Llama-3.1-8B-Instruct \
  --port 8102 --tp 1 --max-new-tokens 4096 --num-blocks 64 \
  --max-batch-size 64 --enable-graph --enable-paged-attn \
  --attn flash-attn --ignore-eos

优化内容

修改文件：python/infinilm/llm/scheduler.py。

增加 INFINILM_PREFILL_BATCH_CAP 与 INFINILM_DECODE_BATCH_CAP：允许 prefill 保持保守批次以控制瞬时显存，同时让 decode 使用更大的安全批次以提升输出吞吐。
增加长输入判定与 INFINILM_LONG_CONTEXT_MAX_BATCH：默认只将 prompt_len >= 4096 的请求视为长上下文，避免把短输入、长输出误串行化。
增加 INFINILM_DECODE_FIRST_WHEN_RUNNING：当已有 decode 在运行时，延后新的长输入 prefill，避免长 prefill 与长 decode 重叠导致 OOM。
所有策略均由环境变量控制；默认值保持原始 batch 行为，便于回退和复现。

问题与验证

本组在原始配置调测过程中，于以下点复现 cudaMalloc failed、RankWorker stopped 与 /health 异常：

con=4, input=4096, output=1024
con=16, input=256, output=256

启用本文调度策略后，长输入卡点稳定完成：

场景	成功请求	输出吞吐	Mean TTFT	Mean/P99 TPOT	Mean/P99 ITL	服务状态
con=4, in=4096, out=1024	40/40	53.89 tok/s	54604.96 ms	18.09 / 18.24 ms	18.07 / 18.90 ms	healthy
con=4, in=4096, out=4096	40/40	54.46 tok/s	203503.93 ms	17.33 / 18.61 ms	18.24 / 19.64 ms	healthy
con=16, in=4096, out=256	8/8	50.75 tok/s	17291.99 ms	22.60 / 36.95 ms	22.51 / 36.27 ms	healthy

高并发分相位限批的消融结果：

场景	策略	成功请求	输出 tok/s	总 tok/s	Mean/P99 TTFT ms	Mean/P99 TPOT ms	Mean/P99 ITL ms	结果
con=16, in=256, out=256	静态 max-batch=8	80/80	407.30	814.65	437.84 / 619.32	37.70 / 39.20	37.54 / 39.61	healthy
con=16, in=256, out=256	prefill=8, decode=24	80/80	726.03	1445.77	468.25 / 648.21	20.26 / 21.79	20.20 / 22.70	healthy
con=64, in=256, out=256	静态 max-batch=8	128/128	376.64	753.37	21498.23 / 69212.98	51.69 / 53.70	51.50 / 61.84	healthy
con=64, in=256, out=256	prefill=8, decode=24	128/128	725.92	1449.00	10944.62 / 25269.96	24.19 / 25.64	24.09 / 27.34	healthy
con=64, in=32, out=256	prefill=8, decode=24	64/64	1052.16	1180.10	4299.80 / 8402.76	29.31 / 30.72	29.20 / 47.44	healthy

边界与解释

output=4096 的高并发受 KV 容量而非 decode kernel 限制。以 input=256, output=4096 为例，每个请求约需要 ceil((256+4096)/256)=17 个 block；64 个 block 只能容纳约 3 个完整请求。因此 con=16 测得 137.23 tok/s、Mean TPOT 19.61ms、Mean TTFT 176.76s。该现象是安全 admission 导致的排队，服务保持 healthy。

不采用“只少预留几个 block”的激进策略，因为没有 KV swap/preemption 时，请求会在生成中途耗尽 block，风险从排队变成失败。

8B 测试矩阵运行结果

按照赛题给出的 8B 测试矩阵，本组共完成 30 个测试点，所有测试点均成功返回，服务保持 healthy。其中 con=16/64, in=256, out=256/1024 采用参数扫描阶段中与官方矩阵完全相同配置的成功结果，其余高并发点来自最终续跑目录。

con	input	output	success	输出 tok/s	总 tok/s	Mean/P99 TTFT ms	Mean/P99 TPOT ms	Mean/P99 ITL ms
1	32	256	20/20	56.86	63.77	32.04 / 35.86	17.53 / 17.59	17.46 / 18.12
1	32	1024	20/20	56.42	58.13	33.57 / 37.35	17.71 / 17.78	17.70 / 18.34
1	32	4096	20/20	56.19	56.62	36.27 / 39.52	17.79 / 17.89	17.79 / 18.52
1	256	256	20/20	55.84	111.68	59.00 / 65.34	17.75 / 17.83	17.68 / 18.29
1	256	1024	20/20	56.34	70.40	62.17 / 70.27	17.71 / 18.07	17.68 / 18.26
1	256	4096	20/20	56.07	59.56	72.66 / 95.72	17.82 / 17.86	17.84 / 19.03
1	4096	256	20/20	49.95	852.13	530.22 / 571.01	18.01 / 18.08	17.94 / 18.94
1	4096	1024	20/20	53.96	269.84	540.27 / 581.55	18.02 / 18.11	18.01 / 19.12
1	4096	4096	20/20	54.40	108.78	552.19 / 587.24	18.25 / 18.30	18.25 / 19.30
4	32	256	40/40	219.68	246.37	68.45 / 83.37	18.01 / 18.30	17.94 / 19.76
4	32	1024	40/40	218.34	224.96	71.65 / 85.85	18.27 / 18.37	18.31 / 20.60
4	32	4096	40/40	147.13	148.25	26035.76 / 81451.53	19.49 / 19.92	19.49 / 21.63
4	256	256	40/40	211.18	422.36	149.97 / 188.61	18.42 / 18.83	18.35 / 19.56
4	256	1024	40/40	212.85	265.91	155.94 / 196.74	18.66 / 18.79	18.65 / 19.79
4	256	4096	40/40	142.62	151.50	26983.21 / 83198.15	20.12 / 20.30	20.11 / 21.85
4	4096	256	40/40	106.39	1814.25	2939.61 / 7078.04	24.76 / 25.73	24.66 / 24.14
4	4096	1024	40/40	53.89	269.49	54604.96 / 462816.24	18.09 / 18.24	18.07 / 18.90
4	4096	4096	40/40	54.46	111.78	203503.93 / 1000116.28	17.33 / 18.61	18.24 / 19.64
16	32	256	16/16	798.81	895.94	174.00 / 237.02	19.40 / 19.79	19.32 / 23.38
16	32	1024	16/16	414.56	427.12	5312.69 / 20810.77	19.69 / 20.24	19.68 / 23.08
16	32	4096	16/16	138.96	140.02	174643.55 / 386805.00	19.36 / 19.54	19.36 / 21.08
16	256	256	80/80	726.03	1445.77	468.25 / 648.21	20.26 / 21.79	20.20 / 22.70
16	256	1024	80/80	483.11	602.73	11469.24 / 21660.05	20.43 / 20.83	20.42 / 23.17
16	256	4096	16/16	137.23	145.77	176758.32 / 392478.99	19.61 / 19.88	19.61 / 21.67
64	32	256	64/64	1052.16	1180.10	4299.80 / 8402.76	29.31 / 30.72	29.20 / 47.44
64	32	1024	64/64	530.96	547.03	45873.64 / 104608.76	20.20 / 20.45	20.18 / 23.19
64	32	4096	64/64	153.98	155.97	682827.66 / 1000204.93	11.86 / 19.67	19.48 / 21.49
64	256	256	128/128	725.92	1449.00	10944.62 / 25269.96	24.19 / 25.64	24.09 / 27.34
64	256	1024	128/128	475.28	593.76	86502.94 / 207693.01	20.44 / 20.78	20.43 / 23.28
64	256	4096	64/64	152.06	168.37	686751.99 / 1000352.92	12.07 / 19.81	19.72 / 21.50

结果上，短输出场景受益最明显：con=64, in=32, out=256 输出吞吐达到 1052.16 tok/s，con=64, in=256, out=256 达到 725.92 tok/s。长输出场景的 TPOT/ITL 仍保持在约 19-21ms，但 TTFT 会随 KV 容量排队显著升高，这是 24GB 单卡与 64 个 KV block 下的容量边界。

单并发基线与 decode 稳定性

为确认问题并非来自单请求 decode 性能，本组首先记录了 8B 模型在单并发下的基线表现。以下结果均使用 Flash Attention 与 Paged Attention，每个测试点 20 个请求。

con=1	input	output	输出 tok/s	总 tok/s	Mean TTFT ms	Mean/P99 TPOT ms	Mean/P99 ITL ms
1	32	256	56.86	63.77	32.04	17.53 / 17.59	17.46 / 18.12
1	32	1024	56.42	58.13	33.57	17.71 / 17.78	17.70 / 18.34
1	32	4096	56.19	56.62	36.27	17.79 / 17.89	17.79 / 18.52
1	256	256	55.84	111.68	59.00	17.75 / 17.83	17.68 / 18.29
1	256	1024	56.34	70.40	62.17	17.71 / 18.07	17.68 / 18.26
1	256	4096	56.07	59.56	72.66	17.82 / 17.86	17.84 / 19.03
1	4096	256	49.95	852.13	530.22	18.01 / 18.08	17.94 / 18.94
1	4096	1024	53.96	269.84	540.27	18.02 / 18.11	18.01 / 19.12
1	4096	4096	54.40	108.78	552.19	18.25 / 18.30	18.25 / 19.30

结论：单流 decode 始终约 56 tok/s、TPOT 约 18ms；4096 输入主要增加 prefill/TTFT，而未破坏 decode 路径。这为后续将问题定位到“并发调度时的瞬时显存峰值”提供了对照。

并发基线与故障复现

con=4	input	output	输出 tok/s	Mean TTFT ms	Mean/P99 TPOT ms	Mean/P99 ITL ms	现象
4	32	256	219.68	68.45	18.01 / 18.30	17.94 / 19.76	正常
4	32	1024	218.34	71.65	18.27 / 18.37	18.31 / 20.60	正常
4	32	4096	147.13	26035.76	19.49 / 19.92	19.49 / 21.63	KV 排队
4	256	256	211.18	149.97	18.42 / 18.83	18.35 / 19.56	正常
4	256	1024	212.85	155.94	18.66 / 18.79	18.65 / 19.79	正常
4	256	4096	142.62	26983.21	20.12 / 20.30	20.11 / 21.85	KV 排队
4	4096	256	106.39	2939.61	24.76 / 25.73	24.66 / 24.14	长输入干扰 decode

在进一步调测中，con=4, in=4096, out=1024 于原始实现下复现 cudaMalloc failed、RankWorker stopped 和服务 unhealthy；con=16, in=256, out=256 也复现相同类型的 failure。这说明仅按请求数准入并不足以覆盖长 prefill 或高并发 prefill/decode 交叠时的临时显存开销。

参数扫描：排除不可靠路径

尝试	结果	决策
`num-blocks=96` / block 256	空载约 22587 MiB，首个长输入 forward OOM	超出 24GB 余量，不采用
`num-blocks=80` / block 256	长输入 forward OOM	不采用
`num-blocks=128` / block 128	paged attention/graph 编译失败	不采用
max batch=3 或 2	长输入仍 OOM/unhealthy	仅全局降 batch 不足

这组反例说明，问题不能通过单纯扩大 KV cache 或全局降低 batch size 稳定解决。最终方案需要区分 prefill 与 decode 阶段的显存压力，为两类阶段设置不同的安全上限。

优化迭代与消融

长输入保护的两次迭代

第一版策略仅限制同一轮 schedule 中的长输入请求数量，但新的长输入 prefill 仍可能与已经在运行队列中的 decode 请求交叠。在 con=4, in=4096, out=1024 场景下，该版本仍会触发服务 unhealthy。

第二版加入 decode-first 保护：当 running queue 非空时，新的长输入 prefill 会被延后调度，优先让已有 decode 请求继续推进。该策略避免了长输入 prefill 与 decode 阶段叠加造成的瞬时显存峰值，con=4, in=4096, out=1024 最终稳定完成 40/40 请求。

随后，本组将 long-context 判定从“总长度达到 4096”收窄为默认仅 prompt_len >= 4096。这样可以只保护真正的长输入请求，避免把短输入、长输出请求误判为长上下文并强制串行化。以 con=4, in=32, out=4096 为例，该调整使输出吞吐从 108.46 提升到 137.01 tok/s，Median TTFT 从 73100ms 降至 66ms，同时长输入卡点仍保持稳定。

长输入保护解决了服务稳定性问题，但高并发短输出场景仍会受到全局 batch 上限限制。为此，本组进一步将 prefill 与 decode 的 batch cap 拆分，使 prefill 保持保守批次以控制显存峰值，同时让 decode 使用更大的安全批次提升输出吞吐。

分相位 batch cap

场景	策略	输出 tok/s	总 tok/s	Mean/P99 TTFT ms	Mean/P99 TPOT ms	Mean/P99 ITL ms
con=16, in=256, out=256	max batch=8	407.30	814.65	437.84 / 619.32	37.70 / 39.20	37.54 / 39.61
con=16, in=256, out=256	prefill=8/decode=16	724.84	1449.68	468.86 / 648.64	20.30 / 21.82	20.23 / 22.91
con=16, in=256, out=256	prefill=8/decode=24	726.03	1445.77	468.25 / 648.21	20.26 / 21.79	20.20 / 22.70
con=16, in=256, out=1024	max batch=8	399.02	497.97	13727.04 / 51497.49	24.91 / 25.38	24.90 / 41.97
con=16, in=256, out=1024	prefill=8/decode=16	483.19	603.04	11460.90 / 21678.92	20.43 / 20.78	20.41 / 23.36
con=16, in=256, out=1024	prefill=8/decode=24	483.11	602.73	11469.24 / 21660.05	20.43 / 20.83	20.42 / 23.17
con=64, in=256, out=256	max batch=8	376.64	753.37	21498.23 / 69212.98	51.69 / 53.70	51.50 / 61.84
con=64, in=256, out=256	prefill=8/decode=16	631.06	1261.17	12516.38 / 31741.32	29.07 / 30.60	28.96 / 46.19
con=64, in=256, out=256	prefill=8/decode=24	725.92	1449.00	10944.62 / 25269.96	24.19 / 25.64	24.09 / 27.34

从消融结果看，decode=24 对 con=16 场景收益有限，但在 con=64 短输出场景中，将输出吞吐从 631.06 提升到 725.92 tok/s，并将 Mean TPOT 从 29.07ms 降至 24.19ms、Mean ITL 从 28.96ms 降至 24.09ms。因此，本次 8B 提交采用 prefill=8/decode=24 作为最终配置。

调度策略说明

waiting queue:
  - prefill 阶段最多调度 prefill_batch_cap 个请求
  - 若请求 prompt_len >= 4096，且已有 decode 请求正在运行，则延后该 prefill
  - 同一 batch 中 long-context 请求数不超过 long_context_max_batch

running queue:
  - decode 阶段最多调度 decode_batch_cap 个请求
  - 同样遵守 long-context batch 上限

该策略将稳定性保护集中在真正的长输入 prefill 上，同时避免短输入、长输出请求被不必要地串行化。对于普通短/中输入请求，decode 阶段可以使用更大的 batch cap 提升吞吐；对于真正长输入请求，则避免其 prefill 与正在执行的 decode 阶段叠加到不安全的瞬时显存峰值。

结果文件与审计

原始详细日志：/root/autodl-tmp/bench-results-official-8b/*.log
vLLM 原始 JSON：/root/autodl-tmp/bench-results-official-8b/*.json
参数扫描结果：/root/autodl-tmp/bench-results-param-scan/
PR 测试截图：随 PR 描述一并上传，包含设备信息、服务健康状态、baseline/before 与 optimized/after 结果矩阵。
实验全过程记录：doc_extern/实验过程记录与卡点分析.md

最后 6 个测试矩阵点已由 doc_extern/run_remaining_official_8b.sh 顺序完成；所有点均有日志或 JSON 可追溯。

PR内容包括：

修改文件：python/infinilm/llm/scheduler.py
赛题报告：T2-1-2_伊里斯_赛题报告.md

测试结果截图

HONOR_CODE.md

2026 春季启元人工智能大赛诚信守则（Honor Code）

本人作为 2026 春季启元人工智能大赛（以下简称"比赛"）的参赛选手，郑重承诺严格遵守比赛规则及本诚信守则，秉持诚信、公正、廉洁的参赛原则，自觉维护比赛的公平性与严肃性。本人充分理解并认可，违反本准则将导致参赛资格被取消、比赛成绩作废等相应后果，且愿意承担由此产生的一切责任。

一、参赛诚信承诺

本人保证所提交的赛题PR（Pull Request）中包含的算子实现代码及相关文档，均为本人（及参赛团队，如为团队参赛）在比赛期间独立完成或在明确标注参考来源的基础上进行开发，不存在任何欺诈、抄袭、作弊行为。
本人承诺主动、全面、真实地披露赛题实现过程中所有参考的外部资源，尤其是开源代码资源，不隐瞒任何可能影响比赛公平性的信息。
本人保证不采用任何不正当手段获取比赛优势，包括但不限于窃取其他参赛选手的代码成果、利用非比赛允许的工具或技术、与他人串通作弊等。

二、参考资源说明

本人确认已按比赛要求，将本次赛题实现过程中涉及的参考资源信息单独撰写至REFERENCE.md文件中，该文件将与本诚信守则一同作为PR附件提交。REFERENCE.md需根据实际参考情况，按以下要求完整填写，信息不完整或虚假填写将视为违反本准则：

情况1：无参考外部开源代码及核心实现思路

REFERENCE.md中需明确声明："本次赛题提交的算子代码、核心算法逻辑及实现方案均为本人（及参赛团队）独立设计与开发，未参考任何外部开源项目、技术文档中的核心代码片段或实现思路，未接受任何第三方的技术指导或代码支持。"

情况2：有参考外部开源代码及相关资源

对每个参考资源提供以下信息陈述：

参考开源项目/资源名称
参考资源链接（GitHub/Gitee/论文/技术文档等）
参考的具体内容（请明确说明参考的代码片段、算法逻辑、实现思路等，需标注对应资源的具体位置，如文件路径、代码行数等）
本人对参考内容的修改与优化说明：（请详细说明在参考基础上，本人所做的独立开发、修改、优化工作，体现自身技术贡献）
若是开源项目，提供参考资源的开源协议类型：（如MIT、Apache 2.0、GPL等）
其他需要补充说明的信息

三、禁止行为确认

本人明确知晓并承诺避免以下违反比赛公平性的行为，若存在以下任一情况，自愿接受比赛组委会的相应处罚：

未经授权复制、抄袭他人（包括其他参赛选手、开源项目、商业代码）的代码、算法或技术方案，且未进行明确标注；
隐瞒或虚假披露参考资源信息，包括遗漏重要参考来源、伪造参考内容说明等；
与其他参赛选手或第三方串通，进行代码共享、成果交换等违规协作；
利用比赛平台漏洞、技术缺陷或非比赛允许的工具获取不正当利益；
伪造比赛相关证明材料、提交虚假信息；
其他违反比赛规则及公序良俗的不诚信行为。

四、责任与确认

本人充分理解，比赛组委会将对所有提交的PR进行代码溯源、参考信息核查等公平性审查，若发现本人存在违反本准则的行为，有权随时取消本人的参赛资格、作废比赛成绩，情节严重的将在比赛相关平台进行公示。
若因本人违反本准则导致比赛争议或第三方权益受损（如开源协议侵权等），本人将独立承担全部法律责任及相关损失，与比赛组委会无关。
本人确认已仔细阅读并完全理解本诚信守则的全部内容，自愿签署本准则，接受比赛组委会的监督与审查。

五、签署信息

参赛选手姓名：李源，王柯翰，狄凡瑞

签署日期：2026年7月12日

REFERENCE

本次提交未复制外部开源项目的核心实现代码。优化工作基于比赛提供的 InfiniLM 仓库现有调度器实现，在 python/infinilm/llm/scheduler.py 内进行小范围修改，并通过 vLLM benchmark 工具进行服务能力测试。

1. 比赛提供的 InfiniLM 仓库

资源名称：InfiniLM
资源链接：比赛官方仓库 / 本次 PR 所在仓库
参考内容：python/infinilm/llm/scheduler.py 中已有 waiting/running queue、Paged Attention KV cache admission、prefill/decode scheduling 流程。
修改与优化：在原有调度流程上增加可配置的 prefill/decode 分相位 batch cap、长输入 batch 保护、decode-first 保护；未引入外部项目代码。
协议：以比赛仓库原协议为准。

2. vLLM benchmark serve

资源名称：vLLM benchmark serve
资源链接：https://github.com/vllm-project/vllm
参考内容：使用 vllm bench serve 作为压测工具，采集 TTFT、TPOT、ITL、吞吐等指标。
修改与优化：未修改 vLLM 源码，仅使用其命令行工具进行性能评估。
协议：Apache-2.0。

3. AI工具

资源名称：OpenAI Codex，Claude Code
资源链接：https://openai.com/codex
参考内容：用于协助整理实验记录、分析 benchmark 结果、撰写报告，并辅助生成小范围代码改动方案。
修改与优化：最终代码与实验决策均由参赛团队确认；
协议：不涉及开源代码复用。

[T2-1-2]伊里斯_commit

a6e21ff

DiFanrui requested a review from a team July 12, 2026 03:10

DiFanrui added 2 commits July 13, 2026 01:15

format scheduler

612571f

run ruff format on scheduler

072bafa

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[2026春季][T2-1-2]DiFanrui#495

[2026春季][T2-1-2]DiFanrui#495
DiFanrui wants to merge 3 commits into
InfiniTensor:mainfrom
DiFanrui:2026-spring-DiFanrui-T2-1-2

DiFanrui commented Jul 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

并发数	输入长度（tokens）	输出长度（tokens）
1, 4	32, 256, 4096	256, 1024, 4096
16, 64	32, 256	256, 1024, 4096

Uh oh!

Conversation

DiFanrui commented Jul 12, 2026

伊里斯-赛题报告

摘要

环境与复现

优化内容

问题与验证

边界与解释

8B 测试矩阵运行结果

单并发基线与 decode 稳定性

并发基线与故障复现

参数扫描：排除不可靠路径

优化迭代与消融

长输入保护的两次迭代

分相位 batch cap

调度策略说明

结果文件与审计

PR内容包括：

测试结果截图

HONOR_CODE.md

2026 春季启元人工智能大赛诚信守则（Honor Code）

一、参赛诚信承诺

二、参考资源说明

三、禁止行为确认

四、责任与确认

五、签署信息

REFERENCE

1. 比赛提供的 InfiniLM 仓库

2. vLLM benchmark serve

3. AI工具

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant