想象你是一位蚂蚁军团总司令，手下有100万只蚂蚁，它们代表城市里的每一辆出租车、每一次航班、每一笔订单。传统的方法，好比派一个手持放大镜的“观察员”（D3.js风格）一只一只登记：记到第1000只，他累瘫了，页面也卡死了。你需要的是另一套思路——让千万只“工蚁”（GPU核心）同时标记每一只蚂蚁，而你站在高处用望远镜（Mapbox底图）看清全局；到山脚再看细节，让蚂蚁们自动聚成一团团“云”。 Deck.gl就是这个“蚁群总指挥台”。它是Uber开源的地图数据可视化框架，专为浏览器端大规模地理数据渲染而生：通过WebGL调用GPU，把百万级数据点流畅地画在网页上。本文将带你从零认识它：GPU为什么快、图层系统怎么组织、如何和Mapbox配合、它与D3有何本质区别，以及如何真正跑起来一张百万点地图。

岗位关联

对数据可视化工程师而言，Deck.gl是处理海量地理数据的“关键武器”——它能让百万级数据展示从“卡顿翻车”变成“丝滑流畅”，是面试与实战的高频竞争力。

目录
  1. 可视化演示
  2. 认识Deck.gl：总司令的指挥台
  3. GPU加速原理：千万工蚁并行发力
  4. 图层系统：不同兵种的蚂蚁部队
  5. Mapbox集成：沙盘上的蚂蚁军团
  6. 对比D3.js：观察员与军团
  7. 大规模渲染：远看云雾近看蚂蚁
  8. 实战应用：指挥一支真实军团
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Deck.gl的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

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

Deck.gl：Deck Deck.gl架构与GPU加速 图层系统与组合式可视化构建 核心机制可视化 Deck.gl整体架构与关键组件

认识Deck.gl：总司令的指挥台

一支百万蚂蚁军团最需要什么？不是更多蚂蚁，而是一个能同时调度全军的指挥系统。Deck.gl就是这样的“指挥台”：它不负责摆弄沙盘本身（那是底图服务商的事），它只专注一件事——把海量数据“蚂蚁”高效地派遣到屏幕指定的位置。这套思路让浏览器里的地理可视化从“几千点就卡”跨入“百万点流畅”的层次。

Deck.gl是Uber在2015年开源的Web端数据可视化框架。它基于WebGL——浏览器里的GPU绘图接口——进行渲染。在它出现之前，Web地图可视化大多使用SVG或Canvas2D：每个点都要CPU单独处理，数据一多页面就僵住。Deck.gl改变了范式：你只需要用“声明式”的方式告诉它“画什么数据、用什么样式”，至于如何调动GPU底层管线，框架全部代劳。

它提供了非常丰富的图层类型：散点、弧线、路径、多边形、3D柱、里程计等，并且能无缝嵌入React、Vue等主流前端生态。开发者常把它比作“WebGIS界的引擎”，因为它把复杂的高性能渲染封装成了几行简单的声明。

所以，Deck.gl这个指挥台的真正价值，是让你不必亲手摆弄每一只蚂蚁，而是把“集结-排队-出发”全流程自动化，让百万蚂蚁军团在网页上滚滚而来。

Tframe=Tcpu+Tgpu\displaystyle T_{\text{frame}} = T_{\text{cpu}} + T_{\text{gpu}}
一帧画面的总耗时，等于CPU准备数据的耗时与GPU绘制耗时的总和。Deck.gl的优化目标，就是尽量压缩前一项。
  1. T_cpu 准备数据耗时CPU要先把数据打包成GPU能读懂的二进制缓冲，相当于指挥官清点蚂蚁、编排队伍。
    TcpuT_{\text{cpu}}
  2. T_gpu 绘制耗时GPU把缓冲里的顶点真正画到屏幕上，相当于千万只工蚁同时开工。
    TgpuT_{\text{gpu}}
  3. 帧目标 16.7ms浏览器每秒刷新60次，每帧只有约16.7毫秒预算，超时用户就会感到卡顿。
    Tframe<16.7 msT_{\text{frame}} < 16.7\,\text{ms}
  4. Deck.gl的策略一次批量上传全部数据，避免CPU每帧反复“传令”，从而把T_cpu压到极低。
    Tframe≈TgpuT_{\text{frame}} \approx T_{\text{gpu}}

GPU加速原理：千万工蚁并行发力

为什么蚂蚁能搬动比自身大几十倍的猎物？因为千万只工蚁同时发力。GPU的原理与蚁群如出一辙：它不追求单只工蚁有多强壮，而是以数量取胜。你电脑里的CPU像是“蚁后型选手”：只有几个核心，但每个核心极强，适合处理复杂但少量的逻辑；而GPU则像是庞大的工蚁群：核心成百上千，单个核心能力有限，却特别擅长同时处理海量重复计算。

Deck.gl正是利用了这一点。在渲染时，它将每个数据点的坐标、颜色、大小打包成二进制缓冲，一次性上传到GPU显存。随后，GPU的顶点着色器（Vertex Shader）会为每个顶点并行执行“投影+上色”的计算——每个数据点对应一个GPU线程，彼此独立、同时推进。这种“一个数据点一个工蚁”的设计，让百万级渲染成为可能。

在Web环境中，这套GPU流程的标准化接口就是WebGL，Deck.gl基于它构建了完整的上层封装。开发者不需要写着色器代码，只需要配置图层参数。

GPU加速并非魔法，它只是把“一只强壮的蚁后单打独斗”改成了“千万只工蚁协同扛鼎”。Deck.gl的使命，就是让每一只工蚁都拿到数据、在线渲染。

S=1(1−P)+PN\displaystyle S = \frac{1}{(1-P) + \dfrac{P}{N}}
阿姆达尔定律：S是理论加速比，P是可并行比例，N是并行处理单元数。它告诉我们：哪怕GPU核心再多，串行部分仍是速度天花板。
  1. P（可并行比例）任务中能分给千万工蚁的部分。Deck.gl里顶点坐标计算、颜色赋值天然可并行。
    PP
  2. 1-P（串行比例）必须由“蚁后”（CPU主线程）亲自完成的调度、上传逻辑。
    1−P1-P
  3. N（并行单元数）GPU中着色器核心的数量，普通显卡可达数千。
    NN
  4. S（加速比）整体提速倍数。若P=0.9、N=1000，则S≈9.9倍——串行1-P的部分决定了它永远达不到1000倍。
    S=10.1+0.91000≈9.9\displaystyle S = \frac{1}{0.1 + \dfrac{0.9}{1000}} \approx 9.9

图层系统：不同兵种的蚂蚁部队

一支成功的蚂蚁军团必然分工明确：侦察蚁探路、工蚁搬运、兵蚁守卫。Deck.gl的图层系统正是这种“兵种编制”。在Deck.gl中，一个“图层”（Layer）就是把一种视觉表现封装成独立单元，它规定了“画什么数据、用什么样式、如何响应鼠标事件”。多个图层可以像多兵种协同一样叠加在同一张地图上。

常见的图层兵种包括：ScatterplotLayer（散点图层，像侦察蚁标注每个点位）、ArcLayer（弧线图层，像信使蚁在两点间画弧线）、HexagonLayer（六边形聚合图层，像统计蚁汇总一片区域的密度）、ColumnLayer（3D柱状图层，像用立柱标记高低地势）。最重要的设计是“数据驱动样式”：比如getFillColor可以传一个函数，根据数据值动态返回不同颜色，让样式跟随数据流动。

图层之间互不干扰、按序叠加，这让复杂项目可以被拆解成多个简单的图层单元，也利于调试复用。不过，不同图层的GPU负载差异很大——选错兵种，代价可不小。

如同指挥官不会用兵蚁去挖洞，你也不该用ArcLayer去画点。选对兵种、看清负载，整支军团才能高效作战。

V=N×vp\displaystyle V = N \times v_p
V是某图层渲染时GPU要处理的顶点总数，N是数据点个数，v_p是每个点平均产生的顶点数。顶点数越多，GPU越忙。
  1. N（数据点数）参加该兵种的蚂蚁数量。100万只蚂蚁就是100万个数据点。
    NN
  2. v_p（每点顶点数）绘制每只蚂蚁需要几个“轮廓点”。一个散点用四边形≈6个顶点，一个3D柱体≈36个顶点。
    vpv_p
  3. V（总顶点数）GPU着色器需要处理的总负载。它决定了这帧画面有多“重”。
    VV
  4. 对比启示3D柱状图图层比同规模散点图层负载大约6倍，所以在选图层兵种前，最好先算一笔顶点账。
    V3D柱≈6×V散点\displaystyle V_{\text{3D柱}} \approx 6 \times V_{\text{散点}}

Mapbox集成：沙盘上的蚂蚁军团

蚂蚁军团再强，也需要一张“地形图”来明确往哪儿走。Mapbox的角色就是这张沙盘底图：它提供全球道路、地形、卫星影像等丰富的地图瓦片数据。Deck.gl并不替代Mapbox，而是把数据图层像蚂蚁一样“铺”在Mapbox底图之上。缩放或拖动地图时，两者必须共享同一套坐标映射，否则蚂蚁就会从沙盘边缘掉下去。

集成方式主要有两种。第一种是把Deck.gl的视图状态（ViewState）与Mapbox的相机参数同步，两个库共用同一个WebGL画布分层渲染；第二种是使用官方提供的MapboxOverlay插件，把Deck.gl图层直接插入Mapbox的渲染管线中。无论哪种方式，底层依赖的都是同一个数学工具：Web Mercator投影。

Web Mercator是互联网地图的事实标准投影：它把球面上的经纬度坐标转换为平面上的像素坐标。有了它，底图瓦片和数据点才能在同一个坐标系下对齐。

有了共享的“沙盘坐标系”，无论你怎么拖动缩放地图，蚂蚁军团始终精准地踩在底图该踩的位置上。

x=R×λ,y=R×ln⁡(tan⁡(π4+φ2))\displaystyle x = R \times \lambda, \qquad y = R \times \ln\left(\tan\left(\frac{\pi}{4} + \frac{\varphi}{2}\right)\right)
其中λ是经度，φ是纬度，R是地球半径的缩放常量。它把“球面上的点”变成“平面上的点”，方便地图和图层统一绘制。
  1. λ（经度）东西方向的位置，直接乘以R得到横向屏幕坐标x，就像在沙盘上拉一根横向标尺。
    λ\lambda
  2. φ（纬度）南北方向的位置，需要经过“球面到平面”的挤压处理。
    φ\varphi
  3. tan(π/4 + φ/2) 与 ln这一步把纬度从球面弧度转换为平面高度，保证方向角不变形，是Mercator投影的核心。
    ln⁡(tan⁡(π4+φ2))\ln\left(\tan\left(\frac{\pi}{4}+\frac{\varphi}{2}\right)\right)
  4. R（缩放常量）它控制单位像素代表的地理范围，地图的zoom缩放级别就是通过调整R实现的。
    RR

对比D3.js：观察员与军团

D3.js像那位手持放大镜的蚂蚁观察员：他细致而灵活，能记录每一只蚂蚁的触角朝向，但速度有限——每记录一只，都要给它在纸上（DOM）留一个档案袋。Deck.gl则像军团指挥系统，能调度百万蚂蚁，却不会为你雕刻每一根触角。这两种工具的选择，本质上是“精细度”与“规模”之间的权衡。

D3.js的工作方式是操作DOM/SVG：每一个数据点会生成一个HTML/SVG节点。浏览器能轻松维护几千个节点，但超过几万后，节点的创建、布局、样式计算和事件绑定都会拖垮页面。而Deck.gl在WebGL的Canvas上绘制，数据点只存在于GPU缓冲里，浏览器层面几乎没有DOM节点，因此数据规模上限高出好几个数量级。

在实际项目中，两者常常是互补的：用D3来画坐标轴、图例、做精细的少量DOM交互；用Deck.gl来渲染海量的主体数据图层。理解它们的时间复杂度差异，是选型的关键。

别再问“Deck.gl能不能取代D3”，它们一个是观察员、一个是军团总指挥。选谁，取决于你面前是10只蚂蚁还是100万只。

TDOM=k×N,TGPU=k′+NP\displaystyle T_{\text{DOM}} = k \times N, \qquad T_{\text{GPU}} = k' + \frac{N}{P}
T_DOM是D3模式的耗时，与数据点数N成正比；T_GPU是GPU模式的耗时，只与一次初始化k'和N/P（N被P个核心分摊）有关。
  1. k × N（D3的线性开销）每只蚂蚁都要建立DOM档案，数量N一涨，耗时线性暴涨。
    k×Nk \times N
  2. k'（GPU初始化开销）上传缓冲、创建渲染上下文的一次性固定成本。
    k′k'
  3. N/P（GPU并行开销）顶点数N被P个GPU核心分摊，P越大，每个核心处理的越少。
    NP\frac{N}{P}
  4. 选型原则N很小时，两者差不多；N很大时，GPU模式完胜——这是“大规模”的真正含义。
    TGPU≪TDOM(N≫1)\displaystyle T_{\text{GPU}} \ll T_{\text{DOM}} \quad (N \gg 1)

大规模渲染：远看云雾近看蚂蚁

站在山顶看蚂蚁军团，你只能看到一片缓缓移动的“黑云”；蹲下身子，才看得清每一只蚂蚁的腿。大规模地理渲染的思路正是如此——根据观察距离（也就是地图缩放级别），动态切换展示的颗粒度。Deck.gl为此提供了三件法宝：聚合（Aggregation）、细节层次（LOD）和视口裁剪（Culling）。

六边形聚合（HexagonLayer）是Aggregation的典型代表：把地图划分为六边形网格，网格内的所有数据点合并为一个柱体，用柱高或颜色表示密度。细节层次（LOD）则是按缩放级别切换方案：远景时用聚合后的宏观渲染，近景时展示个体散点。视口裁剪更直白：只渲染当前屏幕可见范围内的数据，视野外的蚂蚁直接忽略。三管齐下，GPU永远只处理“当下真正需要画的蚂蚁”。

这套组合拳让Deck.gl在千万级数据下依然保持稳定帧率，也是它区别于普通Canvas图表库的核心能力。

有了这三重压缩，百万蚂蚁在屏幕上呈现出来的不过是几十个“格子柱”。远看是雾、近看是蚁，“大”与“快”终于可以兼得。

Cg=∑i1{xi∈cellg}\displaystyle C_g = \sum_{i} \mathbb{1}\{x_i \in \text{cell}_g\}
指示函数判断第i个数据点是否落入第g个六边形格子，把所有落进来的点数相加，就得到该格子聚合后的密度值。
  1. x_i ∈ cell_g（落入判断）检查第i只蚂蚁是否位于第g个六边形格子内。
    xi∈cellgx_i \in \text{cell}_g
  2. 指示函数 1{……}条件成立记1，不成立记0，像饲养员记录“这只进槽了（是/否）”。
    1{⋅}\mathbb{1}\{\cdot\}
  3. 累加求和 Σ把所有落在同一格子的"1"加总，一只蚂蚁贡献一个计数。
    ∑i\sum_{i}
  4. C_g（聚合密度）该格子的蚂蚁总数，后续映射为柱高或颜色，用一组成员代替几千只个体。
    CgC_g

实战应用：指挥一支真实军团

理论讲完，终于到了出征时刻。让我们看看真实世界中，Deck.gl这个司令台是如何指挥三大类军团的：第一类是密度热力，用HexagonLayer或HeatmapLayer展示人口、车辆的空间分布；第二类是飞行轨迹，用ArcLayer展示航班连接、快递流向这类“点对点”数据；第三类是3D柱状图，用ColumnLayer以柱高表达数值高低，比如楼层高度、病例数量。

实际项目里，数据往往是实时更新的。WebSocket每秒钟推送新一批GPS点，Deck.gl会对图层做高效的差异化更新（Diff Update）而不是销毁重建整个图层，从而在数据流动中保持画面的流畅。此外，当数据量极大时，还会配合采样与聚合来平衡精度和性能，而不是把所有原始点无脑渲染。

下面这个公式是3D柱状图最常用的“归一化高度”映射，它让不同数量级的区域放在同一张图上时都能看清。

这就是Deck.gl的完整故事：一个把蚂蚁军团（数据）通过工蚁（GPU）在沙盘（Mapbox）上按兵种（图层）有序部署的系统。掌握它，你就掌握了在Web上指挥百万级地理数据的艺术。

hi=vivmax⁡×Hmax⁡\displaystyle h_i = \frac{v_i}{v_{\max}} \times H_{\max}
v_i是第i个格子的数值，v_max是全场最大值，H_max是设定的最大柱高。归一化后每根柱子高度都在0到H_max之间。
  1. v_i / v_max（归一化）把原始数值压缩到0到1之间，避免某个区域值太大“一柱擎天”。
    vivmax⁡\frac{v_i}{v_{\max}}
  2. × H_max（映射高度）乘以最大柱高，把0-1的比例转换为屏幕上的像素高度。
    Hmax⁡H_{\max}
  3. h_i（最终柱高）第i个格子的柱子实际渲染高度。
    hih_i
  4. 为什么需要它当北京有100万条记录、小城只有1万条时，不归一化会完全看不出小城的差异。
    hi∈[0,Hmax⁡]\displaystyle h_i \in [0, H_{\max}]

AI 应用场景

网约车实时态势监控

阶段：数据可视化与实时渲染

解决的问题：一座城市数万辆网约车的GPS点，若用传统SVG渲染很快就会卡死，调度大厅无法看到全局。AI模型产出的实时位置流数据，需要一种能承载万级点位、且随地图缩放平滑响应的渲染方案。

具体案例：某出行平台使用Deck.gl的ScatterplotLayer叠加ArcLayer，在Mapbox底图上同时展示车辆位置与司乘匹配流向。通过HexagonLayer聚合热点区域，即便高峰期5万+车辆同时在线，浏览器依然保持在60帧流畅运行。

城市人口密度与规划决策

阶段：数据聚合与视觉洞察

解决的问题：手机信令等人口数据往往达到百万级，直接散点绘制既看不清规律又造成渲染压力。需要把离散的点聚合成可读的密度图，辅助城市规划决策。

具体案例：城市规划部门使用pydeck（Deck.gl的Python绑定）将匿名手机信令数据渲染为3D六边形柱状图，柱高代表该区域同时在线人数，快速识别出商业中心、居住区与通勤走廊，为公交线路规划提供直观依据。

Python 演示

python34 行
"""用 pydeck 在 Web 上可视化百万级地理数据点"""import numpy as npimport pandas as pdimport pydeck as pdk def generate_city_points(n, lon_range=(116.20, 116.55),                         lat_range=(39.80, 40.05), seed=42):    """生成模拟北京城区 GPS 数据点"""    rng = np.random.default_rng(seed)    lon = rng.uniform(lon_range[0], lon_range[1], n)    lat = rng.uniform(lat_range[0], lat_range[1], n)    value = rng.integers(1, 100, n)    return pd.DataFrame({"lon": lon, "lat": lat, "value": value}) def build_deck(df):    """构建 ScatterplotLayer 图层与 Deck 实例"""    layer = pdk.Layer(        "ScatterplotLayer",        data=df,        get_position=["lon", "lat"],        get_radius=30,        get_fill_color=[130, 140, 248, 180],        pickable=True,        auto_highlight=True,    )    view = pdk.ViewState(latitude=39.92, longitude=116.40, zoom=10)    return pdk.Deck(layers=[layer], initial_view_state=view,                    tooltip={"text": "数值 {value}"}) if __name__ == "__main__":    df = generate_city_points(1_000_000)    deck = build_deck(df)    deck.to_html("million_points.html")    print("已生成 million_points.html，请在浏览器中打开")
目的：生成包含100万个模拟GPS点的HTML地图页面，演示Deck.gl在大规模散点渲染下的流畅效果。运行前需安装依赖：pip install pandas numpy pydeck。
  1. rng = np.random.default_rng(seed)生成可复现的随机数生成器，保证每次运行结果一致。
  2. rng.uniform(lon_range[0], lon_range[1], n)在北京经度范围内均匀采样n个经度值。
  3. pd.DataFrame({"lon": lon, "lat": lat, "value": value})把经纬度和数值组合成表格，作为图层数据源。
  4. pdk.Layer("ScatterplotLayer", data=df, ...)创建一个散点图层，这是Deck.gl最基础的“侦察蚁兵种”。
  5. get_position=["lon", "lat"]告诉图层用哪两列作为位置坐标。
  6. get_fill_color=[130, 140, 248, 180]设置点的填充颜色RGBA，值范围是0-255。
  7. pdk.ViewState(latitude=39.92, longitude=116.40, zoom=10)设置地图初始中心和缩放级别，相当于望远镜的初始位置。
  8. deck.to_html("million_points.html")生成独立HTML文件，浏览器打开后可拖拽缩放、悬停查看数据。

常见误区

误区我学会了Deck.gl，就能直接显示出道路、建筑等地图了吧？它是做地图的库。

正解Deck.gl是“数据图层引擎”，负责渲染蚂蚁本身；而沙盘底图（道路、建筑、地形）通常由Mapbox或OpenStreetMap提供。确切的分工是：Mapbox画底图，Deck.gl在底图上画数据。两者常常配合使用，但职责完全不同。

为何常见：因为Deck.gl常和地图同时出现，且名字里有"gl"让人误以为它是全栈地图方案。

误区GPU有成千上万个核心，所以1000万个点也能同时画出来，Deck.gl永远不卡。

正解GPU核心数量是数千级别而非百万级别，且数据要经历缓冲上传、顶点着色、图元装配、光栅化等多个流水线阶段。当数据量过大时，显存带宽、CPU上传速度都会成为瓶颈。正因如此，Deck.gl才需要配合聚合、LOD、视口裁剪等手段，而不是盲目堆数据。

为何常见：看到“GPU加速”和“百万级渲染”的演示，容易把并行理解成无限扩张。

误区新技术出现了，D3.js这种老库就该退场，所有可视化都用Deck.gl做。

正解两者定位完全不同。D3像精细观察员，适合几十到几千个元素的高度定制化DOM交互；Deck.gl像军团指挥，适合大规模图层渲染。真实项目中常同时使用：D3画轴、图例，Deck.gl画海量主体数据，各取所长。

为何常见：初看都是“数据可视化工具”就认为同类竞争，忽略了它们在渲染机制和数据规模上的根本差异。

误区把散点、弧线、3D柱、文本等图层全叠上去，数据展示就显得全面又厉害。

正解图层叠加会成倍放大顶点数，GPU显存与绘制时间都被快速消耗，同时信息过载会让读者抓不住重点。正确的做法是像作战部署一样分层：底图一层、宏观聚合一层、细节重点一层，控制同屏图层数量。

为何常见：新手想展示自己掌握了多种图层能力，误把“炫技”当作“有效传达”。

面试题

Q1. GPU相比CPU在大规模渲染上的优势特征有哪些？

多选题 · mid

  • A.核心数量更多适合并行计算
  • B.适合执行重复的简单运算← 正确答案
  • C.通过顶点着色器处理图形数据
  • D.完全不需要CPU参与即可显示
  • E.ScatterplotLayer散点
  • F.ArcLayer弧线图层
  • G.TextLayer文本图层
  • H.IconLayer图标图层
  • I.保持所有地理距离完全不变
  • J.把经纬度映射为平面坐标
  • K.由Deck.gl团队独立发明
  • L.仅用于行星级别的渲染
  • M.渲染一百万个GPS轨迹点
  • N.绘制一个可拖拽的树形图
  • O.实时显示十万辆车辆位置
  • P.生成全国航班弧线视图
  • Q.把散点绘制成六边形形状
  • R.合并相邻点减少渲染负载
  • S.让地图画面更富有棱角
  • T.将地图数据分割成小格子

答案：B。六边形聚合把落在同一网格内的数据点合并为一个柱体，用柱高或颜色表达密度，从而大幅减少GPU需要绘制的图元数量，而不是单纯为了形状好看。

Q2. 下列关于Deck.gl与D3.js组合使用的说法，正确的有？

多选题 · hard

  • A.两者可以共存于同一工程← 正确答案
  • B.D3处理少量DOM交互更灵活← 正确答案
  • C.Deck.gl渲染大规模点更高效← 正确答案
  • D.两者完全互斥不可联合使用

答案：ABC。实践中常用D3做图例、坐标轴和小规模交互，用Deck.gl渲染海量数据图层，两者互补共存在同一工程中，并非互斥关系。

Q3. 关于Deck.gl图层机制，以下哪些说法正确？

多选题 · mid

  • A.支持数据驱动样式绑定← 正确答案
  • B.多个图层可以叠加组合
  • C.一个图层封装数据和样式
  • D.图层必须绑定第三方地图
  • E.4倍左右
  • F.8倍左右
  • G.16倍左右
  • H.20倍以上

答案：A。按阿姆达尔定律 S=1/((1-P)+P/N)，代入P=0.8、N=16得S=1/(0.2+0.05)=4倍。串行部分0.2决定了即使核数无限增加，加速比也不会超过5倍，因此选4倍左右。