swiftLLM：大模型推理加速实战，从算子融合到量化部署

1. 项目概述与核心价值

最近在折腾大语言模型本地部署和推理优化，发现了一个挺有意思的项目，叫interestingLSY/swiftLLM。这名字一看就挺有想法，swift这个词在编程里意味着“快速”，而LLM自然是大语言模型。所以，这个项目的核心目标很明确：让大语言模型跑得更快。这可不是简单的“快一点”，而是在保证模型效果的前提下，通过一系列底层优化技术，显著提升推理速度，降低部署成本。

对于任何一个尝试过在本地机器上运行7B、13B甚至更大参数模型的开发者来说，推理速度慢、显存占用高都是绕不开的痛点。你可能体验过那种输入一个问题，然后看着进度条缓慢前进，等待十几秒甚至几十秒才能得到回复的煎熬。swiftLLM瞄准的就是这个痛点。它不是一个全新的模型架构，而更像是一个“加速器”或“优化工具箱”，通过集成当前最前沿的推理优化技术，对现有的主流开源大模型（比如 Llama、Qwen、ChatGLM 等）进行“改造”，让它们能在更普通的硬件上流畅运行，或者在高性能硬件上发挥出极限性能。

这个项目适合谁呢？首先，肯定是所有希望提升自己本地模型推理效率的开发者、研究者和爱好者。其次，对于希望将大模型集成到产品中，但又受限于服务器成本和响应延迟的创业团队来说，这类优化技术是降本增效的关键。最后，对于想深入学习大模型底层推理、算子和内存优化技术的同学，swiftLLM的源码和实现思路也是一个非常好的学习材料。它把很多论文里的高级优化技术，变成了可以实际运行和调试的代码。

简单来说，如果你受够了慢吞吞的模型推理，想在不升级硬件的前提下榨干现有设备的每一分算力，或者想了解大模型加速背后的“黑科技”，那么swiftLLM值得你花时间深入研究一下。接下来，我就结合自己的实践，带你拆解这个项目的核心思路、关键技术以及如何上手使用。

2. 核心加速技术深度解析

swiftLLM的“快”并非来自单一的魔法，而是多种优化技术协同作用的结果。理解这些技术，不仅能帮你更好地使用这个项目，更能让你在面对其他优化方案时，知道其背后的原理和取舍。我把它核心的技术栈拆解为以下几个层面。

2.1 计算图优化与算子融合

这是最基础也是效果最显著的优化层之一。大模型推理本质上是在执行一个巨大的计算图。原始的 PyTorch 模型在运行时，框架（如 eager 模式）会逐个执行算子（Operator），比如矩阵乘法（MatMul）、激活函数（如 GeLU）、层归一化（LayerNorm）等。每个算子都会产生一次内核启动（Kernel Launch）的开销，并且需要将中间结果写回内存，再由下一个算子读出来，这造成了大量的内存带宽消耗和延迟。

swiftLLM通常会利用像TorchInductor（PyTorch 2.0+）或TVM、ONNX Runtime这样的编译器，对计算图进行静态分析和优化。优化的核心是算子融合。例如，一个经典的融合模式是 “MatMul + Add + GeLU”。在 Transformer 的 FFN 层中，这组操作频繁出现。编译器会识别这个模式，并生成一个融合后的、高度优化的单一 GPU 内核。这个融合内核直接完成(输入 @ 权重) + 偏置 -> GeLU的整个计算流程。

为什么这能带来巨大提升？

1. 减少内核启动开销：一次启动代替三次启动，调度开销大幅降低。
2. 减少内存访问：中间结果（如 MatMul 的输出）直接在 GPU 的寄存器或共享内存中传递，无需写回和读取全局显存。这极大地缓解了内存带宽瓶颈，而现代 GPU 的瓶颈往往就在内存带宽上。
3. 提升硬件利用率：融合后的内核可以更精细地安排线程和内存访问模式，更好地利用 GPU 的 SM（流多处理器）和 Tensor Cores。

实操心得：在编译模型时，关注编译日志中关于 “fusion” 的关键词。成功的融合是性能提升的第一个明显信号。不同的编译器（Inductor, TensorRT）融合能力不同，有时需要手动指定融合模式或调整编译参数。

2.2 注意力机制的高效实现

Transformer 的注意力机制（尤其是 Decoder 的自回归注意力）是推理延迟的主要贡献者之一。标准的实现（如 PyTorch 的F.scaled_dot_product_attention）虽然功能完善，但在特定场景下（如固定的上下文长度、自回归生成）仍有优化空间。

swiftLLM会集成或实现更高效的注意力内核，例如：

• FlashAttention及其变种（FlashAttention-2, Flash-Decoding）：通过巧妙的算法将注意力计算分解，避免实例化巨大的(序列长度, 序列长度)注意力矩阵，从而显著降低显存占用和计算量。这对于长上下文推理至关重要。
• PagedAttention（类似 vLLM 中的技术）：将每个序列的键值缓存（KV Cache）分割成固定大小的“块”进行管理，允许非连续存储。这极大地提高了显存利用率，减少了由于显存碎片化导致的内存浪费，从而可以在同一批处理（batch）中容纳更多并发请求，提升吞吐量。
• 分组查询注意力或多查询注意力：通过让多个查询头共享同一组键/值头，在不显著损失精度的情况下，大幅减少 KV Cache 的大小，这对于内存带宽受限的推理场景非常有效。

为什么注意力优化是关键？在自回归生成中，每一步（生成一个token）都需要计算当前token与之前所有token的注意力。随着生成进行，KV Cache 线性增长，内存访问和计算量成为瓶颈。上述优化技术直接从算法和内存管理层面“釜底抽薪”，解决了这个核心问题。

2.3 量化与低精度推理

量化是将模型权重和激活值从高精度（如 FP32, FP16）转换为低精度（如 INT8, INT4）的过程。这是减少模型体积和加速推理最直接的手段之一，因为低精度数据占用更少的内存带宽，并且某些硬件（如 NVIDIA 的 Tensor Cores）对低精度计算有专门的加速支持。

swiftLLM通常会支持主流的量化方案：

• 权重量化：仅对权重进行量化，推理时动态反量化或使用混合精度计算。这种方法实现相对简单，对精度影响小。
• 动态量化：在推理时，根据输入数据的实际范围，动态确定量化参数。适用于激活值范围变化较大的场景。
• 静态量化：需要一个小规模的校准数据集，预先确定好权重和激活值的量化参数。通常能获得更好的精度-速度权衡。
• GPTQ/AWQ 等后训练量化：这些是更高级的量化方法，通过在量化过程中引入少量校准数据或优化，来最小化量化带来的精度损失。它们通常能实现 INT4 甚至更低的量化，同时保持较好的模型能力。

选择哪种量化？

• 追求极致压缩和速度：选择 GPTQ/AWQ 的 INT4 量化。适合资源极度受限的边缘设备或需要部署超大规模模型。
• 平衡速度和精度：选择 INT8 权重量化或静态量化。这是最常用的方案，在大多数消费级显卡上能获得显著的加速而精度损失可控。
• 注意硬件支持：确保你的 GPU（如是否支持 INT8 Tensor Cores）和推理引擎支持你选择的量化格式。

2.4 持续批处理与推测解码

对于服务端场景，如何同时处理多个用户的请求（批处理）是提升吞吐量的关键。但用户请求的序列长度各不相同，简单的静态批处理会因为等待最长的序列而降低效率。

• 持续批处理：这是swiftLLM这类高性能推理框架的标配。它动态地将新到来的请求加入当前批处理中，并为已结束的请求腾出空间。它需要与高效的内存管理（如 PagedAttention）紧密结合，才能实现高吞吐量。
• 推测解码：这是一种“用计算换延迟”的前沿技术。其核心思想是，用一个小的、快速的“草稿模型”先生成多个候选 token，然后用原始的大模型（“验证模型”）一次性并行地验证这些候选 token。如果验证通过，就一次性接受多个 token，从而减少大模型的调用次数。swiftLLM如果集成了类似Medusa或Eagle的推测解码框架，能在合适的场景下（草稿模型质量高）大幅降低每个输出 token 的延迟。

3. 环境搭建与模型准备实操

理论说了这么多，手痒想试试了。我们来看看如何把swiftLLM跑起来。这里我以在 Linux 系统、配备 NVIDIA GPU 的环境下为例，演示一个典型的流程。

3.1 基础环境配置

首先，确保你的系统环境是干净的，建议使用 Conda 或 Python 虚拟环境来管理依赖，避免包冲突。

# 创建并激活一个新的 conda 环境 conda create -n swiftllm python=3.10 conda activate swiftllm # 安装 PyTorch (请根据你的 CUDA 版本到官网选择对应命令) # 例如，对于 CUDA 12.1 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 克隆 swiftLLM 仓库 git clone https://github.com/interestingLSY/swiftLLM.git cd swiftLLM

接下来，安装项目的依赖。通常项目根目录会有requirements.txt或pyproject.toml。

# 安装项目依赖 pip install -r requirements.txt # 有些优化可能依赖特定的 CUDA 扩展，需要单独编译 # 例如，如果项目使用了自定义的 CUDA 内核（如优化的注意力实现） # 可能需要执行： # python setup.py build_ext --inplace # 或者 # pip install -e . # 以可编辑模式安装，通常会触发编译

注意事项：编译 CUDA 扩展对系统环境要求严格，需确保 CUDA Toolkit 版本、PyTorch 版本、GCC 版本兼容。如果编译失败，仔细查看错误日志，通常是某个头文件找不到或编译器参数问题。有时使用预编译的 wheel 包是更省心的选择，这取决于swiftLLM的发布方式。

3.2 获取与准备模型

swiftLLM本身不提供模型权重，你需要自行下载开源大模型。以 Meta 的 Llama 3 8B 模型为例。

1. 下载原始模型：从 Hugging Face 模型库下载。你需要有相应的访问权限（可能需要同意条款）。

   # 使用 huggingface-cli (需先 pip install huggingface-hub) huggingface-cli download meta-llama/Meta-Llama-3-8B-Instruct --local-dir ./models/llama3-8b-instruct

   或者，如果你已经通过其他方式下载了模型，只需将其放在./models/目录下。

2. 模型转换与优化：原始 Hugging Face 格式的模型可能不是最优的。swiftLLM通常会提供一个脚本，将模型转换为其内部的高效格式。这个过程可能包括：

   • 量化：将模型转换为 INT4/AWQ 等格式。
   • 图优化：应用前面提到的算子融合等优化，并编译成静态图。
   • 序列化：将优化后的模型序列化为一个单独的文件（如.so动态库、.pt或自定义格式），方便快速加载。

   查找项目中的convert.py、export_model.py或build.py之类的脚本。

   # 示例命令，具体参数请参考项目文档 python tools/convert_hf_to_swift.py \ --input_dir ./models/llama3-8b-instruct \ --output_dir ./models/llama3-8b-instruct-swift \ --quantization awq_int4 \ --use_cuda_graph

   这个过程可能会比较耗时，因为它涉及到校准（对于静态量化）和编译。完成后，你会得到一个优化后的模型目录。

3.3 运行推理测试

模型准备好后，就可以进行推理了。项目通常会提供示例脚本。

# 示例：运行一个交互式聊天 CLI python examples/chat_cli.py \ --model_path ./models/llama3-8b-instruct-swift \ --max_new_tokens 512 # 示例：运行一个性能基准测试 python benchmarks/benchmark_speed.py \ --model_path ./models/llama3-8b-instruct-swift \ --batch_size 1,4,8 \ --input_len 128,512,1024

在交互式 CLI 中，你可以直接输入问题，感受优化前后的速度差异。在基准测试中，你会得到一系列指标：

• 前向传播延迟：处理单个提示（Prompt）的时间。
• 生成吞吐量：每秒生成的 token 数（Tokens/s）。这是衡量生成速度的核心指标。
• 首 Token 延迟：从输入结束到收到第一个输出 token 的时间，对用户体验至关重要。
• 峰值显存占用：模型加载和运行过程中消耗的最大显存。

对比一下优化前（原始 Hugging Face 模型 + 标准 Transformers 库）和优化后（swiftLLM格式）的这些指标，你就能直观地感受到性能提升。

4. 性能调优与参数详解

拿到基础性能数据后，我们还可以通过调整参数来进一步“压榨”硬件性能。swiftLLM通常会暴露一些关键的超参数。

4.1 批处理大小与序列长度

这两个参数对性能和显存的影响最大。

• 批处理大小：同时处理的请求数量。增大 batch size 可以提高 GPU 的利用率（更饱和的 Tensor Cores），从而提升吞吐量。但也会增加延迟（因为要等一批都处理完），并线性增加显存占用（尤其是 KV Cache）。在服务高并发场景下，需要找到一个吞吐量和延迟的平衡点。
• 上下文长度：模型能处理的最大序列长度。它直接决定了 KV Cache 的大小。swiftLLM通过 PagedAttention 等技术，使得长上下文下的显存增长不再是严格的平方关系，而是更接近线性。但设置过长的上下文长度，仍然会预留更多显存。应根据实际应用场景设置合理的值。

调优建议： 在benchmark_speed.py脚本中，用不同的--batch_size和--input_len组合进行测试，绘制出“吞吐量-延迟”曲线，找到你业务场景下的最优点。

4.2 KV Cache 精度与量化

KV Cache 占据了生成阶段大量的显存。除了使用 PagedAttention 管理，还可以降低其精度。

• kv_cache_dtype：可以尝试设置为fp16甚至int8。将 KV Cache 从默认的fp16改为int8可以几乎减半其显存占用，但对模型输出的质量可能有轻微影响，需要评估。
• quantization：如果在模型转换时选择了权重量化（如 AWQ-INT4），推理时通常有对应的后端（如TensorRT-LLM或GPTQ后端）来高效执行低精度计算。确保推理脚本正确加载了量化后的模型和对应的推理引擎。

4.3 使用 CUDA Graph 捕获计算图

对于固定计算图模式的推理（如提示处理阶段，模型结构固定，只有输入数据变化），可以使用 CUDA Graph 来捕获一次计算过程，后续直接“重放”。这消除了内核启动和 CPU 调度的开销，对于小模型或固定 batch size 的提示处理阶段有显著加速。

在模型转换或加载时，寻找类似--use_cuda_graph或enable_cuda_graph=True的参数。启用后，首次运行（图捕获阶段）可能会稍慢，但后续重复运行会非常快。

实操心得：CUDA Graph 对动态形状（变化的序列长度、batch size）支持不好。它最适合提示处理阶段，因为对于一个模型，提示处理的图是固定的（直到生成开始）。对于自回归生成阶段，由于计算图每一步都在变化（序列长度+1），通常不适用 CUDA Graph。swiftLLM可能会智能地只对提示处理启用它。

4.4 并行策略配置

对于多 GPU 环境，模型并行是运行超大模型的必要手段。swiftLLM可能支持张量并行和流水线并行。

• 张量并行：将单个层的权重矩阵拆分到多个 GPU 上。通信密集，但能降低单个 GPU 的显存需求，适用于节点内多卡（NVLink 互联最佳）。
• 流水线并行：将模型的不同层分配到不同的 GPU 上。会引入流水线气泡（Bubble），降低效率，但可以跨节点扩展。

在加载模型时，可能需要指定tensor_parallel_size和pipeline_parallel_size。对于 8B 模型，在 2-4 张消费级显卡上，使用张量并行（TP=2或4）通常是性价比最高的选择，能有效分摊显存并利用多卡算力。

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

在实际部署和测试swiftLLM的过程中，你肯定会遇到各种问题。这里我记录了一些典型问题和解决方法。

5.1 编译与安装问题

问题：编译 CUDA 扩展时失败，报错“找不到 nvcc”或“CUDA 版本不匹配”。

• 排查：检查nvcc --version和python -c "import torch; print(torch.version.cuda)"输出的 CUDA 版本是否一致。它们必须匹配。
• 解决：重新安装与系统 CUDA 驱动兼容的 PyTorch 版本，或安装对应版本的 CUDA Toolkit。使用 Conda 安装 PyTorch 时，可以指定cudatoolkit版本，让 Conda 管理 CUDA 环境，避免系统环境混乱。

问题：导入模块时报错，提示缺少某些符号，如undefined symbol: xxx。

• 排查：这通常是编译时和运行时链接的库版本不一致导致的。可能是 PyTorch、CUDA 或某些 C++ 库（如 glibc）的版本问题。
• 解决：尝试在一个全新的虚拟环境中，严格按照项目要求的版本安装所有依赖。如果问题依旧，可能是项目代码对某个新版本库不兼容，可以尝试在项目 Issue 列表中寻找类似问题或回退相关库的版本。

5.2 模型加载与推理错误

问题：加载量化模型失败，提示“不支持的量化格式”或“权重形状不匹配”。

• 排查：确认模型转换时使用的量化方法（如 AWQ）与推理脚本中指定的后端是否匹配。例如，用 AWQ 转换的模型，推理时可能需要加载awq相关的插件或配置。
• 解决：仔细阅读模型转换脚本的输出日志，确认生成的模型格式。然后在推理脚本中，明确指定quantization=awq或相应的参数。确保转换和推理使用的是同一套代码版本。

问题：推理时显存溢出（OOM），即使模型大小看起来小于 GPU 显存。

• 排查：显存占用不仅仅是模型权重。还包括：
  1. 模型权重（量化后已减小）。
  2. KV Cache：这是大头，计算公式约为2 * batch_size * num_layers * num_kv_heads * head_dim * seq_len * dtype_size。seq_len是当前序列长度，在生成过程中会增长。
  3. 激活值（中间计算结果）。
  4. 框架开销。
• 解决：
  1. 减小batch_size。
  2. 减小max_seq_len（最大上下文长度）。
  3. 启用--use_paged_attention（如果支持）来更高效地管理 KV Cache 显存。
  4. 将kv_cache_dtype从fp16改为int8。
  5. 如果有多张 GPU，启用张量并行来分摊显存。

5.3 性能未达预期

问题：测得的吞吐量（Tokens/s）远低于官方报告或预期。

• 排查：进行性能剖析（Profiling）。使用nsys或nvprof工具来查看 GPU 内核的执行时间，找出瓶颈。

  nsys profile -o my_profile python benchmark_speed.py ...

  分析报告，看是计算密集型内核耗时多，还是内存拷贝（MemCpy）耗时多。如果是内存拷贝，可能说明数据在 CPU 和 GPU 之间来回搬运过多，或者批处理/序列长度设置不合理，导致内核效率低。
• 解决：
  1. 确保输入数据（提示）在推理开始前就已经在 GPU 上。避免每个迭代都从 CPU 拷贝。
  2. 调整batch_size。太小会导致 GPU 利用率不足；太大会增加延迟并可能触及显存上限。找到最佳点。
  3. 检查是否成功启用了 FP16/INT8 Tensor Cores。在 profiling 报告中，查看内核名称是否包含hmma（Tensor Core 操作）。
  4. 对于服务端场景，确保使用了持续批处理，而不是简单的静态批处理。

问题：首 Token 延迟很高。

• 排查：首 Token 延迟主要包括提示处理（Prefill）的时间和第一个生成步的时间。如果提示很长，Prefill 阶段是计算密集型的，延迟高是正常的。
• 解决：
  1. 对于长提示，可以尝试启用FlashAttention来加速 Prefill 阶段的计算。
  2. 使用CUDA Graph来捕获和加速 Prefill 阶段的计算图（如果模型和提示形状固定）。
  3. 如果应用场景允许，可以考虑对用户提示进行预处理或缓存部分计算结果。

5.4 精度与效果验证

问题：优化后的模型回答质量下降，出现胡言乱语或知识遗忘。

• 排查：这通常是量化过程引入的误差过大导致的。特别是低比特量化（如 INT4）或激进的量化配置。
• 解决：
  1. 使用更保守的量化：从 INT8 开始尝试，如果精度可接受，再尝试 INT4。不同的量化算法（GPTQ vs AWQ）在不同模型上表现不同，需要实验。
  2. 校准数据：对于静态量化，确保使用了有代表性、多样化的校准数据集。不要用太小的或领域偏斜的数据集。
  3. 评估：在优化前后，使用标准的评测数据集（如 MMLU, C-Eval, GSM8K）对模型能力进行定量评估，而不仅仅是定性观察几个例子。swiftLLM项目可能提供了评估脚本。
  4. 检查融合：过于激进的算子融合在极端情况下可能引入数值误差。可以尝试禁用某些融合选项，观察精度是否恢复。

6. 进阶应用与生态集成

当你熟练使用swiftLLM进行单模型推理后，可以探索更进阶的应用场景，并将其集成到更大的生态系统中。

6.1 构建高性能 API 服务

本地测试用 CLI 脚本，但要对外提供服务，需要一个高性能的 API 服务器。你可以基于swiftLLM的推理引擎，用 FastAPI 或类似框架封装一个 HTTP 服务。

核心要点：

1. 模型单例：全局加载一个模型实例，避免每次请求都重复加载。
2. 异步处理：使用asyncio来处理并发请求，但注意，模型推理本身通常是同步的 CPU/GPU 密集型操作，需要将其放到线程池中执行，避免阻塞事件循环。
3. 请求队列与持续批处理：实现一个请求队列，由后台工作线程从队列中取出多个请求，组成一个批处理，调用swiftLLM的推理接口。这正是体现swiftLLM持续批处理优势的地方。
4. 流式输出：对于生成任务，支持 Server-Sent Events (SSE) 流式返回 token，提升用户体验。
5. 健康检查与监控：添加/health端点，并集成 Prometheus 指标（如请求延迟、队列长度、GPU 利用率等）。

6.2 与 LangChain / LlamaIndex 集成

swiftLLM可以作为 LangChain 或 LlamaIndex 的底层 LLM 提供者。你需要实现一个自定义的LLM类，封装swiftLLM的调用接口。

例如，在 LangChain 中：

from langchain.llms.base import LLM from typing import Optional, List, Any class SwiftLLMWrapper(LLM): model: Any # 这里存放 swiftLLM 加载的模型实例 def _call(self, prompt: str, stop: Optional[List[str]] = None, **kwargs) -> str: # 调用 swiftLLM 的同步生成接口 output = self.model.generate(prompt, **kwargs) return output @property def _llm_type(self) -> str: return "swift-llm" # 使用时 from swiftllm import load_model model = load_model("./models/llama3-8b-swift") llm = SwiftLLMWrapper(model=model) # 现在可以将 llm 用于 LangChain 的 Chain, Agent 等

这样，你就可以利用swiftLLM的高性能，来驱动 RAG（检索增强生成）、智能体等更复杂的应用。

6.3 在多模态场景下的探索

虽然swiftLLM主要针对纯文本 LLM，但其优化思想可以扩展到多模态模型。例如，对于 LLaVA 这类视觉语言模型，其语言部分同样可以应用swiftLLM的优化技术。

你需要：

1. 将视觉编码器（如 CLIP）和 LLM 部分解耦。
2. 使用swiftLLM加载并优化 LLM 部分。
3. 在推理时，先将图像通过视觉编码器得到特征向量，再与文本 token 一起输入给优化后的 LLM。

这需要对模型结构有较深的理解，并可能修改swiftLLM的模型加载和输入处理逻辑。这是一个更高级的集成方向。

7. 总结与未来展望思考

折腾swiftLLM这类项目的过程，其实是一个深入理解大模型推理底层细节的绝佳机会。它把那些藏在论文和框架深处的优化技术，变成了可触摸、可调试的代码。从算子融合减少内存带宽压力，到 PagedAttention 巧妙管理 KV Cache，再到推测解码用“小聪明”换时间，每一步优化都直指当前推理瓶颈的咽喉。

我个人最大的体会是，没有银弹。AWQ 量化在 A 模型上效果拔群，在 B 模型上可能就损失惨重；持续批处理对吞吐量提升巨大，但对某些超低延迟要求的场景可能不友好。真正的实战，就是根据你的具体模型、硬件条件和服务指标（延迟 vs 吞吐），在这些技术组合中寻找最佳平衡点。swiftLLM提供了这样一个工具箱和实验平台。

未来，这类推理优化框架会越来越“智能”和“全栈化”。我猜想几个方向：一是编译优化会更激进，从单个算子融合扩展到整个计算图的全局优化，甚至针对不同硬件（NVIDIA, AMD, Apple Silicon）自动生成最优内核。二是与硬件结合更紧密，特别是对于 NPU 等 AI 专用芯片，框架需要更底层地发挥其能力。三是动态适应性更强，能够根据实时负载和输入特征，动态调整批处理大小、并行策略甚至量化精度，实现资源利用率和响应速度的全局最优。

对于开发者来说，这意味着我们不再需要像现在这样手动尝试各种配置组合。也许不久的将来，我们只需要告诉框架“我要在 RTX 4090 上以低于 100ms 的延迟运行 Llama 3 70B”，它就能自动编译、量化、配置出一个最优方案。而在那一天到来之前，像interestingLSY/swiftLLM这样的项目，就是我们手中的利器，让我们能在现有的硬件上，将大模型的潜力发挥到极致。