Commit f74fdc9
[misc]: surface GenerationResult.peak_memory_mb in the MiniMax H3 examples
Every generation already computes its own peak. The worker calls
torch.cuda.max_memory_allocated() at multiproc_executor.py:699 and the
value reaches the caller as GenerationResult.peak_memory_mb, but both H3
examples print only the generation time and drop it.
On a memory-constrained device that number is the one that decides whether
a configuration runs at all, and it is what a reader has to reproduce to
check any memory claim about this model. Right now they cannot: the field
is populated, handed over, and discarded.
examples/inference/optimizations/spark_benchmark.py already prints it, so
this only brings the H3 examples in line.
Two lines each, guarded on the value being present, so nothing changes for
a backend that does not report it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>1 parent a159b63 commit f74fdc9
2 files changed
Lines changed: 7 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
343 | 343 | | |
344 | 344 | | |
345 | 345 | | |
| 346 | + | |
| 347 | + | |
| 348 | + | |
346 | 349 | | |
347 | 350 | | |
348 | 351 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
114 | 114 | | |
115 | 115 | | |
116 | 116 | | |
| 117 | + | |
| 118 | + | |
117 | 119 | | |
118 | 120 | | |
119 | 121 | | |
120 | 122 | | |
| 123 | + | |
| 124 | + | |
121 | 125 | | |
122 | 126 | | |
123 | 127 | | |
| |||
0 commit comments