一、项目背景

这个项目的客户是一家已经私有化部署了大模型底座的集团企业，八张推理卡支撑着智能客服、知识问答等在线服务。问题出在他们的离线任务上：运营部门每天要给几万条商品评论打标签、法务要批量摘要合同、数据团队要跑周期性的报告生成——这些非实时任务全都挤在工作时间调同一套推理服务。白天在线客服高峰期，批量任务把 GPU 打满，客服问答的 P99 延迟从两秒飙到十几秒；而凌晨到早八点，整个集群利用率不足 15%，八张卡在那里空转。运维试过用"错开时间跑脚本"的土办法约束各部门，坚持不了两周就名存实亡。

我们的判断是：这不是算力不够，是负载没有分类管理。我们基于所采用的 AI 私有化部署底座的算力调度监控层，为客户搭建了一套离线批处理与错峰调度体系，让在线保时延、离线保吞吐，项目周期约两个月。

二、落地场景

改造后的使用方式是这样的：各部门的批量任务不再直接调推理接口，而是向批处理队列提交任务包——一个任务包包含任务清单（如三万条评论）、使用的模型与提示词模板、期望完成时间（截止时间）。调度器把任务包拆成分片，在算力闲时窗口（主要是 22:00 到次日 8:00，以及工作日午间的低谷）下发执行，完成后回调通知提交方，结果落到对象存储供下载。

在线与离线的算力隔离通过两级机制实现：常态下离线任务只允许使用"在线水位线以上的剩余算力"，调度器每 30 秒读一次在线服务的负载指标，动态调整离线并发；夜间窗口则反过来，离线任务可以占到集群的 85%，只保留一小片算力兜底夜间零星的在线请求。批推理本身也做了吞吐优化：同一任务包内的请求按输入长度分桶组批，充分吃满连续批处理的吞吐；对打标签这类短输出任务，把采样参数改为贪心解码，单卡吞吐又抬了一截。

对任务提交方，我们给了明确的服务分级：标准任务承诺 24 小时内完成，加急任务 4 小时（占用配额加倍计量），超大任务（百万级条目）按协商窗口执行。每个部门的批量用量单独计量，月底出账。

三、关键技术挑战与解决思路

第一个挑战是截止时间保障与闲时窗口的矛盾。夜间窗口只有十小时，如果当天提交的任务总量超过窗口产能，就必然有任务违约。我们做了两层防护：提交时调度器按当前队列深度和历史吞吐估算预计完成时间，超过截止时间的直接在提交阶段拒绝并提示可选窗口，而不是收下再违约；执行期每小时重估一次全队列的完成时间，发现风险就把临近截止的任务提升优先级，必要时向白天的剩余算力借用配额。原则是"少接单不违约"。

第二个挑战是失败分片的重跑与幂等。批量任务跑到一半，某个分片因为显存碎片或单条超长输入失败是常态。我们把分片设计成幂等单元：每个分片有确定性的分片键，重跑时按分片键覆盖写结果，不会产生重复条目；单条失败不拖垮分片，坏行记录到隔离区，任务完成报告里明确列出成功、失败、隔离三类计数。运营同事最初对"隔离区"不理解，直到有一次三万条评论里混进了两百条超长文本，隔离机制让任务按时完成了 99% 而不是整体卡死，他们才接受了这个设计。

第三个挑战是错峰调度和在线突发的冲突。凌晨偶尔也有在线流量（海外用户、定时任务触发的问答），离线占着 85% 算力时在线请求会排队。我们在网关层给在线请求设了抢占标记：在线队列等待超过阈值，调度器立即暂停若干离线分片释放算力，离线分片本身支持中断续跑（进度按条目持久化），抢占的代价只是几分钟的吞吐损失。

案例片段（已脱敏）：错峰调度器的核心配置——yaml scheduler:  probe_interval_s: 30  online_watermark:            # 在线水位线    daytime:  { gpu_util: 0.55, offline_max_share: 0.25 }    night:    { window: "22:00-08:00", offline_max_share: 0.85 }  preempt:    online_queue_wait_ms: 3000    action: pause_offline_shards(n=4)  batch:    bucket_by_input_len: [512, 1024, 2048, 4096]    greedy_decode_for: [tagging, extraction] deadline:  admission_check: estimated_finish <= deadline  reestimate_interval_h: 1压测记录：打标签类任务分桶组批后，单卡吞吐从约 1400 tokens/s 提到约 3100 tokens/s；一次凌晨在线突发触发抢占，暂停 4 个分片释放算力，在线 P99 在 40 秒内回落到正常水位。

四、效果数据

上线三个月后的数据（脱敏示意值）：GPU 夜间利用率从不足 15% 提升到约 72%，全天平均利用率从 38% 提升到 61%；在线服务白天 P99 延迟稳定在 2.5 秒以内，批量任务引发的在线延迟劣化事件归零；批任务按时完成率约 98.5%，提交阶段被拒绝改约的任务占比约 6%（这些原本都会成为违约单）；折算下来，相同业务量下等效算力成本下降约三成，原计划的扩卡采购推迟了两个季度。各部门月度用量账单上线后，两个"用量大户"部门主动优化了提示词长度，单任务 token 消耗降了约 20%。

五、可复用经验总结

第一，在线和离线负载必须分类管理，混跑的结果是时延和吞吐两头都得不到保障。第二，错峰是最便宜的扩容，买卡之前先看夜间利用率。第三，截止时间承诺的关键在准入控制——接单时就算清楚能不能按时交付，少接单永远好过违约。第四，批量任务要按分片设计幂等和隔离，让失败局部化，坏数据进隔离区而不是拖垮整批。第五，用量计量要到部门，账单是最有效的成本优化驱动力，比任何行政通知都管用。