企业官网建设流程全解析

1. AI算力需求正在经历一场静默的迁移

过去两年，大家聊算力，聊的都是训练。千卡集群、万卡集群、MFU（模型浮点运算利用率）能拉到多少、通信带宽够不够、checkpoint 写盘会不会把存储打爆。这些话题在技术社区里反复出现，几乎成了某种“算力叙事”的默认框架。但如果你最近半年真正在业务侧落地过 AI 功能，会发现一个明显的变化：推理侧的算力消耗正在以远超训练的速度膨胀。训练是一次性的、集中的、可规划的；推理是持续的、分散的、随用户行为波动的。一个日活百万的 AI 应用，光是对话推理的日常算力开销，就可能超过当初训练这个模型本身的成本。

这个变化带来的直接后果是，传统的“集中式算力供给”模式开始显得力不从心。你把所有推理请求都发回中心机房，网络延迟先吃掉一截体验，带宽成本再吃掉一截利润，遇到流量高峰还得临时扩容，扩完高峰过去资源又闲置。端脑科技提出的“云边端协同算力体系”，本质上就是在回应这个问题：不是把所有算力堆在一个地方，而是让算力分布在云、边、端三个层级上，各司其职，动态调度。

这篇文章不打算复述端脑科技的官方 PR 稿，而是从一个实际做 AI 系统架构的从业者视角，拆解这套体系背后的技术逻辑、关键设计点、落地时会踩的坑，以及如果你自己团队要参考这套思路，应该从哪几个维度入手。适合正在做 AI 应用架构、推理优化、边缘计算部署的工程师和产品负责人阅读，也适合对算力成本敏感、想搞清楚“推理算力到底该怎么省”的团队参考。

2. 为什么集中式推理架构越来越撑不住

2.1 推理负载的三个本质特征

训练负载和推理负载在工程特性上几乎是两种东西。训练追求的是吞吐和稳定性，任务可以排队、可以重试、可以容忍分钟级的延迟。推理追求的是响应时间和并发能力，用户发一条消息，期望是秒级甚至毫秒级返回，而且请求量随时间段剧烈波动。

具体来说，推理负载有三个特征值得单独拎出来说。

第一是潮汐性。早上通勤时段、午休时段、晚间时段，请求量可能是凌晨的几十倍。你按峰值配置中心算力，低谷时资源利用率可能不到 10%；你按均值配置，峰值时用户直接排队超时。

第二是地理分散性。用户分布在全国甚至全球各地，请求从不同城市发出，统一回传到一个中心节点，物理距离带来的网络延迟是绕不过去的。光在光纤里跑，每 1000 公里单向延迟大约 5 毫秒，来回就是 10 毫秒，这还没算路由跳数和拥塞。

第三是模型异构性。一个 AI 产品里往往不止一个模型。对话用大语言模型，图像生成用扩散模型，语音识别用另一个模型，还有各种小模型做意图分类、敏感内容过滤。不同模型对算力的需求差异巨大，有的吃显存，有的吃算力，有的吃内存带宽。全部塞进同一个中心集群，调度复杂度会指数级上升。

2.2 集中式架构的成本结构正在恶化

我拿一个实际测算过的场景来说明。假设一个 AI 对话产品，日活 50 万，人均每天 20 轮对话，每轮对话平均输入 200 token、输出 300 token。按当前主流开源大模型 7B 量化版本的推理开销来算，单次推理大约需要 0.5 到 1.5 秒的 GPU 时间（取决于批处理效率）。一天的总推理请求是 1000 万次，折算下来需要大约 1400 到 4200 GPU 小时的日算力。

如果全部放在中心云上，按按需实例价格算，一天的推理成本可能在数万元级别。这还没算网络出口带宽费用。而如果能把其中 60% 到 70% 的请求下沉到边缘节点或端侧处理，中心云只需要承担复杂推理和兜底流量，成本结构会完全不同。

注意：这里的关键不是“边缘一定比中心便宜”，而是“不同层级的算力单位成本不同，把合适的任务放在合适的层级上，整体成本才最优”。边缘节点的单卡算力成本可能比中心云高，但它省掉了带宽和延迟成本，综合账要一起算。

2.3 云边端协同要解决的核心矛盾

端脑科技这套体系要解决的核心矛盾，可以概括为一句话：推理需求的分散性与算力供给的集中性之间的不匹配。

云侧有大规模、弹性、但昂贵的算力；边侧有靠近用户、低延迟、但规模有限的算力；端侧有零边际成本、隐私友好、但算力碎片化的资源。三者单独看都有明显短板，但协同起来，就能形成一个互补的算力网络。

这个思路并不新鲜，CDN 就是内容分发领域的云边端协同。但 AI 推理比内容分发复杂得多，因为推理任务是有状态的、计算密集的、模型版本需要同步的。CDN 缓存一个静态文件，过期了重新拉取就行；推理任务涉及模型权重、KV Cache、会话状态，调度难度完全不是一个量级。

3. 云边端三层算力体系的技术拆解

3.1 云侧：复杂推理与全局调度的锚点

云侧在这套体系里的角色，不是“主力算力”，而是“锚点”。它承担三类任务。

第一类是复杂推理任务。比如长上下文对话、多模态推理、需要调用外部工具的 Agent 任务。这些任务对算力要求高，对延迟相对不敏感，放在云侧最合适。端脑科技如果采用类似 vLLM 的推理引擎，云侧可以部署完整精度或 FP16 精度的大模型，利用 PagedAttention 做高效的 KV Cache 管理，支撑高并发。

第二类是全局调度与模型管理。云侧需要维护所有边缘节点和端侧设备的模型版本、算力状态、网络质量，并根据实时负载做任务分发。这需要一个中心化的调度器，但调度决策不能太“重”，否则会成为瓶颈。常见做法是云侧只做粗粒度调度，比如按地域、按模型版本、按任务类型分发，细粒度调度交给边缘节点自己做。

第三类是兜底与弹性扩容。当边缘节点过载或不可用时，请求回落到云侧。云侧的弹性伸缩能力是整套体系的最后一道防线。

从技术选型上看，云侧推理引擎需要考虑几个关键点：是否支持连续批处理（continuous batching）、是否支持量化推理（INT8/FP16）、是否支持多模型并行加载、是否有成熟的 OpenAI 兼容 API。目前社区里 vLLM、TensorRT-LLM、SGLang 都是常见选择，各有侧重。vLLM 的生态最成熟，TensorRT-LLM 在 NVIDIA 硬件上性能最优，SGLang 在结构化生成场景有优势。

3.2 边侧：低延迟推理的主力承载层

边缘节点是这套体系里最容易被低估的一层。很多人觉得边缘算力弱，只能做做预处理。但实际上，边缘节点的算力正在快速提升。一台配备 RTX 3090 或 RTX 4090 的边缘服务器，单卡算力已经可以支撑 7B 到 14B 参数模型的实时推理。如果做 INT8 量化，13B 模型在 3090 上跑出每秒几十 token 的输出速度是完全可行的。

边缘节点的核心价值在于物理距离带来的延迟优势。用户请求到同城边缘节点，网络延迟可以控制在 5 毫秒以内；到跨省中心节点，延迟可能是 30 到 50 毫秒。对于实时对话场景，这几十毫秒的差异用户是能感知到的。

端脑科技在边侧的设计，我推测会包含几个关键模块。一是模型热更新机制，边缘节点需要在不中断服务的情况下更新模型版本，这涉及到权重差分下载、双缓冲加载、灰度切换等工程细节。二是本地缓存与状态管理，多轮对话的 KV Cache 如果每次都要回传云侧，带宽开销太大，边缘节点需要本地维护会话状态。三是健康检查与自动降级，边缘节点检测到自身算力不足或模型异常时，要能自动把请求转发到云侧或其他边缘节点。

这里有一个实操中很容易踩的坑：边缘节点的 GPU 显存是有限的，如果你同时加载多个模型，显存碎片化会导致实际可用显存远小于理论值。我试过在一台 24GB 显存的机器上同时加载一个 7B 对话模型和一个图像分类模型，结果两个模型互相挤占，推理延迟波动很大。后来改成按需加载、用完卸载，虽然增加了加载时间，但稳定性好了很多。

3.3 端侧：碎片化算力的聚合与隐私边界

端侧算力是这套体系里最“野”的一块。手机、PC、IoT 设备，算力参差不齐，网络环境不稳定，用户随时可能关掉应用。但端侧有两个不可替代的优势：零边际成本和隐私天然隔离。

零边际成本很好理解。用户自己的设备跑推理，不消耗你的云上算力，你只需要提供模型和调度逻辑。对于轻量级任务，比如短文本分类、简单意图识别、本地敏感词过滤，端侧处理完全够用。

隐私天然隔离是端侧的另一张牌。有些用户对数据上云有顾虑，如果推理在本地完成，原始数据不出设备，只把脱敏后的结果回传，合规压力会小很多。这在一些对数据敏感的行业场景里是刚需。

但端侧推理的工程挑战也最大。首先是硬件碎片化，不同手机的 NPU 指令集不同，不同 PC 的 GPU 驱动版本不同，你要做一套能兼容大部分设备的推理运行时，工作量巨大。其次是模型压缩，端侧显存和内存都有限，模型必须做量化甚至剪枝，INT4 量化在端侧越来越常见。再次是任务拆分，哪些任务放端侧、哪些放边侧、哪些必须回云侧，这个决策逻辑需要根据设备能力动态调整。

端脑科技如果要在端侧落地，大概率会采用“端侧轻量模型 + 边侧中等模型 + 云侧大模型”的三级模型体系。端侧跑一个 1B 到 3B 的量化模型做快速响应，复杂请求转发到边侧或云侧。这样用户感知到的首 token 延迟可以做到很低，因为端侧先给出了一个“草稿”回答，后续再被更强大的模型修正或补充。

4. 协同调度的核心机制与实操要点

4.1 任务分级与路由策略

云边端协同的第一个核心问题是：一个推理请求来了，怎么决定它去哪一层？

端脑科技的做法，我推测是基于任务复杂度 + 延迟敏感度 + 隐私等级三个维度做分级。任务复杂度包括输入长度、输出长度、是否需要多步推理、是否涉及多模态。延迟敏感度包括用户场景是实时对话还是异步任务。隐私等级包括数据是否包含敏感信息、用户是否开启了本地处理选项。

具体路由策略可以用一个决策表来表示：

这个表不是固定的，实际运行中需要根据实时负载动态调整。比如边侧节点过载时，部分中复杂度任务可以上浮到云侧；云侧网络拥塞时，部分任务可以下沉到边侧。

实操心得：路由策略不要一开始就做得太复杂。我见过团队一上来就搞强化学习做动态路由，结果训练数据不够，策略震荡严重，还不如简单的规则引擎稳定。先用规则跑通闭环，积累足够多的线上数据后，再考虑用模型优化路由决策。

4.2 模型版本同步与一致性保障

云边端三层部署同一个模型的不同版本，版本同步是个大问题。云侧更新了模型权重，边侧和端侧怎么跟上？如果版本不一致，同一个问题在不同层级可能得到不同答案，用户体验会割裂。

常见的做法是版本号 + 灰度发布 + 回滚机制。每个模型版本有唯一的版本号，云侧作为版本源头，边侧节点定期拉取版本清单，发现新版本后按灰度策略逐步更新。端侧更新更谨慎，通常只在应用启动或用户主动触发时检查更新。

模型权重同步的带宽开销需要认真计算。一个 7B 模型的 FP16 权重约 14GB，INT8 量化后约 7GB。如果有 1000 个边缘节点，每次全量更新就是 7TB 的下载量。所以边侧更新通常采用差分更新，只下载变化的权重分片。这要求模型存储格式支持分片索引，safetensors 格式在这方面比较友好。

端侧更新还要考虑用户流量成本。不能默认用户愿意用手机流量下载几个 GB 的模型文件。通常的做法是只在 Wi-Fi 环境下更新，或者只更新轻量级的适配层（LoRA），基础模型保持不变。

4.3 算力状态感知与动态负载均衡

协同调度的基础是实时感知各层算力状态。云侧调度器需要知道每个边缘节点的 GPU 利用率、显存占用、当前排队请求数、网络延迟；边缘节点需要知道端侧设备的可用算力、电量状态、网络类型。

这些状态信息的采集频率和上报开销需要平衡。上报太频繁，网络和调度器压力大；上报太稀疏，调度决策滞后。我试过 5 秒一次的状态上报，在 1000 节点规模下，调度器每秒要处理 200 条状态更新，用 Redis 做状态缓存基本能扛住。如果节点规模上万，可能需要引入分层聚合，边缘节点先聚合端侧状态，再统一上报云侧。

负载均衡策略上，常见的做法是加权最小连接数 + 延迟感知。每个节点根据自身算力配置一个权重，调度器优先把请求发给当前连接数最少且延迟最低的节点。但要注意，推理任务不是无状态的，同一个会话的多个请求最好落到同一个节点，否则 KV Cache 无法复用，推理效率会大幅下降。所以调度器需要维护会话亲和性，把同一会话的请求绑定到同一节点。

5. 落地过程中绕不开的五个硬骨头

5.1 边缘节点的运维复杂度

边缘节点不像中心机房，有完善的监控、供电、散热、网络冗余。一个部署在社区机房或企业机房的边缘节点，可能面临网络抖动、电压不稳、灰尘堆积导致 GPU 过热等问题。你不可能给每个边缘节点配一个运维工程师。

所以边缘节点的设计原则是自治 + 远程管理。节点要能自己检测异常、自己重启服务、自己在网络恢复后重新注册。远程管理通道要轻量，通常用消息队列做指令下发，用对象存储做日志和模型分发。

我踩过的一个坑是：边缘节点的 GPU 驱动版本不一致，导致同一个容器镜像在不同节点上表现不同。后来统一了驱动版本基线，并且在节点注册时强制检查驱动版本，不匹配的节点直接拒绝接入调度池。这个检查看起来麻烦，但省掉了后面无数排查时间。

5.2 端侧推理的功耗与发热

端侧推理最大的限制不是算力，而是功耗和发热。手机跑一个大模型，CPU/GPU/NPU 满载几分钟，机身温度就能到 40 度以上，然后系统开始降频，推理速度断崖式下跌。用户感知到的就是“越用越卡”。

解决思路有几个方向。一是限制端侧推理的持续时间，单次推理不超过几秒，长任务自动切到边侧。二是动态调整模型精度，温度低时用 INT8，温度高时切到 INT4。三是利用 NPU 而非 GPU，NPU 的能效比通常比 GPU 高，但兼容性差，需要针对不同芯片做适配。

端脑科技如果要在端侧大规模落地，大概率会优先支持主流芯片平台（如高通、联发科、苹果），通过统一的推理运行时抽象层来屏蔽底层差异。这个抽象层的开发工作量很大，但一旦做成，就是很深的护城河。

5.3 云边端之间的数据一致性

三层架构下，数据一致性是个容易被忽视的问题。用户在端侧发起对话，中途切换到边侧继续，再切换到云侧，对话历史怎么同步？如果每层都维护自己的会话状态，切换时就需要做状态迁移。

常见的做法是会话状态集中存储 + 本地缓存。会话的完整历史存在云侧数据库，边侧和端侧只缓存最近几轮对话的 KV Cache。切换层级时，从云侧拉取完整历史，重建 KV Cache。这样一致性有保障，但重建 KV Cache 需要时间，切换时会有一次额外的延迟。

如果对切换延迟敏感，可以采用状态增量同步。端侧和边侧在本地维护会话状态的同时，把增量变化异步同步到云侧。切换时只需要拉取缺失的增量部分，重建速度更快。但增量同步的冲突处理比较复杂，需要引入版本向量或 CRDT 之类的机制。

5.4 安全与合规边界

云边端协同扩大了攻击面。端侧设备可能被逆向，边缘节点可能被入侵，云侧 API 可能被滥用。安全设计需要覆盖模型保护、数据加密、访问控制三个层面。

模型保护方面，端侧部署的模型权重需要加密存储，运行时解密加载，防止被直接提取。边缘节点的模型文件也需要签名校验，防止被替换。数据加密方面，云边端之间的通信要全链路加密，端侧本地存储的敏感数据要加密。访问控制方面，每个节点和设备都需要有身份凭证，调度器只接受合法节点的注册和状态上报。

合规方面，如果涉及用户数据跨层级流动，需要明确数据分类分级策略。哪些数据可以出端侧、哪些可以出边侧、哪些必须留在云侧，要有清晰的规则并且可审计。

5.5 成本核算与计费模型

云边端协同的计费比单一云服务复杂得多。云侧算力按 GPU 小时计费，边侧算力可能按节点包月或按请求量计费，端侧算力是用户自带的，理论上零成本但需要考虑用户激励。

如果端脑科技面向企业客户提供这套体系，计费模型可能需要支持混合计费：基础套餐包含一定量的云侧算力，超出部分按量计费；边侧算力按节点或按地域打包；端侧算力作为增值项，鼓励用户开启端侧处理以降低整体成本。

成本核算的难点在于跨层级的任务追踪。一个请求可能在端侧发起、边侧处理、云侧兜底，每个层级的资源消耗都要准确记录并归因到对应的用户或租户。这需要一套贯穿三层的请求追踪 ID 体系和资源计量模块。

6. 如果你要参考这套体系，从哪开始

6.1 先跑通两层，再扩展三层

不要一上来就追求完整的云边端三层架构。我见过太多团队在端侧适配阶段耗尽精力，结果核心业务逻辑还没跑通。更务实的路径是：先把云侧和边侧跑通，端侧先用简单的 API 调用代替，等云边协同稳定了，再逐步把轻量任务下沉到端侧。

云边协同的最小可行架构包括：云侧推理服务（vLLM 或类似引擎）、边侧推理节点（至少一个）、调度器（规则引擎即可）、状态存储（Redis + 对象存储）。这套架构跑通后，你已经能覆盖大部分推理场景，端侧只是锦上添花。

6.2 推理引擎选型的三个硬指标

选推理引擎不要只看 benchmark 上的吞吐数字，要结合你的实际场景看三个指标。

第一是首 token 延迟。对话场景下，用户对首 token 延迟最敏感。有些引擎吞吐很高，但首 token 延迟也高，因为它在等批处理凑满。vLLM 的连续批处理在这方面表现较好，但配置不当也会导致首 token 延迟恶化。

第二是显存效率。同样一张卡，有的引擎能跑 13B 模型，有的只能跑 7B，差别就在 KV Cache 管理和权重量化支持上。PagedAttention 是目前比较成熟的显存优化方案，选引擎时优先考虑支持它的。

第三是多模型支持。如果你的业务需要同时服务多个模型，引擎是否支持动态加载、是否支持模型间显存共享，就很重要。有些引擎设计时只考虑单模型，多模型场景下需要起多个进程，显存开销翻倍。

6.3 调度器的极简实现

如果你不想一开始就搞复杂的调度器，可以用一个极简方案起步：Nginx 或 Envoy 做反向代理，根据请求头里的地域信息做路由，边侧节点注册到 Consul 或 Nacos 做服务发现，健康检查用 HTTP 探针。这套方案能覆盖 80% 的调度需求，开发量不到一周。

等业务量上来了，再逐步替换成自研调度器，引入实时算力感知、会话亲和性、动态权重等高级特性。不要为了架构而架构，能解决问题的简单方案就是好方案。

6.4 监控体系要覆盖三层

云边端协同的监控比单层架构复杂，因为故障可能发生在任何一层，而且层与层之间的调用链路需要串联。建议至少采集以下指标：

监控数据不仅要用于告警，还要用于调度优化。比如发现某个边缘节点在特定时间段 GPU 温度偏高导致降频，调度器可以提前把请求转移到其他节点。

7. 关于这套体系的一些个人判断

我在实际做推理系统优化的过程中，越来越觉得“云边端协同”不是一个纯技术问题，而是一个资源分配的经济学问题。技术上的可行性早就验证了，难的是怎么让三层算力的成本、延迟、可靠性达到一个对业务最优的平衡点。

端脑科技这套体系如果真能落地，最大的价值不在于技术有多先进，而在于它提供了一种可复用的算力调度范式。就像当年 CDN 把内容分发标准化了一样，云边端协同推理如果也能标准化，后续的 AI 应用开发者就不需要每个人都从头搭一套推理基础设施，直接接入调度网络就行。

但我也要泼一盆冷水。这套体系的复杂度决定了它不可能适合所有团队。如果你的日推理请求量不到百万级，或者你的模型不需要低延迟响应，那集中式云侧推理仍然是更简单、更经济的选择。云边端协同的收益，只有在规模足够大、延迟足够敏感的场景下才能体现出来。

最后分享一个我在推理优化中反复验证过的小技巧：不要迷信模型压缩的极限。很多人为了把模型塞进端侧，拼命做量化，INT4 不够就 INT3，结果模型效果崩了，用户体验反而更差。我的经验是，量化到 INT8 通常损失很小，INT4 需要仔细评估，再往下就要非常谨慎。与其把一个大模型压到失真，不如换一个小一点的原生模型，效果可能更好。

这套体系后续还可以往几个方向扩展。一是跨云调度，不只调度自有的云边端资源，还能接入多个云厂商的算力池，做跨云的成本优化。二是推理任务的市场化交易，闲时的端侧和边侧算力可以挂牌出租，有需求的团队可以竞价购买。三是与 Agent 框架深度集成，让 Agent 的每一步推理都自动选择最优算力层级。这些方向都还在早期，但值得持续关注。