一文梳理清楚生成式 AI 与大模型的相关知识和概念
阅读对象：有一点“生成式 AI / 大模型 / AI 模型”概念的初学者，以及想理解 ChatGPT、Claude、GLM、OpenRouter、阿里云百炼、腾讯云 TokenHub、Ollama 本地模型、AI Agent、多模态和视频生成工具等服务区别的普通用户。
资料时间：截至 2026 年 6 月 25 日。生成式 AI 模型、芯片和云服务变化很快，具体模型规格、价格和可用地区应以官方页面为准。
0. 先给结论
这里说的“生成式 AI（Generative AI）与大模型（large model）”，主要指 ChatGPT、Claude、Gemini、GLM、Qwen、DeepSeek、Sora、Seedance、AI Agent 等这一代以基础模型（foundation model）为核心、能生成文字 / 图片 / 语音 / 视频 / 代码并调用工具的 AI 体系。它不同于更早的传统 AI 应用，比如单一分类、识别、推荐、搜索排序或规则系统。
日常使用的大多数生成式 AI / 大模型服务，本质上可以拆成三层；如果扩展到多模态（multimodal）和 AI Agent，还要分别关注“模型处理什么模态”和“谁负责把任务持续推进下去”：
第一层：模型从哪里来
也就是训练：谁训练了 GPT、Claude、GLM、Qwen、DeepSeek、Llama 等模型。
第二层：模型在哪里运行
也就是推理：你的问题发到哪里，由哪台机器、哪些芯片把答案算出来。
第三层：你通过什么产品或系统使用它
例如 ChatGPT、Claude、智谱开放平台、OpenRouter、阿里云百炼、腾讯云 TokenHub、Ollama、本地网页 UI、企业私有部署等。
多模态层：模型处理哪些输入和输出
例如文字、图片、语音、视频、音频、代码、PDF、屏幕截图等。
Agent 编排层（agent orchestration）：谁来规划步骤、调用工具、读写记忆、处理失败、等待人工确认
例如代码 Agent、客服 Agent、办公自动化 Agent、企业流程 Agent、研究助理 Agent 等。
所以，OpenAI、Claude、GLM、Qwen、DeepSeek 这些名字，很多时候指的是“模型或模型厂商”；而 OpenRouter、阿里云百炼、腾讯云 TokenHub、AWS Bedrock、Google Vertex AI 这类平台，更多时候是“模型服务平台 / 云端推理（cloud inference）入口 / 模型聚合与托管平台”；Ollama、llama.cpp、LM Studio 则更偏“本地推理运行器（local inference runtime）”。AI Agent 不是和这些并列的新模型，而是把模型、工具、数据、权限和执行流程组织起来的一种应用形态。
一句话概括：
训练（training）是把模型造出来；推理（inference）是把已经造好的模型拿来回答问题；多模态只是把文字扩展到图片、语音、视频等输入输出；Agent 是把一次次推理和工具调用（tool calling）组织成可持续推进的任务流程。
1. 一个普通问题背后发生了什么？
假设你在 ChatGPT、Claude、GLM 或一个接入 OpenRouter 的代码助手里输入：
帮我分析这段代码哪里可能有 bug。
背后大致发生的是：
用户输入
↓
客户端 / 网页 / App / 插件
↓
API 网关：鉴权、计费、限流、安全检查
↓
模型服务层：选择模型、调度 GPU/NPU、加载上下文
↓
推理引擎：把文字切成 token，运行模型前向计算（forward pass）
↓
逐 token 生成答案
↓
返回给用户
这个过程通常不会重新训练模型。它是在调用已经训练好的模型权重，做一次或多次推理。
如果这个服务接了网页搜索、数据库、代码执行器、文件检索、企业知识库，那么中间还会多出一层：
模型判断需要工具
↓
系统调用搜索 / 数据库 / 代码执行 / 文件检索
↓
把工具结果再交给模型
↓
模型综合结果生成回答
这也是为什么现在的生成式 AI 服务看起来不只是“聊天模型”，而更像“模型 + 工具 + 数据 + 权限 + 云端调度系统”的组合。
如果产品进一步做成 AI Agent，流程会变成循环，而不只是一次问答：
用户给出目标
↓
Agent 理解任务、拆解步骤、判断风险
↓
模型生成计划或下一步动作
↓
系统按权限调用工具：搜索、数据库、代码仓库、浏览器、邮件、工单、终端等
↓
Agent 观察工具结果，更新上下文或记忆
↓
继续下一轮推理和工具调用
↓
完成任务，或在高风险步骤前请求人工确认
因此，Agent 的关键不只是“模型更聪明”，而是系统能否稳定地管理 目标、状态（state）、工具、权限、记忆（memory）、错误恢复和人工介入（human-in-the-loop）。同一个模型，放在普通聊天框里、代码编辑器里、企业工单系统里，能完成的任务会很不一样。
2. 大模型从哪里来：训练阶段
2.1 训练的含义
训练就是把模型参数（parameters）学出来。
LLM 可以粗略理解为一个巨大函数。输入一串 token，它输出下一个 token 的概率。这个函数内部有大量参数。训练阶段就是让模型看海量数据，通过不断预测、比较误差、反向传播（backpropagation）、更新参数，让它逐步学会语言、代码、知识结构、推理模式和任务习惯。
可以类比：
训练 = 培养一个学生
推理 = 让这个学生回答问题或完成任务
训练阶段通常包括：
| 阶段 | 含义 | 结果 |
|---|---|---|
| 预训练（Pretraining） | 用海量通用文本、代码、多模态数据学习基础能力 | 得到基础模型 |
| 后训练（Post-training） | 用指令、对话、偏好、强化学习（reinforcement learning）等方式让模型更会听指令 | 得到可聊天、可执行任务的模型 |
| 微调（Fine-tuning） | 针对某类行业或任务继续训练 | 得到领域模型或企业模型 |
| 对齐（Alignment） | 让模型更符合人类偏好、安全规范和产品要求 | 得到更稳定的服务模型 |
| 蒸馏（Distillation） | 让小模型学习大模型输出 | 得到更便宜、更快的小模型 |
2.2 谁在训练模型？
主要有几类：
| 类型 | 例子 | 特点 |
|---|---|---|
| 闭源模型厂商 | OpenAI、Anthropic、Google DeepMind、xAI 等 | 模型能力强，权重通常不公开，通过 API 或产品提供服务 |
| 中国大模型厂商 | 智谱 / Z.ai、DeepSeek、月之暗面、MiniMax 等 | 有自研模型，也可能开放部分权重或 API |
| 云厂商自研模型 | 阿里 Qwen / 通义千问、腾讯混元、火山豆包等 | 既有模型能力，也有云基础设施和企业服务入口 |
| 开源 / 开放权重模型生态 | Meta Llama、Qwen 开源系列、Mistral、DeepSeek 开源模型等 | 用户可以下载权重，在本地或私有服务器部署 |
模型厂商真正的核心资产通常包括：
- 训练数据和数据清洗体系；
- 模型结构和训练方法；
- 大规模算力集群；
- 训练稳定性工程；
- 后训练和对齐方法；
- 模型评测（evaluation）体系；
- 推理优化和产品化能力。
2.3 LLM、多模态、语音和视频模型的关系
LLM 是“生成式 AI / 大模型服务”的一种，但不是全部。多模态模型、语音模型、图像生成模型、视频生成模型，本质上仍然离不开训练和推理 ，只是输入输出不再只限于文字。
| 类型 | 主要处理什么 | 常见产品形态 | 和 LLM 的关系 |
|---|---|---|---|
| LLM | 文本、代码、结构化文本 | ChatGPT、Claude、GLM、Qwen、Llama 等 | 语言大模型，是很多 AI 产品的核心底座 |
| VLM / 多模态理解模型 | 文本 + 图片 / 截图 / 视频片段 | 读图、分析 PDF、看图表、理解 UI 截图 | 通常把视觉信息编码后交给语言模型或统一模型处理 |
| 语音模型 | 语音识别、语音合成、实时语音对话 | ASR、TTS、Realtime voice、语音助手 | 可以是“语音识别 + LLM + 语音合成”，也可以是原生语音多模态模型 |
| 图像生成模型 | 文生图、图生图、图片编辑 | DALL-E、Stable Diffusion、Midjourney 等 | 不一定是 LLM，常和语言理解模块配合 |
| 视频生成模型 | 文生视频、图生视频、音视频生成 | Sora、Veo、Runway、Seedance 等 | 通常是视频生成基础模型，也会结合语言和多模态理解能力 |
统一来看：
训练 = 用文字、图片、语音、视频等数据学习跨模态规律
推理 = 用户输入文字 / 图片 / 语音 / 视频，模型生成当前结果
所以，多模态和视频生成不是训练、推理之外的新阶段，而是 把同一套“训练权重 + 在线推理”的服务框架扩展到更多模态。
3. 服务如何提供：推理阶段
3.1 推理的含义
推理就是使用已经训练好的模型来生成结果。
模型收到输入后，会先把文字拆成 token，然后根据已有参数计算下一个 token 的概率，再按照一定策略选出下一个 token。生成一个 token 后，把它接到上下文后面，再继续生成下一个 token。
输入 prompt
↓
切成 token
↓
模型计算下一个 token 的概率
↓
选择一个 token 输出
↓
加入上下文
↓
继续生成，直到结束
所以 LLM 的生成常常是“逐字 / 逐 token”流式输出，而不是一次性把全文吐出来。
3.2 推理的两个关键阶段：Prefill 和 Decode
推理内部常被分成两个阶段：
| 阶段 | 做什么 | 主要压力 |
|---|---|---|
| Prefill | 处理用户输入的整段上下文，建立注意力缓存 | 计算量大，适合并行 |
| Decode | 一个 token 一个 token 生成输出 | 更容易被显存带宽、KV cache 和延迟限制 |
这就是为什么“长输入”和“长输出”的成本结构不同：
- 输入很长时，prefill 成本高；
- 输出很长时，decode 时间长；
- 多轮对话很长时，KV cache 占用显存会变大；
- 多用户并发时，调度和缓存管理会变得很重要。
3.3 KV cache 为什么重要？
Transformer 模型在生成新 token 时，需要关注前文。为了避免每生成一个 token 都重新计算全部前文，推理系统会缓存前文的 Key/Value 张量，这就是 KV cache。
KV cache 的好处是让长对话更快；坏处是很吃显存。NVIDIA 的推理优化文章也把模型权重和 KV cache 视为 LLM 推理显存需求的两个主要来源。[1]
因此，长上下文、多人并发和 Agent 工作流都会把推理系统推向一个核心问题：
不是模型文件能不能放进去，而是权重、KV cache、并发请求和延迟要求能不能同时撑住。
3.4 推理服务软件在优化什么？
现代推理服务软件不只是“运行模型”，还要解决很多工程问题：
| 技术 | 目的 |
|---|---|
| 连续批处理（Continuous batching） | 不断把不同用户请求合批，提高 GPU 利用率 |
| 分页注意力 / 分页 KV cache（PagedAttention / Paged KV cache） | 像操作系统管理内存一样管理 KV cache，减少浪费 |
| 前缀缓存（Prefix cache） | 多个请求有相同前缀时复用缓存 |
| 推测解码（Speculative decoding） | 用小模型猜、大模型校验，提高生成速度 |
| 量化（Quantization） | 用更低精度存储和计算，减少显存和成本 |
| 张量 / 流水线 / 专家并行（Tensor / pipeline / expert parallelism） | 把大模型拆到多张卡或多台机器上运行 |
| prefill/decode 分离（Prefill-decode disaggregation） | 把处理输入和生成输出拆给不同资源池，提高吞吐 |
| 工具调用 / 结构化输出（Tool calling / structured output） | 让模型可靠调用工具或输出 JSON |
vLLM 文档将其定位为高吞吐推理服务系统，支持多种解码算法、分布式并行、流式输出、结构化输出、工具调用和 OpenAI 兼容 API。[2] SGLang 也强调生产级低延迟、高吞吐推理，并支持 RadixAttention、prefill-decode disaggregation、speculative decoding、continuous batching、paged attention 和多种量化格式。[3]
3.5 Agent 为什么会放大推理成本？
普通聊天常常是一轮输入、一轮输出。Agent 工作流通常会把一个任务拆成多次模型调用和多次工具调用：
分析目标 → 生成计划 → 调用工具 → 读取结果 → 修正计划 → 再调用工具 → 汇总交付
这会带来几类额外成本：
| 成本来源 | 为什么增加 |
|---|---|
| 多轮模型调用 | 一个任务可能需要多次推理，而不是一次回答 |
| 长上下文 | Agent 要保留目标、计划、工具结果、文 件片段、历史决策 |
| 工具等待时间 | 搜索、数据库、浏览器、代码执行、外部 API 都有额外延迟 |
| 失败重试 | 工具报错、权限不足、结果不一致时需要重新规划 |
| 结构化输出 | 为了可靠调用工具，模型常要输出 JSON、函数参数或计划格式 |
| 安全检查 | 高风险动作需要权限校验、审计日志或人工确认 |
所以，Agent 应用的成本不能只按“这次回答用了多少 token”来估算，还要看：
任务平均轮数 × 每轮上下文长度 × 工具调用延迟 × 失败重试率 × 人工确认点
这也是为什么 Agent 产品比普通聊天产品更依赖工程系统：需要任务状态机、工具注册表、权限控制、沙箱、日志、评测和回放能力。
3.6 多模态、语音和视频生成如何推理？
纯文本 LLM 的输入输出主要是 token。多模态服务会先把图片、音频、视频转成模型可处理的内部表示（representation），再和文字一起推理。
多模态理解服务大致是：
图片 / 截图 / PDF / 视频片段
↓
视觉编码器 / 多模态编码器
↓
图像特征、视觉 token 或语义向量
+ 用户文字问题
↓
多模态模型
↓
文字回答或结构化结果
语音对话常见有两条路线：
| 路线 | 链路 | 特点 |
|---|---|---|
| 拼接式语音对话 | 语音输入 → ASR → 文本 → LLM → 文本 → TTS → 语音输出 | 容易搭建，但语气、停顿、情绪和打断处理容易损失 |
| 原生语音多模态 | 音频输入 → 多模态模型 → 音频输出 | 延迟和自然度更好，但模型和服务系统更复杂 |
视频生成工具也仍然是推理，只是输出不再是文字 token，而是视频帧、运动、镜头、口型、声音或多轨道媒 体：
文字提示词 / 参考图片 / 音频 / 视频片段
↓
语言理解 + 图像/音频/视频条件编码
↓
视频生成模型
↓
生成视频、音频或口型同步结果
这类服务通常比文本推理更吃算力、显存、存储和排队调度。因为它不仅要理解提示词，还要生成高维度的图像帧、时间连续性、镜头运动和音画一致性。
4. 训练和推理对硬件的要求有什么不同？
训练和推理都需要大量矩阵计算，但它们的压力点不同。
4.1 训练更像“建造发动机”
训练要做：
前向传播
↓
计算 loss（损失）
↓
反向传播
↓
计算梯度
↓
更新参数
↓
保存 checkpoint（检查点）
↓
继续下一批数据
训练时显存里不只放模型权重（weights），还要放梯度（gradients）、优化器状态（optimizer state）、中间激活（activations ）、batch（批次）数据等。因此训练对硬件要求极高：
| 硬件需求 | 为什么重要 |
|---|---|
| 大量 GPU / TPU / NPU | 训练数据和模型参数太大，需要并行 |
| 高 HBM 显存容量 | 放模型、梯度、优化器状态、激活值 |
| 高 HBM 带宽 | 大规模矩阵计算要持续读写数据 |
| 高速互联 | 多卡 / 多机训练需要频繁同步参数和梯度 |
| 高速存储 | 数据集和 checkpoint 非常大 |
| 高可靠性 | 训练可能持续数周甚至数月，中断恢复很重要 |
| 高效软件栈 | PyTorch、JAX、FSDP、Megatron、DeepSpeed、XLA、ROCm、CUDA 等 |
4.2 推理更像“开着发动机接业务”
推理通常不更新参数，主要做前向计算。但服务化推理会面对另一类问题：
| 硬件 / 系统需求 | 为什么重要 |
|---|---|
| 足够显存 | 放模型权重和 KV cache |
| 高显存带宽 | decode 阶段经常被权重读取和 KV cache 访问限制 |
| 低延迟 | 用户希望尽快看到首 token |
| 高吞吐 | 同时服务大量用户 |
| 高效调度 | 请求长度不同、输出长度不同，需要动态合批 |
| 低精度计算支持 | FP8、FP4、INT8、INT4 等能降低成本 |
| 多卡互联 | 大模型或高并发推理需要跨卡通信 |
| 稳定 API 服务 | 鉴权、限流、计费、日志、监 控、故障切换 |
| 多模态吞吐 | 图片、音频、视频会增加编码、生成、存储和网络传输压力 |
推理常看的指标包括：
| 指标 | 含义 |
|---|---|
| TTFT | Time To First Token，首 token 延迟 |
| TPOT | Time Per Output Token，每个输出 token 的耗时 |
| TPS | Tokens Per Second，每秒 token 数 |
| Throughput | 吞吐量，单位时间服务多少请求或生成多少 token |
| Tail latency | 尾延迟，常看 P95 / P99，影响大规模服务体验 |
| Cost per token | 单 token 成本，常折算为每百万 token 成本 |
| GPU utilization | GPU 利用率，衡量 GPU 是否真正被吃满 |
5. 芯片级别：为什么 AI 芯片竞争这么激烈？
LLM 的核心计算是大规模矩阵乘法（matrix multiplication）和注意力计算（attention computation）。因此 AI 芯片竞争主要围绕几件事展开。
5.1 算力：Tensor Core / Matrix Core / TPU Core / NPU Core
普通 CPU 也能算矩阵，但效率不够。现代 AI 加速器会加入专 门的矩阵计算单元，例如 NVIDIA Tensor Core、AMD Matrix Core、Google TPU、华为 Ascend NPU 等。
训练通常更看重 BF16、FP16、FP8 的稳定高吞吐（throughput）；推理则越来越重视 FP8、FP4、INT8、INT4 等低精度格式，因为推理的目标是用更低成本生成足够好的结果。
5.2 显存容量：模型和 KV cache 能不能放下
显存容量决定了能运行多大的模型、多长上下文、多少并发。
例如，一个 70B 参数模型如果用 FP16/BF16 权重，光权重就可能需要约 140GB 显存；如果量化（quantization）到 4bit，权重体积会大幅下降，但质量、速度和兼容性要具体评估。
对推理来说，模型权重不是唯一问题。长上下文和多人并发会让 KV cache 快速增长，这也是为什么高端 AI 卡越来越强调 HBM 容量。
5.3 显存带宽：decode 经常卡在“读数据”
LLM decode 生成 token 时，经常需要反复读取模型权重和缓存。很多推理场景不是算力不够，而是显存带宽不够。
这也是 HBM3E、HBM4、HBM 带宽、封装和芯片互联成为竞争焦点的原因。
5.4 互联：大模型不是一 张卡就能解决
大模型训练和大规模推理都需要多卡协同。关键互联包括：
| 类型 | 例子 | 作用 |
|---|---|---|
| 卡间互联 | NVLink、Infinity Fabric、UB 等 | 多 GPU/NPU 之间高速传输 |
| 机间网络 | InfiniBand、RoCE、Spectrum-X、以太网增强方案 | 多服务器之间同步和通信 |
| 交换系统 | NVSwitch、光互联、CPO 等 | 扩大互联域，降低通信瓶颈 |
当模型进入 MoE、长上下文和 Agent 时代，互联的重要性进一步上升。因为 token 可能要在不同专家、不同 GPU、不同缓存节点之间移动。
5.5 功耗和散热：AI 工厂的硬约束
现在前沿 AI 计算已经不是“几张显卡”的问题，而是整机柜、整机房、甚至电力基础设施的问题。液冷、供电、机柜密度、网络布线、数据中心选址都会影响 AI 服务成本。
6. 截至 2026 年中的硬件竞争格局
6.1 NVIDIA：从单卡优势走向整柜级 AI 工厂
NVIDIA 仍是主流 AI 训练和推理硬件生态的中心。其优势不只是 GPU 本身，还包括 CUDA、cuDNN、NCCL、TensorRT-LLM、Triton、NVLink、NVSwitch、InfiniBand / Spectrum-X 网络，以及成熟的软件和开发者生态。
NVIDIA GB200 NVL72 是一个典型例子：官方介绍称，它把 36 个 Grace CPU 和 72 个 Blackwell GPU 连接成一个液冷整柜系统，形成 72-GPU NVLink 域，并面向万亿参数 LLM 的实时推理和训练加速；NVIDIA 还强调 Blackwell 的第二代 Transformer Engine、FP4 AI 和第五代 NVLink 对推理性能的提升。[4]
2026 年，NVIDIA 又宣布 Vera Rubin 平台，强调面向 Agentic AI 的整柜级平台、NVFP4 推理、机柜级可信计算和更强的可靠性设计。[5]
这反映出一个趋势：
前沿 AI 竞争已经从“哪张卡更快”，升级到“谁能把芯片、显存、网络、机柜、软件、调度和生态做成一个整体”。
6.2 AMD：以 Instinct + ROCm 追赶 AI 数据中心
AMD 的优势在于大显存 GPU、开放生态和 CPU/GPU 组合。AMD Instinct MI350 系列官方称相对上一代有最高 4 倍 AI 计算改进和最高 35 倍推理性能提升；MI355X 官方规格包括 288GB HBM3E、8TB/s 带宽和 1400W 典型板级 功耗。[6][7]
AMD 的挑战主要在软件生态。ROCm 在不断成熟，但在很多生产环境里，CUDA 生态仍然更成熟、更容易找到现成优化。对企业来说，硬件规格只是第一步，能否稳定跑 vLLM、TensorRT 类似能力、MoE 模型、长上下文推理和主流框架，才是最终选择依据。
6.3 Google TPU：从训练走向大规模推理
Google 长期使用自研 TPU 服务内部模型和 Google Cloud 客户。Google 在 2025 年发布 Ironwood，第七代 TPU，并称其是第一款专门为推理时代设计的 TPU，面向大规模 thinking / inferential AI 模型。[8]
Google Cloud 后续资料称 Ironwood 面向大规模训练、强化学习、高吞吐低延迟推理和模型服务，并将进入通用可用阶段。[9]
TPU 的特点是硬件和 Google 软件栈深度绑定，例如 XLA、JAX、TensorFlow、Google Cloud AI Hypercomputer 等。它的优势可能出现在 Google 自身和深度使用 Google Cloud 的企业场景中。
6.4 AWS Trainium：云厂商自研芯片路线
AWS Trainium 是云厂商自研 AI 芯片路线的代表。AWS 官方资料显示，Trainium3 每芯片配备 144GB HBM3e、4.9TB/s 带宽，并支持硬件加速 W4A8 量化；Trainium3 UltraServer 可扩展到 144 个 Trainium3 芯片，用于大模型训练和规模化推理。[10][11]
云厂商自研芯片的目的不是单纯“跑赢 NVIDIA”，而是降低云服务商自己的成本、改善供应链弹性，并把芯片、网络、虚拟化、计费和云产品绑定成整体。
6.5 华为 Ascend：国内算力替代和软硬件协同
在中国市场，华为 Ascend 是重要的国产 AI 算力路线。Reuters 2025 年报道称，华为准备批量出货 Ascend 910C，并称该芯片由两个 910B 处理器组合而成。[12] Reuters 2026 年关于智谱 / Z.ai 的报道也提到，GLM-5/GLM-5.2 等中国模型正在针对国产芯片基础设施进行优化。[13]
这类路线的关键不只是芯片，还包括 CANN、MindSpore、算子库、通信库、模型适配和工程稳定性。国内 AI 厂商如果能把模型结构、推理引擎和国产 NPU 特性深度配合，就可能在特定场景中获得不错的成本和供应链优势。
7. 我们平时用的生成式 AI 服务来源有什么不同？
7.1 模型厂商自营服务
代表：OpenAI、Anthropic Claude、Google Gemini、智谱 / Z.ai、DeepSeek、月之暗面、MiniMax 等。
这类服务的特点是：
| 维度 | 说明 |
|---|---|
| 模型控制权 | 通常最高，模型由自己训练或深度控制 |
| 能力更新 | 新模型、新上下文、新工具能力通常最先出现在自家平台 |
| 推理优化 | 能针对自家模型做深度优化 |
| 产品体验 | ChatGPT、Claude、GLM Chat、Gemini 等体验完整 |
| 缺点 | 可能价格较高、接口风格不同、数据和合规要看厂商政策 |
例如 OpenAI 官方模型文档列出 GPT-5.5 作为前沿模型，提供 1,050,000 token context window 和 128,000 max output tokens 等规格。[14] Anthropic 也在 Claude API 文档中维护 Claude 模型家族和版本说明。[15]
对于用户来说，模型厂商自营服务通常意味着：
能力强、更新快、省心，但更依赖单一厂商。
7.2 第三方模型路由 / 聚合平台
代表：OpenRouter、LiteLLM 网关、一些企业内部模型网关。
OpenRouter 官方文档称 ，它通过一个统一 API 访问数百个 AI 模型，并可以自动处理 fallback 和选择更具成本效益的选项。[16] 它也说明不同上游提供商有不同日志和数据保留策略，用户可以配置是否允许路由到可能训练数据的提供商，以及使用 Zero Data Retention 约束。[17][18]
这类平台的价值是：
| 优点 | 说明 |
|---|---|
| 一个 API 接多个模型 | 不用分别接 OpenAI、Anthropic、Google、Meta、DeepSeek 等 |
| 方便比较价格和能力 | 同一应用可以切换模型 |
| 回退 / 故障切换（fallback） | 某个供应商限流或故障时可以换路由 |
| 成本控制 | 可以按价格、速度、上下文选择模型 |
| 多模型路由 | 根据任务选择更合适的模型 |
但它也多了一层中间环节：
| 风险 / 代价 | 说明 |
|---|---|
| 隐私链路更复杂 | 数据经过聚合平台，再到上游模型提供商 |
| 行为差异 | 同一个模型经不同 provider 可能限流、参数、上下文支持不同 |
| 故障归因复杂 | 出错时要判断是应用、OpenRouter、上游 provider 还是模型问题 |
| 高级特性未必完整 | 某些原厂工具能力、状态化 API、多模态细节可能不完全一致 |
适合场景：开发者试模型、AI 编程工具、希望多供应商回退的应用、对成本敏感但能接受中间层的团队。
7.3 云厂商模型平台 / MaaS
代表：阿里云百炼 / Model Studio、腾讯云 TokenHub、火山方舟、AWS Bedrock、Google Vertex AI、Azure AI Foundry 等。
这类平台的核心不是“只训练模型”，而是把模型部署、API、权限、计费、日志、企业网络和云上工具整合起来。
阿里云 Model Studio 官方文档说明其提供 Qwen 和第三方模型，覆盖文本、图像、音频和视频等类型。[19] 腾讯云 TokenHub 文档说明其大型模型服务平台支持 API 调用，服务条款中也提到 AI 模型访问按 token 消耗计量和收费。[20][21]
云厂商平台的强项：
| 强项 | 说明 |
|---|---|
| 云资源 | GPU/NPU、存储、网络、负载均衡、弹性伸缩 |
| 企业账号体系 | IAM/RAM、组织、权限、审计 |
| 数据集成 | 云数据库、对象存储、日志、向量库、搜索、数据湖 |
| 合规和地域 | VPC、私网访问、地域部署、行业合规 |
| 模型市场 | 自家模型 + 第三方模型 + 开源模型 |
| 私有化能力 | 专属实例、专有云、混合云部署 |
和模型厂商自营服务相比，云厂商的不同在于：
模型厂商强在模型本体和训练能力；
云厂商强在基础设施、企业集成和规模化运维。
如果云厂商托管的是第三方模型，比如 GLM、DeepSeek、Llama、Mistral，它主要提供的是“在自己云设施上的推理服务”。如果云厂商也有自研模型，比如阿里 Qwen、腾讯混元，那么它同时是模型厂商和云服务商。
7.4 本地自建服务：Ollama、llama.cpp、LM Studio
Ollama、llama.cpp、LM Studio 这类工具让用户把模型权重下载到本地电脑或服务器上运行。
Ollama 官方文档显示，它提供本地 API，并支持 OpenAI Responses API 的非状态化兼容能力；Ollama 隐私页面也明确说本地运行时 Ollama 看不到你的 prompts 或数据。[22][23]
本地推理大致是：
你的应用 / 命令行 / 本地网页 UI
↓
Ollama / llama.cpp / LM Studio
↓
本地模型文件
↓
你的 CPU / GPU / Apple Silicon / NPU
↓
本机生成结果
优点：
| 优点 | 说明 |
|---|---|
| 隐私更可控 | 不主动上传 prompt 和文档 |
| 可离线 | 下载模型后弱网或断网也能用 |
| 无按 token 计费 | 边际成本主要是电费和硬件折旧 |
| 可折腾 | 可换模型、量化、系统提示词、本地 RAG（Retrieval-Augmented Generation，检索增强生成） |
| 适合私有资料 | 笔记、代码、企业内部文档、个人文件 |
缺点：
| 缺点 | 说明 |
|---|---|
| 能力受限 | 本地能跑的模型通常小于云端前沿模型 |
| 速度受硬件影响 | 没有好显卡或统一内存，体验会明显下降 |
| 长上下文困难 | KV cache 会吃大量内存 / 显存 |
| 工具生态要自己搭 | 搜索、RAG、Agent、权限、日志都要自己配置 |
| 安全仍要管理 | 本地服务暴露公网、恶意模型文件、插件上传数据都可能有风险 |
GGUF 是本地推理常见模型格式之一。Hugging Face 文档说明 GGUF 针对快速加载和保存进行了优化，用于 GGML 及相关执行器，并由 llama.cpp 作者开发。[24]
7.5 AI Agent 平台和代码助手
AI Agent 平台不是单纯卖“一个模型”，而是把模型调用变成可执行任务的系统。它通常包含：
| 组成 | 作用 |
|---|---|
| 模型接口 | 负责理解目标、生成计划、判断下一步动作 |
| 工具注册表 | 告诉模型可以调用哪些工具，以及每个工具需要什么参数 |
| 状态和记忆 | 保存任务进度、用户偏好、历史结果、长期知识 |
| 权限系统 | 限制 Agent 能读什么、写什么、调用什么、是否能联网 |
| 执行环境 | 浏览器、代码沙箱、终端、数据库连接、企业 API、办公系统等 |
| 审计和回放 | 记录 Agent 做过什么，便于排错、合规和评测 |
| 人工确认 | 对发邮件、删文件、付款、改生产数据等动作设置确认点 |
代码 Agent 是最容易理解的例子。它不只是回答“这段代码怎么写”，而是可能读取仓库、搜索引用、修改文件、运行测试、分析报错、继续修复，再把结果交给人确认。企业流程 Agent 也是类似逻辑：它可能读取工单、查数据库、调用内部系统、生成处理建议，必要时再交给人工审批。
这类系统对模型能力有要求，但更依赖工程边界：
模型能力决定上限；
工具和数据决定能做什么；
权限和审计决定能不能上线；
评测和回放决定能不能持续改进。
如果没有清晰的工具边界和权限设计，Agent 很容易从“自动化助手”变成“不可控脚本”。如果没有评测和日志，也很难判断它到底是在稳定完成任务，还是偶尔碰巧成功。
7.6 多模态和生成媒体工具
多模态和生成媒体工具更像是“模型能力 + 产品工作流”的组合。用户看到的是读图、语音对话、文生图、图生视频、视频剪辑、数字人、配音、口型同步；底层仍然是模型训练和在线推理。
常见形态可以这样看：
| 工具类型 | 用户看到的能力 | 底层更接近什么 |
|---|---|---|
| 读图 / 读 PDF / 看截图 | 上传图片或文件，让模型解释、提取、比较 | 视觉编码 + LLM / 多模态模型 |
| 实时语音对话 | 直接说话，AI 用语音回答 | ASR + LLM + TTS，或原生语音多模态模型 |
| 文生图 / 图像编辑 | 根据提示词生成或修改图片 | 图像生成模型 + 文本理解 |
| 文生视频 / 图生视频 | 生成短视频、镜头运动、人物动作 | 视频生成模型 + 文本/图像条件控制 |
| 数字人 / 口型同步 | 让头像说话、配音、表情同步 | 音频、视频、人脸和动作生成模型组合 |
因此，选择这类产品时除了看“模型名”，还要看分辨率、时长、延迟、队列、版权政策、商用许可、水印、隐私、素材上传限制和失败重试成本。
8. 为什么同一个模型，在不同平台体验不同？
你可能会遇到这种情况：同样叫“Claude”“GLM”“DeepSeek”或“Qwen”，在不同平台上速度、价格、上下文、输出风格甚至是否支持工具调用都不一样。
原因通常包括：
- 版本不同：同名模型可能有不同日期版本、快慢版本、推理版、思考版。
- 量化不同：本地模型可能是 4bit / 5bit / 8bit 量化，云端可能使用 FP8 / FP4 / INT8 或自研格式。
- 推理引擎不同：vLLM、TensorRT-LLM、SGLang、TGI、Ollama、llama.cpp 的性能和功能不同。
- 上下文限制不同：平台可能限制最大输入、输出或消息数量。
- 系统提示词不同：平台可能加入自己的安全、风格和工具提示词。
- 工具能力不同：原厂可能支持网页搜索、文件搜索、计算机使用；第三方网关未必完整支持。
- 硬件不同：同一模型跑在 H100、B200、MI355X、TPU、Ascend 或普通 PC 上体验会不同。
- 并发和限流不同：高峰期速度和稳定性会受平台资源影响。
- Agent 编排不同：不同平台的工具协议、记忆策略、计划循环、沙箱权限和人工确认机制不同。
- 多模态实现不同：读图、语 音、视频生成可能使用不同模型链路，延迟、质量、成本和可控性差异很大。
所以，选择生成式 AI 服务时不能只看模型名字，还要看：
模型版本 + provider + 推理平台 + 上下文限制 + 多模态能力 + 工具能力 + Agent 编排 + 价格 + 数据政策
9. 常见误区
误区 1：我用 ChatGPT，就是在训练 ChatGPT
多数日常使用不是训练，而是推理。你输入的问题通常是作为一次请求被模型处理，不会立刻改变模型参数。
不过，服务商是否把用户数据用于未来模型改进，要看具体产品和隐私设置。OpenAI 官方说明，API 和商业产品默认不使用业务数据训练模型，除非用户明确选择加入数据共享。[25][26]
误区 2：本地模型一定安全
本地模型的隐私上限更高，但不是自动安全。
需要注意：
- 是否安装了会联网的插件；
- Ollama 或本地服务是否暴露到局域网 / 公网；
- 模型文件来源是否可靠；
- 本地日志、历史记录、缓存是否保存敏感内容；
- 本地电脑本身是否安全。
误区 3：开源模型一定弱
不准确。开源和开放权重模型在代码、数学、中文、长上下文、Agent 等方向进步很快。智谱 / Z.ai 的 GLM-5 和 GLM-5.2、DeepSeek、Qwen 等模型都推动了开源或开放模型竞争。Reuters 2026 年报道提到 GLM-5.2 在编码和 Agent 任务上接近顶级闭源模型，并具有 1M token 上下文窗口；但这类第三方报道和厂商 benchmark 仍应结合实际任务测试来看。[13]
更准确的说法是：
开源模型的控制权和可部署性更强；
顶级闭源模型通常仍在综合能力、工具生态和产品体验上领先。
误区 4：云厂商提供模型服务，就一定自己训练了模型
不一定。
云厂商可能有自研模型，也可能只是托管第三方模型，还可能二者都有。例如阿里云既有 Qwen / 通义千问，也在 Model Studio 中提供第三方模型。[19]
误区 5：只要显卡显存够，就能获得好体验
显存够只是第一步。还要看：
- 推理引擎是否优化；
- 模型是否适配该硬件；
- 是否支持高效 attention kernel；
- 是否支持量化和 KV cache 管理；
- CPU、内存、磁盘和系统调度是否拖后腿；
- 多卡互联是否足够快。
误区 6：AI Agent 就是更强的聊天机器人
不准确。
Agent 的核心是“围绕目标持续行动”。它通常需要计划、工具、状态、权限、记忆、错误 处理和人工确认。强模型能提高 Agent 的理解和规划能力，但不能自动解决工具权限、数据边界、执行风险和结果验证问题。
更准确的说法是：
聊天机器人主要生成回答；
Agent 试图推进任务；
生产级 Agent 是模型能力 + 工具系统 + 权限治理 + 评测闭环。
误区 7：多模态、语音和视频生成不属于训练/推理框架
不准确。
它们仍然是先训练模型，再在用户使用时推理。区别在于输入输出从文字扩展到了图片、语音、视频等模态，服务链路也可能多出编码器、解码器、扩散模型、语音合成、视频生成、内容审核和素材存储等环节。
更准确的说法是：
文本服务：主要生成文字 token；
多模态理解：把图片/音频/视频变成模型可处理的表示，再推理；
生成媒体：根据条件生成图片、音频或视频内容。
10. 如何选择日常生成式 AI 服务？
10.1 普通用户
| 需求 | 建议 |
|---|---|
| 日常问答、写作、翻译、复杂分析 | 用 OpenAI、Claude、Gemini、GLM 等成熟云端产品 |
| 代码助手、复杂项目分析 | 优先选强模型云端服务，再考虑本地辅助 |
| 读图、读 PDF、语音聊天 | 选多模态和语音体验成熟的官方产品或平台 |
| 文生图、图生视频、短视频生成 | 重点看质量、速度、素材政策、商用许可和价格 |
| 私密文件、个人笔记、离线使用 | Ollama / LM Studio / 本地 RAG 更合适 |
| 想尝试很多模型 | OpenRouter 或类似聚合平台方便 |
| 自动整理资料、处理重复任务 | 选择有工具调 用、文件读写和确认机制的 Agent 产品 |
| 不想折腾 | 直接用官方 Chat 产品 |
10.2 开发者
| 需求 | 建议 |
|---|---|
| 快速接强模型 | 直接接 OpenAI / Anthropic / Gemini / 智谱 / DeepSeek 等 API |
| 多模型 fallback | OpenRouter / LiteLLM / 自建网关 |
| 控制成本 | 小模型 + 路由 + 缓存 + 批处理 + 本地推理组合 |
| 私有知识库 | RAG：向量数据库（vector database）+ 向量嵌入（embedding）+ 重排序（rerank）+ LLM |
| 多模态应用 | 明确输入输出模态、文件大小、延迟、存储和审核要求 |
| Agent 应用 | 先定义工具、权限、状态和评测，再选择模型 |
| 本地开发测试 | Ollama / llama.cpp / vLLM 单机部署 |
| 生产高并发 | vLLM / SGLang / TensorRT-LLM + GPU 云或私有集群 |
10.3 企业
| 需求 | 建议 |
|---|---|
| 快速上线 | 云厂商 MaaS 或模型厂商企业版 |
| 数据合规 | 企业版 API、ZDR（Zero Data Retention）、私有网络、专属实例或私有化部署 |
| 成本优化 | 多模型路由、缓存、评测、分层模型策略 |
| 关键业务 | 不只看模型能力，还要看 SLA（Service Level Agreement，服务等级承诺）、审计、权限、可观测性和灾备 |
| 内部敏感数据 | 本地 / 私有云 / VPC 部署，配合权限和日志治理 |
| 多模态内容生产 | 关注素材版权、商用授权、内容审核、资产管理和生成成本 |
| 业务流程 Agent | 从低风险只读场景开始，逐步加入写操作、审批和回滚机制 |
11. 一个比较稳妥的混合架构
很多实际系统不会只选一种方式，而会混合使用：
普通问答 / 复杂推理 / 多模态
→ 云端强模型
图片、语音、视频生成
→ 专门的多模态 / 生成媒体模型和素材处理管线
私密文档初筛 / 本地笔记 / 内部代码库检索
→ 本地模型或私有部署
模型选择、成本控制、故障切换
→ OpenRouter / LiteLLM / 企业模型网关
企业数据、权限、审计、向量库、对象存储
→ 阿里云、腾讯云、AWS、Azure、Google Cloud 等云平台
高并发推理
→ vLLM / SGLang / TensorRT-LLM + GPU/NPU 集群
Agent 任务编排
→ 工具注册表 + 权限系统 + 状态存储 + 沙箱 + 人工确认 + 审计日志
这类架构的核心思想是：
不要用最贵、最强的模型处理所有问题；也不要为了隐私把所有任务都硬塞到本地小模型。应该按任务风险、难度、成本和延迟选择合适的模型与部署方式。
如果要加入 Agent，还要多问 一个问题：
这件事是否适合自动执行？如果执行错了，是否能发现、阻止、回滚或让人接管？
12. 简明术语表
| 术语 | 原始写法 / 全称 | 简单解释 |
|---|---|---|
| 生成式 AI | Generative AI | 能生成文字、图片、语音、视频、代码等内容的 AI 体系 |
| 大模型 | Large model | 参数规模大、能力泛化强，通常可作为多类任务底座的模型 |
| 基础模型 | Foundation model | 用大规模数据训练出来，可适配多种下游任务的模型 |
| LLM | Large Language Model | 大语言模型，主要处理文本、代码和结构化文本 |
| Token | Token | 模型处理文本的基本单位，可能是字、词或词片段 |
| 参数 | Parameters | 模型内部学到的数值，决定模型行为 |
| 权重 | Weights | 参数文件，开放权重模型通常会发布它 |
| 训练 | Training | 更新模型参数，让模型学会能力 |
| 推理 | Inference | 使用已有参数生成答案或结果 |
| 预训练 | Pretraining | 用海量数据学习基础能力 |
| 后训练 | Post-training | 让模型更会听指令、更安全、更适合产品使用 |
| 微调 | Fine-tuning | 用特定数据继续训练，适配某个场景 |
| 对齐 | Alignment | 让模型更符合人类偏好、安全规范和产品要求 |
| 蒸馏 | Distillation | 让小模型学习 大模型能力，降低成本和延迟 |
| RAG | Retrieval-Augmented Generation | 先查资料，再让模型结合检索结果回答 |
| 向量数据库 | Vector database | 用向量相似度检索文本、图片等内容的数据库 |
| 重排序 | Rerank / reranking | 对检索结果再次排序，提高返回结果相关性 |
| 多模态模型 | Multimodal model | 能处理文字以外的图片、语音、视频等输入或输出的模型 |
| VLM | Vision-Language Model | 视觉语言模型，常用于读图和图文理解 |
| ASR | Automatic Speech Recognition | 把语音转成文字 |
| TTS | Text To Speech | 把文字转成语音 |
| 视频生成模型 | Video generation model | 根据文字、图片、音频或视频条件生成视频内容的模型 |
| AI Agent | AI Agent | 围绕目标持续规划、调用工具、更新状态并推进任务的 AI 应用形态 |
| 工具调用 | Tool calling | 模型按结构化参数请求系统调用外部工具 |
| 工具注册表 | Tool registry | 记录 Agent 可用工具、参数、权限和说明的配置 |
| 状态 / 记忆 | State / Memory | Agent 为完成任务保存的短期进度、长期偏好或历史信息 |
| 沙箱 | Sandbox | 限制代码、浏览器或文件操作的隔离环境 |
| 人工介入 | Human-in-the-loop | 人在关键步骤中确认、审批或接管 |
| 向量嵌入 | Embedding | 把文本变成向量，用于相似度检索 |
| KV cache | Key-Value cache | 缓存前文注意力结果，加速生成，但占显存 |
| Prefill | Prefill | 处理输入上下文阶段 |
| Decode | Decode | 逐 token 生成输出阶段 |
| 量化 | Quantization | 用更低精度表示模型，降低显存和成本 |
| FP16 / BF16 | Float16 / Brain Floating Point 16 | 常见训练和推理精度 |
| FP8 / FP4 | Float8 / Float4 | 新一代低精度 AI 计算格式，常用于降低训练/推理成本 |
| INT8 / INT4 | 8-bit integer / 4-bit integer | 整数量化格式，常见于推理部署 |
| HBM | High Bandwidth Memory | 高带宽显存，AI 芯片关键资源 |
| TTFT | Time To First Token | 首 token 延迟 |
| TPOT | Time Per Output Token | 每个输出 token 的耗时 |
| TPS | Tokens Per Second | 每秒生成 token 数 |
| 吞吐量 | Throughput | 单位时间内能处理的请求数或生成的 token 数 |
| 尾延迟 | Tail latency | 高百分位延迟，常看 P95 / P99 |
| 单 token 成本 | Cost per token | 生成或处理每个 token 的平均成本 |
| GPU 利用率 | GPU utilization | 衡量 GPU 是否真正被充分使用 |
| SLA | Service Level Agreement | 服务商对可用性、延迟、支持等指标的承诺 |
| ZDR | Zero Data Retention | 上游服务不保留请求数据的隐私约束 |
| vLLM | vLLM | 高吞吐 LLM 推理服务框架 |
| TensorRT-LLM | TensorRT-LLM | NVIDIA 推理优化框架 |
| SGLang | SGLang | 高性能 LLM serving 框架 |
| Ollama | Ollama | 本地运行开放模型的工具和本地 API 服务 |
| OpenRouter | OpenRouter | 多模型聚合和路由 API 平台 |
| MaaS | Model as a Service | 以 API 或平台形式提供模型能力的服务形态 |
13. 最后总结
理解日常生成式 AI / 大模型服务，最重要的是把三件事分开：
模型是谁训练的？
模型在哪里推理？
用户通过什么服务入口调用？
如果是多模态，它处理哪些输入输出？
如果是 Agent，谁负责工具、状态、权限和人工确认？
OpenAI、Claude、GLM、DeepSeek、Qwen 等代表模型和模型厂商；阿里云百炼、腾讯云 TokenHub、AWS Bedrock、OpenRouter 等代表不同形态的模型服务入口；Ollama、llama.cpp、LM Studio 则让普通用户能在本地运行开放模型。
AI Agent 则是在这些能力之上增加任务编排：它把一次次模型推理、工具调用、状态更新和人工确认串起来，让 AI 从“回答问题”进一步走向“协助完成任务”。
多模态、语音对话和视频生成工具也可以放进同一套框架里理解：它们不是训练和推理之外的新阶段，而是把模型的输入输出从文字扩展到图片、语音、视频和音频 。Seedance、Sora、Veo、Runway 这类视频生成产品，用户看到的是生成视频，底层仍然是模型权重、条件输入、推理调度和媒体生成管线。
训练和推理都依赖先进芯片，但要求不同。训练更看重大规模集群、显存容量、互联、稳定性和训练软件栈；推理更看重显存带宽、KV cache、低延迟、高并发、低精度计算、调度系统和服务成本。
截至 2026 年中，AI 硬件竞争已经进入“整柜级 AI 工厂”阶段。NVIDIA 仍凭 Blackwell、Rubin、NVLink 和 CUDA 生态占据强势位置；AMD 以 Instinct 和 ROCm 追赶；Google TPU、AWS Trainium、华为 Ascend 等自研芯片路线则体现了云厂商和国家级算力体系对成本、供应链和生态控制的追求。
对普通用户和开发者来说，最实用的判断不是“本地还是云端”“开源还是闭源”，而是：
这项任务需要多强能力？数据有多敏感？可接受多少成本？是否需要联网工具？是否要求稳定高并发？
如果是 Agent 场景，还要继续问：
它能调用哪些工具？能操作哪些数据？失败后谁负责确认和回滚？日志是否足够追溯？
如果是多模态或生成媒体场景，还要继续问：
输入输出是什么模态？生成质量和延迟是否能接受？素材版权和隐私怎么处理？失败重试和商用成本怎么算？
按这些问题来选模型和服务，才是真正可落地的 AI 使用方式。
参考资料
[1] NVIDIA Developer Blog, Mastering LLM Techniques: Inference Optimization, https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/
[2] vLLM Documentation, https://docs.vllm.ai/
[3] SGLang Documentation / GitHub, https://docs.sglang.ai/ and https://github.com/sgl-project/sglang
[4] NVIDIA GB200 NVL72, https://www.nvidia.com/en-sg/data-center/gb200-nvl72/
[5] NVIDIA Vera Rubin Platform, https://www.nvidia.com/en-sg/data-center/technologies/rubin/
[6] AMD Instinct MI350 Series and Beyond, https://www.amd.com/en/blogs/2025/amd-instinct-mi350-series-and-beyond-accelerating-the-future-of-ai-and-hpc.html
[7] AMD Instinct MI355X GPU specifications, https://www.amd.com/en/products/accelerators/instinct/mi350/mi355x.html
[8] Google Blog, Ironwood: The first Google TPU for the age of inference, https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/ironwood-tpu-age-of-inference/
[9] Google Cloud Blog, Ironwood TPUs and new Axion-based VMs for your AI workloads, https://cloud.google.com/blog/products/compute/ironwood-tpus-and-new-axion-based-vms-for-your-ai-workloads
[10] AWS Trainium, https://aws.amazon.com/ai/machine-learning/trainium/
[11] Amazon News, Trainium3 UltraServer delivers faster AI training at lower cost, https://www.aboutamazon.com/news/aws/trainium-3-ultraserver-faster-ai-training-lower-cost
[12] Reuters, Huawei readies new AI chip for mass shipment as China seeks Nvidia alternatives, https://www.reuters.com/world/china/huawei-readies-new-ai-chip-mass-shipment-china-seeks-nvidia-alternatives-sources-2025-04-21/
[13] Reuters, After Anthropic shutdown, China's Z.ai closes frontier gap as it plans dual listing, https://www.reuters.com/world/asia-pacific/after-anthropic-shutdown-chinas-zai-closes-frontier-gap-it-plans-dual-listing-2026-06-25/
[14] OpenAI API Docs, GPT-5.5 model, https://developers.openai.com/api/docs/models/gpt-5.5
[15] Anthropic Claude API Docs, Models overview, https://platform.claude.com/docs/en/about-claude/models/overview
[16] OpenRouter Quickstart, https://openrouter.ai/docs/quickstart
[17] OpenRouter Provider Logging, https://openrouter.ai/docs/guides/privacy/provider-logging
[18] OpenRouter Zero Data Retention, https://openrouter.ai/docs/guides/features/zdr
[19] Alibaba Cloud Model Studio recommended models, https://www.alibabacloud.com/help/en/model-studio/models
[20] Tencent Cloud TokenHub Quick Start, https://www.tencentcloud.com/document/product/1300/78939
[21] Tencent Cloud LLM Service TokenHub Terms of Service, https://intl.cloud.tencent.com/document/product/301/78869
[22] Ollama OpenAI compatibility, https://docs.ollama.com/api/openai-compatibility
[23] Ollama Privacy, https://ollama.com/privacy
[24] Hugging Face GGUF documentation, https://huggingface.co/docs/hub/en/gguf
[25] OpenAI Enterprise Privacy, https://openai.com/enterprise-privacy/
[26] OpenAI, How your data is used to improve model performance, https://openai.com/policies/how-your-data-is-used-to-improve-model-performance/