端云协同大模型推理架构

CH-10-03-060·约 18 分钟·大模型·更新 2026-08-11

想象你走进一家“智慧餐厅”：见习服务员站在餐桌旁，递水、撤盘、记菜名利落又迅速，但真要让他做佛跳墙就抓瞎；后厨的总厨手艺精湛，却远在厨房里，菜品做好还要经过传菜通道慢慢送出来。聪明的餐厅会让服务员处理轻活、把复杂菜式交给总厨，双方通过一条高效的传菜通道协作——这就是端云协同大模型推理架构的缩影。手机、智能音箱、汽车就是“见习服务员”，它们靠近用户、响应快，但算力有限；云端的大模型则是“总厨”，能力强大但离用户远、响应慢。端云协同要做的事，就是让两者分工合作：简单任务在端侧秒回，复杂任务交给云端处理，同时用通信优化、任务分配、模型分层等手段，让整家“餐厅”又快又省又稳。本文会用大白话讲清楚这套架构的核心原理和工程落地要点。

岗位关联

对 AI 从业者来说，掌握端云协同能让你在真实产品中同时兼顾低延迟与强算力，是构建高可用推理系统的关键能力，也是边缘 AI 岗位的必备认知。

可视化演示
边缘计算基础
端云协同概念
任务分配策略
模型分层部署
通信优化技巧
体验成本平衡
工程实践路径
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示端云协同架构拓扑、任务路由决策流程与延迟成本对比，含端侧/云侧推理路径与负载均衡策略，支持模式切换。

本节配有交互动效（进入视口后自动加载，约 3KB）。

端云协同推理架构端侧处理简单低延迟任务云侧处理复杂高算力任务 Edge ↔ Cloud 端云协同通过任务分流实现低延迟与强算力平衡

边缘计算基础

智慧餐厅里，见习服务员站在餐桌旁，递水、撤盘、记录需求都又快又近，顾客几乎不用等。他们虽然不会做佛跳墙，却用“近”这个优势消化了大部分高频轻活。边缘计算也是一样：把计算放在手机、路由器、基站等离用户最近的设备上，让低延迟成为可能。

过去，大模型都住在远方的中心机房，手机上的每个请求都要跨越几十毫秒甚至几百毫秒的网络，才轮到云端回答。边缘计算改变了这种“凡事都问总厨”的做法，它利用端侧芯片完成一部分推理，让简单问题在用户身边就地解决，网络再好也快不过“当面回答”。

但边缘计算不是万能的。手机 NPU 虽然能跑几 B 参数的小模型，内存、功耗、散热却限制了它承载百亿参数大模型。边缘计算的价值在于“近而轻”：用轻量模型覆盖高频、实时、隐私敏感的任务，把难题留给更强大的云端。

正如见习服务员用轻活撑起前厅体验，边缘计算先把简单高频推理挡在本地，让用户明显感到“秒回”，也为更精细的端云分工埋下伏笔。

\displaystyle T_{\text{total}} = \frac{C_{\text{edge}}}{P_{\text{edge}}} + \frac{M}{B} + T_{\text{cloud}}

公式解读：一次任务的总延迟等于端侧算力耗时、网络传输耗时和云端耗时之和，想降低延迟就要从这三项分别下手。

总延迟T_total 表示一个请求从发起到拿到结果的整体时间，是衡量推理体验的核心指标。
$\displaystyle T_{\text{total}} = T_{\text{edge}} + T_{\text{net}} + T_{\text{cloud}}$
端侧处理时间C_edge 是端侧承担的计算量，P_edge 是端侧算力，二者相除得到端侧本地耗时。
$\displaystyle T_{\text{edge}} = \frac{C_{\text{edge}}}{P_{\text{edge}}}$
网络传输时间M 是端云之间传输的数据量，B 是带宽，传输时间等于数据量除以带宽。
$\displaystyle T_{\text{net}} = \frac{M}{B}$
云端兜底时间T_cloud 是云端大模型处理剩余计算所需的时间，通常与模型大小和输入复杂度有关。
$\displaystyle T_{\text{cloud}} = f(C_{\text{cloud}},\;P_{\text{cloud}})$

端云协同概念

真正的智慧餐厅里，服务员和总厨不是各干各的，而是共用一套传菜流程和菜单。端云协同也是这样：它不是“转发请求”这么简单，而是把一次推理任务拆成端侧能做的部分和云侧擅长的部分，让两边像同一组齿轮一样咬合运转。

拆开看，端云协同是把“算在哪里”变成“各自算哪一部分”。常见模式有三种：端侧部署完整小模型，拿不准时再让云端大模型兜底；模型按层切分，浅层特征在端侧算完，中间结果交给云端继续；端侧先做上下文压缩或预处理，再上传精简后的数据，云端只负责最重的生成。

这种协同的价值在于优势互补。端侧提供低延迟、隐私保护和离线能力，云端提供强大算力和知识广度，二者合起来才是一个完整的 AI 服务。端云协同的目标，就是让每一项任务都找到最佳执行地点，同时让系统整体有更低的延迟和更平滑的体验。

当服务员知道哪些事自己能拍板、哪些要请总厨，并且能把“半成品”顺畅送进后厨时，这家餐厅才真正实现了协同。

\displaystyle \min_{C_e,C_c}\Big[T_{\text{edge}}(C_e)+T_{\text{comm}}(m)+T_{\text{cloud}}(C_c)\Big],\quad C_e+C_c=C

公式解读：端云协同让端侧处理量 C_e 和云端处理量 C_c 分配最优，目标是使端侧耗时、通信耗时和云端耗时之和最小。

目标函数min 表示我们要找一个合理的任务切分方案，让总时间尽量短。
$\displaystyle \min_{C_e,C_c}\Big[T_{\text{edge}} + T_{\text{comm}} + T_{\text{cloud}}\Big]$
端侧部分T_edge(C_e) 是端侧承担计算量 C_e 时花费的时间，C_e 越大，端侧越忙。
$\displaystyle T_{\text{edge}}(C_e) = \frac{C_e}{P_{\text{edge}}}$
通信部分T_comm(m) 是中间数据 m 在端云之间传输的时间，m 越小，通信越快。
$\displaystyle T_{\text{comm}}(m) = \frac{m}{B}$
云端部分T_cloud(C_c) 是云端处理计算量 C_c 所需的时间，云端算力强但仍有耗时。
$\displaystyle T_{\text{cloud}}(C_c) = \frac{C_c}{P_{\text{cloud}}}$
计算量守恒C_e 与 C_c 之和等于总计算量 C，切分方案不能删减任务本身。
$\displaystyle C_e + C_c = C$

任务分配策略

顾客说“再拿双筷子”，服务员立刻照办；说“来一份佛跳墙”，她马上转告总厨。但判断不能只凭固定菜名，还要看门店忙不忙、传菜通道堵不堵。任务分配策略要解决的就是：“这个请求该端侧答，还是该云端答？”

技术实现上，系统先给每个输入打一个“复杂度分数”：指令很短的可以走端侧，长文本、多轮复杂推理则倾向于云端。常见策略包括按难度分流，简单任务留在端侧；动态决策，根据实时延迟和成功率调整阈值；离线兜底，没网时端侧小模型继续服务；负载感知，云端过载时主动把请求留在端侧。

实际工程里最常用的是动态阈值。系统统计最近请求的平均延迟，与目标延迟比较，如果云端太慢，就把阈值调高，让更多请求留在端侧；如果端侧错误率升高，又适当降低阈值，请云端大模型把关。这个阈值就像餐厅排班表，随客流和菜品情况不断调整。

动态任务分配就像餐厅副总管站在前厅，哪条队伍短、哪个后厨忙，他一眼扫过去就能调度，让整家店始终有人在服务、有人在做硬菜。

\displaystyle D(x)=\begin{cases}\text{edge}, & s(x) < \theta \\\text{cloud}, & s(x) \ge \theta\end{cases}

公式解读：对请求 x 计算一个难度分数 s(x)，与阈值 θ 比较后决定由端侧还是云端执行。

决策函数D(x) 表示请求 x 的最终路由去向，输出是“端侧”或“云侧”。
$\displaystyle D(x) \in \{\text{edge},\;\text{cloud}\}$
难度分数s(x) 是对输入复杂度的估计，比如问题长度、语义难度、上下文长度。
$\displaystyle s(x) = w_1 \times L_x + w_2 \times N_x$
阈值比较θ 是分配阈值，s(x) 低于 θ 表示任务足够简单，可以在本地完成。
$\displaystyle s(x) < \theta \Rightarrow \text{edge}$
动态调整θ 可以根据目标延迟和当前平均延迟的差距持续更新，保证系统适应流量波动。
$\displaystyle \theta_{t+1} = \theta_t + \eta\,(L_{\text{target}} - L_{\text{avg}})$

模型分层部署

总厨做佛跳墙时，后厨早就备好高汤和半成品配料；出餐口也放着提前装好的常用酱料。这种“半成品前置”让最终出餐快了很多。模型分层部署就是这个思路：把大模型的一部分计算搬到端侧，让端侧做“预加工”，云端只做“最后工序”。

实现时，团队会把一个 Transformer 大模型按层切开：端侧运行 Embedding 和前几层，输出中间向量；这个向量通过网络传给云端，云端继续运行剩余层并生成最终结果。端侧像一个“特征提取器”，云侧像一个“推理引擎”，两者通过分割点衔接。

分割点放在第几层，决定了端侧算力压力、通信量和云端负担。放得越靠前，端侧越轻松但传的数据量越大；放得越靠后，端侧越吃力但传输量越小。工程上还会对端侧层做量化、剪枝、蒸馏，让端侧轻量模型更快；云端保留完整精度，作为重载模型响应复杂任务。

备餐台放多少半成品，要看传菜通道多宽、后厨多忙；模型分割点放哪一层，也要看带宽够不够、端侧算力强不强。

\displaystyle T(k)=T_{\text{end}}(k)+\frac{S(k)}{B}+T_{\text{cloud}}(n-k)

公式解读：模型总层数为 n，端侧部署前 k 层，云端部署剩余 n-k 层，总延迟由端侧计算、中间状态传输和云端计算三部分组成。

分层总延迟T(k) 表示选择第 k 层作为分割点时，整个请求的端到端延迟。
$\displaystyle T(k) = T_{\text{end}}(k) + T_{\text{comm}}(k) + T_{\text{cloud}}(n-k)$
端侧浅层计算T_end(k) 是端侧跑前 k 层所花时间，k 越大端侧耗时越高。
$\displaystyle T_{\text{end}}(k) = \frac{k \times C_{\text{layer}}}{P_{\text{edge}}}$
中间状态传输S(k) 是第 k 层输出的中间向量大小，S(k)/B 是传到云端所需时间。
$\displaystyle T_{\text{comm}}(k) = \frac{S(k)}{B}$
云端深层计算T_cloud(n-k) 是云端运行剩余 n-k 层所需时间，层数越多耗时越大。
$\displaystyle T_{\text{cloud}}(n-k) = \frac{(n-k) \times C_{\text{layer}}}{P_{\text{cloud}}}$

通信优化技巧

服务员不会为了一瓶酱油往返厨房三次，她会顺便把邻桌的菜也端上；老顾客常点的菜，她也提前记在心里。端云通信也一样，要用尽可能小的代价完成“传菜”。

端云协同中最贵的往往不是算力，而是频繁的中间数据传输。通信优化就是从“少传、少跑、少算”三个方向下手。数据压缩对中间激活做量化，把浮点数变成低位整数，减少字节数；增量传输只传发生变化的部分，不重复传全量内容；请求合并把多个用户的请求打包成一个 batch，一次传输批量处理；本地缓存把高频问题的答案存在端侧，下次直接命中。

这些优化叠加起来效果非常明显。压缩比越高，单位带宽能传的有效信息越多；缓存命中率越高，真正走到云端的请求就越少。通信优化不是单纯换大带宽，而是帮系统“少说话、说重点”。

一次上齐几道菜、熟客菜单提前记好，传菜通道的压力自然小；端云通信优化也是让数据“少跑几趟、轻装上路”。

\displaystyle T_{\text{comm}}=\frac{M_0}{r \cdot B}

公式解读：原始数据量 M_0 经过压缩比 r 压缩后，实际传输时间等于压缩后数据量除以带宽。

通信时间T_comm 表示端云之间完成一次中间结果传输所需时间。
$\displaystyle T_{\text{comm}} = \frac{M}{B}$
原始数据量M_0 是未压缩前的中间特征或请求数据大小。
$\displaystyle M_0 = \sum_{i} m_i$
压缩比r 表示压缩后数据变为原来的 1/r，例如 r=4 表示数据被压到四分之一。
$\displaystyle M = \frac{M_0}{r}$
带宽利用B 是有效传输带宽，带宽越大，同样的压缩数据传得越快。
$\displaystyle T_{\text{comm}} = \frac{M_0}{r \cdot B}$

体验成本平衡

如果餐厅为了快，把所有菜都提前做好放在桌上，菜会凉；为了省钱都让总厨现做，顾客又会等急眼。真正的经营要在出餐速度和备料成本之间找平衡点。端云协同也面临同样问题：体验越好，往往成本越高；成本压得越狠，体验可能下降。

体验端要关注延迟指标：P50、P95、P99 延迟，以及超时率和兜底成功率；成本端则要考虑云端 GPU 算力费用、网络带宽费用、端侧功耗和电池损耗。端侧处理会消耗用户设备的电，云端处理会消耗厂商的算力，两者都存在“账单”。

工程上，团队会根据业务定义一条综合代价曲线：给延迟超标设置惩罚分，给每次推理设置成本分，再乘以权重求和。延迟敏感的 VIP 请求可以更“大方”地上云，低频低价值的请求则尽量本地消化。必要时启动服务降级，复杂能力暂时不可用，也要保证基础功能不中断。

好的餐厅会根据顾客贵贱和食材成本调整菜单；好的端云架构也会根据用户价值和系统压力，用一条动态曲线切换“奢侈模式”和“经济模式”。

\displaystyle \min \big(\omega_1 U + \omega_2 C\big)

公式解读：系统的目标是让用户体验惩罚 U 和资源成本 C 的加权和最小，权重 ω 由业务优先级决定。

优化目标min 表示我们希望找到一个同时照顾体验和成本的分配方案。
$\displaystyle \min \big(\omega_1 U + \omega_2 C\big)$
体验惩罚U 是延迟超时、请求失败等带给用户的负面影响，越大说明体验越差。
$\displaystyle U = \frac{N_{\text{timeout}}}{N_{\text{total}}}$
资源成本C 是云端算力、带宽、端侧能耗等资源支出的总和。
$\displaystyle C = C_{\text{cloud}} + C_{\text{bandwidth}} + C_{\text{energy}}$
权重系数ω1 和 ω2 表示产品更看重体验还是更看重成本，权重由业务定位决定。
$\displaystyle \omega_1 + \omega_2 = 1,\quad \omega_1,\omega_2 \ge 0$

工程实践路径

一家店要开得长久，得先试营业、记录出餐数据、安排安全巡检，再逐步优化菜单。端云协同的落地也是这样，不能一上来就切模型、搞复杂调度，而要小步快跑、持续迭代。

第一步是架构选型。先明确业务场景：是智能音箱、手机助手，还是车载系统？不同场景对延迟、隐私、成本的要求完全不同。初期可以采用最稳的“端侧小模型 + 云端大模型兜底”模式，跑通后再逐步尝试分层部署和动态路由。

第二步是监控调优。上线后要盯住端云请求成功率、P95 延迟、端侧功耗、云端成本等指标，用 A/B 测试验证每次改动是否真的有收益。第三步是安全隐私：隐私敏感数据尽量在端侧完成脱敏和特征提取，云端只接收必要信息，同时做好端侧模型加密和更新校验。最后是演进路线，从简单转发到动态阈值，再到模型切分和局部微调，让系统能力稳步提升。

试营业期间的每个数据、每次用户抱怨，都是调整菜单的依据；端云协同系统也要靠监控数据和故障复盘，把架构越养越成熟。

\displaystyle \text{SLO达标率}=\frac{N_{\text{ok}}}{N_{\text{total}}}\times 100\%

公式解读：服务水平目标达标率是满足延迟或成功率目标的请求数占总请求数的比例，是端云协同上线后最重要的健康指标。

达标率定义SLO 达标率衡量系统在目标范围内的稳定程度，越高越好。
$\displaystyle \text{SLO达标率} = \frac{N_{\text{ok}}}{N_{\text{total}}} \times 100\%$
达标请求数N_ok 表示在目标延迟内成功返回结果的请求数量。
$\displaystyle N_{\text{ok}} = \sum_{i=1}^{N_{\text{total}}} I(L_i \le L_{\text{target}})$
总请求数N_total 是统计周期内端云协同系统处理的所有请求数量。
$\displaystyle N_{\text{total}} = N_{\text{edge}} + N_{\text{cloud}}$
百分比换算乘以 100% 让达标率变成更直观的百分比指标。
$\displaystyle \text{SLO达标率} \to [0,100]$

AI 应用场景

手机智能助手

阶段：推理路由与端云协同

解决的问题：传统手机助手把每句话都传到云端，网络稍差就卡顿，隐私也令人担心；现在端侧小模型负责唤醒、简单指令和本地知识问答，复杂创作、长文总结才调用云端大模型。

具体案例：手机用户说“帮我设个明天早上八点的闹钟”，端侧模型秒级完成；说“帮我写一份年终总结”，系统自动把请求路由到云端大模型生成，完成后返回手机。

智能座舱助手

阶段：分层推理与离线兜底

解决的问题：车辆行驶在隧道或山区时网络不稳定，云端服务可能断连；通过端云协同，车端模型处理导航、空调控制、本地语音识别等高实时任务，云端负责多模态问答和复杂路线规划。

具体案例：驾驶员在无网络的地下车库说“打开座椅加热”，车端小模型立即执行；在高速路上询问“前方服务区有什么餐厅”，云端大模型联网回答并返回。

可穿戴健康监测

阶段：端侧筛选 + 云端精查

解决的问题：手表手环不适合一直联网，也不应把心率、血氧等隐私数据全部上传；端侧模型先做异常检测，只有发现可疑信号时才把脱敏特征发给云端做深入分析。

具体案例：智能手表检测到用户心率持续偏高，端侧模型触发告警，并把 10 秒的心率波形特征压缩上传，云端大模型判断是否需要就医提醒。

Python 演示

python42 行

# -*- coding: utf-8 -*-"""端云任务分配路由器的简化模拟。""" class EdgeCloudRouter:    def __init__(self, threshold=0.6, edge_cost=0.2, cloud_cost=1.0):        self.threshold = threshold        self.edge_cost = edge_cost        self.cloud_cost = cloud_cost        self.stats = {"edge": 0, "cloud": 0, "latency": []}     def route(self, complexity, network_quality):        # 复杂度分数低于阈值，或网络质量差时，留在端侧        if complexity < self.threshold or network_quality < 0.3:            return "edge"        return "cloud"     def handle(self, requests):        for req in requests:            target = self.route(req["complexity"], req["network_quality"])            self.stats[target] += 1            if target == "edge":                latency = req["complexity"] * self.edge_cost            else:                latency = req["complexity"] * self.cloud_cost + 0.5            self.stats["latency"].append(latency)        return self.stats def main():    requests = [        {"complexity": 0.2, "network_quality": 0.9},        {"complexity": 0.9, "network_quality": 0.8},        {"complexity": 0.7, "network_quality": 0.1},        {"complexity": 0.4, "network_quality": 0.6},    ]    router = EdgeCloudRouter(threshold=0.6)    result = router.handle(requests)    print("路由结果:", result)    avg_latency = sum(result["latency"]) / len(result["latency"])    print("平均延迟:", avg_latency) if __name__ == "__main__":    main()

目的：模拟一个根据请求复杂度和网络质量决定路由的端云协同分配器，并统计端侧、云端请求数与平均延迟。

self.threshold = threshold保存判断请求走端侧还是云侧的阈值，是任务分配的核心参数。
def route(self, complexity, network_quality)定义一个路由决策函数，输出目标是端侧还是云端。
if complexity < self.threshold or network_quality < 0.3简单任务或弱网条件下强制留在端侧，体现“离线兜底”思想。
self.stats[target] += 1统计每种路由选择的次数，方便后续观察分配比例。
latency = req["complexity"] * self.cloud_cost + 0.5给云端请求额外加上固定网络耗时，模拟通信成本。
sum(result["latency"]) / len(result["latency"])计算平均延迟，用于评估整体服务质量。

常见误区

误区端侧算力那么弱，不如把每个请求都发给云端大模型，反正云端效果最好、最稳定。

正解把所有请求都丢给云端，就像让服务员只会喊“总厨你来”，顾客多等一会儿，总厨也会忙到崩溃。端侧处理大量简单请求，既降低响应时间，又减少带宽和云端算力成本；同时弱网或离线场景下，端侧是唯一能继续服务的保障。

为何常见：大家默认“大模型越强越好”，忽略了延迟、成本和可用性才是真实系统的核心约束。

误区觉得端云协同只是在手机里存一些云端返回的结果，命中缓存就直接用，没命中就照旧上云。

正解缓存只是通信优化中的一种手段，真正的端云协同还包括任务路由、模型分层部署、动态阈值和离线兜底。它强调的是端侧和云侧各自承担一部分智能计算，而不是简单地把云端的答案“抄一份”存在本地。

为何常见：因为缓存最容易理解，而且确实能提升体验，容易让人把“局部优化”误当成“整体架构”。

误区把一个大模型从中间切开，端侧跑一层、云端跑一层，中间结果一定损失信息，模型效果肯定不如完整云端模型。

正解如果分割点设计合理，端云传送的是连续层之间的中间激活，信息并未被“截断”，云端后半段可以正常接续计算，精度几乎不受影响。真正影响精度的是端侧量化、蒸馏等压缩手段，而这些可以通过校准和微调来弥补。

为何常见：人们习惯把“切分”和“裁剪”混为一谈，其实分层部署是分工而非删减。

误区5G 和千兆光纤普及后，上传下载又快又稳，直接把数据传到云端处理不就行了，端侧模型纯属多余。

正解网络再快也快不过本地直连，而且快不等于免费、不等于稳定。带宽提升只改善 T_net，但端侧处理能同时降低云端成本、保护隐私、支持离线场景。信号抖动、漫游、地铁隧道里，端侧兜底仍然是不可替代的安全网。

为何常见：人容易高估技术的理想状态，低估真实网络环境中的波动和成本。

误区小模型推到手机里，架构就定型了，之后只需要维护云端大模型。

正解端侧模型也会遭遇数据漂移和业务变化，需要定期更新。但端上更新要考虑包体积、发版节奏、用户设备碎片化等问题，所以工程上常采用“热更新 + 监控回滚”策略。持续迭代才是常态，上线只是开始。

为何常见：大家把端侧模型想象成普通 App 安装包，忽视了模型更新对延迟、兼容性和耗电的连锁影响。

面试题

Q1. 端云协同的核心优势是什么？

单选题 · easy

A.让端侧完全替代云端
B.平衡低延迟与云端算力← 正确答案
C.降低所有网络速度
D.只需要一个边缘服务器

答案：B。端云协同追求的是“端侧做轻活、云端做重活”，让简单任务获得低延迟，复杂任务获得强算力，两者互补。A 错在端侧无法完全替代云端，C 是反向理解，D 只提到了边缘服务器，忽略了协同。

Q2. 端侧最擅长处理哪类推理任务？

单选题 · easy

A.频繁的小规模推理← 正确答案
B.千亿参数长文本生成
C.海量语料预训练
D.全量微调大模型

答案：A。端侧算力和内存有限，适合高频、轻量、实时性强的推理任务，比如唤醒词、简单问答和系统控制。长文本生成、预训练和全量微调都需要强大算力，必须交给云端或专用集群。

Q3. 以下哪些属于端云协同的通信优化技巧？

多选题 · mid

A.对中间结果做量化压缩← 正确答案
B.只传输增量变化← 正确答案
C.将多个请求合并发送← 正确答案
D.无限增大云端带宽

答案：ABC。压缩、增量传输和请求合并都是减少传输数据量或交互次数的手段。D 属于单纯堆资源，既不经济也没有解决“少传”的本质问题。

Q4. 动态阈值分配策略中，阈值上调的主要效果是什么？

单选题 · mid

A.更多请求留在端侧← 正确答案
B.更多请求送往云端
C.模型精度必然提高
D.带宽消耗必然增加

答案：A。根据 D(x) 规则，s(x) < θ 走端侧。阈值 θ 上调后，更多请求满足小于 θ 的条件，因此更多请求会留在端侧。B 与条件相反，C 和 D 与阈值调整没有必然因果关系。

Q5. 模型分层部署中，分割点选择主要受哪些因素影响？

单选题 · mid

A.端侧算力和通信带宽← 正确答案
B.只有云端 GPU 数量
C.用户界面的颜色
D.训练数据的大小

答案：A。分割点决定端侧计算多少层、中间状态传多大、云端剩余多少层，因此受端侧算力和通信带宽共同影响。云端 GPU 数量只影响一部分，C 和 D 与分割点无关。

Q6. 端云协同体验与成本平衡时，需要考虑哪些成本？

多选题 · hard

A.云端 GPU 算力成本← 正确答案
B.端侧电池功耗成本← 正确答案
C.网络带宽费用← 正确答案
D.员工培训费用

答案：ABC。云端算力、端侧能耗和网络带宽是端云协同中直接相关的三类成本，它们共同决定每次请求的边际开销。员工培训属于团队建设成本，不在推理架构的成本模型内。

Q7. 离线兜底机制的目标是什么？

单选题 · mid

A.网络断开时端侧模型继续服务← 正确答案
B.让云端永不响应
C.替换所有云端模型
D.删除本地缓存

答案：A。离线兜底是在网络不可用时，由端侧小模型接管基础服务，保证用户核心功能不中断。它不排斥云端，而是作为弱网和断网场景的安全网。

Q8. 本地缓存主要优化端云协同中的哪个环节？

单选题 · easy

A.减少重复请求的通信量← 正确答案
B.增加模型参数量
C.加快云端训练
D.提高输入数据复杂度

答案：A。本地缓存命中后直接返回已有结果，减少了端云之间的重复通信，也降低了云端负载。它不改变模型参数，也不影响训练过程和输入复杂度。

Q9. 端云协同工程实践中应关注哪些运维指标？

多选题 · hard

A.端云请求成功率← 正确答案
B.P95 推理延迟← 正确答案
C.端侧设备功耗← 正确答案
D.单一模型参数量

答案：ABC。成功率、P95 延迟和端侧功耗分别反映可用性、体验和资源开销，是迭代调优的核心观测项。模型参数量是设计时的静态配置，不是运维指标。

Q10. 在总延迟公式 T_total = T_edge + T_net + T_cloud 中，以下哪项不一定能降低总延迟？

单选题 · hard

A.增加端侧处理工作量
B.降低网络传输数据量
C.提升云端模型精度← 正确答案
D.压缩端云通信内容

答案：C。A 如果合理分担可能降低 T_cloud，B 和 D 直接降低 T_net，都能压总延迟。C 提升云端精度可能引入更大模型和更长计算时间，反而可能增加 T_cloud，因此不一定降低总延迟。