首页 / 文章 / 在单个 H200 GPU Droplet 上微调 LLM Ornith 9b:成本、延迟和服务开销
← 返回
IT技术

在单个 H200 GPU Droplet 上微调 LLM Ornith 9b:成本、延迟和服务开销

✍️ zhirenhun 📅 2026/8/9 👁 191 阅读 ⏱ 18 分钟
在单个 H200 GPU Droplet 上微调 LLM Ornith 9b:成本、延迟和服务开销

我们对 Ornith-1.0-9B 进行了微调,这是一个来自 DeepReinforce AI 的开源 9B agentic 编码模型,在一个包含 61,000 个示例的推理-摘要数据集上,使用了 DigitalOcean 上的单个 H200 GPU Droplet。目标是:不将模型的完整原始思维链展示给最终用户,而是让微调后的模型在生成正常输出的同时,生成其推理的结构化摘要(标题、副标题、通俗语言摘要和当前任务字段)。

具体来说,这次微调改变的是模型推理的呈现方式,而不是模型的内在任务性能。我们并不声称这里提高了准确性、更好的工具使用或更强的 agentic 行为。那需要完全不同的评估方式。我们可以用真实数据展示的是训练成本、服务延迟与吞吐量,以及最关键的一点:这些是否以推理性能为代价。

并没有。下面会有更多说明。

为什么构建这个

构建面向用户的 agentic 产品的模型提供商通常会在两个糟糕的默认选项之间做选择:完全隐藏推理过程,这使得调试和建立信任更加困难;或者将原始思维链直接抛给用户,而思维链通常冗长、重复,有时还包含你不希望逐字呈现的信息。一个能够原生生成干净、结构化推理摘要的模型,无需单独的摘要步骤或第二次模型调用,是一条值得用真实数据验证的中庸之道。

从抽象层面看,这并非新奇的想法,但其背后有一个值得测试的具体主张:为现有 agentic 模型添加这一行为,是否会在服务时带来任何成本?从推理角度来看,改变输出格式而非输出内容的微调通常被认为“免费”。我们想确认这一点,而不是凭空假设;与未修改的基线的完整对比见下文结果。

训练设置:在单个 H200 上使用 LLaMA-Factory 微调 Ornith-1.0-9B

Ornith-1.0-9B 是 DeepReinforce AI 的 Ornith-1.0 系列中最小的检查点,该系列是一组开源的、MIT 许可的模型,专门为 agentic 编码而构建(该系列还包括 31B dense、35B MoE 和 397B MoE 检查点)。它是一个 dense 9B 模型,在 Qwen 3.5 之上进行了后训练,并且足够小,可以在单个 80GB GPU(约 19GB VRAM)上以 bf16 运行。该系列在架构上的独特之处不在于大小,而在于训练方法:Ornith-1.0 没有将模型与固定的人工设计的 agent 框架配对,而是通过强化学习训练模型在构建解决方案的同时构建自己的脚手架,并联合优化两者。DeepReinforce 报告称,该 9B 模型在 Terminal-Bench 2.1 上达到 43.1,在 SWE-Bench Verified 上达到 69.4,尽管规模较小,但在类似基准测试上匹配或超越了更大的开源模型。我们的微调不会改变这些;我们不会触及脚手架生成行为或编码性能,只会改变模型向最终用户展示其推理的方式。

数据集 SupraLabs/reasoning-summaries-61k 包含 61,000 个示例,专门用于训练模型生成清晰、结构化的推理链摘要,而不是暴露原始思维链。每个示例都配对了原始推理轨迹和摘要版本,以及结构化字段(标题、副标题、摘要、当前任务)。该数据集基于明确署名且已获许可的上游来源构建,而非抓取或专有数据,这对于任何评估是否复现的人来说都很重要:数据谱系可追溯,许可条款在开始时便已知。

我们使用 LLaMA-Factory 在单个 H200 GPU Droplet 上运行微调。

超参数
学习率 5e-5
学习率调度器 cosine
轮次 3.0
批大小 2(有效 16,使用梯度累积)
梯度累积 8
最大梯度范数 1.0
截断长度 10,200
计算类型 bf16

训练结果与成本

指标
轮次 3.0
已见 Token 数 75,092,496
总 FLOPs 3.790 × 10¹⁸
最终训练损失 0.550
运行时间 88,831 秒(约 24.7 小时)
样本/秒 2.06
步骤/秒 0.129

按照 $3.44/小时(单个 H200),24.675 小时总计为 $84.88,即可对全部 61K 示例数据集进行三轮微调。这是完整的训练成本,而非估算(仅计算运行时;请注意,DigitalOcean 按秒计费 GPU Droplet,并且在 Droplet 关机期间继续计费,因此在销毁 Droplet 之前,资源创建和空闲时间会单独计费)。无论创始人接下来会问什么(我们能负担得起尝试吗,实际账单是多少),这个数字都能回答。

服务设置:在同一个 H200 上使用 vLLM 与 DigitalOcean Bring Your Own Model

我们使用DigitalOcean的“自带模型”服务,将微调后的模型部署在同一个H200 Droplet上,在兼容OpenAI的端点后面运行vLLM

为了测量延迟和吞吐量,我们构建了一个小型异步基准测试工具:它使用asyncio.gather发起一批并发请求,解析流式服务器发送事件响应,以记录每个请求的首令牌时间(TTFT)和每秒令牌数(TPS),并报告每请求和聚合吞吐量。我们在并发级别1、5和20下各运行了五次试验,并在任何计时试验之前都进行了显式的预热请求。

测试中出现的两件事值得直接指出,因为它们影响了我们对结果的解读。首先,在新的并发级别上的首次运行显示的TTFT远高于同级别的后续每次运行(并发级别5的首次命中为0.691秒,而之后每次运行约为0.035秒)。这与vLLM处理CUDA图捕获的方式一致:它首次看到给定批次大小时会编译执行图,然后缓存。对一个批次大小的预热传递不会预热你计划服务的所有批次大小。如果你在为自己的部署做基准测试,请在打算测试的每个并发级别进行预热,而不仅仅是在开始时预热一次。

其次,在微调模型上,总共100个请求中(每次20个并发请求的5次试验)有1个请求返回了零个令牌,这是彻底的失败而非减速。我们没有查明这是客户端超时还是服务器端在负载下的拒绝。我们将其报告出来,而不是将其从平均值中平滑掉,鉴于样本量,我们将其视为一个悬而未决的问题,而非确定的结论。

推理结果:1、5和20个并发请求下的TTFT和吞吐量

微调模型

并发 平均TTFT 平均TPS/请求 聚合吞吐量
1 0.021s 187.63 tok/s 187.63 tok/s
5 0.036s 178.94 tok/s 894.69 tok/s
20 0.047s 159.05 tok/s 3,181.02 tok/s

(并发级别5的数据排除了上述冷启动试验;并发级别20的数据包含那次失败的请求。)

一旦服务器预热,TTFT从单请求一直到20个并发请求都保持接近平稳,范围在20至47毫秒之间。每请求吞吐量在20倍并发时下降约15%(从187.63降至159.05令牌/秒),而聚合吞吐量大约扩展17倍(从187.63升至3,181.02令牌/秒)。这就是对任何规划容量的人来说重要的权衡:每请求适度减速,以换取总吞吐量的大幅提升。

微调模型与基础模型对比

我们针对未修改的基础Ornith-1.0-9B模型运行了完全相同的基准测试,相同的提示词、相同的硬件,每个并发级别进行相同的五次试验。

并发 指标 基础模型 微调 差值
1 TTFT 0.022s 0.021s ~0%
1 TPS 187.41 187.63 +0.1%
5 TTFT 0.036s 0.036s ~0%
5 TPS 178.48 178.94 +0.3%
20 TTFT 0.046s 0.047s ~2%
20 TPS 160.62 159.05 -1.0%
20 聚合 3,212.34 3,181.02 -1.0%

这里的每个差异都落在基础模型自身试验间变异的噪声范围内(仅其并发级别20的TTFT在五次试验中就在0.043秒至0.051秒之间波动)。简而言之:微调Ornith-1.0-9B以生成结构化推理摘要,在我们测试的任何并发级别上都没有增加可测量的服务开销。

有一个值得标记而非过度强调的数据点:基础模型在并发级别20下最差的单请求TPS读数为133.94令牌/秒(是减速,不是失败),而微调模型在同一并发级别下出现了一次零令牌失败。由于在该负载级别下每个模型只有100个请求,这还不足以说明微调导致了失败,或者它与基础模型偶尔的减速有任何关联。这是一个悬而未决的问题,而非结论。

实际变化:前后对比

上述数字表明微调在服务时不会产生任何额外成本。它真正改变的,是输出本身的形态。以下是针对两个模型运行的相同提示词(“二氧化碳排放如何影响现代生活?”)。

基础模型:

基础Ornith-1.0-9B暴露原始的、非结构化的思维链

未修改的模型将其完整推理过程暴露为一段冗长、自由格式的“思考”块:在最终给出答案之前,包含编号步骤、嵌套项目符号点,以及对语气、目标和结构的连续评论。它是可读的,但很原始。面向用户的产品要么必须完全隐藏它,要么将其原样发布,而这种非结构化文本的长度不可预测。

微调模型:

微调后的Ornith-1.0-9B生成结构化的JSON推理摘要

微调后的模型在收到相同提示词时,返回的则是一个单一的结构化对象:

{
  "title": "CO2 Impact Analysis",
  "sub_title": "Exploring how carbon dioxide emissions influence daily life and the environment.",
  "summary": "I'm considering how carbon dioxide exhaust influences modern life, focusing on environmental and health effects. I plan to examine air quality, climate impacts, and policy responses to provide a comprehensive overview.",
  "cur_task": "I'm thinking about how carbon dioxide emissions affect everyday life and the environment."
}

根据 SupraLabs/reasoning-summaries-61k 数据集卡,这是微调模型被训练生成的确切结构:一个 title 和一个 sub_title 作为推理步骤的简短、人类可读的标题,一个 summary 概括实际的推理内容,以及一个 cur_task 字段,用于命名模型当前正在执行的任务。与其呈现一整面嵌套推理的墙,UI 可以渲染一个标题和一行状态,按需展开摘要,并且完全不显示原始轨迹。

相同的底层任务、相同的模型系列,以及(根据上述基准测试)相同的延迟和吞吐量特征。区别完全在于推理结果是以松散的文本形式到达,还是以一个小型、可预测的对象形式到达,前端可以实际基于该对象进行构建。

何时使用此方法,何时不使用

如果你希望模型在不暴露完整思维链的情况下,向用户提供透明的推理过程,并且希望在确定生产环境中的并发目标之前获得真实的成本和延迟数据,请使用此方法。

不要将此作为任务准确性或智能体可靠性提高的证据。此微调改变的是输出格式,而不是任务性能,我们在此未对后者进行测量。

来源与延伸阅读

——

🧑‍💻

zhirenhun

一个热爱技术的程序员,喜欢分享前沿AI知识和开发经验。

← 上一篇
为什么你的 vLLM p99 延迟在生产环境暴涨,以及分块预填充和调度如何解决
下一篇 →
让AI代理在无服务器推理中感知更快

📌 相关推荐

GraphRAG 是推理问题,而非数据库问题
2026/8/30
构建市场时光机:使用 Python 和 WebSocket 重放交易会话
2026/8/30
如何自行基准测试LLM推理:值得信赖的数字设计标准
2026/8/30
← 返回文章列表