判断 Ling 3.0 Flash 能不能接某批任务，顺序比结论重要：先把待办拆到单次请求能完成的颗粒度，再从自己的请求记录里量出单条响应耗时分布，最后用目标请求速率乘单条耗时换算并发预算。颗粒度没拆清楚时，延迟和并发都无从讨论——同一条“摘要”需求，输入几十字和输入几千字，耗时和失败表现完全不是一个量级。下面按这个顺序给出可以直接照做的方法，涉及的数字都要用你自己的日志和环境配置量出来。

适合放进 Ling 3.0 Flash 的，通常是输入不长、输出可控、单轮能完成、格式要求宽松的任务，例如短文本分类、字段抽取、回复润色、意图识别、短摘要。判断顺序建议是：先拆任务颗粒度，再用请求日志量 P50/P95 单条耗时，然后用目标请求速率乘单条耗时估并发，最后把长链推理、超长输入、强格式约束的任务挑出去，改成更大参数档模型或拆成多步编排。延迟和并发都要以自己环境里量到的分布为准，别人的经验值只能当参考。

把待办任务拆成单次请求能完成的颗粒度

先把候选待办列成三列：输入长度、期望输出长度、是否需要多轮。三列都偏小的任务，才值得进入轻量模型的候选池；任意一列超标，先拆任务，再谈选型。填写时用定性描述加自己的粗略估计即可，不必精确到 token。

最后一行这类任务不要直接丢给轻量模型，拆成两步更稳：第一步只抽取当前工单的关键字段，第二步用抽取结果匹配处理动作。拆完后每步的输入输出都变小，才重新回到“是否适合轻量档”的判断上。

在请求记录里量出单条响应耗时分布

延迟基线只能从自己的调用记录里来。建议在调用包装层打点，至少记录这些字段：请求标识、请求发出时间、首 token 返回时间（流式才需要）、完整响应结束时间、状态码与超时标记、重试次数、输入长度、输出长度。字段用途是——首 token 时间反映用户感知到的“开始有反应”，完整响应时间用于算并发，输入输出长度用于后续分桶。

{"req_id":"a1","ts_start":1710000000.120,"ts_first_token":1710000000.480,"ts_end":1710000001.640,"in_chars":420,"out_chars":96,"status":"ok","retry":0}

取样条数上没有硬标准，建议覆盖一个完整的业务高峰时段，攒到几百条再做统计，条数太少时分位数会被个别慢请求带偏。统计方式很简单：只取成功请求，按“结束时间减发出时间”排序，取 P50 看典型体验，取 P95 或 P99 看尾部波动。下面这段脚本读上面的记录文件，可按需替换文件名和字段。

import json
rows = [json.loads(l) for l in open('req.jsonl', encoding='utf-8') if l.strip()]
ok = [r for r in rows if r['status'] == 'ok']
lat = sorted(r['ts_end'] - r['ts_start'] for r in ok)

def pct(xs, p):
    if not xs:
        return None
    k = (len(xs) - 1) * p
    lo = int(k)
    hi = min(lo + 1, len(xs) - 1)
    return xs[lo] + (xs[hi] - xs[lo]) * (k - lo)

print('n=', len(lat), 'P50=', round(pct(lat, 0.50), 3), 'P95=', round(pct(lat, 0.95), 3))

同一份脚本建议按输出长度分桶再跑一遍：输出几十字和输出几百字，单条耗时往往差出明显一截。后续算并发时，要用最重那一桶的耗时，而不是全局平均。

按输出长度反推每秒可承接的请求量

把延迟换算成并发预算，用这个近似公式：可用并发 ≈ 目标 QPS × 单条耗时（秒）。含义是在维持目标请求速率的前提下，平均同时在途的请求数。下面用一组自造数字演示代入过程，数字仅用于说明算法，实际要换成你自己量到的值。

target_qps = 5        # 假设的业务峰值请求速率，按自己的监控填
p95_latency = 1.2     # 假设的单条 P95 耗时（秒），来自上一节统计
concurrency = target_qps * p95_latency
print(round(concurrency, 2))        # 6.0
print(round(concurrency * 1.5, 2))  # 9.0，留出波动余量后的舒适并发

代入过程：目标 5 QPS、单条 1.2 秒，5 乘 1.2 得到约 6 条在途请求；再乘 1.5 的余量，得到约 9 条。这里的 1.5 是余量系数，用来吸收 P95 之后的尾部慢请求和重试，不是性能改善手段。如果输出较长的任务单独跑一遍，同样 5 QPS、单条耗时假设为 3 秒，算出的在途请求会到 15 条左右，这时要么限制此类任务的速率，要么单独排一档容量，不要和短任务混在同一个并发池里。平台侧的速率限制和超时设置需要结合环境确认，公式给出的只是你这一侧的估算。

标出必须换更大模型或多步编排的任务

出现下面这些特征时，建议把任务从轻量档移出，或改成多步编排：需要长链推理才能得出结论，比如多条件比对、排除法诊断；输入超长且信息分散在多段，比如整本手册、完整会话历史；对输出格式有强约束，比如必须严格符合某个 JSON 结构、字段顺序、枚举值，一旦格式错就整条链路失败；需要多跳检索或工具的，比如先查库存再算价格。替代做法有几类：把长链拆成“抽取—判断—生成”多步，每步单独调用并加规则校验；把格式约束改成“模型出内容 + 本地校验修正”，校验不过就重试或降级；对确实需要长上下文的场景，换更大参数档模型，或先用检索把输入缩到单段。判断标准不是模型好坏，而是单次请求能不能稳定收敛。

把结论写成一页选型对照表

把上面几步的判断落成一张表，评审时按行过一遍即可。判断理由一列写清触发条件，方便后续复核。

表格填完后，回到第二节的请求记录再核一遍：候选行是否都在你量到的延迟和并发预算之内，超标的那几行就按第四节的办法移出或拆分。选型不是一次定终身，任务颗粒度或输出长度变了，这张表也要跟着改。