城市的凌晨，一辆深夜食堂餐车停在写字楼下。它很小，没有大饭店的后厨那么气派；但它只卖三道招牌菜，每道菜出餐前都预处理成半成品，客人一下单就能在几秒内端上桌，整晚只耗一箱油。大饭店什么菜都能做，可它得养庞大的后厨团队，电费账单让人看一眼就心疼。Edge TPU 就是 AI 世界里的这辆餐车——小、省电、出餐快，但你必须按它的规矩来：把模型做成 INT8 的“预制菜”，只点菜单上有的“菜品”，更别指望它在车上现场训练新厨师。这篇文章将带你从硬件架构、性能限制、量化要求、Coral 开发板、与移动 GPU 的对比，一直看到部署优化策略，搞懂这辆“两瓦特餐车”为什么能成为边缘 AI 的明星。

岗位关联

掌握 Edge TPU 的约束边界与优化方法，是边缘 AI 工程师把模型从“能跑”推向“跑得省、跑得快”的核心竞争力。

目录
  1. 可视化演示
  2. 硬件架构：为三道菜定制的炉头
  3. 推理性能限制：菜单之外皆需等待
  4. INT8 量化要求：预制半成品才能上车
  5. Coral 开发板：一辆能上路的餐车
  6. 移动 GPU 对比：大饭店还是深夜餐车
  7. 部署优化策略：让每一秒都在出餐
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Edge TPU的硬件架构与INT8量化约束、算子支持与CPU回退机制、以及与移动GPU的推理性能对比。

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

Edge TPU架构 专为INT8推理设计的ASIC，支持Conv2D/FC/Pool等有限算子 8MB片上内存约束模型大小，编译器检查内存预算 INT8 only | 8MB SRAM | 4 TOPS 强制INT8量化是精度与性能的核心权衡

硬件架构：为三道菜定制的炉头

深夜食堂餐车的厨房很小，但设计得像瑞士手表：几个炉头紧挨着，每个炉头专攻一道招牌菜，锅铲、调料盒全在伸手可及的位置。主厨不需要满后厨跑，转个身就能完成所有操作。因为专为这几道菜设计，热量损失最小，汽油消耗也最低——这正是 Edge TPU 的设计哲学。

餐车里的“专用炉头”在芯片世界里叫 ASIC（专用集成电路）。与 CPU、GPU 这类“什么都能干”的通用选手不同，Edge TPU 只做一件事：把已经训练好的神经网络“端上桌”——也就是推理。官方标称算力 8 TOPS，功耗却只有约 2 瓦，相当于给手机充电的零头。这背后是“以专用换效率”的典型思路。

TOPS 是“每秒万亿次运算”的单位。8 TOPS 意味着每秒钟可以完成大约 8 万亿次整数运算。在系统里，Edge TPU 不是主角而是“协处理器”：它依附在主控 SoC 旁边，等 CPU 把数据准备好，再高速完成卷积、全连接这类密集计算，最后把结果交还主控，整个过程像帮厨把菜端给大厨翻勺。

大饭店的后厨什么菜都能做，但每道菜都要临时备料、开大火，电费惊人；餐车只做三道菜，却把每个环节都压缩到极致。Edge TPU 就是靠这种“牺牲通用性、换取效率”的硬件架构，把低功耗边缘推理变成了现实。

TOPS=每秒运算次数1012=f时钟×N每周期运算数×10−12\text{TOPS} = \frac{\text{每秒运算次数}}{10^{12}} = f_{\text{时钟}} \times N_{\text{每周期运算数}} \times 10^{-12}
TOPS 是衡量芯片速度的“出菜速度”指标：1 TOPS 就是一秒做一万亿道简单算术。
  1. 每秒运算次数芯片时钟每秒“滴答”的次数，乘以每个滴答内能并行完成的算术次数。
    每秒运算次数=f时钟×N每周期运算数\text{每秒运算次数} = f_{\text{时钟}} \times N_{\text{每周期运算数}}
  2. 除以 10 的 12 次方把庞大的数字折算成以“万亿”为单位，方便宣传与对比。
    1 TOPS=1012 次/秒1\,\text{TOPS} = 10^{12}\,\text{次/秒}
  3. 8 TOPS 的具体含义Edge TPU 每秒可完成约 8 万亿次整数运算，恰好满足常见视觉模型在实时视频流上的需求。
    8 TOPS=8×1012 次/秒8\,\text{TOPS} = 8 \times 10^{12}\,\text{次/秒}

推理性能限制：菜单之外皆需等待

餐车能出菜，但菜单上永远只有那三道招牌菜。你半夜想吃佛跳墙？主厨会礼貌地摇头——不是他手艺不行，是餐车上根本没有那口锅。Edge TPU 的推理限制正是如此：它只负责把训练好的模型“做熟”，绝不在现场“培养新厨师”（不支持训练），也拒绝超出菜单的“菜品”（不支持的算子）。

具体来说，Edge TPU 不支持反向传播与权重更新，训练只能留在云端大算力平台上完成。它支持的操作符（算子）是固定白名单，比如卷积、深度可分离卷积、池化、全连接等；模型里一旦出现它不认识的算子，例如某些复杂的注意力机制或动态形状操作，这部分计算就只能“回退”到 CPU 上执行。

回退可不是免费的：Edge TPU 算完自己能算的部分后，必须停下来等 CPU 慢慢算完不支持的算子，两边串行拼接，总延迟被一下子拉长。同时，片上内存（SRAM）大约只有 8 MB，装不下太大的模型；同一时刻通常只能跑一个模型，无法像 GPU 那样多模型并发。这些限制共同划定了“餐车菜单”的边界。

所以，聪明的“餐车运营者”会严格按菜单点菜：设计模型时主动避开 Edge TPU 不支持的算子，把注意力、动态分支等“特色菜”留给云端。菜单越小，出餐越快——这就是边缘推理限制带给我们的第一条优化直觉。

T总=TTPU 部分+∑kTCPU 回退,kT_{\text{总}} = T_{\text{TPU 部分}} + \sum_{k} T_{\text{CPU 回退},k}
推理总耗时等于 Edge TPU 处理的时间，加上所有回退到 CPU 的算子耗时之和。菜单外的菜会让整桌出餐变慢。
  1. TPU 部分模型里受支持的算子由专用硬件并行处理，速度非常快。
    TTPU 部分=Q运算量8×1012 次/秒T_{\text{TPU 部分}} = \frac{Q_{\text{运算量}}}{8 \times 10^{12}\,\text{次/秒}}
  2. CPU 回退部分不支持的算子被逐段搬运到 CPU，只能串行执行。
    TCPU 回退,k=t搬运+t计算T_{\text{CPU 回退},k} = t_{\text{搬运}} + t_{\text{计算}}
  3. 串行求和两部分按顺序相加，任何一段拖沓都会拉高总延迟。
    T总=TTPU 部分+TCPU 回退部分T_{\text{总}} = T_{\text{TPU 部分}} + T_{\text{CPU 回退部分}}

INT8 量化要求：预制半成品才能上车

为什么餐车能三秒出餐？因为食材早在每天晚上就切好、称重、分装成半成品，每份都精确到克。客人点菜时，主厨只需要把半成品倒进锅里翻炒，不需要现场洗菜切菜。模型之于 Edge TPU，就是这些“预制半成品”——你必须提前把 FP32 浮点模型，压成 INT8 整数模型。

这个“切菜称重”的过程叫量化。量化把连续的浮点数值映射到 256 个整数档位（-128 到 127）。关键参数有两个：缩放因子 S 决定每一档的“分量”（步长）；零点 Z 决定坐标原点，让整数 0 恰好对应原来某个浮点值。两者配合，才能在压缩数值范围的同时尽量保留信息。

为了减少精度损失，最佳实践是先做“量化感知训练”（QAT），让模型在训练时就开始适应量化的“粗糙感”；再准备一组有代表性的校准数据集（比如训练集的子集），交给转换工具统计数值范围，从而算出合适的 S 和 Z。经验上，好的量化模型精度损失可控制在 1% 以内。

预制菜牺牲了一点点锅气，换来的是出餐速度和成本的巨大改善——INT8 模型体积只有 FP32 的四分之一，内存占用大幅下降，而整数运算单元在 Edge TPU 上跑得飞快。想上这辆餐车的菜，就得先学会做合格的“预制半成品”。

q=round(rS+Z),r≈S(q−Z)q = \mathrm{round}\left(\frac{r}{S} + Z\right), \qquad r \approx S\left(q - Z\right)
浮点值 r 除以步长 S，再平移零点 Z，最后四舍五入，就得到整数 q；反过来也能从 q 近似还原浮点值。这就像把一锅汤按“每勺多少克”的标准分装成固定份量。
  1. 原始浮点值 r模型训练时的权重和激活值，通常是 FP32 精度。
    r浮点∈[rmin⁡, rmax⁡]r_{\text{浮点}} \in [r_{\min},\, r_{\max}]
  2. 缩放因子 S每个整数档位代表的浮点“最小刻度”，决定量化步长。
    S=rmax⁡−rmin⁡qmax⁡−qmin⁡S = \frac{r_{\max} - r_{\min}}{q_{\max} - q_{\min}}
  3. 零点 Z浮点零映射到的整数位置，用于对齐坐标原点。
    Z=qmin⁡−rmin⁡SZ = q_{\min} - \frac{r_{\min}}{S}
  4. 四舍五入取整小数落在哪个档位，就归到哪个整数。
    q=round(rS+Z)q = \mathrm{round}\left(\frac{r}{S} + Z\right)

Coral 开发板：一辆能上路的餐车

有了餐车理念，还得有辆真正的餐车。Edge TPU 本身是一颗芯片，普通人没法直接拿它做菜，需要一辆“完整的车”——这就是 Coral Dev Board。它把 Edge TPU、主控 CPU、内存、Linux 系统和 I/O 接口打包在一块开发板上，插上摄像头就能端到端跑一个视觉模型。

Coral 家族里，除了 Dev Board 这种“整车”，还有 USB Accelerator 这种“外挂引擎”——把它插到树莓派或普通电脑的 USB 口，等于给别的车加装一个专用灶台，立刻获得 4 TOPS 的整数量化推理能力。开发者可以根据项目规模，选择“整车”还是“外挂”。

开发流程是一条清晰的流水线：训练模型 → 转成 TFLite 并做 INT8 全量化 → 用 edgetpu_compiler 编译成 Edge TPU 专用格式 → 在板上用 tflite-runtime 加载推理。吞吐量通常用 FPS 衡量：一帧延迟越短，每秒处理的帧数越高；多个 USB 加速器还可以级联，总吞吐量近似相加。

餐车开上路之后，运营者还要算一笔账：每辆车每小时能出多少份餐、每箱油能跑多远。Coral Dev Board 的价值正在于此——它把 Edge TPU 的算力装进一辆“能上路的整车”，让低功耗边缘推理真正落地到路灯、摄像头、果园这些没有机房的地方。

FPS=1000t一帧(ms),总吞吐=∑m=1MFPSm\text{FPS} = \frac{1000}{t_{\text{一帧}}(\text{ms})}, \qquad \text{总吞吐} = \sum_{m=1}^{M} \text{FPS}_m
FPS 就是一秒能处理多少帧画面；多插几个加速器，相当于多开几个窗口同时出餐，总吞吐约等于各窗口之和。
  1. 一帧延迟 t从图像输入到输出结果的总耗时，单位是毫秒。
    t=t预处理+t推理+t后处理t = t_{\text{预处理}} + t_{\text{推理}} + t_{\text{后处理}}
  2. FPS 计算1000 毫秒除以单帧耗时，得到每秒处理的帧数。
    FPS=1000t\text{FPS} = \frac{1000}{t}
  3. 多设备级联M 个加速器并行处理不同帧，总吞吐近似相加。
    总吞吐=∑m=1MFPSm\text{总吞吐} = \sum_{m=1}^{M} \text{FPS}_m

移动 GPU 对比：大饭店还是深夜餐车

很多人会问：手机里的 GPU 不也能做 AI 推理吗？为什么还要搞一辆餐车？想象一下：大饭店的厨房确实什么菜都能做，但它开在市中心写字楼里，占地几百平，每月的电费水费能把小老板吓哭。移动 GPU 强在“什么模型都可能跑”，但它是通用图形单元，跑推理时功耗高、发热快。

从数据看，Edge TPU 的整数推理能效比（每瓦特算力）通常明显优于手机 GPU 的浮点推理：一颗 2 瓦的 Edge TPU 与一颗 5 至 10 瓦的移动 GPU 相比，在 INT8 视觉模型上吞吐量可能相当甚至更高，但功耗只有后者的几分之一。这正是餐车“省油”的优势所在。

延迟方面，Edge TPU 的确定性很强——专用流水线让推理时间稳定可预测，而 GPU 的调度受其他任务干扰较大。生态方面，GPU 胜在“什么框架都支持、什么精度都能跑”的弹性；Edge TPU 则用“只认 INT8 白名单算子”换取低功耗与高确定。两者不是替代关系，而是不同场景下的两种工具。

选餐车还是选大饭店，取决于你的“生意模式”：要开着车到处跑、一天只烧一箱油？选 Edge TPU；要办一场大型宴会、菜品千变万化？留给 GPU。理解了这一层，你就明白为什么边缘 AI 工程师手里，常常同时备着这两把“厨具”。

η=算力 (TOPS)功耗 (W)=8 TOPS2 W=4 TOPS/W\eta = \frac{\text{算力 (TOPS)}}{\text{功耗 (W)}} = \frac{8\,\text{TOPS}}{2\,\text{W}} = 4\,\text{TOPS/W}
能效比是“每瓦特能换多少算力”，好比每升汽油能跑多少公里。Edge TPU 的能效比数字通常比移动 GPU 更漂亮。
  1. 算力分子芯片每秒完成的操作数以 TOPS 计，Edge TPU 为 8 TOPS。
    算力=8 TOPS\text{算力} = 8\,\text{TOPS}
  2. 功耗分母芯片满负荷工作时的功率以瓦计，Edge TPU 约 2 瓦。
    功耗≈2 W\text{功耗} \approx 2\,\text{W}
  3. 能效比结果两者相除得到每瓦算力，数字越大越省电。
    η=4 TOPS/W\eta = 4\,\text{TOPS/W}

部署优化策略：让每一秒都在出餐

餐车生意要做得好，光有好车还不够，还得优化“动线”：食材怎么摆、锅怎么放、出餐口朝哪边，每一步都在省时间。部署模型到 Edge TPU 也一样，优化的本质是让专用硬件尽量“忙碌”，而不是傻等。

最常踩的坑是忽略批处理的影响。Edge TPU 的底层计算单元高度定制，对 batch=1 的单帧推理做了深度优化；盲目把 batch 从 1 改成 8，期望“一锅出八份”，往往不会线性提速，反而可能因内存占用和流水线约束导致延迟上升。正确的“动线”是先做 profiling，找出回退到 CPU 的算子和数据搬运热点。

常用策略清单如下：选择 MobileNet、EfficientNet-Lite 等“为端侧而生”的骨干网络；用量化感知训练把量化误差消解在训练阶段；对校准数据集精心采样，避免数值范围失准；利用编译器移除冗余算子、融合相邻卷积与激活；必要时把模型切分为“Edge TPU 部分 + CPU 部分”的混合流水线，让两边并行而不互相等待。

深夜的餐车后厨里，主厨把备料、炒菜、出餐分成三条节奏同步的流水线，每一秒都不浪费。Edge TPU 部署优化的终极目标同样如此：让硬件忙碌、让等待归零、让每一毫秒的算力都变成真正端上桌的“推理结果”。

U=TTPU 忙碌TTPU 忙碌+T等待搬运U = \frac{T_{\text{TPU 忙碌}}}{T_{\text{TPU 忙碌}} + T_{\text{等待搬运}}}
利用率 U 表示硬件真正干活的占比。等待数据搬运的时间越长，利用率越低，餐车“空转等客”的时间就越多。
  1. TPU 忙碌时间芯片真正执行卷积、池化等运算的时间。
    T忙碌=Q8 TOPST_{\text{忙碌}} = \frac{Q}{8\,\text{TOPS}}
  2. 等待搬运时间数据在内存与算力单元之间搬运、同步的等待时间。
    T等待=TDMA+T同步T_{\text{等待}} = T_{\text{DMA}} + T_{\text{同步}}
  3. 利用率公式忙碌时间占总时间的比例，越接近 1 越好。
    U=T忙碌T忙碌+T等待U = \frac{T_{\text{忙碌}}}{T_{\text{忙碌}} + T_{\text{等待}}}

AI 应用场景

智慧零售端侧商品识别

阶段：模型量化与端侧部署

解决的问题：传统收银依赖扫码，商品识别若连云端，网络一抖动结账就卡顿。利用 Edge TPU 本地推理，INT8 量化后的商品分类模型离线运行，结账秒级响应，断网断电也能工作。

具体案例：某无人货柜企业把 MobileNetV3 量化到 INT8，部署在 Coral Dev Board 上，摄像头采集商品图像，约 80ms 返回类别，整机功耗仅 2W，一台设备可支撑上千种 SKU 的识别。

工业产线缺陷检测

阶段：推理性能优化与编译部署

解决的问题：传统机器视觉用规则算法，漏检率高；云端检测又受带宽和时延限制。Edge TPU 的低功耗与确定性延迟，让质检相机能嵌入产线边缘，实时拦截次品。

具体案例：某电子元件工厂用检测网络识别 PCB 焊点缺陷，将 FP32 模型量化后用 edgetpu_compiler 编译，在产线相机旁实时推理，FPS 达到 60 以上，远超人工目检速度。

野外生态监测

阶段：低功耗持续推理

解决的问题：野外摄像头靠太阳能供电，云端传输成本高，传统方案无法支撑 24 小时持续 AI 识别。边缘端推理只在本地完成识别，大幅降低能耗与流量。

具体案例：某自然保护区部署太阳能供电的 Edge TPU 设备，摄像头 24 小时开机，仅在检测到动物出现时通过 4G 回传片段，整体功耗降低约 80%，电池续航从 2 天提升到 14 天。

Python 演示

python56 行
# -*- coding: utf-8 -*-"""Edge TPU 部署完整流程: INT8 量化转换 -> 编译 -> 推理"""import tensorflow as tfimport numpy as npimport subprocessimport time MODEL_DIR = "saved_model_dir"TFLITE_PATH = "model_int8.tflite"EDGETPU_PATH = "model_int8_edgetpu.tflite"  def representative_dataset():    """生成 100 个校准样本, 供量化器统计数值范围"""    for _ in range(100):        data = np.random.rand(1, 224, 224, 3).astype(np.float32)        yield [data]  def convert_to_int8():    converter = tf.lite.TFLiteConverter.from_saved_model(MODEL_DIR)    converter.optimizations = [tf.lite.Optimize.DEFAULT]    converter.representative_dataset = representative_dataset    converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]    converter.inference_input_type = tf.uint8    converter.inference_output_type = tf.uint8    tflite_model = converter.convert()    with open(TFLITE_PATH, "wb") as f:        f.write(tflite_model)    print("INT8 TFLite 模型已生成:", TFLITE_PATH)  def compile_for_edgetpu():    subprocess.run(["edgetpu_compiler", TFLITE_PATH], check=True)    print("Edge TPU 编译完成:", EDGETPU_PATH)  def run_inference():    from tflite_runtime.interpreter import Interpreter    interpreter = Interpreter(model_path=EDGETPU_PATH)    interpreter.allocate_tensors()    input_details = interpreter.get_input_details()    output_details = interpreter.get_output_details()    input_data = np.full(input_details[0]['shape'], 128, dtype=np.uint8)    start = time.time()    interpreter.set_tensor(input_details[0]['index'], input_data)    interpreter.invoke()    elapsed = (time.time() - start) * 1000    output = interpreter.get_tensor(output_details[0]['index'])    print("推理耗时 %.1f ms, 输出类别 %d" % (elapsed, output.argmax()))  if __name__ == "__main__":    convert_to_int8()    compile_for_edgetpu()    run_inference()
目的：演示一个训练好的模型如何变成 Edge TPU 能跑的“预制菜”——先做 INT8 全量化，再经专用编译器编译，最后在开发板上完成推理。
  1. converter.optimizations = [tf.lite.Optimize.DEFAULT]开启默认优化，为后续量化铺路。
  2. converter.representative_dataset = representative_dataset喂入校准数据，让工具统计数值范围以算出 S 和 Z。
  3. converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]强制全 INT8 运算，不让模型偷偷保留浮点算子。
  4. converter.inference_input_type = tf.uint8输入输出都改为整数，符合 Edge TPU 的“收货标准”。
  5. subprocess.run(["edgetpu_compiler", TFLITE_PATH], check=True)用官方编译器把 TFLite 变成 Edge TPU 专用格式。
  6. interpreter.invoke()真正触发一次推理，整个流程就像餐车接单后三秒出餐。

常见误区

误区我的 TensorFlow 模型训好了，直接传到板子上就能跑，跟 GPU 一样灵活。

正解Edge TPU 只认“全 INT8 量化 + 白名单算子 + 经过 edgetpu_compiler 编译”的模型。FP32 权重、不支持的算子、未量化模型，要么编译失败，要么静默回退 CPU。就像餐车只收预制半成品，生鲜食材和佛跳墙都进不了车门。

为何常见：日常用 GPU/CPU 跑模型太顺滑，习惯了“任何模型直接跑”，忽略了专用硬件必然有适用范围。

误区INT8 只有 256 个档位，精度肯定崩，不如用 FP16 稳妥。

正解配合量化感知训练（QAT）和精心设计的校准数据集，多数分类、检测模型在 INT8 下的精度损失可控制在 1% 以内。量化不是“丢弃信息”，而是把信息重新编码成更适合专用硬件的格式，关键在于训练阶段就让模型适应这种编码。

为何常见：人们直觉上认为“数字位数越少越不准”，忽略了算法侧可以主动适应量化噪声。

误区广告说 Edge TPU 有 8 TOPS 算力，手机 GPU 才几 TFLOPS，所以 Edge TPU 一定更快。

正解8 TOPS 是 INT8 整数算力，GPU 的 TFLOPS 是 FP32 浮点算力，单位不同不能直接比。在受支持的 INT8 模型上，Edge TPU 的能效比更优；但遇到 FP32 模型或不支持的算子，GPU 反而更灵活甚至更快。

为何常见：营销数字单位混用（TOPS 与 TFLOPS），加上“专用一定更快”的简单化联想。

误区我已经把模型转成 .tflite 文件了，拷到开发板上应该就能跑起来。

正解普通 TFLite 模型默认走 CPU/GPU 路径。必须做完整的 INT8 量化，再经过 edgetpu_compiler 编译，产出带 edgetpu 后缀的模型，运行时才会真正调度到 Edge TPU。缺少任何一步，代码不报错，但算力在 CPU 上“假装运行”。

为何常见：工具链把编译和运行封装得很顺滑，回退到 CPU 时通常不报错，使用者很难察觉硬件其实没有在工作。

面试题

Q1. Edge TPU 主要面向哪类任务？

单选题 · easy

  • A.通用科学计算
  • B.边缘端低功耗推理← 正确答案
  • C.云端大规模训练
  • D.数据存储管理

答案：B。Edge TPU 是典型边缘推理芯片，定位是低功耗、低延迟的端侧推理。B 正确；A 是通用计算芯片的强项，C 需要大算力与显存，D 与 AI 推理无关。就像深夜餐车只为快速出餐设计，不是用来开宴会的。

Q2. Edge TPU 对模型的量化精度要求是什么？

单选题 · easy

  • A.FP32 单精度浮点
  • B.FP16 半精度浮点
  • C.INT8 全整数量化← 正确答案
  • D.BF16 脑浮点格式

答案：C。Edge TPU 的硬件只对 INT8 整数运算做了深度优化，模型必须全整数量化后才能被编译器接受。FP32、FP16、BF16 都绕不开它的整数计算单元。按餐车比喻，INT8 是唯一允许进车的“预制菜”规格。

Q3. 量化公式 q = round(r/S + Z) 中，缩放因子 S 的作用是？

单选题 · mid

  • A.决定量化步长与数值范围← 正确答案
  • B.修正零点的偏移位置
  • C.存储待量化的原始输入
  • D.记录训练时的学习率

答案：A。S 决定每个整数档位代表的浮点步长，直接影响量化精度；Z 负责对齐坐标原点；r 是待量化的浮点值；q 是量化结果。S 的取值依赖校准数据统计出的数值范围，就像“每勺多少克”的分装标准。

Q4. edgetpu_compiler 编译失败的最常见原因是什么？

单选题 · mid

  • A.模型算子 Edge TPU 不支持← 正确答案
  • B.训练数据集的规模太大
  • C.设备连接屏幕分辨率低
  • D.电池电量不足无法启动

答案：A。编译失败最典型的原因是模型包含 Edge TPU 不支持的算子，编译器无法把这类运算映射到专用硬件上；数据规模、屏幕分辨率、电量均与编译无关。餐车菜单上没有的菜，主厨再努力也做不出来。

Q5. Edge TPU 相比移动 GPU 的核心优势是什么？

单选题 · mid

  • A.支持更多样的网络算子
  • B.单位功耗算力更高效← 正确答案
  • C.可训练更强的大模型
  • D.浮点运算精度更高

答案：B。Edge TPU 的核心优势是能效比高，能以约 2W 功耗提供 8 TOPS 整数算力；它支持的算子种类反而更少，不能训练大模型，浮点精度依赖量化退化。相当于省油的餐车，而不是什么都能做的大饭店后厨。

Q6. 同一模型在 Edge TPU 上把 batch 从 1 增大到 8，通常会发生什么？

单选题 · hard

  • A.吞吐提高而延迟略增← 正确答案
  • B.延迟降低且吞吐变高
  • C.模型精度大幅下降
  • D.编译报错无法运行

答案：A。Edge TPU 对 batch=1 做了深度流水线优化，增大 batch 通常不会线性加速，反而因内存与流水线约束导致延迟略增，吞吐小幅提升；精度、编译与 batch 无关。把八份菜一起下锅并不等于八倍速度。

Q7. 下列属于 Edge TPU 推理限制的有哪些？

多选题 · mid

  • A.仅推理无法训练模型← 正确答案
  • B.需要 INT8 全量化← 正确答案
  • C.支持任意数值精度
  • D.芯片内存容量有限← 正确答案

答案：ABD。Edge TPU 只做推理、不做训练；模型必须 INT8 全量化；片上内存仅约 8MB，容量有限。它并不支持任意精度模型，所以 C 错误。缺什么菜、用什么锅，都写在餐车菜单上了。

Q8. Coral Dev Board 中 Edge TPU 的角色是什么？

单选题 · easy

  • A.云端的独立推理服务器
  • B.主控 SoC 的协处理器← 正确答案
  • C.通用图形渲染显示卡
  • D.大容量数据存储硬盘

答案：B。Coral Dev Board 上的 Edge TPU 是挂在主控 SoC 旁的协处理器，负责把 CPU 准备好的数据高速推理完再交回；它既不是云端服务器，也不是显卡或硬盘。就像餐车主厨与专用炉头的明确分工。

Q9. 下列哪些做法能提升 Edge TPU 上的推理精度？

多选题 · mid

  • A.训练阶段加入量化感知← 正确答案
  • B.精心构建校准数据集← 正确答案
  • C.换用 FP32 模型部署
  • D.增大批量提升吞吐

答案：AB。量化感知训练让模型适应量化噪声，精心校准让 S、Z 更准确，两者都能提升精度；FP32 模型无法在 Edge TPU 上运行，增大 batch 只影响吞吐与延迟，与精度无关。预制菜切得准不准，取决于训练时就按刀法练过。

Q10. Edge TPU 实现低功耗高效的根源是什么？

单选题 · hard

  • A.把模型交给云端服务器
  • B.专用电路加速固定算子← 正确答案
  • C.使用更小的训练数据集
  • D.提升 GPU 的浮点精度

答案：B。Edge TPU 用专用电路（ASIC）直接加速固定算子，数据通路短、无通用调度开销，因此又省又快；把模型交给云端、缩小数据集、提升 GPU 精度都与它的功耗表现无关。专用炉头只烧一道菜，自然高效。