企业级AI硬件选型与规划

CPU vs. GPU

架构差异的本质

  • CPU：设计初衷是处理顺序指令，擅长复杂逻辑控制和串行计算，核心数较少（数十核），但单核能力强；
  • GPU：由数千个小而高效的核心组成，适合处理LLM的并行矩阵运算。以NVIDIA H100为例，拥有16896个FP32 CUDA核心；RTX 4090 拥有 16384个 CUDA核心，中国特供版4090D为14592个。

我们用人来比喻，CPU是大学生，可以做复杂的计算与事务处理；GPU是几千个小学生，他们只会做简单的加减乘除计算，可以进行并行计算。
以单个核来说，CPU最强。

CUDA 是NVIDIA推出的并行计算平台和编程模型，全称为Compute Unified Device Architecture。
CUDA核心是GPU的基本计算单元，专为并行计算设计，能同时执行大量简单运算。

LLM的矩阵运算

LLM的核心是将文本转化为高维向量（Token）进行处理。每个词会转为一个向量（如4096维），整句话就形成一个矩阵。

Transformer架构通过矩阵运算来捕捉词与词之间的复杂关系。
比如：输入句子有100个token，每个转为1×4096向量，堆叠成100×4096的矩阵。
注意力机制计算 token A与token B的相关度，本质是Query矩阵 × Key矩阵的乘法。
当模型有1750亿参数，处理的矩阵运算，计算量极其庞大。

每个token都有独立的向量。LLM需要理解每个词的位置和含义，以及它们之间的关系。如果整句压缩成一个向量，就丢失了哪个词在前、哪个词在后的顺序信息。
具体过程：

  • 句子有100个token → 生成100个4096维向量（每个token一个）
  • 这100个向量堆叠成 100×4096 矩阵输入Transformer

在LLM中句子不会变成单个向量。 模型输出的也是100个向量（每个位置对应一个token的表示）。但如果你想把整句话压缩成一个句向量，需要额外做池化操作。比如对所有token向量取平均，得到一个4096维的句向量，用于计算相似度，或者分类等下游任务。

Embedding模型
Embedding模型（如BGE、M3E）本质上就是LLM + 池化层。

它把LLM输出的token矩阵压缩成单个向量（768/1024/4096维），专门用来做语义检索和相似度计算。

LLM本身（如GPT、Claude）不做池化：

  • 输入： 100个token → 100×4096 矩阵；
  • 输出： 100个位置的logits，每个位置预测下一个token是什么，保留每个位置的独立表示，才能按顺序生成文本。

Embedding模型 = LLM底座 + 池化头，池化这一步把生成模型变成了表示模型。

LLM推理中的数据搬运

内存墙问题

  • SRAM（静态随机存取存储器）： 速度极快（320GB/s单SM带宽，40TB/s级聚合带宽），但容量极小（每SM仅128KB），用于线程间高效交换数据，GPU芯片内的 超高速小仓库；
  • HBM（高带宽内存）： GPU显存的主力。2026年主流为HBM3e，带宽已达4.8TB/s（H200）到8TB/s（B200），HBM是芯片外的大仓库。

这是打破LLM推理显存墙的关键：大模型推理90%的时间花在数据搬运而非计算上。

2026年的硬件选型逻辑已从算力优先转向带宽优先+显存容量优先。对于推理场景，显存带宽直接决定Token生成速度。

在GPU中，线程间通过SRAM（即Shared Memory/共享内存）高效交换数据：

  1. 数据复用（Tiling/分块计算）
    矩阵乘法、卷积等计算中，多个线程需要重复读取同一块全局内存数据。
    先将数据从显存（HBM/GDDR）加载到SRAM，线程块内线程共享访问，避免重复读取（显存带宽仅~1TB/s，远低于SRAM的40TB/s聚合带宽）。

  2. 并行归约与协作计算
    实现线程块内的归约操作（Reduction，如求和、求最大/最小值、矩阵行/列归一化），前缀和（Prefix Sum/Scan）等需要线程间数据传递的算法。

  3. 结果聚合与缓存
    卷积的多个输出通道复用同一输入特征图，Transformer中的Q/K/V矩阵计算时缓存中间结果。

本质： 用极低延迟，让协作线程以比访问，显存快10-100倍的速度共享中间数据

如果你在工厂加工（矩阵计算），但原材料（模型参数）存在10公里外的仓库（HBM）。虽然你加工速度极快，但卡车运货太慢，你90%时间在等货。
LLM几百GB参数无法全塞进SRAM，必须反复从HBM搬运到SM。虽然SM计算非常快，但搬运速度比计算慢50倍以上。

现在架构都一点点在靠近芯片架构，统一封装，减少传输时间。

GPU算力被内存带宽卡死——这就是内存墙。

核心GPU型号

型号 架构 显存/带宽 定位 适用场景 说明
H100 Hopper 80GB HBM3 / 3.35TB/s 中流砥柱 7B-70B模型训练/推理，生态最成熟 交付稳定，云厂商主力
H200 Hopper 141GB HBM3e / 4.8TB/s 内存怪兽 长上下文推理（>128K）、70B+模型单卡部署 解决"跑不动"问题的首选
B200 Blackwell 192GB HBM3e / 8TB/s 下一代主力 MoE架构、FP4低精度推理、千卡级集群 已大规模交付
B300 Blackwell Ultra 288GB HBM3e / 8TB/s 显存之王 超大模型单卡承载、边缘到云端统一 2025Q3已发布
L40S Ada Lovelace 48GB GDDR6 / 864GB/s 推理黑马 放宽延迟预算的连续批处理场景 性价比之选
RTX 4090 Ada Lovelace 24GB GDDR6X 原型验证 1B-7B模型本地调试、教学用途 消费级，无NVLink

架构代际（从旧到新）： Ada Lovelace (2022) → Hopper (2022) → Blackwell (2025)。
先进程度： Blackwell最新，其次Hopper（数据中心专用），Ada Lovelace已属上一代。

选型建议：

  • <7B参数：用L40S或RTX 6000 Ada，H100性能过剩；
  • 7B-30B全参训练：H100（FP8+梯度检查点，生态最成熟）；
  • 30B-70B推理：H200（141GB显存可单卡运行70B，避免多卡通信开销）；

  • 70B dense或MoE（如DeepSeek-V3）：B200（192GB显存+NVLink 5，显著缓解显存瓶颈）；

  • 超长上下文(>128K)：训练选B200（高带宽），推理选H200（性价比更高）；

显存需求： RTX 6000 Ada 大一倍（48GB），可本地运行 70B 模型（INT8），RTX4090 只能跑 30B 以下；

NVLink 是 NVIDIA 的 GPU 间高速互联技术；

B 系列（Blackwell）优势： 生成式 AI 场景，专用 AI 芯片，做大模型训练/推理，B200 明显更好；
H 系列（Hopper）优势： 科学计算场景，通用计算芯片，做气象模拟、分子动力学等科学计算，H100/H200 更优；

Blackwell架构的革命性变化：

  • FP4精度支持： 相比FP8，内存占用再减1.8倍，吞吐提升55%，且精度损失可接受；
  • 第五代NVLink： 带宽1.8TB/s，适合千卡级超大规模训练；
  • 能效比： 每次推理能耗仅为H100的1/25，Llama 3推理单卡可替代5个H100节点。

CPU与内存的隐形瓶颈：

  • 推理不仅是GPU的事，也和CPU有关。
    CPU负责：并发请求调度、Tokenization（文本Token转换）、前后处理（JSON解析、正则过滤）；
  • CPU与GPU需要合理配比。
    若并发量大，CPU负载过高或系统内存（DRAM）不足，会导致GPU会陷入饥饿等待状态。建议配比：每1张GPU配16-32核CPU + 512GB-1TB DRAM。

功耗与散热的考虑：

  • B200单卡功耗已达1000-1200W，B300将达1400W；
  • 2026年新建机房必须预留液冷基础设施，传统风冷已无法满足Blackwell集群需求。

针对个人：

  • 最多人买： RTX 4090（约¥15,000-20,000），24GB 显存可跑 13B-30B 量化模型，FP8 支持成熟，性价比优于 5090。
  • 预算紧张： 二手 RTX 3090（约¥5,500-6,000，24GB 显存），不推荐 5090，价格贵 50%（约¥20,000-25,000），性能仅提升 15-20%。
  • 不推荐 RTX 6000 Ada： 价格高达 ¥46,000，深度学习性能反而比 4090 慢 15%，且为专业工作站设计。

针对个人GPU 散热情况（无需额外风扇）：

  • RTX 4090（450W）： 标准三风扇风冷即可，满载约 62-70°C，普通 ATX 机箱足够；
  • RTX 5090（575-600W）： 风冷可压但温度较高（75-85°C），建议机箱风道优化（侧面进风、下进上出），水冷效果更好（核心低 5°C，显存低 10°C）；
  • RTX 6000 Ada（300W）： 涡轮散热设计，满载 85°C，噪音可控，适合紧凑机箱；

只有多卡训练（2 张及以上）时才需要额外机箱风扇辅助散热，单卡使用无需担心。

主流部署框架

早期模型服务（如原生HuggingFace、NVIDIA Triton）采用请求级调度（Request Scheduling），面对LLM变长输出时造成巨大算力浪费。

现代LLM推理引擎的核心创新是Continuous Batching（连续批处理）和PD分离架构。

四大主流框架

框架 核心创新 适用场景 2026年最新动态 开源状态
Ollama 极简封装（基于llama.cpp） 本地开发、边缘设备、 CPU推理 定位不变，适合快速验证 Apache 2.0
vLLM PagedAttention（页式KV Cache管理） 高吞吐、大批量Prompt的生产环境 V1架构重构（2025.1 alpha），加入PyTorch基金会（2025.5），生态最活跃 Apache 2.0
SGLang RadixAttention（前缀树KV复用） 多轮对话、 Agent/CoT/RAG等复杂交互 已部署超30万GPU， 日处理数万亿Token，2025.3加入PyTorch生态 Apache 2.0
TensorRT-LLM 硬件原生优化、自定义CUDA核 追求极致性能的NVIDIA GPU环境 v1.0+ 推出trtllm-serve命令，原生支持OpenAI兼容API，门槛大幅降低 Apache 2.0

框架选型：

  • 新手/快速验证： 选Ollama（2分钟跑起来）；
  • 生产环境通用场景： 选vLLM（生态最全，文档最丰富）；
  • 长上下文/Agent/多轮对话： 选SGLang（RadixAttention对重复前缀的复用率可达90%+）；
  • 极致性能/已用Triton： 选TensorRT-LLM（Blackwell上FP4推理必需）；

Ollama本地部署大模型

Ollama 官方主要支持 macOS 和 Linux，但 Windows用户也可以安装。

方法1：使用 WSL
Step1， 打开 PowerShell（管理员权限），运行：wsl --install，重启电脑后，WSL 会自动完成安装（默认安装 Ubuntu）。

Step2， 安装 Ollama
在 WSL 终端（Ubuntu）中运行： curl -fsSL https://ollama.com/install.sh | sh。

Step3， 启动 Ollama 服务，ollama serve（保持此终端运行，另开一个新终端进行后续操作）。

方法 2: 直接下载 Windows 版
Ollama下载windows软件包，安装后，Ollama 会作为服务运行（可在任务管理器查看）。

在这里插入图片描述

从Ollama官方模型库 下载 qwen3.5:0.8b 模型

ollama pull qwen3.5:0.8b

在这里插入图片描述

如果要删除该模型，可以使用

ollama rm qwen3.5:0.8b

运行该模型，使用

ollama run qwen3.5:0.8b

进行询问

你好啊，你是什么大模型？

在这里插入图片描述

Ollama 推理引擎
Ollama 推理引擎：基于 llama.cpp，C/C++ 编写的高性能推理库，针对消费级 GPU 和 CPU 优化。

llama.cpp 是开源的高性能LLM推理引擎，纯C/C++实现，主打跨平台本地部署。支持GGUF格式量化（4/8bit压缩），让消费级CPU甚至手机也能流畅运行大模型。零依赖、可离线使用，被Ollama、LM Studio等工具广泛采用，是本地LLM生态的核心基础设施。

llama.cpp 是软件名称，也是 GitHub 上的开源项目名称。
.cpp 是 C++ 的源代码文件后缀，它明确用 .cpp 后缀告诉开发者：这是一个用 C++ 语言编写的项目。

在这里插入图片描述

实际上Ollama是双层架构：

  • Go 层： 写 API 服务、模型管理、命令行交互（利用 Go 的并发和网络优势）；
  • llama.cpp（C++）： 通过 CGO 封装为 Go 可调用的接口，负责底层矩阵计算和模型推理。

Go 管调度和服务，C++ 管算力，两者通过 CGO 无缝协作。

Go 语言是 Google 开发的静态类型语言，主打高并发（goroutine 轻量线程）、编译速度快和内存管理自动化。语法简洁，自带垃圾回收，适合写网络服务和云原生工具。

Ollama的局限性： 不支持Continuous Batching，并发能力差，仅适合单用户调试。

传统批处理（Static/Dynamic Batching） 要求整批请求同步开始、同步结束。
而 Continuous Batching 将粒度细化到 Token 级别

传统批处理: [请求A 请求B 请求C] → 等待全部完成 → [请求D 请求E …]

       └─────── 必须等待最慢的请求 ────────——┘

Continuous：
迭代1: [A₁, B₁, C₁]
迭代2: [A₂, B₂, C₂]
迭代3: [A₃, B₂, 新请求D₁] ← 请求C完成，D立即插入
迭代4: [A₄, B₃, D₂, 新请求E₁] ← 请求B完成，E立即插入

Ollama的API层不是通过GO语言来实现的么？怎么还不支持并发了？

Go 的并发≠推理层的连续批处理（Continuous Batching）。

Go 层确实能并发处理 HTTP 请求，但瓶颈在底层推理引擎 llama.cpp：

  • Continuous Batching 是推理优化技术： 多个用户的请求在同一个推理步骤中动态拼接，共享一次forward pass。这能大幅提升 GPU 利用率。
  • llama.cpp 的限制： 它主要为单用户本地运行设计，缺乏 vLLM 那样的 Continuous Batching 和PagedAttention 机制。即使 Go 层并发接收了 10 个请求，llama.cpp 可能还是串行执行，或简单静态batching，导致 GPU 利用率低。

Ollama 的定位： 本地单用户调试工具，不是生产级服务。Go 负责快速启动和管理，但不改造 llama.cpp 的推理内核。

案例

使用 Ollama REST API

Ollama 本身提供 REST API 接口，默认运行在 localhost:11434，运行 ollama serve 时，API 服务会自动启动。

在这里插入图片描述

使用 Ollama FastAPI封装

在这里插入图片描述

vLLM高效部署

VLLM 是由伯克利大学 LMSYS 组织开源的LLM高速推理框架，用于提升LLM的吞吐量与内存使用效率。它通过 PagedAttention 技术高效管理注意力键和值的内存，并结合连续批处理技术优化推理性能。vLLM 支持量化技术、分布式推理、与 Hugging Face 模型无缝集成等功能

vllm serve vllm serve /root/autodl-tmp/models/Qwen/Qwen3.5-4B/snapshots/master --tensor-parallel-size 1 --max-model-len 32768 --enforce-eager --quantization gptq --dtype auto

参数说明：

  • vllm serve，启动 vLLM 推理服务的命令；
  • vllm serve /root/autodl-tmp/models/Qwen/Qwen3.5-4B/snapshots/master，modelscope 模型库中的模型名称，vLLM 会尝试从 MS 下载模型；
  • –tensor-parallel-size 1，启用张量并行，在 1 个 GPU 上分布式运行模型（适合 4B 大模型）；
  • –max-model-len 32768，设置模型的最大上下文长度（32K tokens），确保能处理长文本；
  • –enforce-eager，禁用 CUDA Graph 优化（可能在某些环境下更稳定，但性能稍低），必须加，禁用 torch.compile，否则报 AttributeError: FakeTensorMode；
  • –quantization gptq：显式声明使用 GPTQ 量化。
  • –dtype：设为 half（FP16）或 auto（自动选择），因为 GPTQ 本身是 4-bit，但计算时需指定中间精度。

Vllm终端命令：

# 卸载 vllm（不卸载依赖）
pip uninstall vllm -y

# 强制重新安装并重新编译（约 5-10 分钟）
pip install vllm --force-reinstall --no-cache-dir

# vllm
pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple

#  查看torch版本
pip show torch

# vLLM 0.18.0 官方推荐 PyTorch 2.6.0
pip install torch==2.6.0 torchvision torchaudio --upgrade

# vllm列表
pip list | grep -E "(vllm|torch|transformer|openai|httpx|nvidia|flash|numpy|fastapi|uvicorn|pydantic|tokenizers|sentencepiece)"

案例

step1， 先安装modelscope包、vllm包

# vllm
pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple

# modelscope
pip install modelscope -i https://pypi.tuna.tsinghua.edu.cn/simple

在这里插入图片描述

step2， 从modelscope平台下载Qwen3.5-4B模型

在这里插入图片描述

step3， 使用vLLM进行部署Qwen3.5-4B模型

# 在数据盘创建虚拟环境
python -m venv /root/autodl-tmp/venv

# 激活（每次重启或新终端都要执行）
source /root/autodl-tmp/venv/bin/activate

# 升级 pip 后安装
pip install --upgrade pip
pip install vllm transformers --upgrade

# vllm部署
vllm serve vllm serve /root/autodl-tmp/models/Qwen/Qwen3.5-4B/snapshots/master --tensor-parallel-size 1 --max-model-len 32768 --enforce-eager

在这里插入图片描述

在这里插入图片描述

step4， 连接模型

curl http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "/root/autodl-tmp/models/Qwen/Qwen3.5-4B/snapshots/master", "messages": [{"role": "user", "content": "你好，请介绍下自己"}], "max_tokens": 512 }'

在这里插入图片描述

step5，开启Qwen3 特殊功能 - 控制思考模式：

# 开启思考模式（模型会先思考再回答）
curl http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "/root/autodl-tmp/models/Qwen/Qwen3.5-4B/snapshots/master", "messages": [{"role": "user", "content": "解方程 2x + 3 = 7"}], "max_tokens": 1024, "extra_body": {"enable_thinking": true} }'

在这里插入图片描述

step6，Python 调用

在这里插入图片描述

SGLang框架

SGLang 框架是开源的大模型推理引擎，由加州大学伯克利分校的 LMSYS 团队开发（和 Vicuna、Chatbot Arena 是同一个团队），2025 年刚被 PyTorch 官方收编为生态项目，定位是更快的 vLLM，特别适合做高并发、低延迟的 API 服务。

性能特点：

  • RadixAttention： 智能前缀缓存，多轮对话场景下能把重复计算的 Prompt 缓存复用，长上下文吞吐量是 vLLM的 2-5 倍；
  • 结构化输出快 10 倍： 生成 JSON、函数调用参数时，比标准引擎快一个数量级；
  • SGLang Runtime： 原生支持多模态（图片+视频理解），DeepSeek R1 等推理模型开箱即用；
  • Pythonic DSL： 写 LLM 应用像写普通 Python 代码一样，支持条件判断、循环、并行调用；

性能对比（H100 单卡）

  • 吞吐量： 比 vLLM 高 29%（约 16,200 vs 12,500 tok/s）
  • 成本： 百万日活场景下，每月可节省约 $15,000 GPU 费用
  • 首 Token 延迟： 配合 PD 分离技术，可降低 60%

适合的场景：

  • 聊天机器人/客服： 多轮对话多的场景，前缀缓存命中率可达 75-95%；
  • Agent/Function Calling： 需要频繁输出结构化 JSON 的场景；
  • 长文档处理： 论文总结、代码审查等长上下文任务；
  • 多模态 API： 同时处理图文视频的复杂请求；

框架选择：

  • vLLM：最主流，互联网大厂 API 服务、阿里云/腾讯云 GPU 实例内置、绝大多数 AI 初创公司首选；
  • SGLang：快速增长，xAI (Grok)、Microsoft Azure、阿里盘古等大规模部署；2025年3月刚加入 PyTorch 生态；
  • Ollama：个人/边缘端，本地开发、教育、边缘设备，不适合高并发 API 服务；

在企业内部搭建OpenClaw，做 API 服务选择：稳妥优先vLLM

  • PagedAttention： 显存利用率从 30% 提升到 90%+，支持千级并发；
  • 生态最成熟： 支持模型最多（几乎所有 HuggingFace 格式），文档最全，GitHub Issues 里有现成答案；
  • 生产验证： 国内头部大模型厂商的 API 服务很多基于 vLLM 改造；
  • 缺点： 在 H100 上的吞吐量（~12,500 tok/s）比 SGLang 低约 29%

性能优先：SGLang

  • 如果你的团队有较强的底层优化能力，且追求极致性价比（省 GPU = 省钱），选 SGLang；
  • 吞吐量更高： H100 上可达 16,200 tok/s，比 vLLM 快 29%，日活百万级请求下每月可省约 $15,000 GPU 成本；
  • RadixAttention： 对多轮对话、Agent 场景优化极好，前缀缓存命中率 75-95%，长上下文吞吐量可达 vLLM 的 5 倍；
  • 结构化输出快： JSON 生成速度比 vLLM 快 10 倍，适合 Function Calling；
  • 现状： 生态在快速追赶（已支持 DeepSeek V3/R1、AMD GPU、昇腾 910B），但文档和社区不如 vLLM 成熟；

结构化

结构化信息 Outlines

生成式AI如果输出结构化的信息，比如JSON格式的好处：

  • 标准化： 输出一致的格式。
  • 可读性： 易于理解和处理。
  • 易于解析： 很多语言都能轻松解析JSON格式，便于处理。

生成JSON结构化信息有多种场景：

  • 客户信息管理： 创建结构化客户档案，包括姓名、联系方式、车辆信息、保险类型等，便于管理和使用。
  • 索赔处理： 生成索赔申请的结构化数据，包含事故描述、损失估算、相关文件等，以简化索赔审核流程。
  • 保单生成： 自动生成保单信息的JSON格式，便于系统记录和客户查看，确保所有条款清晰可见。

Outlines工具：

  • 开源的 Python 库，为LLM提供结构化文本生成能力；
  • 支持多种语言模型，如 OpenAI、Transformers、llama.cpp、exllama2 等；
  • 与非结构化生成相比，几乎不增加额外开销；
  • 灵活性高，支持与循环、条件语句和自定义 Python 函数结合使用；
  • 支持多种结构化生成方式，比如多项选择、类型约束、正则表达式结构化生成、JSON 生成以及基于上下文无关文法的生成。 比如：正则表达式：email地址、手机号Json: {“name”: “mingming” , “Age”: }。

非结构化生成： 指 LLM 自由发挥生成文本，没有格式约束。

结构化生成（Outlines 做的）是强制模型按 JSON Schema、正则表达式、固定模板 输出，确保格式100% 合法

假设我们希望语言模型生成一个故事中角色的JSON对象, 这个角色需要有一个名字和一个年龄，分别对应JSON的两个Key, “name”和“age”字段。
这里使用Pydantic定义一个角色：

from enum import Enum
from pydantic import BaseModel

class Name(str, Enum):
	john = "John"
	paul = "Paul"

class Age(int, Enum):
	twenty = 20
	thirty = 30

class Character(BaseModel):
	name: Name
	age: Age

Pydantic 是一个Python 库，用于数据验证和设置管理。
在 Outlines 工具中，Pydantic 可以高效地生成符合
JSON Schema 或 Pydantic 模型的 JSON 数据。

我们可以利用这个正则表达式来控制LLM的输出结构化。理论上不是所有的JSON格式都能用正则表达式表示，但大多数情况下，用正则表达式近似表示就够用了。

正则表达式表达为有限状态机
Outlines结构化生成速度快，是因为正则表达式和有限状态机之间的等价性。
1）使用interegular第三方库将JSON正则表达式转换为有限状态机。
2）根据有限状态机进行Json结构的生成了，具体过程：

  • 从状态0开始。
  • 随机生成允许的转换字符之一。
  • 按照相应的转换到达新状态。
  • 重复以上过程，直到达到有限状态机的最终状态之一（这里只有一种最终状态，即状态27）。

使用interegular输出的有限状态机（可视化图）
在这里插入图片描述

通过合并（Coalescence）加速结构化的生成：
观察上述有限状态机（FSM）的部分，可以看到：大多数状态只有一个可转移的状态。那么抽样就显得没有必要。把只有一个转移状态的节点进行合并，我们就可以跳过一些采样过程了（i.e. 大模型的调用次数），合并之后，上面的有限状态机就变成了下面这样：

在这里插入图片描述

假如Prompt是 “generate a character”，以前不需要结构化输出的时候，正常的调用过程是:
第一轮: 输入：generate a character，大模型输出&采样: y；
第二轮: 输入：generate a character, y 大模型输出&采样:e…；
第n轮：输入：generate a character, yes i can generate a character for yo , 大模型输出&采样：u；

有了上面的有限状态机，就变成了下面的采样过程：
第一轮: 输入：generate a character，{“name”, "大模型输出&采样: P
第二轮: 输入：generate a character, {“name”,“Paul”,“age”: 大模型输出&采样: 3
然后就不用再调用大模型了，直接得到generate acharacter, {“name”, “Paul”,“age"30”}

这里只调用2次大模型，但是，LLMs不使用单个字母，而是使用Token。所以还需要需要把字母变成token。

在这里插入图片描述

LLM Works with tokens
Outlines可以将基于字符的有限状态机转换成基于Token的有限状态机。
看起来虽然很复杂，但是和上面单个字符的生成过程是一样的，只不过是把单个字符组合为token输入进大模型。

在这里插入图片描述

案例

在这里插入图片描述

结构化输出（OpenAI兼容协议）

结构化输出： DashScope(通义千问)提供了兼容OpenAI协议的API，支持结构化输出。可使用qwen-turbo、qwen-max等模型。

  • Function calling模式： 在函数定义中设置strict:true，可以结构化输出。
  • response_format参数： 可以通过json_schema提供JSON Schema。当模型不是调用工具，而是以结构化方式响应用户时，很有用。需要提供响应格式并设置为strict:true。

说明: DashScope的OpenAI兼容接口支持Function Calling和response_format两种结构化输出方式，使用方式与OpenAI SDK一致。

在这里插入图片描述

在复杂JSON的评估中，设置 strict=true的结构化输出得分完美 100%。

结构化输出的安全性：

  • 结构化输出将遵循现有的安全政策，允许模型拒绝不安全的请求。
  • API 响应中新增了一个拒绝字符串值，能够以编程方式检测模型是否生成了拒绝，而不是输出匹配模式。
  • 当响应中不包含拒绝且模型的响应没有被提前中断（如 finish_reason 所示）时，模型的响应将可靠地产生与提供的模式匹配的有效 JSON。
  • 基于Python SDK的使用(DashScope/Qwen)原生支持结构化输出。提供工具或作为响应格式的模式就像提供Pydantic对象一样简单。SDK 会自动处理将数据类型转换为支持的 JSON 模式，将JSON 响应反序列化为类型化的数据结构，并在出现拒绝时进行解析

在这里插入图片描述

案例：结构化输出食谱

在这里插入图片描述

# 人工智能 # 语言模型 # 神经网络
Logo
人工智能6S服务平台

作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。

更多推荐

cover

原生鸿蒙像素画板实战 13：矩形选区编辑

avatar 人工智能6S服务平台
cover

鸿蒙三方库 | harmony-utils之ImageUtil Base64与PixelMap互转详解

avatar 人工智能6S服务平台
cover

原生鸿蒙像素画板实战 14：工具状态管理

avatar 人工智能6S服务平台