Ai

当大语言模型的参数规模跨过几十亿门槛之后，一个事实变得不可回避：单卡时代已经结束。无论是训练还是推理，模型本身的参数规模、KV Cache 的增长速度，以及真实业务中并发请求带来的显存与算力压力，都决定了大模型必须运行在多 GPU、甚至多节点的环境中。 然而，用多张卡跑模型并不是一个简单的资源堆叠问题。在实践中，工程团队很快会发现：不同的拆分方式，带来的性能表现差异可能是数量级的。有的配置 TTFT 极低，却在高并发下迅速失速；有的方案吞吐惊人，却难以满足在线服务对延迟的要求；还有一些组合在理论上看似合理，却在真实硬件拓扑下被通信成本完全吞噬。 在训练与推理阶段，业界逐步沉淀出四类核心并行策略： TP（Tensor Parallelism，张量并行） DP（Data Parallelism，数据并行） PP（Pipeline Parallelism，流水线并行） EP（Expert Parallelism，专家并行，主要用于 MoE） 大语言模型四种核心并行策略基础 Tensor Parallelism（TP）：算子级拆分 核心思想：将单层内部的矩阵计算（如 Linear / Attention）沿维度切分到多张 GPU 上并行计算。 典型拆分方式： Linear 层按 hidden_size 或 num_heads 切分 Attention 的 Q / K / V 或 FFN 的中间层拆分 优点： 单层显存占用显著下降 单 token 延迟较低（适合推理） 代价： 每一层都需要 All-Reduce / All-Gather 通信频繁，对 NVLink / IB 依赖高 适用场景： 单模型过大但层数不多 对 **TTFT（Time To First Token）**敏感的在线推理 Data Parallelism（DP）：请求级复制 核心思想：模型完整复制到多张 GPU，每张 GPU 处理不同请求或 batch。...

随着大语言模型（LLM）在对话系统、智能助手和 Agent 场景中的广泛落地，推理系统面临的核心挑战已从“能不能跑”转向“如何以更低延迟、更高吞吐、更稳定的方式运行”。在这一背景下，PD Disaggregated（Prefill / Decode 解耦） 逐渐成为大规模在线推理系统中的关键架构思想。 本文将不依赖任何具体推理框架，从 模型推理执行流 的角度，系统阐述什么是 PD Disaggregated、为什么需要它，以及它为 LLM 推理系统带来的核心优势。 LLM 推理的两个本质阶段 所有自回归大语言模型的推理过程，本质上都可以拆解为两个阶段： Prefill（预填充阶段） Prefill 阶段负责处理用户输入的完整 Prompt，其主要任务包括： 对输入序列进行一次完整前向计算； 构建上下文对应的 KV Cache； 生成第一个输出 Token。 这一阶段具有如下特征： 计算密集型（Compute-bound） 大规模矩阵乘法（GEMM）占主导 序列长度通常较长 对批处理（Batching）高度友好 Decode（解码阶段） Decode 阶段进入逐 Token 生成过程，每一步都会： 输入上一个生成的 Token； 读取历史 KV Cache； 生成下一个 Token，直到结束条件满足。 其特征与 Prefill 明显不同： 访存密集型（Memory-bound） 计算规模小，但 KV Cache 访问频繁 强延迟敏感 执行步数随生成长度线性增长 问题根源：Prefill 与 Decode 的“异构性” Prefill 与 Decode 并非同一类工作负载，它们在多个维度上呈现出显著异构性： 维度 Prefill Decode 计算模式 大算子、密集计算 小算子、频繁访存 批处理需求 大 batch 效果最好 batch 过大反而增加延迟 延迟容忍度 相对较高 极低 资源瓶颈 算力 显存带宽 / KV Cache 如果将这两种阶段混合部署、统一调度，就会导致资源使用上的结构性低效。...

近年来，生成式 AI 技术迅速演进。在自然语言处理之外，图像生成与编辑能力成为 AI 创新的重要前沿。在这一趋势下，OpenAI 推出了 GPT Image 系列模型，在 Azure OpenAI 服务内同样可用。而其中最新发布的 GPT-Image-1.5 可视为图像生成领域的新旗舰，在性能、效率和可控性方面均有显著提升。 什么是 GPT-Image-1.5 GPT-Image-1.5 是 OpenAI 最新发布的多模态图像生成模型，属于 GPT Image 系列，目前是效果最佳的版本。与前代（如 GPT-Image-1）相比，它在指令遵循能力、图像质量、生成速度和成本效率方面都有明显提升。 官方定义上，GPT Image 模型是原生多模态语言模型（natively multimodal），能接收文本和图像输入，并生成图像输出。在功能上，它不仅支持从纯文本生成图像，还可以对已有图像进行编辑、修改、风格化转换等操作。 简而言之： 多模态：同时理解文本和图像输入。 图像生成与编辑：支持从文本生成全新图像，也支持对已有图像进行局部修改和增强。 高质量与高效：相比前代生成更精细、更快速，同时成本更低。 核心能力与特点 1. 指令遵循及表达精准 GPT-Image-1.5 在理解自然语言提示方面得到显著提升，尤其擅长： 对复杂描述的视觉表达，细节理解更准确 在图像中生成清晰可读的文本内容 遵循用户指令进行定制化修改和组合 相比最初的图像生成模型（例如 DALL·E 系列），这类 GPT Image 系列模型对于提示语的响应更直观、可控性更高。 2. 图像质量与生成速度提升 GPT-Image-1.5 的生成速度比上一代快得多（据报道最高可达大约 4 倍提升），这对于需要快速迭代视觉内容的场景（如设计、产品原型等）尤为重要。 此外，图像生成结果在细节、现实感和一致性方面表现更好，尤其是在脸部、纹理、光影等关键元素上有显著进步。 3. 编辑与增强功能 GPT-Image-1.5 同时支持图像编辑，包括： 局部修改：对选中区域进行变更 添加或移除元素 风格化调整与概念转换 无需完全重新生成整幅图像，大幅提升工作流效率。 4. 成本与效率优化 GPT-Image-1.5 在 API 调用成本上较前代降低约 20%，使得高质量图像生成在更大范围内可持续使用，特别适合企业级批量生成需求。 5. 安全性与合规性 作为 Azure OpenAI 服务的一部分，GPT-Image-1....

在电商和物流领域，有一个不起眼但极其耗时的痛点：将复杂的地址格式正确的输入到物流系统固定的字段中。客户发来的地址格式千奇百怪，有时是逗号分隔，有时连成一行，顺序也完全随机，经常还缺少省份或州等关键信息。 本文我想分享我是如何构建 Auto Address 的，这是一个利用 Azure OpenAI 的强大能力来解决这个问题的 Chrome 及 Edge 浏览器扩展插件，其界面和使用方式及其简单。 问题：非结构化数据 想象一下收到这段文本： “张三 13800138000 广东省深圳市南山区科技园南区R2-B三楼” 为了发货，你需要将其拆解为： 姓名: 张三 电话: 13800138000 地址: 科技园南区R2-B三楼 城市: 深圳市 省份: 广东省 国家: 中国 手动处理成百上千个订单既繁琐又容易出错。正则表达式（Regex）可以处理某些情况，但当格式变化或用户有错别字时，它们往往无能为力。 解决方案：LLM 作为解析器 像 Azure OpenAI（如：GPT-4 或 GPT-5）这样的大语言模型在理解上下文方面表现出色。它们能区分街道名称和城市名称，不是因为死板的规则，而是因为它们理解地址的语义。 我选择 Azure OpenAI 进行此项目主要有两个原因： 企业级隐私：发送到 Azure OpenAI 的数据不会用于训练公共模型。 可靠性：稳定的正常运行时间和性能。 技术揭秘：它是如何工作的 插件的核心逻辑出奇地简单。它获取用户的输入，并将其连同一组非常具体的指令发送到 Azure OpenAI API。 1. System Prompt (系统提示词) “魔法”在于系统提示词。我们需要确切地告诉模型要做什么，更重要的是，如何格式化输出。 这是代码中实际使用的提示词： { role: "system", content: "You are an address parser. Return ONLY a raw JSON object (no markdown code blocks) with keys: name, province, city, address, zip_code, country....

过去五年，大语言模型（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 时的首选。...

微软研究院最近发布了 Fara-7B，这是一款专为电脑操作（Computer Use）设计的代理小语言模型（Agentic SLM）。与传统的聊天模型不同，Fara-7B 旨在通过像人类一样使用鼠标和键盘来完成任务。 什么是 Fara-7B？ Fara-7B 是一个拥有 70 亿参数的模型，基于 Qwen2.5-VL-7B 构建。它的主要特点包括： 视觉感知：它通过视觉感知网页（截图）来操作，不需要依赖辅助功能树（Accessibility Trees）或额外的解析模型。 高效紧凑：尽管只有 7B 参数，但在同类模型中实现了最先进的性能，甚至在某些基准测试中可以与更大的模型竞争。 端侧运行：由于体积小，它可以在设备上本地运行，从而降低延迟并提高隐私安全性。 核心技术 Fara-7B 的训练利用了微软开发的合成数据生成管道，该管道基于 Magentic-One 框架。它通过“观察-思考-行动”（observe-think-act）的循环来执行任务。 在每个步骤中，模型会接收： 用户指令 完整的操作历史 最近的三张屏幕截图 然后，它会输出一个推理信息（“思考”下一步行动），随后调用工具（如 click(x,y)、type() 等）来执行操作。 性能表现 在 WebVoyager、Online-Mind2Web 等基准测试中，Fara-7B 展现了强大的性能。例如在 WebVoyager 上，它的任务成功率达到了 73.5%，超过了 UI-TARS-1.5-7B (66.4%) 和 GPT-4o (SoM Agent, 65.1%)。 如何通过 vLLM 使用 Fara-7B Fara-7B 已经发布在 Hugging Face 上。由于它是基于 Qwen2.5-VL 的，我们可以使用 vLLM 来高效地部署和推理。 安装 vLLM 首先确保你安装了最新版本的 vllm： pip install vllm Python 代码示例 以下是一个使用 vLLM 加载 Fara-7B 并进行推理的 Python 脚本示例：...

随着 AI 辅助编程工具的不断进化，GitHub Copilot 也在持续引入更多强大的模型供开发者选择。最近，GitHub Copilot 宣布支持 Google 最新的 Gemini 3 Pro 模型（预览版）。作为一个每天都在使用 Copilot 的开发者，我第一时间进行了体验，发现它在逻辑推理和长上下文理解方面有着令人惊喜的表现。 在这篇文章中，我将手把手教你如何在 VS Code 中切换到 Gemini 3 Pro，并分享一些使用心得。 为什么要关注 Gemini 3 Pro？ Gemini 3 Pro 是 Google 推出的最新一代多模态大模型。在代码生成和理解领域，它展现出了极强的竞争力： 更强的推理能力：面对复杂的算法问题或架构设计，Gemini 3 Pro 往往能给出更深入的分析。 超长上下文窗口：它能够理解更多的项目代码上下文，这对于大型项目的重构和 Bug 修复至关重要。 响应速度：尽管模型参数巨大，但在 Copilot 中的响应速度依然非常流畅。 如何在 GitHub Copilot 中启用 Gemini 3 Pro 启用过程非常简单，只需要确保你的 VS Code 和 Copilot 插件是最新版本。 步骤 1：更新环境 确保你的 Visual Studio Code 和 GitHub Copilot Chat 扩展都已经更新到最新版本。通常 VS Code 会自动更新，但你也可以手动检查一下。 步骤 2：打开 Copilot Chat 在 VS Code 侧边栏点击 GitHub Copilot 图标，打开聊天窗口。...

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