端边云协同账：任务放本地、边缘还是云端

同一个推理任务，放在手机/边缘盒子上、还是送到云端 GPU 上？答案不是"云端更强"，而是四笔账的联合比较：延迟账、效果账、成本账、带宽账。本文把"放哪里"变成可复算的决策流程，方法框架参考开源书稿《深入理解 AI Infra》（Apache-2.0），公式与算例为本站自行推导整理。

1. 先立框架：四笔账联合，不是单点最优

账	本地（端侧小模型）	云端（大模型）
延迟	本地推理延迟（毫秒级）	传输 RTT + 云端排队 + 云端推理
效果	小模型质量（按参数量折损）	大模型质量（基准）
成本	一次性硬件 + 电费	GPU 时租 × 用量
带宽	不出网	上传原始数据（音视频/长文本）

核心判断：四笔账的权衡点随负载变化——延迟敏感且数据量大 → 本地；质量敏感且利用率高 → 云端。

2. 延迟账：找交叉点

端侧推理延迟与"网络来回 + 云端推理"谁大，是放置决策的第一关：

$$T_{local} = T_{infer}(small), \quad T_{cloud} = RTT + T_{queue} + T_{infer}(large) + T_{upload}$$

场景	本地（端侧）	云端路径	结论
语音唤醒/翻译	10-50 ms	RTT 50-200 ms + 排队	本地（交互必须毫秒级）
长文本总结	秒级（小模型）	1-2 s（含传输）	看质量差，见效果账
视频理解	逐帧本地	上传视频耗时 数倍于推理	先本地抽帧/压缩（见带宽账）

判断：交互型任务（每步都要等结果）延迟预算通常 <100ms，本地是唯一选择；离线批处理才谈得上云端。

3. 效果账：质量换延迟与成本

端侧受限于功耗与内存，模型通常小 1-2 个数量级。效果差异无法精确量化，但可用参数量作为质量代理做决策参考：

$$Quality\_proxy = f(N_{params}), \quad 7B \ vs \ 70B: 规模 10×，质量差随任务难度放大$$

• 简单任务（分类、唤醒、模板问答）：小模型损失可接受 → 本地；
• 复杂任务（长文推理、多轮对话、代码）：质量差不可接受 → 云端，或用 分布式推理账 的 PD 分离把重活留给云端大模型。

判断：先按任务难度定"质量底线"，低于底线的一律云端，别在效果上省成本。

4. 成本账：买硬件 vs 租 GPU 小时的盈亏平衡

端侧部署是固定成本，云端是按量成本。盈亏平衡点：

$$BreakEven = \frac{Hardware\_cost}{Cloud\_cost\_per\_hour \times utilization}, \quad 超过平衡点继续租更划算$$

变量	示例
边缘推理盒子（含开发）	5000-20000 元
云端 GPU 推理时租	20-60 元/小时
平衡点	100-1000 小时 ≈ 4-40 天满负荷

关键变量是利用率：日活低、请求稀疏的任务，租比买划算得多（见 GPU 利用率账）；7×24 高负载才考虑自建。

5. 带宽账：先处理再上传

大数据量负载（视频、音频、图片流），上传原始数据的带宽成本常常超过推理本身：

$$Upload\_time = \frac{Data\_size}{Uplink\_BW}, \quad 本地预处理后可压缩 10-100×（抽帧/降采样/转写）$$

例：1 小时 1080p 视频 ≈ 5-10 GB，10Mbps 上行要 1-2 小时；本地先抽关键帧/转成文本，上传量降到 MB 级——这是"端侧预处理 + 云端推理"混合架构的量化理由。

6. 可复算 Python 函数

def placement_decision(local_ms, cloud_rtt_ms, cloud_queue_ms, cloud_ms,
                       data_gb, uplink_mbps, hw_cost, cloud_cost_h, daily_hours):
    """端边云四账联合：延迟对比、上传耗时、盈亏平衡（天）"""
    t_local = local_ms
    t_cloud = cloud_rtt_ms + cloud_queue_ms + cloud_ms + data_gb*8e3/(uplink_mbps/1000*60)
    upload_min = data_gb * 8 * 1000 / uplink_mbps / 60
    breakeven_days = hw_cost / (cloud_cost_h * daily_hours)
    return {"cloud_total_ms": round(t_cloud,1), "upload_min": round(upload_min,1),
            "breakeven_days": round(breakeven_days,1),
            "verdict": "local" if t_local < t_cloud else "cloud"}

placement_decision(local_ms=40, cloud_rtt_ms=80, cloud_queue_ms=50, cloud_ms=300,
                   data_gb=0.001, uplink_mbps=10, hw_cost=8000, cloud_cost_h=40, daily_hours=4)
# cloud_total_ms=430.1 → 本地 40ms 完胜 → verdict=local
# breakeven_days=50 天满负荷后自建才划算

7. 交付清单

1. 先定延迟预算：交互型 <100ms 一律本地；批处理再看其余三笔账；
2. 按任务难度定质量底线，低于底线的不在效果上省钱；
3. 用利用率算盈亏平衡：日活低租、7×24 自建；
4. 大数据量负载先本地预处理（抽帧/转写），把上传量降 10-100×；
5. 混合架构（端侧预处理 + 云端大模型 + PD 分离）通常是三笔账的联合最优解。

---

本文为本站自行推导整理，方法框架参考开源书稿《深入理解 AI Infra》（Apache-2.0）；具体版本号与实测数据以现场为准。