TC39 Float16Array 已成为 2026 年基线：JavaScript 开发者在 ML 和图形工作负载中需要了解的内容

本文在人工监督和审阅下，得到了 AI 的协助撰写。

JavaScript 新兴的 ML 和图形工作负载中的大多数性能问题源于在不匹配的数值格式之间复制数据。团队编写工作线程来解码 Float32 张量缓冲区，将其发送给期望半精度的 WebGPU 着色器，随后好奇为什么带宽在计算之前就饱和了。编译器保持沉默。着色器运行。内存压力加倍。

Float16Array 在 2024 年达到 TC39 第 4 阶段，今年获得 Baseline 2026 状态。它提供原生的 16 位 IEEE 754 半精度浮点数，支持直接的 TypedArray 操作和 DataView 集成。当工程师匹配硬件实际需要的精度时，带宽会减半，计算利用率会提升。

这一区别至关重要。WebGPU 着色器、ONNX 运行时量化以及 HDR 颜色缓冲区均以原生半精度运行。在 Float16Array 出现之前，每个 JavaScript 代码库要么使用 Float32 浪费带宽，要么编写自定义二进制打包器。如今语言自行处理格式转换。

关键要点

• Float16Array 存储具有 10 位尾数和 5 位指数的 16 位 IEEE 754 半精度浮点数，在精度代价（±65504 范围，3-4 位小数）下将内存和带宽成本减半。
• WebGPU 计算着色器和 ML 推理管道通过匹配原生半精度格式即可获得性能提升，从而消除了 GPU 驱动内部的 Float32 → Float16 转换开销。
• DataView 新增了 getFloat16 和 setFloat16 方法，用于二进制协议解析，取代了脆弱的手动位打包例程。
• Float32Array 仍是通用数值工作的默认选择；当内存带宽成为瓶颈且工作负载能够容忍降低的精度时，Float16Array 才显得重要。

理解 16 位浮点数：内存 vs 精度权衡

Float16Array 以 IEEE 754 半精度格式表示数字。每个值占用 16 位：1 位符号位，5 位指数位，10 位尾数位。指数范围为 -14 到 +15（偏置表示），可表示的范围大约为 ±65504。10 位尾数提供大约 3 到 4 位十进制精度。

精度损失是即时且不可协商的。Float32 值 3.14159265 在 Float16 中变为 3.140625。算术运算会叠加舍入误差。这不是缺陷。该格式之所以存在，是因为某些工作负载会以精度换取吞吐量。

机器学习推理和图形渲染是典型用例。使用 Float32 权重训练的神经网络在部署时常量化为 Float16，因为额外的精度对最终预测准确度没有贡献。同样，HDR 颜色缓冲区需要宽动态范围，但不需要 Float32 的 23 位尾数。10 位尾数足以满足感知颜色差异的需求。

内存优势显而易见。100 万元素的 Float32Array 消耗 4 MB。相同数据在 Float16Array 中仅需 2 MB。当该数组在 CPU 与 GPU 之间通过 PCIe 传输，或在网络中传输时，带宽成本减半。GPU 着色器内的算术单元原生以半精度运行，因此驱动在计算过程中不会将值提升回 Float32。整个流水线因此更窄且更快。

开发者必须认识到何时需要精度。金融计算、需要亚像素精度的坐标变换以及会累积误差的迭代求解器在使用 Float16 时都会失效。这不仅仅是性能偏好的问题，而是数学正确性的问题。如果算法依赖于超过 3 位十进制精度，Float16 会得到错误结果。

创建和使用 Float16Array：基本操作

Float16Array 的构造方式与 Float32Array 和 Float64Array 相同。开发者可以通过长度、ArrayBuffer、可迭代对象或复制另一个 TypedArray 来创建实例。其 API 接口与其他类型数组保持一致，因此从 Float32 迁移非常直接。

// Create a new Float16Array with 5 elements
const tensor = new Float16Array(5);
tensor[0] = 1.5;
tensor[1] = -3.14159;
tensor[2] = 0.001;
tensor[3] = 65000;
tensor[4] = 100000; // exceeds max representable value

console.log(tensor);
// Float16Array(5) [ 1.5, -3.140625, 0.0009765625, 65504, Infinity ]

// Create from existing Float32 data
const float32Data = new Float32Array([2.5, 3.7, 4.9]);
const quantized = new Float16Array(float32Data);
console.log(quantized);
// Float16Array(3) [ 2.5, 3.69921875, 4.89453125 ]

// Share an underlying ArrayBuffer
const buffer = new ArrayBuffer(16);
const view16 = new Float16Array(buffer);
const view32 = new Float32Array(buffer);
view16[0] = 1.5;
console.log(view32[0]);
// Output depends on byte interpretation — demonstrates shared storage

量化在赋值过程中自动进行。当出现超出可表示范围的值时，Float16Array 会将其钳位到 ±65504，或将其表示为 Infinity。精度超过 10 位的值会四舍五入到最近的可表示 Float16。整个过程不会产生警告或错误，这种静默截断正是设计所致。

类型化数组的方法无需修改即可使用。map、filter、reduce、slice 和 subarray 均能按预期工作。唯一的限制是，每次产生新 Float16Array 的操作都会对结果进行量化。相同的算术步骤链相比 Float32 会更快地累积舍入误差。

const original = new Float16Array([1.1, 2.2, 3.3, 4.4, 5.5]);

const doubled = original.map(x => x * 2);
console.log(doubled);
// Float16Array(5) [ 2.19921875, 4.3984375, 6.59765625, 8.796875, 11 ]

const sum = original.reduce((acc, val) => acc + val, 0);
console.log(sum);
// 16.5 (accumulated rounding)

const slice = original.slice(1, 4);
console.log(slice);
// Float16Array(3) [ 2.19921875, 3.30078125, 4.3984375 ]

遍历方式与其他类型化数组完全一致。for...of、解构和展开语法都能照常使用。唯一区别是：取出的每个值都带有 Float16 精度。

Float16Array、Float32Array 与 Float64Array：分别该用在什么场景

在 Float16Array、Float32Array 和 Float64Array 之间做选择，要权衡精度需求、内存限制和硬件能力。三者各有分工，选错了格式，要么浪费资源，要么得出错误结果。

Float64Array 是科学计算、金融运算以及需要亚毫米级精度的坐标系统的默认选择。要迭代数千次的模拟，需要额外的尾数位来防止误差累积。在正确性优先的场景下，每元素 8 字节的存储开销完全可以接受。JavaScript 的 Number 运算内部大多基于 Float64，因此 Float64Array 在纯 JS 计算中还能避免类型转换开销。

Float32Array 覆盖了大部分图形、音频处理和常规数值工作。WebGL 缓冲区、Web Audio 节点和物理引擎默认都以 Float32 运行。4 字节的大小在精度和内存之间取得了平衡。6 到 9 位十进制精度的尾数，足以应付渲染变换、光照计算和信号处理。当精度重要但 Float64 又过于奢侈时，Float32 就是主力格式。

Float16Array 面向的是带宽受限且精度可放宽的流水线。运行在移动 GPU 上的 WebGPU 计算着色器立刻就能受益——硬件执行半精度运算的吞吐量是 Float32 的两倍。神经网络推理同样能获益：只要模型本身采用混合精度训练，或是训练后做过量化。WebGL 中的 HDR 帧缓冲需要宽动态范围来做色调映射，但并不要求 23 位色深精度。

踩坑的方式很隐蔽。开发者把 Float32 物理模拟迁移到 Float16 以节省内存后，会遇到物体漂移、碰撞失效、积分器发散——精度损失破坏了算法赖以成立的数值稳定性假设。反过来，把 Float32 张量发给期望 Float16 的 WebGPU 着色器，则会浪费带宽。GPU 驱动会在内部做转换，但 PCIe 传输量和内存占用依然是原来的两倍。

这意味着格式选择首先是正确性决策，其次才是优化。先以 Float32 作为默认。只有在性能分析显示内存或带宽压力且工作负载能够容忍精度下降时，才转向 Float16。对于在 Float32 中已证明数值不稳定的算法，保留使用 Float64。

机器学习工作负载：WebGPU 集成与张量运算

WebGPU 计算着色器以半精度原生执行张量运算。当 JavaScript 代码加载预训练模型并进行推理时，将张量格式与着色器的期望匹配可以消除转换开销。Float16Array 使这种直接交互成为可能。

这一模式在 ONNX Runtime Web、带有 WebGPU 后端的 TensorFlow.js 以及自定义计算管道中均可见。使用自动混合精度在 PyTorch 中训练的模型会生成 Float16 权重。导出的 ONNX 图指定了半精度运算。JavaScript 代码将这些权重反序列化为 Float16Array，并直接上传到 GPU 缓冲区，无需格式转换。

// Load pre-quantized model weights
async function loadModelWeights(url: string): Promise<Float16Array> {
  const response = await fetch(url);
  const buffer = await response.arrayBuffer();
  return new Float16Array(buffer);
}

// Create WebGPU buffer from Float16 tensor
async function uploadTensorToGPU(
  device: GPUDevice,
  tensor: Float16Array
): Promise<GPUBuffer> {
  const buffer = device.createBuffer({
    size: tensor.byteLength,
    usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_DST,
  });

  device.queue.writeBuffer(buffer, 0, tensor);
  return buffer;
}

// Inference pipeline
async function runInference(
  device: GPUDevice,
  weights: Float16Array,
  input: Float16Array
): Promise<Float16Array> {
  const weightBuffer = await uploadTensorToGPU(device, weights);
  const inputBuffer = await uploadTensorToGPU(device, input);

  const outputBuffer = device.createBuffer({
    size: input.byteLength,
    usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_SRC,
  });

  // Shader execution omitted for brevity — assume GEMM kernel
  // reads from weightBuffer and inputBuffer, writes to outputBuffer

  // Read result back
  const resultBuffer = device.createBuffer({
    size: input.byteLength,
    usage: GPUBufferUsage.MAP_READ | GPUBufferUsage.COPY_DST,
  });

  const commandEncoder = device.createCommandEncoder();
  commandEncoder.copyBufferToBuffer(
    outputBuffer, 0,
    resultBuffer, 0,
    input.byteLength
  );
  device.queue.submit([commandEncoder.finish()]);

  await resultBuffer.mapAsync(GPUMapMode.READ);
  const result = new Float16Array(resultBuffer.getMappedRange().slice(0));
  resultBuffer.unmap();

  return result;
}