大模型部署与 AI 应用交付

先建立全局图景

大模型项目交付四个层次：训练教模型「会」，部署让模型「能跑」，API 让模型「能被用」，应用集成让用户「真的用上」。

第 1 层

模型训练 / 微调

用数据优化模型参数，产出「权重文件」。微调是在已有基础模型上继续训练，让模型适应特定领域（如通用大模型 → 出版行业大模型）。

第 2 层

模型部署

让训练好的模型在服务器上运行并提供调用能力：环境准备、模型加载、推理服务启动、API 提供。

第 3 层

API 接口

模型只负责计算答案，API 是让其他系统按约定调用模型能力的入口，解耦模型与业务。

第 4 层

AI 应用开发 / 集成

前端页面、后端接口、知识库、工作流、权限、数据处理——让用户真正通过业务系统使用模型能力。

模型运行的整体架构（自下而上）

8用户通过业务系统发起提问，是交互起点提问 / 指令

7业务系统前端 + 后端，调度中心，处理权限与流程Web / 小程序

6API 接口约定好的调用方式，解耦模型与业务HTTP 接口

5模型服务推理框架对外提供的服务（加载模型、调度）vLLM / SGLang

4推理框架加载模型、调用 GPU、执行计算框架层

3模型文件权重 + 配置 + Tokenizersafetensors

2GPU 服务器提供并行算力的硬件底座GPU / 昇腾

1操作系统管理硬件、文件、网络、进程Linux

建议学习顺序（结合你的岗位，分三阶段）

第一阶段 · 马上学

接口与部署基础

API / SDK / 接口、前后端通信、SIT / UAT / 回归测试、虚拟机 / Docker / 部署。

第二阶段

AI 与检索核心

RAG 完整链路、Elasticsearch / 向量数据库、大模型推理部署、GPU / 显存 / 并发。

第三阶段

安全与工程化

等保 / 安全、性能测试、DevOps、CI/CD。

核心概念：大模型项目交付什么

四个关键词贯穿始终。先看下面这条 AI 调用链路，点击任一节点查看说明。

点击任一节点查看说明

选择一层

AI 调用链路

点击左侧链路中的节点，这里会展示它的角色与作用。

建议沿「用户 → 前端 → 后端 → API → 推理框架 → 模型 → GPU」自上而下理解。

模型训练

数据 → 参数 → 模型

用大量数据让模型学习，训练产出「模型权重」。例如用出版行业数据训练 BookGPT。

本质教模型学习

产出模型权重文件

模型微调

Fine-tuning

在已有基础模型上继续训练，让模型适应特定领域，成本远低于从头训练。

路径通用大模型 → 行业大模型

模型部署

让模型能跑起来

让训练好的模型在服务器上运行并提供调用能力。

包含环境准备 / 模型加载 / 推理服务 / API

AI 应用开发

让用户真的用上

让用户通过业务系统使用模型能力。

包含前端 / 后端 / 知识库 / 工作流 / 权限 / 数据处理

模型怎么「读懂」和「控制」文字

Token

模型的最小文本单元

输入输出都以 Token 计，中文约 1~1.5 字 ≈ 1 Token。

作用文本与数字之间的换算单位

上下文窗口

Context Window

模型一次能处理的最大 Token 数，超出会被截断或遗忘。

影响长文档、多轮对话能否完整记忆

推理超参数

控制生成的「性格」

温度（Temperature）控制随机性，top-p / top-k 控制采样范围。

温度低 = 稳定，高 = 有创造性

Prompt 工程、多模态与工具调用

Prompt

给模型的指令

通过提示词 + 示例引导模型输出，是应用层「调教」模型的主要手段。

多模态

不止文字

支持图像、音频、视频的输入与输出，如 MiniMax 多模态视觉。

Function Calling

模型调用外部工具

模型按约定输出结构化指令，由系统执行工具/API，如待办看板的意图识别。

从模型到上线的完整路线图

1

模型训练完成

产出权重、配置、Tokenizer 等模型文件。

2

服务器准备

CPU / GPU / 显存 / 存储 / 网络到位。

3

GPU 环境配置

驱动 + CUDA（或 CANN）软件栈。

4

推理框架部署

vLLM / SGLang 加载模型、启动服务。

5

模型加载运行

显存装下模型，推理服务可响应。

6

API 服务开放

对外提供标准调用接口。

7

业务系统调用

前端 ↔ 后端 ↔ 模型 API 联调。

8

知识库 / RAG 接入

私有内容检索增强。

9

功能测试 → 性能测试

验证能调用、扛并发。

10

上线运行

进入 7×24 稳定运行与运维。

硬件与算力：模型能不能「算得动」

从 CPU / GPU 的分工，到模型大小与显存，再到多 GPU 的两种用法。

CPU

通用计算

负责通用计算、业务系统运行、数据库运行。

角色系统的「大脑」，调度一切

GPU

AI 加速

加速模型计算，擅长大规模并行。

常见型号H20 / A100 / A800 / RTX 5090 / 昇腾 910B

为什么大模型需要 GPU？

大模型本质是大量矩阵计算。GPU 擅长并行计算，能同时处理海量矩阵运算，因此成为训练与推理的核心算力。

CPU

串行强

擅长复杂逻辑与通用任务，但并行算力有限。

GPU

并行强

成千上万核心并行，正好匹配矩阵运算。

结论

各司其职

业务跑 CPU，模型计算跑 GPU。

模型大小与显存

参数规模以 B（Billion，十亿）计：7B、13B、32B、70B。它直接影响需要多少显存、是否要多卡、推理速度。

规模	含义	对部署的影响
7B	70 亿参数	较轻量，单卡可跑，适合起步
13B	130 亿参数	中等，需关注显存
32B	320 亿参数	较大，可能超出单卡显存
70B	700 亿参数	通常需多卡（模型并行）

为什么需要多张 GPU？两个原因

原因一

模型太大，一张卡放不下

如 32B 模型超过单卡显存容量，需要多卡共同加载一个模型（模型并行）。

原因二

提高并发能力

一张卡跑一个模型，多张卡各跑一个完整模型，把多个用户请求分发出去。

方式一

模型并行

一个模型拆开：GPU1 负责部分计算，GPU2 负责另一部分，再合并生成结果。

目的放下更大的模型、提升单次推理能力

方式二

模型副本

多个完整模型 + 负载均衡，请求分发到 GPU1/GPU2/GPU3。

目的提高并发量，服务更多用户

多 GPU 是否一定更快？

不能简单认为「8 张 GPU = 1 张的 8 倍速度」。实际加速取决于：

模型大小

模型是否真的需要拆到多卡。

并行方式

模型并行与副本的收益不同。

GPU 通信

卡间带宽（NVLink/HCCS）是瓶颈。

输入长度

上下文越长，计算与显存越大。

输出长度

生成越长，耗时越久。

并发量

副本方式才直接提升并发吞吐。

核心要点：显存决定「能不能装下模型」，并发与吞吐决定「能服务多少人」，两者要分开评估，不能只看卡数。

软件与模型：模型怎么「跑起来」

从操作系统、驱动、软件栈，到模型文件与推理框架，再到 Docker 与虚拟机。

软件环境三层：操作系统 → 驱动 → 计算软件栈

操作系统

Linux

管理硬件、文件、网络、进程，是运行底座。

GPU 驱动

识别 GPU

让操作系统识别并管理 GPU 硬件。

计算软件栈

调用 GPU 算力

让程序能真正调用 GPU 的计算能力。

NVIDIA 软件栈

GPU → CUDA → PyTorch → 模型

模型具体模型文件BookGPT

PyTorch深度学习框架框架

CUDA并行计算平台计算栈

GPU硬件算力硬件

华为软件栈

昇腾芯片 → CANN → 框架 → 模型

模型具体模型文件BookGPT

框架MindSpore / PyTorch 适配框架

CANN异构计算架构（对标 CUDA）计算栈

昇腾芯片国产 AI 芯片硬件

模型文件是什么？三类文件缺一不可

权重文件

保存学习后的参数

模型训练的成果，例如 model-00001.safetensors。

配置文件

描述模型结构

模型结构、参数数量、网络结构等元信息。

Tokenizer

文本 ↔ Token 转换

把「什么是 RAG？」转成 Token1/2/3，模型才能计算。

推理框架：训练与推理的分工

训练

教模型学习

用数据优化参数，算力需求极高。

推理

用模型回答问题

加载模型、调用 GPU、执行计算、提供服务。

推理框架负责「加载模型 → 调用 GPU → 执行计算 → 提供服务」。

vLLM

高吞吐推理引擎，主流部署选择。

SGLang

高效推理框架，结构化生成强。

Transformers

HuggingFace 通用库，最基础灵活。

Docker 与虚拟机

虚拟机

隔离运行环境

物理服务器 → 虚拟机 → 操作系统 → 应用，适合多系统隔离与企业服务器管理。

Docker

封装应用运行环境

服务器 → Docker → 容器 → 模型服务，部署方便、环境一致、易迁移。

关系：虚拟机与 Docker 不是替代关系，可组合使用——物理服务器 → 虚拟机 → Docker → 模型服务。

本地化部署关注事项（落地前逐项确认）

本地化项目的难点很多不在代码，而在环境和部署。交付前逐项确认：

CPU / GPU 资源

型号、数量是否达标。

显存

能否装下模型并支撑并发。

操作系统

版本与驱动兼容性。

网络

内外网连通与带宽。

防火墙 / 端口

端口开放与访问策略。

软件依赖

运行库、框架版本一致。

模型文件

权重 / 配置 / Tokenizer 完整。

权限与日志

访问控制与审计留痕。

模型部署 vs 模型推理：成功部署 ≠ 能正常推理

模型部署

让模型具备服务条件

获取模型文件、安装推理框架、配置路径与 GPU、设置端口、启动服务、检查状态。

模型推理

模型实际计算并产出

接收输入 → 计算 → 生成输出。部署成功不代表推理正常（显存不足、格式错、超时都可能失败）。

要点：模型服务启动了，也可能因显存不足、输入格式错误、请求超时而无法完成推理；模型能推理，也不代表生成结果准确。

「部署垂类大模型」到底是哪种工作量？先问清

工作类型	典型内容	工作量
直接部署现成模型	环境准备、安装、服务配置、功能验证	较小
模型适配	调整运行环境、推理框架、算子、依赖	中等
模型微调	准备数据、训练、评测、迭代	较大
模型训练	数据处理、训练集群、训练执行、评测	很大

拿到需求先确认：模型是否已训练/微调完成？只需部署现成模型，还是要按客户数据再微调？是否现场训练？是否要求特定推理性能？这直接决定成本、硬件、范围与周期。

适配

为在目标环境运行而调整

模型基于 NVIDIA CUDA 开发，客户用昇腾 NPU，需评估模型、推理框架、算子、依赖能否适配。

兼容性

能与特定环境正常协作

是否兼容统信 UOS、麒麟 OS、指定数据库版本、Python 版本、已有认证系统。

关系兼容是目标，适配是手段

开发环境 / 测试环境 / 生产环境

DEV 开发环境

研发工作场所

编写代码、调试功能。

TEST 测试环境

验证功能

尽量模拟目标环境，但不一定与生产一致。

PROD 生产环境

正式运行

服务真实用户，如出版社正式使用的平台。

为什么要分开：在生产环境直接改数据库可能造成数据丢失、系统宕机、业务中断。规范做法是开发完成 → 测试验证 → 按变更流程部署生产。本地化项目三环境可能在不同地点、由不同单位负责，是需管理的风险。

部署 / 发布 / 上线：三个词别混

部署 Deployment

安装到目标环境

把程序、配置、依赖装好，具备运行条件。

发布 Release

提供正式版本

把准备好的版本正式提供给目标用户/环境。

上线 Go-live

投入实际业务

系统正式运行、服务真实业务。

要点：部署成功 ≠ 客户同意上线；系统上线 ≠ 项目验收完成。

冒烟测试

Smoke Test：先看能不能跑

正式测试前快速检查最基本功能：页面能否打开、能否登录、核心接口、数据库、模型服务、一次基本问答。

日志 / 监控 / 告警

靠系统而非用户发现故障

日志记录事件，监控持续观察（CPU/GPU/显存/内存/磁盘/响应时间/成功率），告警在指标超限时通知。

AI 系统故障的特殊性：网站能开 ≠ 链路正常

AI 系统故障不一定表现为整个网站打不开，可能只是其中一环异常：

模型服务未启动

网站能开，但问答无响应。

GPU 显存不足

服务在，但推理失败或排队。

检索服务故障

模型正常，但知识库检索不出。

解析任务积压

系统能用，但文件处理堆积。

请求长时间无返回

提交成功，但一直等不到结果。

依赖服务异常

某中间件挂了，拖垮整条链路。

结论：不能只查服务器是否开机，要关注整条服务链路（前端→后端→算法→模型→数据库）是否都正常。

接口与集成：模型怎么「被用上」

模型部署完成后为什么还需要 API？API 与 SDK 的区别、接口联调与常见坑。

模型 ≠ 系统

模型

负责计算答案

模型本身不直接面对用户，只负责「算」。

API

让其他系统调用模型

约定调用方式，把模型能力暴露给业务系统。

调用链路：用户 → 前端 → 后端 → 模型 API → 模型 → 返回结果。

什么是 API

API = 软件之间约定好的调用方式。需要掌握五个要素：

接口地址

请求发到哪个 URL。

请求方式

GET / POST 等。

参数

传什么字段。

返回结果

返回什么格式。

认证方式

怎么验证身份。

例：前端「查询知识库列表」调用 GET /knowledge/list，后端返回知识库名称、创建时间、数量。

SDK 与 API 的区别

	API	SDK
本质	调用规则（说明书）	工具包（封装好的工具箱）
作用	告诉你怎么调用	帮你更方便地调用
使用者	开发人员	开发人员
是否必须	不一定	不一定

一句话理解：API 给你说明书，SDK 给你已经封装好的工具箱。

接口联调：验证模块能合作

前端 ↔ 后端

验证地址是否正确、参数是否一致、返回格式是否一致。

后端 ↔ 算法服务

验证模型接口、OCR 服务、RAG 服务是否连通。

常见接口问题（三个高频坑）

参数不一致

大小写导致识别失败

后端要 username，前端传了 userName。

接口地址错误

404

后端提供 /api/login，前端却调用 /login。

环境地址错误

部署后没改配置

开发环境 192.168.1.10，客户环境 10.10.4.7，上线未修改。

模型部署 vs 业务集成

范围	只部署模型	模型应用集成
内容	安装环境、加载模型、启动服务、API 测试	另加前端页面、后端接口、用户权限、日志、知识库、业务流程
结果	模型能运行	用户真正能使用

参数不一致的四种情况（不只是大小写）

字段名不一致

后端要 username，前端传 userName。

类型不一致

后端要数字 page:1，前端传字符串 "1"。

必填缺失

后端要 book_id，前端只传 question。

含义/结构不一致

book_id 一个传书名一个传编号，或字段放错位置。

接口地址错误：四种原因 + 常见状态码

四种原因

路径写错	/api/login 写成 /api/user/login
端口不对	服务在 8080，访问了 8081
环境配置错	部署后仍访问开发环境地址
网络/代理错	防火墙、DNS、反向代理、证书

常见状态码

404	找不到对应路径
405	HTTP 方法不被允许
401	缺少有效身份认证
403	服务器拒绝访问
500	服务器内部错误

区分：「接口地址错误」是目标地址不对；「接口无法访问」更宽泛，可能由地址、网络、防火墙、服务未启动等多种原因导致。

模块之间怎么通信？（不全是 HTTP 接口）

交互对象	常见通信方式
浏览器前端 ↔ 后端	HTTP / HTTPS API
后端 ↔ 算法服务	HTTP API、RPC
后端 ↔ 数据库	数据库驱动与协议（非普通 HTTP）
后端 ↔ 消息队列	消息队列协议 / 客户端接口
服务 ↔ 文件存储	对象存储 API / 文件系统接口

判断联调：关键不在有没有 HTTP 接口，而在模块之间是否存在需要验证的交互与依赖。A 完成后仍需 B 提供数据/服务才能实现业务功能，就要验证 A、B 协作。

数据与 RAG：模型怎么「知道私有内容」

大模型擅长理解、推理、生成，但不知道企业内部资料、最新文件与私有图书内容，需要 RAG 补齐。

RAG 完整链路（检索增强生成）

1

文档上传

图书 PDF 等私有资料入库。

2

解析（OCR / 抽取）

把 PDF 转成可读文本。

3

文本切分（切片）

按语义切成合适片段。

4

向量化（Embedding）

文本转成向量，存进向量数据库。

5

用户提问

问题同样转成向量。

6

向量检索

召回最相关的原文片段。

7

交给大模型生成

把召回原文 + 问题交给模型，生成带依据的回答。

AI / 算法服务能力清单

AI 服务通常不是直接给用户使用，而是作为后端调用的能力。一个完整的本地化 AI 项目，算法侧通常包含这些能力：

OCR

图片 / 扫描件文字识别。

文档解析

PDF / 版式文档抽取结构化文本。

文本切分

把长文本切成检索片段。

Embedding

文本转成向量。

向量检索

按语义相似度召回原文。

RAG

检索增强生成。

大模型推理

模型回答问题。

智能体

编排多步任务与工具调用。

三种数据存储各司其职

MySQL

结构化业务数据

存用户、书籍、权限等业务数据。

定位关系型数据库

Elasticsearch

搜索与分析引擎

全文检索、关键词搜索，也支持向量检索。

定位不是传统向量数据库

向量数据库

保存文本向量

存 Embedding 向量，做相似度检索。

定位向量检索核心

RAG 与微调：什么时候用哪个

	RAG 检索增强	微调 Fine-tuning
解决什么	补充最新、私有、可溯源的知识	改变模型的行为、风格、专业能力
知识更新	改知识库即可，实时生效	需重新训练，周期长
可解释性	能返回原文与出处	隐式内化，难溯源
成本	低，主要算力在检索	高，需训练算力与数据
典型场景	知识问答、私有文档检索	行业术语、特定输出格式、风格定制

结论：多数场景先上 RAG（快、可溯源、易更新），微调用于 RAG 难以解决的行为/风格/专业能力问题，二者可叠加使用。

两种检索：关键词 vs 向量（语义）

关键词检索

精确匹配字面

按词匹配，快、精确，但换一种说法就搜不到。

代表Elasticsearch 全文检索

向量检索

按语义相似度

语义相近即命中，能理解「同义不同词」，但可能召回不精确。

代表向量数据库相似度检索

最佳实践：混合检索（Hybrid Search）结合两者 + 重排（Rerank）二次精排，是当前召回效果最好的做法。

RAG 链路的重点风险（验收必查）

OCR 错误

文档解析出错，后续全链路失真。

切片不合理

切得太碎或太整，检索质量下降。

检索不到

召回失败，答非所问。

模型幻觉

无依据编造，需靠原文约束。

引用错误

答案与原文出处对不上，需返回原文 + 页码。

测试与验收：怎么「交付合格」

测试体系、职责划分、项目经理评估部署需求与验收维度，以及定位问题的通用方法。

测试体系：从单元到验收

测试	对象	回答的问题	主要负责
单元测试	最小代码模块	这个功能本身是否正确？	开发
联调测试	多个模块之间	模块之间能不能配合？	开发
集成测试	多个组件组合	组合起来是否正常？	测试
系统测试	完整系统	是否满足需求？	测试
回归测试	改动后的旧功能	新增是否影响已有功能？	测试
SIT	系统集成	技术链路是否跑通？	研发 + 测试
UAT	用户验收	客户业务是否认可？	客户业务人员

测试职责划分

开发

单元测试 + 修复

负责单元测试，修复代码问题。

测试

方案 + 执行 + 缺陷管理

测试方案、执行、缺陷管理、验证修复。

算法

AI 效果测试

模型指标、Prompt 优化、效果评估。

运维

环境与稳定

环境、部署、网络、服务稳定。

项目经理

计划 + 闭环 + 风险

测试计划、资源、问题闭环、风险管理。

项目经理评估部署需求：六问

① 模型

什么模型？参数规模？是否训练完成？模型文件是否完整？

② 硬件

GPU 型号？数量？显存？内存？存储？

③ 部署

裸机？虚拟机？Docker？国产 GPU 还是 NVIDIA？

④ 接口

谁提供 API？谁开发接口？谁负责联调？

⑤ 应用

是否需要知识库 / RAG？是否需要前端、权限体系？

⑥ 验收

功能、性能、稳定性、安全四维是否达标？

项目经理部署评估清单（点击勾选）

0 / 6

✓

模型与文件确认模型选型、参数规模、权重/配置/Tokenizer 完整。

✓

硬件与显存确认GPU 型号/数量/显存能装下模型并支撑并发。

✓

部署形态确认裸机 / 虚拟机 / Docker 及国产化路线明确。

✓

接口与联调分工确认API 提供方、开发方、联调责任到人。

✓

应用集成范围确认前端、权限、知识库 / RAG 需求明确。

✓

验收标准确认功能 / 性能 / 稳定性 / 安全四维可度量。

验收的四个维度

功能

能否调用、能否返回结果。

性能

响应速度、并发能力。

稳定性

服务持续运行。

安全

网络访问、权限控制、日志。

项目经理技术问题分析方法

遇到任何技术问题，用这个框架定位。

第一步

问题发生在哪一层？

业务层 → 后端 → 接口 → 算法 → 模型 → 服务器 → 网络，逐层排查。

第二步

判断问题类型

类型	例子
开发问题	功能没实现
接口问题	调用失败
环境问题	部署失败
网络问题	服务不通
数据问题	结果错误
AI 效果问题	回答不好
性能问题	响应慢

第三步：追问四个问题

现象

是打不开？报错？结果错误？速度慢？

环节

模型不能启动，还是后端调用失败？

责任人

前端 / 后端 / 算法 / 运维 / 客户。

完成标准

不是「部署好了」，而是「服务启动成功 + 接口调用成功 + 问答链路验证通过」。

回归测试：局部回归 vs 全量回归

局部回归

只测本次改动相关

重点测试修改涉及的功能及其直接关联模块。

全量回归

重跑完整测试集

重新执行较完整用例，验证主要功能是否正常。

选型依据：按修改范围、模块依赖、风险评估回归范围。涉及公共组件、核心接口、模型服务、权限体系、数据库结构时，需更谨慎。

SIT / UAT / 生产验证：三个别混

名称	重点验证什么	主要参与者
SIT	系统集成后能否正常协作	研发、测试、系统负责人
UAT	是否满足业务需求与验收标准	客户业务人员、项目团队
生产验证	正式环境能否正常运行	运维、研发、测试、业务

要点：听到「SIT 和生产两轮」，不能直接认定为「SIT 和 UAT」，要按团队原话确认第二轮究竟是 UAT、生产验证还是另一轮测试。生产验证≠可随意在生产环境测试，须用经批准的测试数据与方案。

真实项目场景速查：听到 → 理解 → 追问

听到的术语	你应该理解为	建议追问
单测通过	独立功能测试已通过	核心异常场景是否覆盖？
开始联调	模块开始连接协同验证	涉及哪些模块？前置条件齐了吗？
联调阻塞	模块协作遇到阻碍	是接口、网络、数据还是服务问题？
回归测试失败	修改后原有功能仍有问题	哪些功能受影响？是否扩大回归范围？
SIT 通过	集成测试达约定标准	是否还有遗留缺陷？
模型部署完成	模型服务已部署	是否实际推理成功？性能达标吗？
模型适配	处理模型与硬件/软件兼容	涉及哪些组件？工作量和风险？
显存不足	GPU 显存无法满足运行	是加载、输入长度还是并发导致？
接口超时	请求未在规定时间完成	是调用方、网络还是被调用服务？
缺陷关闭	问题已按流程处理验证	有测试记录和关闭依据吗？
上线完成	系统已投入正式运行	监控、备份、回滚、运维安排落实了吗？
评测不达标	AI 输出质量未达标准	用什么评测集和评价口径？

性能与算力：怎么「算得动、跑得快、扛得住」

从显存估算、模型量化，到吞吐/延迟与关键指标，再到性能测试方法——这是你评估算力变更、论证选型时最常用的一层。

显存怎么估算：一个公式 + 一张表

估算显存占用的核心公式：显存 ≈ 参数量 × 每参数字节数 + KV Cache + 激活值。其中「每参数字节数」取决于精度：

精度	每参数字节数	7B 模型权重占显存	特点
FP32	4 字节	约 28 GB	全精度，训练常用
FP16 / BF16	2 字节	约 14 GB	推理主流精度
INT8	1 字节	约 7 GB	量化后体积减半
INT4	0.5 字节	约 3.5 GB	极致压缩，有精度损失

要点：显存占用不只是权重——还要加上 KV Cache 与激活值。上下文越长、并发越高，KV Cache 占用越大，这是「模型能装下」≠「能扛并发」的关键原因。

模型量化

Quantization：用精度换体积

把 FP16 权重转成 INT8 / INT4，显著减小体积、降低显存、加速推理。

常见方法GPTQ / AWQ / GGUF

收益显存↓、延迟↓、吞吐↑

代价可能损失少量精度

KV Cache

为什么上下文越长越吃显存

推理时缓存已计算的键值（Key/Value），避免重复计算，但会随上下文长度线性增长。

影响长上下文 / 高并发时显存压力骤增

两个核心指标：吞吐 vs 延迟

吞吐 Throughput

单位时间处理多少

单位时间处理的请求数或 Token 数（TPS）。反映「能服务多少人」。

延迟 Latency

单次请求多久返回

从请求发出到拿到结果的时间。反映「单个人体验多快」。

权衡：二者常互相制约——批量越大吞吐越高，但单个请求等待可能越久。部署时要按业务目标（优先并发？优先体验？）取舍。

推理的四个关键指标

TTFT

首 Token 延迟

发出请求到吐出第一个字的时间，决定「卡不卡」。

TPS

每秒生成 Token

生成速度，决定「回答快不快」。

P50 / P95 / P99

响应分位数

P95 = 95% 请求的耗时上限，比平均值更反映真实体验。

并发数

同时在线请求

系统能同时稳定服务的请求量。

性能测试怎么做

1

定目标

明确并发用户数、目标响应时间（如 P95 ≤ 3s）。

2

逐步加压

从低并发往上加，观察 QPS、延迟、错误率的变化。

3

找拐点

定位吞吐不再上升、延迟骤增的「性能拐点」。

4

监控验证

GPU 利用率、显存占用、QPS、错误率四类指标对照。

监控四要素：GPU 利用率、显存占用、QPS（吞吐）、错误率——这四项是评估「7×24 稳定运行」是否达标的核心证据。

常见优化手段速览

量化

INT8 / INT4 降显存。

批处理

合并请求提高吞吐。

连续批处理

Continuous Batching，动态组批。

PagedAttention

分页管理 KV Cache，省显存。

投机采样

Speculative Decoding，加速生成。

多副本

多卡多副本扛并发。

缓存

相似问题命中缓存。

蒸馏

小模型模仿大模型。

安全与合规：政企项目的红线

本地化 AI 项目（尤其政企、出版）绕不开的合规要求：等保、内容安全、数据安全、鉴权与审计。

网络安全等级保护（等保 2.0）

定级

确定系统等级

按系统重要性定级（二级 / 三级最常见）。

备案

向主管部门备案

定级后提交备案材料。

测评

第三方测评

由测评机构检测并出具报告，整改后复测。

PM 要记住：等保是「持续合规」而非一次性工作，涉及技术 + 管理两方面；定级越高，安全要求越严，成本和周期越长，需在立项时纳入预算与排期。

内容安全审核

生成内容也要守底线

对模型输入与输出做双向审核，拦截涉政、涉黄、涉暴等违规内容。

对象用户输入 + 模型生成输出

数据安全

脱敏、加密、最小权限

敏感数据脱敏后再处理，传输与存储加密，按最小权限原则授权。

手段脱敏 / 加密 / 分级分类 / 最小权限

API 鉴权：接口不能「裸奔」

方式	原理	适用场景
API Key	固定密钥，随请求携带	服务间调用、简单场景
Token	登录后签发、有时效的令牌	用户会话、前后端认证
OAuth	第三方授权协议	接入第三方平台、单点登录

风险：无鉴权的接口等于把模型和数据「敞开大门」，会被滥用、盗刷算力、越权访问数据。

日志与审计

操作留痕、可追溯

记录谁在什么时间做了什么操作，便于事后定位与合规审计。

要点登录、调用、数据访问、异常

访问控制

谁能访问什么

身份认证（你是谁）+ 权限授权（你能做什么）分开管理。

要点认证 Authentication + 授权 Authorization

AI 特有的安全风险

提示注入

Prompt Injection

恶意构造提示词诱导模型越权、泄露或执行不当操作。

数据泄露

RAG 越权检索

检索时未做权限隔离，A 用户召回 B 用户的私有内容。

模型幻觉

编造与误导

生成看似权威实则错误的内容，需靠原文约束与人工复核。

AI 效果评测：功能正常 ≠ 效果合格

传统软件验证「行为是否符合预期」，AI 还要验证「输出质量是否达标」。这是 AI 项目验收最容易扯皮的地方，需在立项时就定好评测口径。

功能测试 vs 效果评测：两个不同的问题

功能测试

能不能用

能否上传文件、建立知识库、发起问答、返回答案、展示引用页码。

效果评测

好不好用

答案是否正确、检索是否相关、引用是否支持答案、页码是否准确、有无无依据编造。

核心区分：接口调用成功、页面能点，只代表「功能正常」；AI 输出是否达到业务标准是另一件事，不能混为一谈。

测试集 / 评测集 / Benchmark

测试集

验证功能的数据

为验证系统功能或模型表现准备的一组数据，如 100 个问题。

评测集

评价能力的数据

经专家审核的问题 + 标准答案 + 原文出处，用于评价问答效果。

Benchmark

基准评测

一套数据集 / 任务 / 方法，用于横向衡量系统或模型表现。

常见评测指标（口径要先对齐）

指标	含义
检索命中率	是否找到预期的相关资料（有多种算法，需统一口径）
答案准确性	答案是否符合标准（生成式任务需自定义评价标准）
引用准确性	引用内容和出处是否正确
响应时间	从请求到获得结果所需时间
成功率	请求成功完成的比例

提醒：不能只看指标名称就认定各团队计算口径一致，「检索命中率」等有不同算法，比较前必须对齐定义。

准确率 / 召回率 / 幻觉

准确率 Accuracy

答对的比例

分类任务中预测正确样本占比；生成式问答需自定义评价标准。

召回率 Recall

找回了多少

专家确认有 10 段相关原文，系统找出 8 段，召回率 = 80%。

幻觉 Hallucination

无依据编造

看似合理实则缺乏事实依据的内容，是出版 AI 重点防范项。

注意：召回率高 ≠ 检索结果全部相关，也不代表最终回答正确。

评测要在立项时就定好（6 个问题）

避免项目结束后才争论「AI 到底好不好用」，启动 / 需求阶段就应明确：

用什么数据

评测集由谁准备？

标准答案

由谁审核？

评价指标

用哪些指标衡量？

通过标准

达到什么程度算合格？

不通过怎么办

是否允许继续优化？范围如何界定？

口径对齐

各团队指标算法是否一致？

项目管理：把技术工作变成可交付计划

WBS、里程碑、依赖与关键路径、风险与问题——这些直接关系到你的本职工作：范围、进度、成本、风险。

大型 AI 项目的完整流程（10 阶段）

阶段	主要做什么	你要关注什么
1 需求调研	弄清客户究竟要什么	需求是否明确、有无遗漏
2 方案设计	设计系统如何实现	技术方案是否可行
3 环境准备	准备服务器、网络、OS	客户是否具备部署条件
4 开发与配置	写代码、配模型、开发功能	工作量、进度、依赖
5 单元测试	验证单个功能	开发交付是否合格
6 联调测试	验证模块能否协同	接口 / 配置问题
7 集成/系统测试	验证整体系统	业务链路能否跑通
8 性能/安全测试	验证承载能力与安全性	是否达合同要求
9 用户验收测试	客户按业务场景验收	是否满足交付标准
10 上线与运维	正式运行、维护	是否稳定、可监控、可回退

两点关键认识：① 这不是严格线性流程，大型项目常并行开发、分批测试；② 开发（做出来）、测试（做得对不对）、部署（装到目标环境）、验收（满足标准）四者不是一回事。

WBS

工作分解结构

把大项目拆成可分配、可估算、可跟踪的小工作，明确谁负责、何时完成、判断标准。

意义拆到能估算工作量、识别依赖的程度

里程碑

Milestone

有重要意义的节点或阶段性成果，必须对应「可验证成果」，而非简单日期。

示例模型服务启动 + 测试请求推理成功 + 性能达标

依赖关系与关键路径

依赖 Dependency

一件事要等另一件事

客户提供服务器，才能现场部署；网络连通，才能接口联调。

关键路径 Critical Path

决定最早完成时间

一系列相互依赖的任务链，路径上任何延期都会推迟整体交付。

典型链条：客户 GPU 服务器延期 → 模型无法部署 → AI 联调无法开始 → 系统测试无法开展 → 整体进度风险。所以服务器交付延期不只是运维问题，而是项目级风险。

缺陷 / 阻塞项 / 风险 / 问题：四个别混

术语	含义	示例
缺陷	已发现的软件 / 系统错误	页码显示错误
阻塞项	当前无法继续推进的关键事项	模型服务未启动，联调无法进行
风险	未来可能发生、影响目标的事件	客户 GPU 服务器可能延期
问题	已经发生、需要处理的事项	服务器已延期，部署受影响

风险 vs 问题：「可能无法按期提供服务器」是风险（提前识别、制定预案）；「约定日期已过仍未到位」是问题（明确负责人、方案、期限）。

问题单与「关闭」的标准

问题单字段

记录与跟踪

编号、描述、复现步骤、预期/实际结果、严重程度、负责人、处理状态、验证结果。

关闭流程

不是「我改好了」就行

发现 → 记录 → 分配 → 分析原因 → 修复 → 重新测试 → 验证通过 → 关闭。

PM 要点：研发口头说「修复了」≠ 缺陷已关闭；测试不通过就重新打开。你关注的不只是缺陷数量，还有严重缺陷、阻塞项、长期未解决、是否完成验证、是否反复出现。

「完成」有五个不同状态，别画等号

1

技术模块完成

算法检索能力开发完成。

2

模块集成完成

后端已接入接口、联调通过。

3

业务功能完成

用户能从页面完整使用该功能。

4

测试通过

功能、效果、性能、安全达标。

5

正式交付

通过验收，客户认可。

术语速查表

随时检索不熟悉的缩写与概念。

⌕

没有匹配的术语，换个关键词试试。

我的笔记本地模式

随时记录学习心得、疑问与待办。部署后自动云端同步、跨设备保存；本地打开时回退本地模式。可编辑、删除、搜索、导出备份。

共 0 条笔记

⌕

还没有笔记，先在上方记一条吧。

知识测验

40 道题检验掌握程度，答完即时反馈解析。

0 / 40