大模型的热度这两年一直没降过但真正把 AI 落到业务里的人都知道赛道再热闹最后拼的还是工程细节。这里头有两件事最容易被低估一是把模型真正部署起来、稳定跑通的功夫二是从模型能力到产品能力之间的那层“胶水”也就是 Agent 应用、提示词工程和质量测试。这篇文章我打算把这几年折腾大模型部署、应用开发和测试排障的流程完整梳理一遍覆盖本地模型部署、Agent 架构、提示词工程、自动化评估与常见故障适合正在做 AI 应用开发的后端工程师、测试工程师以及想自己搭一套 AI 应用但又不知道怎么下手的技术爱好者。我见过太多项目死在“模型很强但我们集成不起来”这一步也见过不少团队把 80% 的时间花在调提示词、补异常、改接口上。AI 落地这件事模型选型只占很小一部分真正决定成败的是你有没有一套稳定的工程闭环。1. 模型部署方式选型本地跑还是调 API1.1 三条路线各自的优劣势先说选型。开始做 AI 应用第一个绕不开的问题就是模型从哪里来。目前主流路线无非三条本地部署开源模型、直接调用云端 API、本地云端混合。没有绝对的好坏只有适不适合当前业务。本地部署最大的优点有三个数据不出内网、推理成本随用量可控、模型行为可定制。医疗、金融、政务这类对数据边界要求极高的场景数据根本不允许出内网那本地部署就成了唯一选择。但缺点也很明显硬件成本高GPU 一台动辄好几万而且模型版本更新、环境维护、推理性能优化都得自己搞小团队很容易被运维拖死。云端 API 正好相反接入简单、模型迭代不用自己操心、按量付费前期几乎零门槛。适合做原型验证、内容生成类应用、低频工具类产品。最大的顾虑是敏感数据出网以及长期跑下来 token 费用可能远超预期。有些模型调用量一上来一个月账单能到几万甚至几十万那时候再想迁移到本地前期的架构耦合会让你非常痛苦。混合路线是目前中型团队比较常见的选择。把高频、低延迟、敏感的核心链路放在本地把长尾、多样化、对延迟不敏感的任务丢给云端。比如客服系统里意图识别和敏感词过滤走本地小模型复杂问答走云端大模型这样既能控成本也能保证核心体验。我给你的选型建议很简单先想清楚数据能不能出网再算财务账最后才看模型效果。很多团队一上来就对比模型效果却忘了业务约束条件结果技术选型全被数据安全策略推翻白做一轮。1.2 模型量级和硬件配置怎么匹配确定部署方式后选多大的模型又是一个麻烦事。开源模型现在从 0.5B 到 70B 甚至更大都有但并不是越大越好。参数规模直接决定显存占用和推理速度。这里需要学会估算显存。一个经验公式是FP16 精度下大约每 10 亿参数占 2GB 显存INT8 量化大约占 1GB 多一点INT4 量化大约占 0.6GB 左右。以 7B 模型为例FP16 大概需要 14GB 显存单张 24GB 的显卡勉强能跑INT4 量化后大约 5GB 到 6GB消费级显卡和部分大内存笔记本都能带得动。70B 模型 FP16 需要 140GB 以上常规单卡基本没戏要么多卡并行要么配合 CPU offload体验通常不会太好。所以我的建议是个人开发者或者小团队起步优先考虑 7B 到 14B 的量化模型。这类模型在代码生成、文本摘要、结构化信息抽取上已经能打显存要求 16GB 到 24GB 之间硬件门槛可控。如果任务是复杂推理、长文档理解再考虑 32B 或 70B但那时候就不是一两张显卡能解决的事了你得有专门的推理集群预算。还要提醒一句不要只看显存够不够要看“显存 内存 带宽”的整体表现。有些模型虽然能塞进显存但算力不够响应慢到没法用。所以做压力测试时不要只测一个并发要测 P95 延迟那个数字才是用户真实感受到的卡顿程度。1.3 一张表帮你做部署决策维度本地私有化部署云端 API本地云端混合数据私密性高低中初期成本高硬件采购低按量付费中长期成本相对可控随用量线性增长需动态调度延迟稳定性受自身集群影响受网络和限流影响可优化维护成本高低中适合阶段业务稳定、数据敏感验证期、轻量使用中大规模生产如果你看完还是不知道怎么选就用一个笨办法先接云端 API 把业务跑通验证产品价值和用户需求。等日调用量稳定到一定量级再把高频链路迁移到本地。这个顺序风险最低也是我经历过的项目里最稳的一条路。2. 本地大模型部署配置完全指南2.1 环境准备GPU、驱动、CUDA、容器本地部署最怕的不是模型太大而是环境一团乱麻。我见过不少人在裸机上装了 Python、CUDA、PyTorch结果版本互相打架模型跑起来各种报错。所以第一步先统一环境。如果你是 Linux 服务器推荐直接用 Docker 容器。把 NVIDIA 驱动装好然后安装 NVIDIA Container Toolkit让容器能访问 GPU。这个步骤做完后面换模型、换框架都很干净不用在一台机器上反复“考古”。如果你是 Windows 本机优先用 WSL2 模式别直接在原生 Windows 上折腾 CUDA坑太多了。装好驱动后可以用 nvidia-smi 确认 GPU 状态重点看显存大小、驱动版本和 CUDA 版本。一般来说驱动版本不要太旧CUDA 版本决定你后面能不能跑最新的推理框架。不用纠结于把 CUDA 装到多新很多框架自带的运行环境已经够用你只需要保证驱动支持到位就行。2.2 用 Ollama 五分钟跑起第一个模型如果只是想快速验证和本地调试没有比 Ollama 更省事的工具了。它把模型下载、模型管理、API 服务打包成了一体对新手极其友好。在 Linux 或 macOS 上执行curl -fsSL https://ollama.com/install.sh | sh安装完就能拉取模型ollama pull qwen2.5:7b-instruct ollama run qwen2.5:7b-instruct跑起来后我们可以测试一下curl http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct, messages: [{role: user, content: 用一句话解释什么是Agent}], stream: false }Ollama 默认监听本地 11434 端口而且提供了 OpenAI 兼容的接口路径是 /v1/chat/completions。这意味着你后端代码里原来对接 OpenAI SDK 的逻辑只需要把 base_url 改成 http://localhost:11434/v1几乎不用改业务代码就能切换到本地模型。这个兼容性设计是我觉得最值钱的地方省掉了大量集成成本。比如用 Python 调本地模型from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama ) resp client.chat.completions.create( modelqwen2.5:7b-instruct, messages[{role: user, content: 写一段Python代码读取CSV文件并统计每列均值}], temperature0.3 ) print(resp.choices[0].message.content)2.3 用 vLLM 搭建高并发推理服务Ollama 适合个人调试和低并发场景但如果你的服务要对生产环境开放并发一高Ollama 的性能和显存管理就容易拖后腿。这时候更推荐上 vLLM它是目前开源社区里做高并发推理的主流方案通过 PagedAttention 等技术把显存利用率和吞吐量拉高了很多。安装和启动也比较直接pip install vllm vllm serve Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192启动后同样暴露 OpenAI 兼容接口端口默认 8000。几个关键参数我得解释一下。tensor-parallel-size 表示用几张 GPU 并行切分模型单卡就写 1多卡按实际数量写。gpu-memory-utilization 是控制预留给模型和 KV Cache 的显存比例0.9 意味着最多用 90% 显存留一部分给系统和其他进程。max-model-len 控制最大上下文长度越长越吃显存要根据业务实际需求来设不是越大越好。之前有同事问为什么 vLLM 的返回速度和 Ollama 差不多但 QPS 高很多。因为 vLLM 的核心优势是连续批处理它能动态合并多个推理请求到一个 batch 里大幅提高 GPU 利用率。服务线程模型也经过优化。所以在生产环境只要不是超小规模我都建议直接上 vLLM。生产部署时我习惯在前面挂一层 Nginx 或网关做请求转发和限流。vLLM 本身不提供用户认证直接把 8000 端口暴露到公网是很危险的至少也要加个 API Key 验证避免别人白嫖你的算力。2.4 推理参数调优温度、Top-p、max_tokens模型部署起来不代表就完事了推理参数不调好效果和成本都会出问题。最关键的是 temperature、top_p、max_tokens 三个参数。temperature 控制随机性值越高输出越发散越低越稳定。代码生成、信息抽取、分类这类任务我一般设 0.1 到 0.3追求稳定性和可复现性开放式的文案创作可以调高到 0.7 到 0.9让语言更生动。top_p 是核采样控制候选 token 的累计概率范围通常和 temperature 配合使用二选一微调就行不要两个同时大改否则输出会失控。max_tokens 则是硬性限制防止模型无限生成既保护成本也保护接口响应时间。注意并不是所有模型对 temperature 的响应都一样。有些模型在温度调高以后很容易开始“自说自话”编造没有根据的内容。所以在生产环境里宁可用低温度、多轮追问的方式提升输出质量也不要用高温度赌它发挥。3. 从模型到产品Agent 应用开发与提示词工程3.1 Agent 的本质感知、记忆、行动三步循环模型部署好之后怎么把它变成真正解决问题的产品这就是 Agent 的舞台了。我理解的 Agent不是简单套壳 API而是一个能自主拆解任务、调用工具、根据反馈连续调整的智能体系统。最简单的 Agent 核心是个循环接收用户请求让大模型判断需要什么工具调用工具拿到结果再把结果回传给模型模型决定下一步是继续调用还是给出最终回答。这个循环至少要跑一到五轮。没有这个循环模型就是个单次问答机器有了循环模型才能真正去查数据库、发请求、查天气、算公式成为能改变外部状态的系统。在实践中Agent 框架通常会抽象出几个模块任务规划、记忆管理、工具注册、执行器。任务规划负责把复杂需求拆成子任务记忆管理负责保存上下文、历史结果、用户偏好工具注册则告诉模型“当前环境里你能调什么”执行器负责真正调用外部系统并处理返回结果。这四个模块不用一开始就做得特别复杂但边界要清晰。3.2 手写一个最小可用的 Agent 循环很多人一上来就上 LangChain 这类重框架结果被抽象层绕晕。我建议先把底层逻辑自己写一遍跑通后再决定要不要引入框架。下面这个最小循环是理解 Agent 最好的入门代码import json def run_agent(user_input, tools, max_steps5): messages [{role: user, content: user_input}] for step in range(max_steps): resp chat_model(messages, toolstools) if not resp.tool_calls: return resp.content for call in resp.tool_calls: result execute_tool(call.function.name, call.function.arguments, tools) messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result) }) raise TimeoutError(Agent 超过最大执行步数)这段代码虽然短但已经把 Agent 的骨架都包含进来了。chat_model 负责和模型交互并把模型返回的工具调用请求解析出来execute_tool 根据函数名找到对应实现执行后把结果以 tool 消息回传。最关键的是防御机制max_steps 限制防止模型陷入无限循环这在生产环境几乎必备。真实项目里工具返回结果可能非常长直接塞进上下文会污染模型注意力。一个常见优化是把工具返回先做摘要或者结构化提取只把关键信息传给模型。比如查数据库后返回几百行记录可以先算好汇总指标再丢给模型而不是把原始数据全量塞进去。3.3 在 Java 微服务里用 Spring AI Alibaba 接入 Agent如果是 Java 技术栈的团队人工造轮子会比较辛苦直接用 Spring AI 这类框架更合适。Spring AI Alibaba 在 Spring AI 基础上做了大量生产化适配对国内主流云模型有很好的兼容也支持本地模型接口。一个最简单调用示例ChatClient chatClient ChatClient.builder(chatModel).build(); String answer chatClient.prompt() .user(今天杭州适合穿短袖吗请结合当前天气回答) .call() .content();但这只是单轮问答。真实应用里要结合 Spring AI 的 Advisor、Memory、Tool 机制去构建完整链路。我比较推荐先把模型调用封装成独立的 Service 层不要让 Controller 直接依赖 ChatClient方便后续加日志、限流、缓存和灰度。在 Java 体系里做 Agent 有个容易被忽略的好处链路追踪。老项目里通常已经有 SkyWalking、Micrometer 这类监控体系AI 调用也可以接入到同一个 trace 里出了问题能直接定位是模型层、工具层还是业务层的问题。这一点是 Python 原型项目比较难立刻补齐的运维优势。3.4 提示词工程一套可复用的 Agent 提示词模板提示词看着简单实际是回报率最高的优化点。我总结了适合 Agent 场景的结构化模板大概长这样你是{角色}负责帮助用户完成{目标}。 可用工具{工具列表每个工具包含名称、描述、参数格式} 约束条件 1. 必须基于工具返回结果作答禁止编造数据。 2. 当工具返回为空或异常时明确告知用户无法回答。 3. 每轮最多调用{数量}次工具。 4. 最终回答要简洁控制在{字数}字以内。模板背后的逻辑是显式告诉模型边界减少它自由发挥的空间。很多人写提示词喜欢堆形容词比如“请你以专业专家的身份”这种话对模型的影响非常有限。真正有用的是给模型提供格式约束、示例和明确的判断标准。少样本示例的威力远大于规则描述。比如你想让模型从合同里抽取甲方乙方与其写一堆“请正确识别合同双方”不如给两个标注好的输入输出对模型马上就能学会你的格式。在 Agent 场景里工具返回的解析规则也要用示例固定下来否则模型每次输出的字段风格可能都不一样后续解析代码会被迫写得很脏。注意提示词不是一成不变的模型升级后行为可能会变原来效果很好的提示词可能突然失灵。所以提示词必须纳入版本管理并配合自动化测试持续回归。4. AI 测试与质量保障被低估的关键环节4.1 AI 应用到底要测什么很多团队把模型一接功能一跑就以为万事大吉。直到某天线上某个回答突然开始胡说八道用户投诉雪花一样飘过来才发现原来 AI 应用也要被测试。但 AI 应用的测试和传统软件测试很不相同传统测试断言明确比如“输入 11 输出 2”但生成式模型的输出是开放式、概率性的很难用固定断言去验证。我在实际项目里会把 AI 测试拆成五个维度。第一是功能正确性检查答案是否准确、格式是否符合预期第二是稳定性同一个问题多跑几次看结果波动是否在可接受范围第三是回归质量模型升级或提示词调整后之前测过的好用例是否还正常第四是性能包括首 token 延迟、总响应时间、并发下的 P95 延迟第五是内容规范性检查生成内容里是否出现不适用的表述、敏感信息或诱导性内容。内容规范这块尤其要重视。大模型本身没有主观判断能力它的训练数据里什么样的话都有如果不加护栏很容易在业务场景里产出违规或带偏见的文本。很多大厂在做的是“红队测试”也就是用大量恶意或边缘输入去攻击模型找出防御薄弱点再针对性加过滤规则或调整提示词。个人团队虽然做不到那么大规模但至少要把高危场景的输入输出都录下来做回归集。4.2 自动化回归测试用数据驱动的方式评估 Prompt回归测试最让我头疼的就是“怎么判断这次输出算对”。我的解决方案是构建一个带标注的评测集然后用一个强模型当裁判给当前模型的输出打分。评测集的基本格式是一组 JSONL 数据每条包含输入、期望结果和评估维度。比如{id: case_001, input: 帮我写一段Python读取CSV的代码, expected: 包含read_csv, dimension: keyword} {id: case_002, input: 解释什么是KV Cache, expected: 包含显存、复用、计算优化, dimension: keyword}然后写一个简单的评测脚本把当前模型的输出和期望结果一起发给裁判模型让它输出 1 到 5 分低于 3 分视为失败。跑一遍评测集后统计通过率和平均分这个指标就可以作为后续每次模型或提示词改动的验收依据。import json def eval_prompt(prompt, eval_set): failures [] for case in eval_set: output get_model_output(prompt, case[input]) score judge_model_score(case[input], output, case[expected]) if score 3: failures.append(case[id]) return len(failures) / len(eval_set)用模型评价模型的做法并不完美裁判模型也会有偏好和偏差但它至少能提供一个相对稳定、低成本的基准线。你可以把通过的评测集里的用例全部缓存起来在日常开发中跑回归只要出现大面积分数下滑立刻能定位到是哪次改动导致的。4.3 测试工程师在 AI 项目里怎么发挥作用我接触过很多测试工程师面对 AI 项目时第一反应是焦虑觉得“模型输出不可控我还能测什么”。实际上 AI 让测试工作更重要了只是测的内容变了。测试工程师最该做的三件事搭建回归测试框架、沉淀评测数据集、建立线上监控大盘。回归测试框架能保证每次迭代不把旧功能搞坏评测数据集是团队的核心资产数据越丰富回归能力越强线上监控则是最后的防线通过采集线上请求的成功率、无效回答率、用户反馈等数据快速发现问题并回滚。要特别强调的是AI 应用必须具备“无效回答率”这个概念。传统接口要么成功要么失败生成式模型可能返回一个 200 状态码但内容完全是废话这在用户侧依然是不可用。所以测试阶段要把“逻辑是否成立”“格式是否满足”“信息是否完整”这些软性判断纳入监控指标而不是只看 HTTP 状态码。4.4 监控指标怎么定指标说明建议阈值首 token 延迟从请求到第一个 token 的时间P95 2s总响应时间完整生成时间视业务而定token 消耗每次会话平均 token 数持续观察成本工具调用失败率Agent 调工具失败占比 5%无效回答率语义上无意义的输出占比 3%评测集通过率恢复自动回归通过比例 95%监控不是为了让数据好看而是为了能提前发现异常。我见过很多系统在线上跑得很顺直到某天模型服务悄悄升级了版本生成质量整体下滑但业务方浑然不觉。如果当时有跑评测集做定期回归这种问题半小时内就能发现。5. 常见问题与排查技巧实录5.1 部署环节的典型报错先说显存溢出这是本地部署最常见的坑。启动模型时报 CUDA out of memory第一反应不应该是换更大的卡而是先检查当前的并发和上下文长度。如果只是单卡 24GB 跑 7B FP16还有余量但如果你在 vLLM 里把 max-model-len 开到几万几个请求进来显存直接爆掉。优先调整 gpu-memory-utilization 和 max-model-len再考虑换量化模型。还有一个高频问题是“模型下载慢”。不管是 Ollama 还是 huggingface都需要连外部模型仓库网络波动时很容易中途失败。解决思路是用断点续传或者把模型文件先下载到本地再导入。Ollama 的话可以用 ollama pull 反复重试它本身有断点恢复机制HuggingFace 的话建议用 hf 命令行工具配合镜像配置但具体镜像地址要根据你所在网络环境来选。再说一个玄学问题同样的模型在自己电脑上跑和服务器上跑输出结果不一样。这其实不玄学根源可能是推理框架的算子实现差异也可能是 float 精度差异。解决方法是把 temperature 设成 0并把随机种子固定这样可以缩小偏差。但别指望完全一致模型服务之间做到可复现本来就是个伪需求关键是语义质量稳定。5.2 Agent 开发中的常见陷阱Agent 最常见的翻车现场是“死循环”。模型反复调同一个工具拿不到有效结果就再调一次最后把 token 打光。除了设 max_steps还要在工具层做结果去重和缓存如果工具输入和上次完全一样直接返回上次的结果避免模型重复劳动。第二个陷阱是“上下文爆炸”。每轮工具返回结果都塞进 messages几轮之后上下文就接近窗口上限模型开始遗忘早期的用户意图。常规思路是引入滑动窗口或摘要压缩把早期对话做一个 summary替换掉原始长文本。还有更细的做法对不同工具的结果做字段裁剪只保留模型决策真正需要的字段。第三个陷阱是“工具权限过大”。有些开发者在 Agent 里放一个万能 execute_code 工具让模型想执行什么代码就执行什么。这在原型阶段很爽但生产环境里等于把一个没有安全检查的远程执行器交给模型很容易出事故。实际项目中工具命令应该是白名单制、细粒度的比如“查定时任务”“重启某个服务”分开注册而不是给一个“执行任意 shell 命令”的万能入口。注意Agent 的工具调用一定要有审计日志。模型在什么时候调了什么工具、传了什么参数、工具返回了什么这些全部要留痕。否则线上出问题你连回放都做不到排查就跟大海捞针一样。5.3 测试环节自查清单如果你现在要上线一个 AI 功能可以对照下面这个清单做一遍自查。是否有一个至少 50 条用例的评测集覆盖正常场景、边界场景和异常输入是否做过稳定性测试同一个 prompt 跑 10 次结果波动是否可接受是否记录了模型版本、提示词版本、评测通过率的变化历史是否对工具调用失败、模型超时、API 限流等重要异常做了兜底文案是否验证过高并发下的表现而不是只在单并发下测过是否对用户上传的内容做了必要的输入校验和输出过滤这套清单是我每次上线前必过的虽然不能保证万无一失但能把绝大多数低级问题挡在上线之前。6. 我从这些实践中踩出来的几条经验项目做得越多越能体会到AI 应用的很多问题都不是模型本身造成的而是工程前置条件没做好。比如模型明明能力很强但因为部署时显存参数没调好导致响应太慢最后被业务方判定为“模型不行”。又比如 Agent 明明逻辑设计得好但因为工具接口不稳定结果整个流程频繁失败体验一落千丈。我现在的习惯是接到新的 AI 需求先问五个问题数据能不能出网并发量大概多少预期的响应延迟是多少容错要求多高预算上限在哪这五个问题问完技术方案基本就浮出水面了剩下的都是执行细节。如果让我给正在入门的人一个建议我会说先别急着上复杂框架用最小代码把“模型调用-工具执行-结果回填”这条路走通再逐步加模块。本地部署先用 Ollama 跑通再做 vLLM 优化Agent 先手写循环再考虑框架测试先积累一个 50 条左右的评测集再考虑自动化平台。每一步都不难难点只在于你有没有沉下心把链路里的每一环都亲手摸一遍。还有一点不得不提做 AI 应用不要迷信“大模型万能”。模型只是决策引擎它需要靠工程系统来约束行为、提供工具、管理状态。真正值钱的是你围绕模型搭建的那套完整闭环而不是模型本身。把你的评测集、提示词版本、工具规范、监控指标当成项目资产一样持续打磨比换更强的模型更早见效。