博客

随着大语言模型（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：...

在构建 AI 应用的过程中，大语言模型（LLM）的微调是企业和开发者实现“定制化能力”的核心手段。随着行业快速发展，微调技术已经从最早的传统全参数微调，演进到高效、低成本的多种方法，比如 LoRA、QLoRA、Adapters、指令微调（SFT）、奖励模型训练（RM）与 RLHF 等等。 本文将系统介绍主流微调方法，并对比它们的优缺点，最后给出“什么场景适合什么方法”的决策指南，帮助您在项目中做出正确选择。 为什么需要微调 LLM？ 预训练大模型虽然功能强大，但在具体业务中往往会出现： 行业术语理解不够（如金融、法律、医疗） 回答不符合企业风格或业务逻辑 需要模型具备专门技能（如 SQL 生成、代码风格限定） 数据结构化能力不佳 多轮对话表现不符合行业预期 因此 —— 您需要微调。 主流微调方法概览 1. 全参数微调（Full Fine-tuning） 原理： 更新模型中的所有参数（数十亿级），直接用业务数据对大模型做“重训练风格的修改”。 优点： 效果最好，可深度定制 可改变模型内在知识结构 缺点： 昂贵（训练成本高） 需要大量显存 对数据量要求大 适用场景： 超大企业、科研机构 需要深度改造模型知识，例如专业领域（法律、医学）的专家模型 2. Adapter / Prefix Tuning 原理： 冻结大部分模型，只在中间层插入小的“微调模块”（Adapter），只训练这些模块。 优点： 轻量、可插拔 多任务共存方便（一个模型挂多个 Adapter） 效果通常不错 缺点： 极端任务下效果不如 LoRA / 全参数 适用场景： 企业想在一个模型上运行多个不同业务 需要模块化、可管理的微调方式 3. LoRA 微调（Low-Rank Adaptation） 原理： 不训练大模型的全量矩阵，而是训练低秩矩阵（A、B），通过“低秩更新”改变模型行为。 这是目前最主流的微调技术。 优点： 显存需求极低 效果接近全参数微调 开源生态成熟（如 HuggingFace PEFT） 缺点：...

原文链接：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....

DeepSeek 的爆火让人们再一次看到了 AI 的魅力，而随之而来的不仅不是对算力需求的减少，而是在低成本亲民化人工智能中构建更多 AI 业务场景带来的另一波算力需求。今天我们来通过 Azure AI Foundry（原 Azure AI Studio）快速体验 DeepSeek 的风采。 先决条件 首先需要拥有 Azure 订阅，新用户参考玩转大语言模型：无需任何代码通过 Azure OpenAI 服务构建个人专属 ChatGPT中步骤进行开通。然后在 Azure 订阅中创建 AI Foundry 及相关资源，可以参考创建 Azure AI Foundry 服务中的步骤，这里不再赘述。 一切完成后进入 Azure AI Foundry 首页，并打开名为 main 的 Project，界面如下： 部署 DeepSeek-R1 大语言模型 点击左侧菜单中的 Model catalog 进入模型列表页： 这里可以看到 Azure 提供了超过 1800 种模型，满足用户全方位的需求。 在搜索框输入 DeepSeek 来查看 Azure 支持的 DeepSeek 模型种类： 其中，第一个是全量版 DeepSeek-R1 671B 模型： 另一个是经过 NPU 优化的基于 Qwen 的 DeepSeek-R1 1.5B 蒸馏版：...

原文地址（英文）：The Istio Service Mesh for People Who Have Stuff to Do 我最近为开源服务网格项目 Istio 做出了一点贡献。 我的贡献包括为 Istio CLI 命令之一添加一些测试。如果您想查看详细信息， 可以在此处找到 Pull Request。 这不是一个巨大的变化，但却是一次很棒的学习经历。在 Istio 上工作帮助我更深入地了解服务网格。 我很高兴能做出更多贡献。在这篇文章中，我将解释 Istio 是什么、它为什么有用以及它是如何工作的。 Istio 是什么？ 从本质上讲，Istio 是一种服务网格。服务网格管理微服务之间的通信， 处理诸如路由流量、保护通信和提供可观察性等事务。随着微服务数量的增加， 管理这些交互会变得复杂。Istio 可以自动执行其中许多任务， 因此您可以专注于构建应用程序，而不是管理服务到服务的通信。 为什么要使用 Istio？ 随着架构变得越来越复杂，您将面临新的挑战。 服务需要以可靠、安全和高效的方式进行通信。Istio 可在三个关键领域帮助您实现此目标： 管理流量：Istio 让您可以控制服务之间的流量流动方式。 您可以在服务的不同版本之间拆分流量，在部署期间重新路由请求，或设置重试和超时策略。 确保通信安全：Istio 可以轻松启用双向 TLS（mTLS）。 这可确保服务之间的所有通信都经过加密和身份验证，从而阻止未经授权的服务进入。 可观察性：Istio 自动收集指标、日志和链路，让您实时了解服务。这有助于监控、故障排除和性能调整。 这三个领域 - 流量管理、安全性和可观察性是运行健康的微服务架构的关键，Istio 可以轻松处理它们。 通过 Istio 管理流量 Istio 的主要功能之一是管理服务之间的流量。在微服务设置中， 您可能同时运行多个版本的服务。例如，您可能正在测试支付服务的新版本， 并希望将大部分流量发送到版本 1，但将部分流量路由到版本 2。 以下是如何使用 Istio 在服务的两个版本之间分割流量的示例： apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: payments spec: hosts: - payments....

日常使用 ChatGPT 来帮助我们解决工作和生活中的问题已经变成习惯，但偶尔重度使用官方 GPT-4o 后发现会出现临时限额问题，今天我们就来手把手教大家如何轻松通过 Azure OpenAI 服务构建一个专属 ChatGPT 应用。 先决条件 在开始之前，请确保您拥有 Azure 国际版订阅服务，如果您还没有 Azure 订阅，可以通过 Pay-as-you-go 轻松开启一个 Azure 订阅： 注意：开启 Pay-as-you-go Azure 订阅必须绑定国际信用卡，对于新用户还有 200 美金的免费额度，我们完全可以使用这些额度充分使用 Azure 的各项服务。 下面介绍的内容除了与 GPT-4o 交互产生的费用外，其他都是免费的，日常不适用的话不会产生任何费用，GPT-4o 的费用也可以完全使用免费额度覆盖，所以大家不用担心信用卡被刷爆。 成功拥有 Azure 订阅后，然我们开始吧！ 步骤 1：创建 Azure AI Studio 服务 在 Azure 订阅主页上方搜索栏中输入 azure ai，找到 Azure AI Studio： 点击进入 Azure AI Studio 资源页面： 点击 + New Azure AI Hub 进入创建页面： 从界面可以看到创建 Azure AI Hub 共分为 7 个步骤，这里按照指引一路 Next 都选择默认即可，其中需要注意的是区域建议选择 East US，由于免费订阅有一些资源使用限制，目前根据经验来看 East US 区域的使用便利性更佳。...