性能优化

前言：为什么本地推理服务会成为团队的基础设施 过去两年，很多团队已经把大模型从“能聊几句的玩具”推进到了真正的业务链路里：客服质检、代码助手、文档检索、知识库问答、BI 分析、研发自动化、设备运维助手，场景越来越具体，调用量也越来越稳定。这个阶段最容易遇到的矛盾是：单次体验看起来不错，但一旦多人同时使用，延迟、成本、限流、数据安全、模型版本控制都会变成工程问题。 如果只是给个人写一个脚本，直接调用云端 API 最省事；如果团队已经有私有数据、内网系统、稳定 QPS、固定模型和合规要求，本地推理服务就值得认真建设。它不是为了“完全替代云服务”，而是为了把一部分可控、可预测、可缓存、可审计的请求沉到自己的基础设施里：模型版本自己定，日志留在内网，显卡利用率自己优化，业务峰值也可以通过队列和降级策略来处理。 在这一类方案中，vLLM 是目前很常见的选择。它的优势并不是“启动一个模型”这么简单，而是围绕大模型在线推理做了系统级优化：OpenAI 兼容 API、连续批处理、PagedAttention、张量并行、流式输出、Prometheus 指标、较成熟的服务端参数。对于很多团队来说，vLLM 正好站在“研究代码”和“生产服务”之间：比手写 Transformers server 更接近生产，比完整平台又轻量许多。 本文不打算只列一组启动命令。我们会按工程落地的顺序讲清楚：怎样选择模型与硬件，如何启动 OpenAI 兼容服务，为什么 PagedAttention 对吞吐和显存很关键，压测时应该看哪些指标，常见参数如何调，最后再补上网关、监控、systemd、Docker Compose 和故障排查。读完以后，你应该能搭出一个可用的内网推理服务，并知道下一步该怎么把它调稳。 一、先把目标说清楚：不是“跑起来”，而是“稳定地跑” 很多本地大模型项目的第一步都很顺利：下载模型，装依赖，跑一个 demo，看见回复，大家都很兴奋。真正的问题通常在第二周出现：同事开始接入，输入长度不一样，输出长度不一样，有人跑 8K 上下文，有人开流式输出，还有人批量生成摘要。GPU 显存看起来还剩不少，但请求排队越来越长；某些请求首 token 等待十几秒；升级模型后，原来的参数突然不合适；日志里偶尔出现 CUDA OOM，却很难复现。 所以在搭 vLLM 前，建议先明确四个目标。 第一，服务对象是谁。是给内部研发少量调用，还是给业务系统持续调用？如果只是研发使用，优先保证灵活性；如果是业务链路，优先保证限流、监控、灰度和回滚。 第二，模型规模是多少。7B、14B、32B、70B 对显存和并行方式的要求完全不同。模型越大，单卡部署越困难，吞吐和延迟的权衡也越明显。不要只看参数量，还要看量化格式、上下文长度、是否需要多 LoRA、是否要跑 embedding 或 rerank。 第三，请求形态是什么。短问短答、长文摘要、代码生成、Agent 工具调用的 token 分布差别很大。Prefill 阶段主要处理输入 token，Decode 阶段逐 token 生成输出；输入特别长会拉高首 token 延迟，输出特别长会占用更久的 KV Cache。压测时如果只用“你好”这种请求，结果没有参考价值。 第四，接受什么样的服务等级。比如 P95 首 token 延迟小于 3 秒，平均输出速度大于每秒 40 token，排队超过 30 秒直接返回忙碌，单 GPU 显存利用率维持在 85% 左右。这些指标越早写下来，后面调参越不会靠感觉。 ...

前言 做嵌入式 Linux 或边缘 AI 项目时，很多性能问题最后都会绕回一个朴素但容易被低估的事实：算力不等于吞吐，CPU、NPU、GPU 跑得再快，只要数据喂不上去，整机性能就会被内存系统卡住。 我第一次真正意识到 DDR 带宽的重要性，是在一块多核 ARM SoC 上做 4 路摄像头视频分析。算法同事看 NPU 利用率只有 40% 左右，以为模型还可以继续加大；系统同事看 CPU 使用率也不高，以为瓶颈不在软件。直到我们把 ISP、RGA、NPU、VPU 同时压起来，再去读 DDR 控制器计数器，才发现内存读写已经接近平台可持续带宽的上限。那一刻，所谓“还有很多算力没用上”，其实只是“大家都在等内存”。 这篇文章想把这个问题讲透一点：DDR 带宽不是一个孤立参数，它贯穿了 CPU Cache、AXI/NoC 互联、DMA burst、内存控制器调度、DRAM Bank 冲突、刷新开销以及 Linux 调度策略。很多项目里大家会直接跑一个 memcpy 或 stream，看到数字不错就认为内存没问题；但真实业务往往不是连续大块搬运，而是多个主设备同时访问、读写混合、缓存命中率波动、实时任务和后台任务互相抢总线。 本文会从 SoC 视角出发，拆解一条内存访问路径，并给出一套可以落地的排查和优化方法。示例代码以 Linux 用户态为主，兼顾裸机/RTOS 下的思路。目标不是把每个 DDR 时序参数都背下来，而是建立一个工程上有用的判断框架：什么时候该看 Cache Miss，什么时候该看 AXI outstanding，什么时候该怀疑 DDR controller 的 page policy，什么时候该从数据布局和 DMA burst 入手。 一、先把“带宽”这件事说清楚 DDR 厂商手册里常见的理论带宽计算很简单： 理论带宽 = 数据总线宽度 / 8 × 数据传输速率 例如 32-bit LPDDR4X，数据速率 4266 MT/s，理论峰值约为： ...

前言 2023 年被称为「大模型元年」，但到了 2026 年，真正的革命才刚刚开始——不是在云端，而是在你的本地机器上。 如果你还在依赖 OpenAI API 做所有 AI 相关的工作，那你可能已经错过了一个重要的趋势：本地大模型正在以惊人的速度追赶云端模型的能力。今天，一个 7B 参数的量化模型在中端消费级显卡上就能跑出接近 GPT-3.5 的效果，而 70B 参数的模型在高端显卡上的表现甚至能在某些任务上超越 GPT-4。 更重要的是，本地部署带来了三个无可替代的优势：绝对的数据隐私、零 API 调用成本、完全的控制权。对于企业来说，这意味着敏感的内部文档永远不会离开公司内网；对于个人开发者来说，这意味着你可以 24/7 不间断地运行 AI 工作流而不用担心账单爆炸。 这篇文章是我过去两年部署本地大模型的经验总结。从最基础的 Ollama 一键部署，到深入 llama.cpp 的性能优化，再到企业级的 API 服务架构，我会把每一个踩过的坑、每一个优化技巧都毫无保留地分享给你。 一、为什么要部署本地大模型？ 在谈论技术细节之前，让我们先回答一个根本问题：既然 OpenAI、Anthropic 这些公司已经提供了这么好用的 API，为什么还要费心自己部署本地大模型？ 我给出的答案是四个「自由」。 1. 隐私自由 这是最核心的理由。当你把数据发送给 OpenAI API 时，你实际上放弃了对这些数据的控制权。虽然 OpenAI 的服务条款说不会用用户数据训练模型，但谁也无法保证 100% 的安全——更不用说政府监管、数据泄露、内部人员滥用这些潜在风险。 而本地部署意味着： 你的代码永远不会离开公司内网 客户的敏感数据永远在你的掌控之中 内部知识库的问答不会有任何泄露风险 我有一个朋友在金融公司工作，他们的合规部门绝对不允许任何客户数据出现在第三方 API 中。最后他们用本地部署的 Qwen-72B 搭建了内部的文档问答系统，成本只有云端方案的 1/10，安全性却高了几个数量级。 2. 成本自由 API 调用的成本看起来很低——每 1K tokens 几美分，但当你真的开始大规模使用时，账单会让你大吃一惊。 我做过一个简单的计算：如果一个开发团队有 10 个人，每人每天用 AI 辅助编程 4 小时，平均每 10 秒生成 100 tokens，那么一个月的 API 费用大概是： ...

前言 如果你是一名嵌入式开发者或者系统程序员，可能会有这样的困惑：「我都用上 C/C++ 甚至 Rust 了，为什么还要学汇编语言？」 这个问题我被问过很多次。2018 年我在做一个手机相机 HAL 层的性能优化项目时，算法团队用 NEON intrinsics 写的图像处理函数在骁龙 845 上跑 12ms，离 8ms 的目标还差很远。我花了三天时间，把核心循环改成纯 AArch64 汇编，最终跑到了 6.8ms——这就是汇编的力量：你完全掌控了 CPU 的每一个周期、每一个寄存器。 今天，AArch64 已经无处不在：从你的智能手机到树莓派 4/5，从 AWS Graviton 服务器到 NVIDIA Jetson 开发板，甚至苹果 M 系列芯片本质上也是 AArch64 兼容架构。理解 AArch64 架构，不仅能让你写出更快的代码，更能让你真正理解现代 CPU 是如何工作的。 这篇文章不会教你「Hello World」级别的汇编入门。我要做的是：从架构设计哲学讲起，深入寄存器模型、指令集、寻址模式、函数调用约定，最后用实战项目教你如何写出高性能的 AArch64 汇编代码。 一、ARMv8-A 架构：从 32 位到 64 位的革命 1.1 ARM 架构演进简史 在深入 AArch64 之前，我们先快速回顾一下 ARM 架构的演进路线： ARMv4/v5 (1990s): 经典 ARM，32 位 ARM 状态 + 16 位 Thumb 状态 ARMv6 (2001): 引入 SIMD 媒体处理扩展、未对齐内存访问 ARMv7-A (2005): Cortex-A 系列诞生，NEON SIMD、虚拟化扩展 ARMv8-A (2011): 革命性的 64 位架构，AArch64 执行状态 ARMv8.1-A ~ ARMv8.5-A: 持续增强，加入 SVE、指针认证、内存标记等 ARMv9-A (2021): SVE2、机密计算架构 (CCA)、更多安全增强 很多人误以为 ARMv8-A 「就是 64 位的 ARMv7」——这是完全错误的。ARMv8-A 不是在 ARMv7 基础上「加了几根地址线」，而是几乎重新设计了整个指令集架构。 ...

前言 在嵌入式系统飞速发展的今天，GPU 早已不再仅仅是"游戏显卡"的代名词。从智能手机的流畅 UI 渲染，到车载娱乐系统的 3D 导航，从边缘设备的 AI 推理加速，到 AR/VR 设备的实时渲染，GPU 已经成为现代嵌入式 SoC 中不可或缺的核心组件。而在这个领域，ARM Mali GPU 无疑是占据统治地位的存在——全球超过 70% 的 Android 设备都搭载了 Mali GPU，从入门级的 Mali-G52 到旗舰级的 Mali-G720，Mali 架构覆盖了从低端到高端的完整产品线。 然而，尽管 Mali GPU 如此普及，真正深入理解其架构原理的开发者却并不多。大多数嵌入式工程师习惯于 CPU 的线性编程模型，面对 GPU 的并行计算架构和独特的渲染流水线时，往往感到无从下手。更重要的是，Mali GPU 采用的基于分片（Tile-Based）的渲染架构，与桌面端 NVIDIA/AMD 的立即模式渲染有着本质区别，如果不理解这种差异，写出的着色器代码往往会出现严重的性能问题。 我曾见过太多这样的案例：一个在 PC 上运行流畅的 OpenGL ES 应用，移植到嵌入式平台后帧率暴跌；一份看似合理的着色器代码，却在 Mali GPU 上出现了难以解释的带宽瓶颈；一个经过精心优化的渲染流程，实际性能却只有理论值的三分之一。这些问题的根源，往往都在于对 Mali GPU 架构的理解不够深入。 本文将从硬件架构出发，系统地讲解 Mali GPU 的工作原理。我们会从最基础的 Tiler 分片渲染机制讲起，深入到着色器核心的执行模型，分析内存层次结构的设计考量，最后给出一套完整的性能优化方法论。无论你是正在开发嵌入式图形应用的工程师，还是对 GPU 架构感兴趣的技术爱好者，这篇文章都能为你揭开 Mali GPU 的神秘面纱。 一、为什么嵌入式 GPU 需要不同的架构设计？ 在深入 Mali GPU 的具体架构之前，我们首先要回答一个根本性的问题：为什么嵌入式 GPU 不能直接沿用桌面 GPU 的设计？答案可以用三个关键词来概括：功耗、带宽、面积。 ...

前言 2020 年代，AI 算力的需求呈现出爆炸式增长。从大语言模型的推理，到计算机视觉的实时处理，再到科学计算的海量数据处理，计算领域对数据并行处理能力的需求从未如此迫切。传统的标量 CPU 虽然通用，但面对海量重复运算时显得力不从心；GPU 虽然并行能力强大，但功耗和延迟问题使其难以在嵌入式和端侧场景中广泛应用。 正是在这样的背景下，RISC-V 向量扩展（RISC-V Vector Extension，简称 RVV） 应运而生。作为 RISC-V 指令集架构的官方标准扩展，RVV 提供了一套灵活、可扩展的向量处理机制，能够以远低于 GPU 的功耗和延迟，实现高效的数据并行计算。从低功耗的 IoT 设备，到高性能的服务器 CPU，RVV 正在成为 RISC-V 生态中最具变革性的技术之一。 RVV 的设计哲学与传统的 SIMD 扩展（如 x86 的 SSE/AVX、ARM 的 NEON/SVE）有着本质的不同。它不是简单地固定宽度的向量寄存器堆，而是引入了运行时可配置向量长度、向量寄存器分组、掩码操作等一系列创新设计，使得同一份 RVV 代码能够在不同硬件实现上高效运行，真正实现了"一次编写，处处加速"。 本文将从底层原理出发，带你深入理解 RVV 1.0 规范的设计精髓，通过完整的代码示例，手把手教你掌握 RVV 编程和优化技巧。无论你是芯片架构师、系统工程师，还是想要在 RISC-V 平台上优化算法性能的开发者，这篇文章都会为你提供完整的知识体系和实战指南。 一、为什么我们需要向量扩展？ 在深入探讨 RVV 的具体细节之前，让我们先回答一个最基本的问题：为什么 CPU 需要向量扩展？ 1.1 数据级并行的本质 现代计算任务中，绝大多数密集运算都具有一个共同的特征：对大量数据执行相同的操作。例如： 图像卷积：对每个像素点执行相同的乘加运算 矩阵乘法：大量的元素级乘累加操作 神经网络推理：张量之间的批量运算 信号处理：FFT、滤波等时域频域变换 这种"单指令，多数据"的模式，正是向量计算能够发挥巨大优势的场景。如果用传统的标量指令来处理这些任务，每个数据元素都需要取指、译码、执行一次，这会造成巨大的指令开销和控制开销。而向量指令可以在一条指令中处理数十甚至上百个数据元素，将指令吞吐量提升一个数量级。 1.2 传统 SIMD 的局限性 在 RVV 出现之前，主流 CPU 架构都有自己的 SIMD 扩展： ...