明确能证明您租赁合理性的交付成果
对于文件处理，要定义要遍历的数据量、输出格式和续跑规则。一个已完成的文件应当无需重读整个执行过程就能被识别。对于交互式服务，要定义请求的最大规模、可接受的时延以及容量达到上限时的行为。同一个模型根据这些约束可能需要两种截然不同的组织方式。
保留一个有代表性的样本，其中包含短的、常规的以及接近你上限的用例。在嵌入流水线中，把每个向量与其输入的标识符和版本关联起来。在文本生成中，记录用于评估的生成参数。你应当能够解释结果的差异，而不是立刻把它归因于 GPU。
为完整的推理负载选择内存
模型文件的权重并不能描述推理过程中使用的全部内存。还需要考虑临时张量、输入、保留的输出，以及对于相关模型而言，注意力机制的键值缓存。当序列变长或同时处理多个请求时，该缓存可能会变得很大。
先从一张内存足以在可衡量余量下完成代表性试跑的显卡开始。24、32、48、80 GB 及以上的型号满足不同的需求；没有任何一种容量能保证某个给定模型在其全部设置下都能跑通。降低精度或量化可能改变内存占用，但必须验证软件支持情况以及在你自己的输入上的输出质量。
选择与您软件链兼容的 GPU
在选择硬件之前，先列出推理引擎、其特殊算子以及你所依赖的扩展。一个 PyTorch 应用可能提供多条执行路径，而一个专用扩展只支持其中一条。要在 NVIDIA 的 CUDA 或 AMD 的 ROCm 上验证整条链路，包括模型加载及其预处理。
保留一条能贯穿整个流水线直到写出结果的最小命令。只有在此之后，才逐一启用你的优化。每一次精度、编译或引擎的更改都应保持可比的质量检查。加载成功只证明权重可读，并不证明所有必要的计算路径都能正常工作。
根据您的处理目标调整批量大小
方法示例：按长度把文本分成三组，然后分别以批大小为 1、2 和 4 的输入进行处理。这些大小只是试跑点，并非通用建议。对每种组合，记录已完成的输入、总耗时、观测到的最大内存以及错误。当出现上限时就停止推进，而不是把失败掩盖在平均值里。
对于交互式服务，还要加上在队列中等待的时间。更大的批处理可能改变吞吐量和一个请求所感受到的时延；仅凭一个平均值不足以做出选择。对于离线处理，要确保分组不会打乱结果的顺序。最终选择一种既满足你的质量准则又满足时延约束的配置。
如果您的应用能够分配工作，就扩展到多块 GPU
如果模型的每一份副本都能装进一张卡，你可以组织多个工作进程，各自消费输入的不同分区。此时需要协调标识符、续跑和结果收集。如果模型必须分散到多张卡上，就使用你的引擎所支持的并行策略，并核对其通信要求。
所订购的批次描述的是硬件数量，而非应用层批次或合并后的内存空间。对于B200，一个批次包含两张卡；对于其他方案，一个批次包含一张卡。请在您的方案中列明计划的工作进程数量、每个进程承担的输入份额，以及如何确认某项工作确实已经完成。
选择一段包含检查与导出的时长
首次租用3天时，请设定一个有限的目标：安装、验证流水线并产出第一个可用的结果。7天的时长可用于尝试更多变体；30天则可用于重复某项处理并巩固其运行。这些只是组织工作的方式，并非对执行时限的承诺。
输出时，请保留权重或其版本、配置、质量检查、实际获得的指标以及导出的结果。您可自主选择软件和处理方式；Kernodeck 不会对其内容进行检查。请自行准备好访问凭据、备份，以及使用模型和数据所需的授权。