Measure what uses the 141 GB
This Hopper configuration has 141 GB of HBM3e memory. Break down your needs between persistent data, temporary workspaces and the memory consumed by each active task. For an inference service, test in particular long requests and simultaneous arrivals: a daily average easily masks the peaks that determine sizing.
Set an admission limit for jobs based on your measurements. The goal is to know the volume your application accepts, then keep a margin for its variations. A model that loads correctly has not yet proven that it can handle your operating rate.
Migrate from an 80 GB configuration
First replay the same dataset and the same parameters as in your previous environment. Then increase one factor at a time: batch size, input length or concurrency. This way you can attribute a change in results to its cause and hand over an understandable procedure to the next team.
H100 or H200: choose according to the constraint
An 80 GB H100 SXM remains an alternative if your workload and its margin already fit within that envelope. The H200 becomes particularly worth considering when per-card capacity is the bottleneck. Memory alone, however, does not allow you to predict how long a computation will take: keep an identical protocol when comparing configurations.
Give each period a goal
Over 3 days, prepare a reception focused on memory spikes. Over 7 days, organize several passes representative of your team's schedule. Over 30 days, set up regular checks and result exports rather than waiting until the end of the period.
Rental is prepared by choosing the duration, lots and environment, then providing the order contact. Each lot corresponds to one H200. Keep the summary together with your acceptance criteria so you can easily reconcile the capacity ordered with the work actually planned.