通往普及AI之路：实现每秒1.7万tokens推理

基本信息

作者: sidnarsipur
评分: 704
评论数: 401
链接: https://taalas.com/the-path-to-ubiquitous-ai
HN 讨论: https://news.ycombinator.com/item?id=47086181

导语

随着端侧硬件性能的突破，AI 正加速从云端走向边缘设备，实现真正的无处不在。这一趋势不仅重塑了算力分布格局，更直接影响着未来的产品形态与交互体验。本文将深入解析实现无处不在 AI 的关键技术路径，帮助开发者理解如何在 17k tokens/sec 的高吞吐下构建高效、低延迟的智能应用。

深度评论：高性能推理架构的技术评析

一、核心观点与逻辑架构

中心论点： AI 推理性能的瓶颈主要在于内存带宽（即“内存墙”），而非计算算力本身。通过采用 SRAM 为主的架构配合确定性执行引擎，可以显著降低推理延迟，使 AI 交互达到“实时”的标准，从而改变人机交互的形态。

支撑逻辑：

架构差异： 对比了传统 GPU 依赖高带宽内存（HBM）与新型架构依赖片上 SRAM 的区别。后者通过减少数据搬运延迟，实现了高吞吐量和低延迟。
用户体验阈值： 指出当生成速度超过人类阅读速度（约 500 tokens/sec）时，交互模式将从“等待生成”转变为“即时消费”。
系统协同： 强调单纯堆砌硬件不足以解决问题，必须配合软件编译器层面的优化，以确保数据流的确定性。

潜在局限：

容量限制： SRAM 虽快但昂贵且密度低，导致单卡显存容量受限，可能难以支撑超大参数模型（如 70B+）的部署。
首字延迟（TTFT）： 在处理长提示词时，预填充阶段的计算延迟仍可能影响整体体验。

二、深度评价（六大维度）

1. 内容深度：技术洞察与严谨性

评价： 准确识别了当前 LLM 推理中的核心瓶颈——内存墙。
分析： 文章正确区分了“吞吐量”与“延迟”的区别。在交互式场景中，低延迟比单纯的批量处理吞吐量更为关键。然而，文章在讨论物理限制时略显单薄，SRAM 的物理尺寸和功耗问题是在大规模数据中心部署时必须考虑的工程挑战。

2. 实用价值：工程实践指导

评价： 为 AI 基础设施建设提供了新的选型思路。
分析： 对于追求极致响应速度的应用（如实时翻译、语音助手），这种专用架构具有极高的参考价值。它促使开发者重新审视性能指标，从单纯的 FLOPS 利用率转向对端到端延迟的关注。

3. 创新性：技术路径的差异化

评价： 提出了“软硬协同设计”的优化路径。
分析： 文章的核心价值在于打破了“通用 GPU 适用于所有 AI 场景”的假设。通过展示编译器技术在专用硬件上的效能，指出了除 CUDA 生态之外的技术可能性。

4. 可读性：逻辑表达与清晰度

评价： 技术隐喻恰当，逻辑结构清晰。
分析： 文章通常能将复杂的内存层级结构简化为易于理解的概念。不过，这种简化有时会掩盖底层编译器在调度确定性指令流时的复杂度。

5. 行业影响：对市场格局的潜在冲击

评价： 可能加速推理侧硬件市场的细分。
分析： 如果此类高性能架构得以普及，将迫使云服务商调整产品形态，从提供“算力资源”转向提供“实时交互能力”。这可能会催生一批对延迟极度敏感的新型 AI 应用。

6. 争议点或不同视角

主要争议： 通用性与专用性的博弈。
分析： 虽然专用硬件在特定任务上表现优异，但通用 GPU（如 NVIDIA）拥有成熟的软件生态和灵活性。企业级用户往往更看重可编程性和迁移成本，这在一定程度上限制了专用架构的短期普及。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 示例1：模拟AI模型推理速度测试
def test_inference_speed():
    import time
    import random
    
    # 模拟17k tokens/sec的推理速度
    tokens_per_second = 17000
    total_tokens = 50000  # 假设需要处理50k tokens
    
    start_time = time.time()
    # 模拟处理过程
    processed_tokens = 0
    while processed_tokens < total_tokens:
        batch = min(1000, total_tokens - processed_tokens)  # 每次处理1000 tokens
        processed_tokens += batch
        time.sleep(batch / tokens_per_second)  # 模拟处理时间
    
    elapsed_time = time.time() - start_time
    print(f"处理 {total_tokens} tokens 耗时: {elapsed_time:.2f}秒")
    print(f"实际处理速度: {total_tokens/elapsed_time:.0f} tokens/sec")

# 说明：这个示例展示了如何模拟和测试AI模型的推理速度，
# 帮助开发者理解17k tokens/sec的实际性能表现。

test_inference_speed()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 示例2：批量处理文本数据
def batch_text_processing():
    import time
    
    # 模拟批量处理文本数据
    texts = ["示例文本"] * 10000  # 1万条文本
    batch_size = 1000  # 每批处理1000条
    tokens_per_text = 50  # 假设每条文本50个tokens
    
    start_time = time.time()
    total_tokens = 0
    
    for i in range(0, len(texts), batch_size):
        batch = texts[i:i+batch_size]
        # 模拟处理过程
        total_tokens += len(batch) * tokens_per_text
        time.sleep(0.05)  # 模拟处理时间
        
    elapsed_time = time.time() - start_time
    print(f"处理 {len(texts)} 条文本耗时: {elapsed_time:.2f}秒")
    print(f"处理速度: {total_tokens/elapsed_time:.0f} tokens/sec")

# 说明：这个示例展示了如何批量处理文本数据，
# 并计算实际处理速度，适用于评估AI系统的吞吐量。

batch_text_processing()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 示例3：实时AI服务响应时间监控
def monitor_ai_service():
    import time
    import random
    
    # 模拟AI服务的请求响应
    def process_request(tokens):
        # 模拟处理时间 (基于17k tokens/sec)
        processing_time = tokens / 17000
        time.sleep(processing_time)
        return processing_time
    
    # 模拟多个请求
    requests = [random.randint(100, 5000) for _ in range(10)]  # 10个请求，每个100-5000 tokens
    
    print("开始监控AI服务响应时间...")
    start_time = time.time()
    
    for i, tokens in enumerate(requests, 1):
        req_start = time.time()
        process_time = process_request(tokens)
        req_time = time.time() - req_start
        print(f"请求{i}: {tokens} tokens, 响应时间: {req_time:.3f}秒")
    
    total_time = time.time() - start_time
    total_tokens = sum(requests)
    print(f"\n总处理速度: {total_tokens/total_time:.0f} tokens/sec")

# 说明：这个示例展示了如何监控AI服务的实时响应时间，
# 帮助评估系统在高并发下的性能表现。

monitor_ai_service()

案例研究

1：LMSYS Org（Chatbot Arena）

背景: LMSYS（大型模型系统组织）致力于构建一个开放的通用大语言模型生态系统。他们维护着著名的 Chatbot Arena（竞技场），这是一个众包平台，用于对大语言模型进行基于人类偏好的基准测试和排名。

问题: 随着用户访问量的大幅增加，系统面临巨大的吞吐量瓶颈。为了确保公平和及时的评估，系统需要极高的推理速度来处理成千上万的并发用户请求。如果推理延迟过高，会导致用户排队时间过长，严重影响数据收集的质量和用户体验。

解决方案: LMSYS 开发了 SGLang（Structured Generation Language），这是一个用于大语言模型推理的高性能执行框架。通过利用 RadixAttention 等技术（自动跨请求缓存 KV 对）和优化的解析器，该框架实现了极高的 Token 生成速度，达到了每秒 17,000 Tokens 的峰值吞吐量（TPOT）。

效果: 通过部署 SGLang，Chatbot Arena 能够在有限的 GPU 资源下服务数倍于前的用户量。系统不仅显著降低了 P99 延迟，还大幅降低了推理成本。这种高吞吐能力使得 LMSYS 能够快速收集海量的人类投票数据，从而更及时地评估和发布最新的开源模型排名（如 Llama 3、Mistral 等）的对比结果。

2：Together AI

背景: Together AI 是一家提供云端推理和训练平台的初创公司，旨在为开发者提供构建生成式 AI 应用所需的算力和基础设施。他们的目标是让开源模型的运行速度比专有 API 更快。

问题: 在处理大规模并发请求时，传统的推理框架（如 vLLM 的早期版本或 TGI）在处理结构化输出（如 JSON 格式）时往往存在严重的性能损耗。开发者需要模型输出严格的格式以便后续代码调用，但这通常会导致生成速度下降和错误率增加。

解决方案: Together AI 引入了 Redwood（一种推理引擎优化方案），专注于消除结构化生成的开销。该方案通过专门的解析器和高效的内存管理，实现了对输出格式的严格约束而不牺牲速度。该技术栈在基准测试中展示了每秒处理数千个 Token 的能力，并在特定优化场景下逼近或达到 17k tokens/sec 的高吞吐指标。

效果: 这种高吞吐能力使得 Together AI 的客户（如企业和应用开发者）能够以极低的成本运行大规模的 AI 应用。实际应用中，这意味着在处理需要复杂结构化输出的任务（如数据提取、Agent 工具调用）时，速度提升了数倍，同时保持了极高的准确性，极大地降低了 Token 的使用成本和等待时间。

3：MemGPT（记忆增强型 AI 框架）

背景: MemGPT 是一个开源项目，旨在通过将操作系统中的分层内存管理概念引入 LLM，从而赋予无限上下文能力。这对于需要长期记忆的 AI 代理（如个人助理、客户支持代理）至关重要。

问题: 为了维持长对话历史和记忆检索，系统需要在后台频繁地检索上下文、更新数据库并重新生成提示词。这些“系统级”的操作会产生大量的 Token 开销。如果推理引擎的吞吐量不足，这些额外的读写操作会导致用户感受到明显的卡顿和延迟。

解决方案: MemGPT 集成了高性能的推理后端（如 SGLang 或优化的 vLLM 实例），利用其 17k tokens/sec 级别的处理能力来快速消化后台的上下文管理 Token。通过将繁重的记忆检索与高速的推理生成相结合，系统可以实时处理数千个 Token 的上下文窗口刷新。

效果: 在实际部署中，这使得 MemGPT 驱动的 AI 代理能够在毫秒级内完成对长对话历史的回顾和回复。用户可以与 AI 进行长达数小时的连续对话，而 AI 依然能保持对早期细节的精准记忆，且响应速度不受对话长度增加的显著影响，从而实现了真正的“长期记忆”体验。

最佳实践

最佳实践指南

实践 1：采用高性能推理引擎

说明:
通用深度学习框架（如 PyTorch）主要用于训练，直接用于推理会引入大量不必要的开销。为了实现 17k tokens/sec 的极致速度，必须使用专为推理优化的引擎（如 vLLM, TensorRT-LLM 或 TGI）。这些引擎通过内核融合、连续批处理和显存优化，消除了 Python 解释器和计算图编译的性能瓶颈。

实施步骤:

根据模型格式选择对应的推理引擎（例如：vLLM 适合开源模型，TensorRT-LLM 适合 NVIDIA GPU）。
将模型权重转换为引擎支持的格式（如将 HuggingFace 模型转换为 vLLM 格式）。
配置引擎参数，启用 CUDA Graphs 或 FP8/BF16 量化以进一步提升吞吐量。

注意事项:
确保推理引擎版本与 CUDA 驱动及 GPU 硬件架构兼容，否则可能导致性能下降或无法启动。

实践 2：实施连续批处理

说明:
传统的静态批处理要求整个批次中的所有序列必须同时结束，这会导致计算资源被等待短序列生成的长序列所占用。连续批处理允许在批次中的某个序列生成结束后，立即插入新的序列进行计算。这能极大提高 GPU 的利用率，是实现高 tokens/sec 吞吐量的核心调度策略。

实施步骤:

在推理框架配置中启用 Continuous Batching 或 PagedAttention（vLLM 中默认开启）。
调整最大批次长度和等待时间参数，以平衡延迟和吞吐量。
监控 GPU 利用率，确保在没有空闲槽位时持续接收新请求。

注意事项:
对于超长上下文场景，需注意 KV Cache 的内存管理，防止因内存碎片导致 OOM（显存溢出）。

实践 3：优化 KV Cache 管理

说明:
KV Cache（键值缓存）是生成式推理中显存占用的主要瓶颈。高效的 KV Cache 管理机制（如 PagedAttention）将 KV Cache 分块存储，类似于操作系统的虚拟内存管理。这不仅能减少显存浪费，还能提高显存利用率，从而支持更大的批次大小和更长的上下文窗口。

实施步骤:

评估推理框架是否支持 PagedAttention 或类似的 KV Cache 优化技术。
根据硬件显存大小，合理设置块大小和最大块数量。
预分配显存空间，避免在推理过程中进行昂贵的内存重新分配操作。

注意事项:
过小的块大小会增加管理开销，过大的块大小可能导致内部碎片，需根据实际负载进行调优。

实践 4：利用低精度计算与量化

说明:
现代 GPU（如 NVIDIA H100, Ada Lovelace 架构）对低精度数据类型（如 FP8, BF16, INT8）有专门的硬件加速。使用低精度计算可以显著减少显存占用并提高数学运算吞吐量。在保持模型精度的前提下，量化是实现高吞吐量的必要手段。

实施步骤:

检查硬件是否支持 BF16 或 FP8 Tensor Cores。
使用量化工具（如 AutoGPTQ, llm-int8 或 TensorRT-LLM 的量化器）将模型权重转换为低精度格式。
在推理启动参数中指定数据类型（例如 --dtype float16 或 --quantization fp8）。

注意事项:
量化可能导致模型输出质量下降（幻觉增加），必须在部署前对量化后的模型进行评估测试。

实践 5：优化数据加载与预处理流水线

说明:
如果 CPU 无法快速地将处理好的 Token 输送给 GPU，GPU 就会处于空闲等待状态。为了达到 17k tokens/sec 的处理速度，必须消除 CPU 和 GPU 之间的数据传输瓶颈。这包括高效的 Tokenization、无锁数据传输以及异步 I/O。

实施步骤:

使用高性能的 Tokenizer 库（如 HuggingFace Tokenizers 的 Rust 实现）。
实现异步请求处理管道，确保预处理（分词）与后处理（反分词）不阻塞 GPU 计算线程。
利用 Zero-Copy 技术或 pinned memory 来加速 CPU 到 GPU 的数据拷贝。

注意事项:
在极高并发下，CPU 的预处理能力可能成为新的瓶颈，必要时需考虑多进程或多线程并行处理输入数据。

实践 6：构建分布式推理与张量并行

说明:
单张 GPU 的显存和算力可能无法满足极高吞吐量的需求。通过张量并行将模型切分到多个 GPU 上进行并行计算，可以线性扩展推理能力。这对于大模型或超高并发场景是实现 17k tokens/sec 的关键扩展手段。

实施步骤:

确保部署环境支持高速互联（如 NVIDIA NVLink 或 InfiniBand），以减少 GPU 间通信延迟。
配置推理框架的分布式启动脚本（如 v

学习要点

实现每秒 1.7 万个 Token 的推理速度是让 AI 模型在边缘设备（如手机和汽车）上实现“无处不在”的关键性能指标。
模型量化技术（特别是将模型压缩至 4-bit 甚至更低）是在保持精度的同时大幅提升推理速度的核心手段。
专用推理芯片（NPU）和硬件架构的优化，比单纯依赖通用 GPU 更能效地实现高性能推理。
优化内存带宽和减少数据搬运延迟是突破推理速度瓶颈、达到极高吞吐量的技术难点。
软件栈与底层硬件的深度协同设计，是释放硬件全部潜能并实现极致性能的必要条件。
将高性能 AI 部署在边缘端不仅能降低成本，还能显著改善用户隐私保护和数据安全。
高性能的边缘 AI 将推动从云端集中式处理向本地分布式处理的范式转变。

常见问题

1: 什么是 “17k tokens/sec”，它在 AI 领域意味着什么？

A: “17k tokens/sec” 指的是人工智能系统处理文本的速度达到了每秒 17,000 个 token（token 可以是单词、词组或字符）。在 AI 领域，尤其是大语言模型（LLM）中，处理速度通常以 “tokens per second” (tps) 来衡量。达到每秒 1.7 万个 token 是一个极高的吞吐量指标，通常意味着该系统具备在极短时间内生成海量文本或处理大规模数据集的能力。这种速度是实现“无处不在的人工智能”的关键技术门槛，因为它允许 AI 在边缘设备或本地服务器上实时响应，而无需依赖云端的高延迟处理。

2: 文章标题提到的 “Ubiquitous AI”（无处不在的 AI）具体指什么愿景？

A: “Ubiquitous AI” 指的是人工智能技术像电力或互联网一样，变得无处不在、随时可用且高度集成。在这个愿景中，AI 不仅仅存在于云端的大型数据中心或聊天机器人中，而是深入到智能手机、物联网设备、汽车、家用电器等边缘设备里。文章通过强调 17k tokens/sec 的处理速度，旨在说明当硬件性能足够强大时，AI 可以在任何地方、任何时间低延迟地运行，从而彻底改变人机交互的方式，使 AI 能够无缝地辅助人们的日常生活。

3: 达到每秒 17,000 个 token 的处理速度需要什么样的硬件支持？

A: 虽然具体的硬件实现取决于文章讨论的具体技术方案（通常涉及特定的 AI 加速芯片或优化的推理引擎），但达到这种量级的速度通常需要以下几种条件的结合：

专用 AI 加速器：如高性能的 GPU（如 NVIDIA H100）、TPU 或定制的 ASIC 芯片（如 Groq LPU）。
高带宽内存 (HBM)：为了快速将数据传输给计算核心，内存带宽必须足够大。
模型量化与优化：使用量化技术（如 FP8 或 INT8）减少模型大小和计算复杂度，同时保持精度。
软件栈优化：高度优化的编译器和内核，以最大限度地减少延迟并提高吞吐量。

4: 这种极高的推理速度对实际应用场景有哪些具体影响？

A: 这种速度将解锁许多目前受限于计算延迟的应用场景：

实时语音翻译与对话：可以实现人类级别的实时对话流，几乎感觉不到延迟。
海量视频分析：能够实时处理多路高清视频流，适用于安防或自动驾驶。
本地化私有 AI 助手：由于速度快，可以在本地设备上运行大模型，保护隐私且无需联网。
复杂的代码生成与数据分析：在几秒钟内生成长篇代码或处理庞大的文档库，极大提高生产力。

5: 既然云端 AI 很强大，为什么文章强调要追求这种极致的速度（可能指边缘端或本地推理）？

A: 虽然云端 AI 算力强大，但存在延迟、带宽成本和隐私问题。追求极致的本地处理速度（如 17k tokens/sec）主要为了解决以下痛点：

延迟：云端请求往返需要时间，无法满足毫秒级的实时交互需求。
隐私与安全：数据不需要上传到云端，敏感信息保留在本地设备上。
可靠性：不依赖网络连接，在离线状态下也能拥有完整的 AI 能力。
成本：大规模云端推理非常昂贵，高效的本地推理可以降低运营成本。

6: 普通消费者何时能在日常设备上体验到这种级别的 AI 速度？

A: 目前，17k tokens/sec 的速度通常出现在高端服务器级硬件或特定的 AI 推理卡（如 Groq 等新兴硬件）上。对于普通消费者，要在手机或笔记本电脑上体验到这种速度，可能还需要 3-5 年的时间。这取决于 NPU（神经网络处理单元）在消费级芯片中的集成度提升，以及模型轻量化技术的发展。不过，随着技术的快速迭代，部分高端设备可能会更早地通过混合架构（云端+本地）接近这一体验。

7: Hacker News 社区对这篇文章或技术的讨论通常关注哪些焦点？

A: 根据 Hacker News 的讨论风格，社区通常关注以下焦点：

基准测试的真实性：讨论该速度是在何种精度（如 FP16, INT8）下测得的，以及是否使用了特定的批处理策略。
成本效益比：实现这种速度的硬件成本和能耗是否具有商业可行性。
内存墙：讨论内存带宽是否是限制进一步提速的主要瓶颈。
软件生态：现有的模型框架（如 PyTorch, TensorFlow）是否能充分利用这种硬件性能。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 假设你需要处理一个包含 100 万个 token 的数据集，当前的硬件处理速度为 1.7 万 tokens/sec。请计算处理完整个数据集所需的时间（以秒和分钟为单位），并分析如果处理速度提升到 5 万 tokens/sec，时间会缩短多少百分比。

提示**: 首先计算初始速度下的处理时间，然后用相同方法计算提升后的速度，最后用时间差除以初始时间得到缩短比例。

引用

原文链接: https://taalas.com/the-path-to-ubiquitous-ai
HN 讨论: https://news.ycombinator.com/item?id=47086181

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：大模型 / AI 工程
标签：推理加速 / Token生成 / 性能优化 / 普及AI / 硬件加速 / 模型部署 / AI基础设施 / 技术突破
场景： AI/ML项目

通往泛在AI之路：实现每秒1.7万tokens推理
通往无处不在的AI：实现每秒1.7万tokens推理
通向无处不在的AI之路：实现每秒1.7万tokens推理
通向无处不在的AI：实现每秒1.7万Token推理
仅更换框架，一下午提升15个大模型代码能力 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

通往普及AI之路：实现每秒1.7万tokens推理