Python

过去五年，大语言模型（Large Language Models, LLMs）的发展几乎完全重塑了人工智能的技术版图。从 GPT 到 LLaMA，从 Transformer 到 Mixture-of-Experts（MoE），从单体模型到大规模分布式参数服务器体系，架构演进直接推动了能力跃迁。 本文将从架构层面系统梳理 LLM 的主流技术路径，并从应用视角分析其优劣及适配场景，为研发与业务团队提供技术选型参考。同时也希望可以为初学者们打开迈入大模型世界的一条门缝！ 大语言模型的主流架构体系 目前的 LLM 架构，大概可以分为这么几类： 传统 Transformer（Dense Transformer） Mixture-of-Experts（MoE）架构 多模态扩展架构（Vision-Language / Audio-Language） 检索增强生成（RAG）与混合推理架构 基于代理（Agentic）架构的系统级 LLM 超大规模分布式训练架构（例如 Parameter Server / Fully Sharded） 下面逐一展开。 传统 Transformer：主流 LLM 的基础架构 Dense Transformer 是绝大多数 LLM 的基座，包括 GPT 系列、LLaMA、Mistral、Qwen 等。 架构 简单来说，就是“大力出奇迹”： 所有 token 通过全连接注意力进行计算； 全部参数在每次前向推理中都会被激活； 结构相对规则，训练稳定； 模型规模靠堆叠层数与扩大 hidden size 线性提升。 优势 推理路径稳定、可预测； 训练过程成熟，生态支持丰富； 对所有任务通用，不需要额外路由机制。 局限 参数规模大时推理成本高（全部参数激活）； 扩展模型能力的成本几乎与参数规模线性相关。 应用场景 场景 适用性 通用对话 高 编程、数学推理 高 对实时需求强的应用（低延迟） 较低 资源受限设备（边缘推理） 一般，可用量化缓解 Dense 模型依然是绝大多数企业首次采用 LLM 时的首选。...

随着大语言模型（LLM）规模不断增长，推理成本也随之飙升。为了让模型在响应用户请求时更快、更经济地运行，各类优化技术不断涌现。其中，**KV-Cache（Key-Value Cache）**是目前最关键、影响最深远的推理加速机制之一，被所有主流的推理框架（如 vLLM、TensorRT-LLM、LLama.cpp、llm-d、OpenAI Triton Transformer Engine 等）广泛使用。 这篇文章将全面介绍什么是 KV-Cache、它如何工作、为什么它能极大提升推理效率、它对行业带来了什么影响，以及在实际使用中的最佳实践。 KV-Cache 是什么？ 首先，其工作原理架构图如下： 理解起来非常简单，单其中细节结合复杂度计算还是略有抽象。 KV-Cache，全称 Key-Value Cache，是在 LLM 推理过程中对 Transformer 解码器中**自注意力层（Self-Attention）**的中间结果进行缓存的一种方法。 Transformer 的自回归生成方式决定了： 每生成一个新 token，就需要重新计算它与全部历史 token 的注意力关系。 如果每次都把过去所有 token 的 Key 和 Value 重新计算一遍，其计算量是： 推理时间复杂度：O(n²) （n 为上下文长度） 为了避免重复计算，KV-Cache 会在每步生成 token 时，将计算后的 Key（K） 和 Value（V） 保存下来，这样之后再生成下一步 token 时就能直接引用过去的 Key/Value，而无需重新计算历史部分。 这让时间复杂度大幅下降为： 推理时间复杂度：O(n) 所以简单总结一下，KV-Cache 是在自回归解码中缓存历史 token 的 Key/Value，让后续生成直接复用过去的注意力结果，从而把时间复杂度从 O(n²) 降到 O(n)，节省的成本非常巨大。 KV-Cache 是如何工作的？ 以当前主流的解码流程为例，我们以是否使用 KV-Cache 来做一个简单的对比。 如果没有 KV-Cache 每次生成新 token 时需要做： 重新对全部历史序列做 embedding 通过所有 Transformer 层重新计算 K/V 根据新 token 与整个序列做自注意力 得到新 token 并输出 具体流程图示如下：...

随着 Azure AI Foundry 开放对 **Sora 2（OpenAI 生成式视频模型）**的支持，开发者现在可以在企业级合规、可管控的环境中使用顶尖的视频生成能力。本教程将带你从零开始，通过 Playground 和 Python SDK 两种方式调用 Sora 2，完成「文本生成视频」的流程。 准备工作 在开始之前，你需要： 获取 Azure 订阅 拥有一个 Azure 订阅，如果您不清楚如何获取 Azure 订阅，可以参考之前文章中的注册 Azure 订阅内容进行操作。 创建 Azure AI Foundry 首先进入您的 Azure 订阅中的 AI Foundry，展开左侧 All Resources，找到 Azure AI Foundry，点击 Create 创建一个 Azure AI Foundry： 创建时注意区域选择，由于 Sora 2 模型并未在所有 Azure 区域开放预览，这里建议选择 East US 2 区域： 1. 创建 Azure AI Foundry Project 创建完成后进入您的 Azure AI Foundry 在 All Resources 中找到 Projects，点击 New 创建一个新的 Project：...

原文链接：The Best Choice for AI Inference -> vLLM 注意：本译文已获得的原文作者翻译授权，为避免广告嫌疑，本文中移除了特定产品和品牌的商业宣传内容，仅保留技术特性及企业级产品功能描述，相关内容请以原文为准。 随着各组织从大语言模型（LLM）的试验阶段迈向生产部署，选择哪种推理平台就成了一项关键的业务决策。这个选择不仅影响性能，也影响灵活性、成本优化，以及应对快速变化业务需求的能力。 对于技术人员和方案架构师在评估 LLM 推理平台时，应该重点考虑以下三大因素： 架构灵活性：能否在不同硬件加速器和混合云环境间部署，而不会被某一家厂商锁定。 运行可扩展性：支持从单 GPU 部署扩展到分布式多节点的高级部署模式。 生态开放性：对最广泛的模型与内核支持，以及能与各种企业软件生态系统整合。 vLLM 在开源基础、先进内存管理能力，以及即将推出的分布式部署蓝图方面，独特地满足这些需求。与专有或硬件专用方案不同，这套组合提供了在成本、性能和运营需求上随时优化调整的自由。 本文将深入分析为何 vLLM 在其技术架构与能力上（尤其是其 KV-Cache 管理、并行策略，以及未来的 llm-d 分布式能力）提供了最可持续的生产级 LLM 部署路径。 开源优势 社区驱动的大规模创新 LLM 推理的发展，根本上受到开源创新的推动。过去一年半以来 vLLM V1: A Major Upgrade to vLLM’s Core Architecture | vLLM 博客（英文版），vLLM 在支持多样模型、功能和硬件后端方面取得显著成绩，从伯克利大学的研究项目成长为开源 AI 生态中的事实标准之一 vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。 vLLM 社区发展参考链接 vLLM 现在隶属于 PyTorch 基金会托管项目（GitHub — vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs），这保证了其长远的可持续性和治理机制。...

大模型在推理部署时，往往存在显存瓶颈： 模型参数（Parameters, P）动辄上百 GB，需要长期驻留显存。 输入/输出数据（Data, D）则随请求动态变化，但往往和参数耦合在同一设备上，导致显存占用不均衡，扩展性受限。 为了解决这一问题，可以借助 vLLM 框架实现参数 / 数据（P/D）分离，提升推理系统的灵活性和吞吐。 大模型推理的资源瓶颈 以一个 70B 规模的 Transformer 模型为例： 参数权重（FP16 存储）约需 140GB 显存； 每次请求输入的序列数据、KV Cache 会消耗额外显存，并随 batch size 增长而急剧膨胀。 如果不加区分地将 P 与 D 放在同一块 GPU： 参数长期驻留，挤压了用于动态数据的显存； 多实例并发时，数据显存不足，限制了吞吐。 因此，在分布式推理系统中，业界逐渐采用 参数与数据分离（P/D Separation） 的架构思路。 vLLM 简介 vLLM 是一个高性能的大模型推理引擎，核心优势包括： PagedAttention：高效管理 KV Cache，支持大批量并发； 高吞吐率：相较于 Hugging Face Transformers 推理，吞吐提升数倍； 灵活的分布式支持：可结合 DeepSpeed、Megatron 等方案，支持参数/数据分布式存储与调度。 vLLM 的模块化架构，使其天然适合实现 P/D 分离。 P/D 分离的实现思路 在 vLLM 中，推理流程大致分为两个部分： 参数侧（P） 模型权重加载与存放； 可通过 ZeRO-3 / Tensor Parallel 等策略将参数分布在多 GPU 节点上； 参数在整个推理生命周期中保持常驻，不随请求波动。 数据侧（D）...

什么是 VibeVoice？ VibeVoice 是 Microsoft Research 发布的一套面向长篇、多说话人、对话式语音合成的研究框架，目标场景例如整集播客、有声剧或访谈：能在单次生成中维持说话人一致性并处理自然的换手（turn-taking）。模型家族包含多个规模（例如 1.5B、7B 等），并在 Hugging Face 上以 microsoft/VibeVoice-1.5B 形式开放（模型卡、模型文件、model card 中有安装/使用与责任使用说明）。 它解决了传统 TTS（Text-To-Speech）系统的一些痛点，比如： 难以维持长时间对话的语音一致性（speaker consistency）； 多说话人的切换自然性（turn-taking）差； 效率低 — 长文本 + 多说话人时，资源消耗大。 核心创新与架构 VibeVoice 有几个比较新的或者关键的技术设计： 组件 功能 / 目的 Continuous Speech Tokenizers（声学 + 语义两种） 用来把音频压缩成低帧率（7.5 Hz）表示，同时保留语义与音质信息。声学 token 与语义 token 分别负责声音细节和内容表达。 LLM 基础模型（Large Language Model） 在该版本里用的是 Qwen2.5-1.5B，用来处理文本、说话人信息以及上下文对话流。 Diffusion Head 对声学 VAE 的特征进行预测，是生成高保真声音细节的模块。这个模块较轻 (大致 4 层结构)，在推理阶段使用 diffusion 的技术（包括去噪等）。 上下文长度 & 多说话人 支持高达 90 分钟语音生成，最多 4 个说话人。 架构图如下： 优点和局限 优点 长篇幅对话能力 — 能生成近 90 分钟的连续对话，并维持说话人一致性。 多说话人支持 — 最多支持 4 个不同说话人的切换，且对话流程自然。 压缩效率高 — 用 7....

随着大语言模型热度的升级，企业和个人使用者的研究重心逐步从训练转移至推理（说白了是由造轮子转变为务实的使用）。而在模型推理领域，最炙手可热的两大框架无疑是 vLLM 和 SGLang，而作为后起之秀的 SGLang，其表现也值得大家关注，今天就基于 SGLang 为大家带来一篇入门教程文章，希望能帮助更多希望了解大语言模型及 SGLang 框架的朋友。 SGLang 简介 SGLang 是一款面向大语言模型（LLM）和视觉语言模型（VLM）的高性能推理框架，通过精心设计的后端运行时与前端语言协同工作，使模型交互更加高效且可控。其核心优势包括： 高效后端运行时：采用创新的 RadixAttention 技术实现前缀缓存，支持跳跃式受限解码、零开销 CPU 调度、连续批处理、令牌注意力（分页注意力）、张量并行、FlashInfer 内核、分块预填充以及多种量化技术（FP8/INT4/AWQ/GPTQ），显著提升推理效率。 灵活前端语言：提供直观且强大的 LLM 编程接口，支持链式生成调用、高级提示工程、复杂控制流、多模态输入、并行处理及外部系统交互。 广泛模型兼容性：支持多种主流生成式模型（Llama、Gemma、Mistral、QWen、DeepSeek、LLaVA 等）、嵌入模型（e5-mistral、gte）及奖励模型（Skywork），并提供简便的新模型扩展机制。 活跃开源生态：拥有蓬勃发展的社区支持，已获得广泛业界认可（截至 2025 年 3 月 17 日，GitHub 累计星标超过 12,000）。 其技术架构如下： 除此之外，对于初学者，需要了解其以下特性： OpenAI 兼容 API：直接用 openai Python SDK 或 cURL 调用，不用改你的上层业务代码。 高吞吐与低延迟：结合连续批处理与前缀缓存等技巧，让相同前缀的请求复用计算。 生产友好：支持多并发、流式输出、可与 Hugging Face 模型库直接对接。 环境准备 工欲善其事必先利其器，要完成本文的新手实验，需准备如下环境： 操作系统：建议 Linux（常用为 Ubuntu 20.04+）。WSL2 也可尝试。 Python：建议 3.10 或 3.11。 GPU：建议 NVIDIA 显卡，24GB 显存可跑 7B/8B 级（如 Llama 3.1 8B）。没有 GPU 也能跑小模型或量化模型，但性能有限。 模型来源：Hugging Face（如 meta-llama/Llama-3....