1. 从标题拆解：Positron 到底想解决什么问题

第一次看到 “Positron – Purpose-built hardware for the age of generative AI” 这个标题，我的直觉是：又一家做 AI 加速硬件的公司。但仔细琢磨 “purpose-built” 这个词，它和市面上大多数 “general-purpose GPU 也能跑 AI” 的说法是站在对立面的。通用硬件追求的是灵活，什么都能干；专用硬件追求的是在特定负载上把效率压榨到极致。Positron 选择的是后者，而且它瞄准的负载非常明确——生成式 AI 的推理，尤其是 Transformer 架构的推理。

为什么这件事值得单独拿出来做硬件？我们得先理解生成式 AI 推理和传统深度学习推理的本质差异。传统 CNN 推理（比如图像分类、目标检测）是计算密集型的，算力瓶颈在矩阵乘法的吞吐上，GPU 的并行能力正好对口。但 Transformer 推理，尤其是自回归生成（autoregressive generation）阶段，瓶颈根本不在算力，而在显存带宽。每生成一个 token，模型都要把全部权重从显存里读一遍，然后和当前的激活值做一次矩阵向量乘。这个过程中，计算量很小，但数据搬运量巨大。用个生活化的类比：GPU 像一个超级能算的会计，但你每让他算一笔账，都得把整本账册从仓库搬到他的办公桌上，搬书的时间远远超过算账的时间。

这就是 Positron 这类专用硬件的切入点。它不需要像 GPU 那样堆砌海量算力核心去应付训练任务，而是把设计重心放在内存子系统的带宽、容量和访问效率上，让权重读取这件事变得尽可能快、尽可能省电。标题里的 “for the age of generative AI” 不是营销话术，而是在说：过去为训练和通用计算设计的硬件，在推理这个场景下性价比已经不够看了，需要重新设计。

这篇文章我会从几个层面展开：先讲清楚 Positron 这类专用推理硬件的设计逻辑和它要替代的方案，再拆解 Transformer 推理的核心技术点（这也是理解硬件设计的前提），然后给出一个可复现的实操路径——怎么在类似硬件或替代方案上跑通一个生成式 AI 推理服务，包括 OpenAI API 兼容层的搭建。最后是我在实际折腾这类方案时踩过的坑和排查经验。适合对 AI 硬件、推理优化、Transformer 部署感兴趣的读者，不管你是刚入门还是已经在做推理服务，都能拿到能直接用的东西。

2. 专用推理硬件的设计逻辑与方案选型

2.1 为什么通用 GPU 在推理场景下开始吃力

要理解 Positron 的价值，得先承认一个事实：GPU 不是为推理生的。NVIDIA 的 GPU 架构从设计之初就是为图形渲染和通用并行计算服务的，它的 SM（Streaming Multiprocessor）结构、寄存器文件、缓存层级，都是围绕 “高吞吐、可编程” 这个目标来的。训练大模型时，这种通用性带来了巨大的灵活性——你可以用同一块卡跑不同的模型、不同的并行策略。但到了推理阶段，尤其是线上服务阶段，这种通用性反而成了负担。

具体来说有几个问题。第一是功耗。一块高端 GPU 的 TDP 动辄 300W 到 700W，但推理时真正用于有效计算的功耗占比可能不到一半，大量功耗花在了数据搬运和缓存一致性维护上。第二是成本。训练可以接受高成本硬件，因为一次训练产出的是一个模型，可以服务很久；但推理是持续运营成本，每 token 的成本直接决定商业模式能不能跑通。第三是利用率。GPU 的算力核心在自回归生成阶段大量闲置，因为瓶颈在显存带宽，算力根本用不满。你花大价钱买的算力，大部分时间在等数据。

Positron 这类专用硬件的思路就是：既然推理的瓶颈在内存，那我就把成本花在内存子系统上，算力核心够用就行。这就像你不需要一辆 F1 赛车去送外卖，一辆优化过电池和储物空间的电动车反而更合适。

2.2 Positron 的核心设计取向：内存优先

从公开信息和行业常见做法推断，Positron 的硬件设计大概率围绕几个关键点展开。首先是高带宽内存接口。Transformer 推理的 decode 阶段，每生成一个 token 需要读取的权重数据量等于模型参数量乘以精度字节数。一个 70B 参数的模型，如果用 FP16 存储，权重就是 140GB。每生成一个 token 就要把这 140GB 读一遍。如果内存带宽是 1TB/s，那理论上每秒最多生成 7 个 token 左右。带宽直接决定了吞吐上限。所以专用推理硬件会把内存带宽做到尽可能高，可能是 HBM 方案，也可能是大容量高带宽的 DDR 方案，取决于成本定位。

其次是内存容量。模型权重必须全部放在内存里，否则就要频繁从外部存储加载，延迟会爆炸。70B 模型 FP16 需要 140GB，INT8 量化后 70GB，INT4 量化后 35GB。硬件的内存容量设计必须覆盖目标模型规模。Positron 如果定位在中大规模模型推理，内存容量至少要在 64GB 到 256GB 这个区间。

第三是能效比。专用硬件的一个核心卖点就是每瓦性能。通过去掉通用计算不需要的模块、优化数据通路、减少不必要的缓存层级，可以在相同功耗下提供更高的有效推理吞吐。这对于大规模部署推理服务的数据中心来说，直接意味着电费和散热成本的下降。

2.3 方案选型：什么场景该考虑专用推理硬件

不是所有场景都适合上专用推理硬件。我总结了一个简单的判断框架，你可以对照自己的情况看。

如果你的业务是每天跑固定的几个模型做推理，而且量很大，那专用硬件的成本优势会非常明显。但如果你还在频繁试模型、做研究，通用 GPU 的灵活性无可替代。Positron 这类产品的目标客户，大概率是已经有稳定推理负载、正在被 GPU 成本和功耗困扰的团队。

3. Transformer 推理的核心技术点拆解

3.1 自回归生成的两个阶段：Prefill 和 Decode

要理解为什么硬件要这样设计，必须搞清楚 Transformer 推理的两个阶段。这两个阶段的负载特征完全不同，对硬件的要求也不一样。

Prefill 阶段是处理输入 prompt 的阶段。用户输入一段话，模型要把这段所有 token 一次性送进去，计算它们的注意力。这个阶段是计算密集型的，因为所有 token 可以并行处理，矩阵乘法规模大，GPU 或专用硬件的算力核心能跑满。这个阶段的瓶颈在算力。

Decode 阶段是逐 token 生成的阶段。模型根据已有的上下文，生成下一个 token，然后把这个 token 追加到上下文里，再生成下一个，循环往复。这个阶段每次只处理一个 token，矩阵乘法的规模退化成矩阵向量乘，算力核心大量闲置，瓶颈完全转移到内存带宽上。每生成一个 token，都要把全部权重读一遍。

这两个阶段的耗时占比取决于输入输出长度。如果输入很长、输出很短，Prefill 占主导；如果输入短、输出长（比如聊天场景），Decode 占主导。Positron 这类硬件如果主打生成式 AI，那它必须对 Decode 阶段做深度优化，因为这才是生成式 AI 的典型负载。

3.2 KV Cache：内存占用的隐形杀手

除了模型权重，Transformer 推理还有一个内存消耗大户：KV Cache。在自回归生成过程中，为了避免重复计算，模型会把之前所有 token 的 Key 和 Value 向量缓存下来。每生成一个新 token，只需要计算当前 token 的 Query，然后和缓存的 K、V 做注意力计算。

KV Cache 的大小和序列长度成正比。公式是：KV Cache 大小 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数。以一个 70B 模型为例，假设 80 层、64 个头、头维度 128，序列长度 4096，FP16 精度，那 KV Cache 大约是 2 × 80 × 64 × 128 × 4096 × 2 字节，算下来超过 10GB。如果并发服务多个用户，每个用户一个序列，KV Cache 会线性增长。这就是为什么推理服务的内存容量规划不能只看模型权重，还要留足 KV Cache 的空间。

专用推理硬件在设计时，必须把 KV Cache 的存储和访问也考虑进去。有些方案会把 KV Cache 放在单独的存储层级，用更高的带宽去访问，避免和权重读取抢带宽。

3.3 量化：用精度换效率和容量

量化是推理优化的核心手段之一。简单说，就是把模型权重和激活值从高精度（如 FP32、FP16）转换成低精度（如 INT8、INT4）。这样做有两个好处：一是减少内存占用，INT8 比 FP16 省一半空间，INT4 再省一半；二是减少内存带宽压力，每次读取的数据量变小了，decode 阶段的瓶颈就能缓解。

但量化不是免费的午餐。精度降低会带来模型效果下降，尤其是 INT4 量化，如果做得粗糙，模型可能会变傻。常见的做法是 GPTQ、AWQ 这类训练后量化方法，它们会针对权重的重要性做差异化处理，对效果影响大的权重保留较高精度，对影响小的权重压到更低精度。Positron 这类硬件如果原生支持低精度计算，那量化模型的推理效率会更高。

我在实际项目里试过 INT8 量化一个 13B 模型，效果损失基本可以忽略，但内存占用直接减半，decode 速度提升了接近 80%。INT4 的话，效果损失开始明显，需要仔细调量化参数，但内存占用只有 FP16 的四分之一，对于内存受限的场景非常香。

4. 实操：搭建一个可复现的生成式 AI 推理服务

4.1 环境准备与依赖安装

这一节我给出一个可以在类似专用硬件或替代方案上复现的推理服务搭建流程。核心目标是：跑通一个 Transformer 模型的推理，并对外提供 OpenAI API 兼容的接口。这样你现有的基于 OpenAI API 的应用代码几乎不用改就能迁移过来。

先准备基础环境。假设你用的是 Linux 系统，有 Python 3.10 以上。我习惯用 conda 管理环境，避免依赖冲突。

conda create -n positron-infer python=3.10 -y conda activate positron-infer

然后安装推理框架。目前主流的选择有 vLLM、TensorRT-LLM、HuggingFace TGI 等。vLLM 的优势是部署简单、对 OpenAI API 兼容好、社区活跃，我下面以 vLLM 为例。如果你用的是特定厂商的专用硬件，通常厂商会提供适配好的推理框架，优先用厂商推荐的。

pip install vllm

如果你需要 OpenAI API 兼容层，vLLM 本身就内置了 OpenAI 兼容的 server，不需要额外装。但如果你要自己写一层做定制，可以装 openai 库做客户端测试。

pip install openai

注意：安装 vLLM 时要注意 CUDA 版本或硬件厂商 SDK 版本的匹配。版本不匹配是后续各种诡异报错的头号原因。装之前先确认硬件的驱动和运行时版本。

4.2 模型下载与量化处理

模型可以从 HuggingFace 或 ModelScope 下载。以一个小规模模型为例，方便快速验证。如果你有专用硬件，可以换成更大的模型测试真实性能。

# 用 huggingface-cli 下载，先安装 pip install huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/qwen2.5-7b

如果你要做量化，可以用 GPTQ 或 AWQ 的预量化模型，直接下载量化版本，省去自己量化的时间。比如搜索 “Qwen2.5-7B-Instruct-GPTQ-Int4” 这类模型名。自己量化的话，可以用 auto-gptq 或 autoawq 库，但需要额外的校准数据集，流程较长，建议先用现成的量化模型验证流程。

实操心得：下载大模型时一定要检查磁盘空间和下载完整性。我遇到过下载中断导致模型文件损坏，加载时报各种奇怪的 shape mismatch，排查了半天才发现是文件不完整。下载完可以用 sha256 校验，或者至少确认文件大小和官方标注一致。

4.3 启动推理服务并配置 OpenAI 兼容接口

vLLM 启动 OpenAI 兼容服务的命令很直接：

python -m vllm.entrypoints.openai.api_server \ --model ./models/qwen2.5-7b \ --served-model-name qwen2.5-7b \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9

几个关键参数解释一下。--max-model-len是最大序列长度，决定了 KV Cache 的上限，设太大浪费内存，设太小长文本会报错。--gpu-memory-utilization是内存使用比例，0.9 表示用 90% 的显存或专用内存，留一点给系统。如果是专用硬件，参数名可能不同，但逻辑类似。

启动后，服务会在 8000 端口监听，提供和 OpenAI API 一样的接口。你可以用 curl 测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-7b", "messages": [{"role": "user", "content": "用一句话解释什么是 Transformer"}], "temperature": 0.7 }'

4.4 用 OpenAI 客户端调用本地服务

如果你现有代码用的是 OpenAI 的 Python SDK，只需要改两个地方：base_url 和 api_key。api_key 随便填一个非空字符串就行，本地服务不校验。

from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="not-needed" ) response = client.chat.completions.create( model="qwen2.5-7b", messages=[ {"role": "system", "content": "你是一个简洁的助手。"}, {"role": "user", "content": "解释一下 KV Cache 的作用"} ], temperature=0.7, max_tokens=256 ) print(response.choices[0].message.content)

这样你的应用代码几乎不用动，就能从调用云端 API 切换到本地专用硬件推理。对于成本敏感或者数据不能出本地的场景，这个迁移路径非常实用。

提示：关于 OpenAI API Key 的获取，如果你要调用云端服务，去官方平台申请即可。但本文的重点是本地推理，本地服务不需要真实 key。千万不要把云端 key 硬编码在代码里，用环境变量管理。

5. 常见问题与排查技巧实录

5.1 硬件驱动加载失败怎么排查

专用硬件最常见的问题就是驱动加载失败。表现可能是系统识别不到设备，或者推理框架报 “no device found”。排查思路我整理成一个速查表。

我踩过最坑的一次是驱动版本和推理框架要求的版本差了一个小版本号，表面上看设备识别正常，但一跑推理就段错误。后来对着厂商的兼容性矩阵逐个核对才找到问题。所以强烈建议：装之前先看厂商的兼容性文档，别凭感觉装最新版。

5.2 推理速度不达预期的优化路径

如果你发现推理速度比预期慢很多，按这个顺序排查。先确认瓶颈在 Prefill 还是 Decode。如果输入短输出长但速度慢，那瓶颈在 Decode，重点看内存带宽利用率和量化是否生效。如果输入长时慢，那瓶颈在 Prefill，看算力利用率。

然后检查量化是否真的生效。有时候你加载了量化模型，但推理框架没启用对应的低精度计算内核，实际还是按高精度算的，白白浪费了量化带来的带宽优势。可以看框架的日志，确认用的计算精度。

再检查 batch size 和并发配置。Decode 阶段如果 batch size 太小，内存带宽利用率上不去。适当增大并发请求数，让多个序列的 decode 并行，可以显著提升内存带宽利用率。这也是为什么推理服务通常要做 continuous batching。

最后看 KV Cache 的管理。如果 KV Cache 频繁换入换出，或者碎片化严重，会拖慢速度。vLLM 的 PagedAttention 就是解决这个问题的，它把 KV Cache 分页管理，减少碎片。如果你用的框架没有类似机制，可以考虑换框架。

5.3 模型输出质量下降的排查

量化之后如果发现模型变傻，先确认是不是量化导致的。用同样的 prompt 分别跑 FP16 和量化版本，对比输出。如果确实是量化问题，可以尝试更温和的量化方法，比如从 INT4 换到 INT8，或者用 AWQ 替代 GPTQ。

还有一个容易被忽略的点是 temperature 和 top_p 等采样参数。不同推理框架对这些参数的默认值可能不同，迁移时如果没显式设置，输出风格会变。建议在代码里显式指定所有采样参数，保证行为一致。

实操心得：我在迁移一个客服机器人到本地推理时，发现回答变得很啰嗦。排查后发现是框架默认的 repetition_penalty 和原来云端 API 不一样。显式设置成一样的值之后，输出风格就对齐了。这种问题不看日志根本想不到。

6. 我对这类专用推理硬件的实际体会

折腾了这段时间，我最大的感受是：生成式 AI 的推理优化，本质上是一场和内存带宽的战争。算力早就过剩了，真正卡脖子的是数据搬运。Positron 这类专用硬件的价值，不在于它算得多快，而在于它把每一分成本都花在了刀刃上——让权重读取更快、更省电、更便宜。

对于正在做推理服务的团队，我的建议是：先用量化把模型压小，再用 continuous batching 把并发做上去，最后才考虑换硬件。软件层面的优化往往能带来几倍的提升，而且成本几乎为零。等软件优化做到头了，再上专用硬件，这时候硬件的收益才能最大化。

另外，OpenAI API 兼容层这件事比想象中重要。它让你的应用代码和推理后端解耦，今天用云端，明天换本地，后天换另一家硬件，代码都不用大改。这个抽象层值得在项目早期就做好。

最后分享一个小技巧：压测推理服务时，不要只用短 prompt。生成式 AI 的真实负载往往是长输入长输出，Prefill 和 Decode 都会吃满。用真实业务数据做压测，才能暴露真正的瓶颈。我见过太多人用 “你好” 做压测，结果上线后被长文本打爆的案例。