在 Next.js 中架构 AI 异步处理：避免请求阻塞的完整方案

大多数“给应用添加 AI 超分辨率”教程的做法都一样：在组件或 route handler 里放一个 fetch()，等待结果，然后渲染。演示时一切正常。接着，真实用户上传了一张照片，请求卡了 8 秒，serverless function 超时；而且由于没有缓存，同一张图片会在每次页面加载时重新进行超分辨率处理。

问题不在模型，而在于你把调用放在了哪里。

超分辨率处理是一项生成式任务：速度慢、结果不确定，而且每处理一张图片都要花钱。它的特征与应用其他部分发起的 CRUD 调用截然不同，不应该出现在请求路径上。本文讨论的是 pipeline 的整体形态：这个步骤应该放在哪里、如何缓存，以及如何优雅地处理失败。超分辨率模型本身可以随时替换，因此我会把实际的 API 调用封装在一个函数后面，你可以让它指向任意 provider。

简短答案：不要把它放在请求路径上

整个 pipeline 用一行就能概括：

上传 → 对输入进行哈希 → 检查缓存 → 如果未命中，则将异步超分辨率任务加入队列 → 存储结果 → 由 next/image 提供最终文件。

用户的请求永远不需要等待模型。图片上传后，用户会收到一个 job ID（或者直接拿到原图），超分辨率版本准备好后再自动出现。同一个输入始终映射到同一个输出，因此每张不同的图片只需要处理一次。

要让这种方案奏效，需要具备三个特性。这也是任何高负载生成式步骤都应该具备的三个特性：

异步：超分辨率处理在后台任务中运行，而不是在 HTTP handler 中运行。

幂等：使用输入内容的哈希作为缓存键，因此重试和重复上传都不会产生额外成本。

回退优先：如果超分辨率版本不存在或处理失败，就提供原图。不会因为模型响应缓慢而出现任何 500 错误。

第 1 步：对输入进行哈希，确保只处理一次

缓存键由文件字节和缩放倍数组合后计算出的哈希构成。同一张照片以 4 倍放大时，无论来自重试、重新上传，还是两个用户上传了完全相同的图片，最终都会解析到同一个键。

// lib/upscale-key.ts
import { createHash } from "node:crypto";

export function upscaleKey(input: Buffer, scale: 2 | 4): string {
  return createHash("sha256")
    .update(input)
    .update(`@${scale}x`)
    .digest("hex");
}

这个十六进制字符串既是存储路径（upscaled/{key}.webp），也是缓存查询键。刚开始甚至不需要数据库记录，只靠对象存储的文件列表就足够了。

第 2 步：把超分辨率调用封装在一个函数后面

这是整个 pipeline 中唯一与 vendor 绑定的代码，因此更换 provider 时，只需要替换这里。函数签名保持简单即可：输入字节，输出字节。

// lib/upscale.ts
// Swap the body for whichever service you use. Read ITS docs for the
// exact endpoint, auth, and request shape. Don't copy numbers from a blog.
export async function upscaleImage(
  input: Buffer,
  scale: 2 | 4,
): Promise<Buffer> {
  const res = await fetch(process.env.UPSCALE_API_URL!, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.UPSCALE_API_KEY!}`,
      "Content-Type": "application/octet-stream",
      "x-scale": String(scale),
    },
    body: input,
  });

  if (!res.ok) {
    throw new Error(`upscale failed: ${res.status} ${res.statusText}`);
  }
  return Buffer.from(await res.arrayBuffer());
}

我刻意没有提供真实 endpoint，也没有写什么“典型延迟为 X 毫秒”，因为我没有对每家 provider 的 API 都做过基准测试，而编造的数据还不如不提供。真正重要的是它的形态：一个可能失败的异步函数，并通过封装确保 pipeline 的其他部分永远不会假设它能快速完成。

第 3 步：上传 handler 只负责入队，不负责等待

route handler 执行成本低且同步的工作，包括计算哈希、检查缓存和启动任务，然后立即返回。它永远不会等待模型。

// app/api/images/route.ts
import { NextResponse } from "next/server";
import { upscaleKey } from "@/lib/upscale-key";
import { getUpscaled, enqueueUpscale } from "@/lib/store";

export async function POST(req: Request) {
  const input = Buffer.from(await req.arrayBuffer());
  const scale = 4 as const;
  const key = upscaleKey(input, scale);

  // Cache hit: the upscaled file already exists.
  const existing = await getUpscaled(key);
  if (existing) {
    return NextResponse.json({ key, status: "ready", url: existing });
  }

  // Cache miss: store the original as the fallback, queue the job, return now.
  const originalUrl = await enqueueUpscale(key, input, scale);
  return NextResponse.json({ key, status: "processing", url: originalUrl });
}

客户端会立即渲染 url。缓存未命中时，这个 URL 指向原图：视觉上没有问题，只是暂时还没有变得更清晰。任务完成后，客户端再将其替换为超分辨率版本。你可以轮询 GET /api/images/{key}，也可以使用现有的任意 realtime channel。

真正执行耗时调用的地方是后台 worker：

// worker/upscale-job.ts
import { upscaleImage } from "@/lib/upscale";
import { putUpscaled, markFailed } from "@/lib/store";

export async function runUpscaleJob(key: string, input: Buffer, scale: 2 | 4) {
  try {
    const out = await upscaleImage(input, scale);
    await putUpscaled(key, out); // now the next request is a cache hit
  } catch (err) {
    // Fallback stays in place: the original keeps serving. Log and move on.
    await markFailed(key, String(err));
  }
}

如果任务抛出异常，没有人会看到错误页面。系统仍会把原图作为 fallback 提供；你只是没能得到更清晰的版本，而日志会告诉你具体原因。

第 4 步：让 next/image 负责图片交付

超分辨率文件存入存储系统后，它就是一张普通图片。不要自己手写图片交付逻辑。next/image 已经支持响应式尺寸、懒加载和格式协商：

import Image from "next/image";

export function Photo({ src, alt }: { src: string; alt: string }) {
  return (
    <Image
      src={src}          // cache-hit URL, or the original fallback
      alt={alt}
      width={1600}
      height={1200}
      sizes="(max-width: 768px) 100vw, 800px"
    />
  );
}

超分辨率处理为你提供尺寸更大、质量更好的源图；next/image 再根据布局实际需要，将其缩小到适当尺寸。如果先放大到 4 倍，最后却只提供一张 400px 的缩略图，那就是在浪费成本。因此，缩放倍数应该与图片实际展示时的最大尺寸相匹配。

Landing page 不会告诉你的事：超分辨率会虚构细节

这是一个值得在设计时认真考虑的限制。AI 超分辨率模型并不能找回已经丢失的细节。小图片里根本没有可供恢复的细节，因为这些信息原本就不存在。Super-resolution 模型会根据训练数据，生成看起来合理的新像素。这些都是模型幻觉出来的细节，也正因如此，经过超分辨率处理的人脸可能会显得微妙地不对劲，而处理后的 logo 甚至可能出现模型自行虚构的字形。

实际影响是：你需要筛选发送给模型的图片。超分辨率处理最适合那些本身质量尚可、只是略显模糊的图片。对于极小的缩略图和经过严重 JPEG 压缩的输入，它的表现往往不佳，因为模型会非常自信地虚构出错误内容。在任务入队前进行一次成本很低的尺寸和格式检查，既能省钱，也能避免产生糟糕的输出：

// lib/should-upscale.ts
export function shouldUpscale(bytes: number, width: number): boolean {
  const tooSmall = width < 256;          // not enough signal; it'll fabricate
  const tooLarge = bytes > 10 * 1024 * 1024; // common provider ceiling: ~10MB
  return !tooSmall && !tooLarge;
}

上面的 pipeline 与 vendor 无关。任何能够接收图片并返回更大图片的服务，都可以接入 upscaleImage()。在原型开发阶段，我一直在使用 Imagvio 的 AI image upscaler。它支持 2 倍和 4 倍放大，并宣称最高可以放大到 8 倍，支持 JPG、PNG 和 WEBP。

完整披露：这是一个独立的第三方工具，并非 OpenAI 或 Google 的产品，而且我是基于它进行开发的人。因此，请把免费套餐当作评估环境，而不是生产环境的 SLA。它很适合用来确认整个 pipeline 能否端到端运行，也适合使用你自己的真实图片直观评估输出质量；不过，在将生产流量交给任何服务之前，请先查看其服务条款，并以 provider 的文档为准确认请求细节，而不是照搬本文。

应该测量什么，而不是相信博客里给出的数字

我不会给出一个延迟数据，因为它取决于 provider、缩放倍数、输入大小，甚至当天的服务状态。请使用你自己的图片自行测量：

每种缩放倍数下的单图延迟。直接测量 upscaleImage() 的执行时间。它决定了用户会看到“processing”状态多长时间。

缓存命中率。如果命中率很低，说明你的哈希键可能有问题——你是否在某些地方对解码后的像素计算哈希，而在另一些地方对原始字节计算哈希？另一种可能是，你正在对大量近似重复的图片进行超分辨率处理。

每张超分辨率图片的成本 × 预计不同图片的数量。这里强调的是不同图片，因为有了缓存，你只需为每个唯一输入付费一次，而不是每次浏览都付费。

在你的输入上的质量。选择 10 张具有代表性的图片，分别进行 2 倍和 4 倍处理，然后直接观察结果。正确的缩放倍数不是 API 支持的最大值，而是能够获得良好效果的最小值。

超分辨率处理是一项高负载的生成式步骤，因此不要把它放在请求路径上。

对输入进行哈希，得到幂等的缓存键；每张不同的图片只处理一次。

把 vendor 隐藏在一个 upscaleImage() 函数后面，让 provider 可以随时替换。

上传 handler 负责将任务加入队列并立即返回；耗时调用交给后台任务完成。

始终保留原图作为 fallback，确保任务失败也不会破坏页面。

让 next/image 负责图片交付。

记住，模型会虚构细节，因此应该筛掉尺寸过小和压缩过度的输入。

我有意将存储和队列层（lib/store）保持为抽象形式，因为这里正是你接入现有基础设施的位置，例如 S3 + SQS、Vercel Blob + cron worker，或者 R2 + Queues。你是如何处理异步部分的？我很好奇，大家会选择真正的队列，还是一个发出后不管的 worker。欢迎在评论区分享你的方案。

我开发了一套基于浏览器的图片工具，前面提到的超分辨率工具就是其中之一。这里完整披露相关关系，方便你据此衡量这项推荐。pipeline 模式本身与 vendor 无关，可以配合你偏好的任意服务使用。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。