大模型应用的部署很多时候比开发更考验人。上周我接手了一个AI智能面试系统的部署任务项目本身不复杂——简历上传、面试题生成、多轮问答、AI追问、自动评分标准的“简历大模型”业务闭环。但真正从拿到代码到线上跑通全流程中间踩的坑比我预想的多得多。这篇记录不会只贴成功路径我会把组件选型的理由、配置文件的坑、故障排查的完整链路、压测调优的数据全部写出来方便之后接手这类项目的朋友直接参考。先说清楚这系统是干什么的候选人上传简历后系统自动抽取简历关键词生成针对性的面试题面试官或候选人通过文字/语音形式完成多轮问答AI会根据岗位要求做追问最终输出一份包含能力维度评分和面试总结的报告。适合用在校招初筛、日常模拟面试、批量候选人评估等场景。部署这东西核心不在某个单一服务而在于“大模型业务系统”的通用架构问题——外部API的稳定性、长请求的并发处理、非结构化文档的解析、流式响应的代理配置。1. 开局前必须想清楚项目组件构成与部署资源权衡很多人拿到代码第一件事就是跑起来但我建议先花半小时把项目拆开看一遍。这个AI面试系统不是单体应用也不是纯前后端分离而是带了不少外部依赖的复合系统。我拆完之后的组件清单大致是这样的功能模块技术组件部署形态说明业务后端Java技术栈Spring Boot 3.x单JAR包进程简历解析、面试会话管理、题目生成编排、评分报告前端界面Vue3 Vite构建产物静态文件 Nginx托管管理后台、候选人面试端、结果查看页业务数据库MySQL 8.xDocker容器或独立服务用户、岗位、简历记录、面试会话、评分明细缓存Redis 7.xDocker容器会话状态、大模型流式响应缓冲、接口限流对象存储MinIO兼容S3协议Docker容器简历原文件、语音录音、导出的面试报告向量检索开源向量数据库Docker容器简历切片Embedding的存储与相似度检索外部依赖大模型HTTP API、语音识别API外部服务题目生成、追问、评分、语音转文字这里我想多说一句为什么选这个组合。计算机资源是有限的部署方案的设计本质上是取舍。MySQL存结构化业务数据无可争议Redis不能省因为AI面试是典型的会话型业务候选人答题过程中要在大模型和前端之间来回传递上下文没有Redis做中间缓存后端多实例部署时状态管理会很难受向量库则是这个项目的关键设计——简历解析后做切片向量化AI追问时从简历的向量索引里捞相关片段作为参考避免“大模型凭空提问”的情况这件事用普通数据库的LIKE查询是做不到的。资源权衡的结论也很明确如果只是演示环境一台8核16G内存的机器就可以全部跑动不过大模型调用必须走外网API如果要做生产级别建议把MySQL、向量库、应用服务分开部署。我这次是在内网的一台16核32G的服务器上加两台备用节点完成的应用和中间件分离部署这样后续扩容比较从容。部署版本锁定也是必须做的。Spring Boot 3.x要求JDK17前端Node版本必须用20以上的LTS版本MySQL别用5.7直接用8.0。我在初始化环境的时候就固定好版本避免后面出现莫名其妙的兼容性问题。2. 数据库、中间件与大模型接入的三件套准备环境准备阶段看似枯燥但问题往往都从这里埋下。我在初始化阶段就踩了不少坑分步骤说一下完整流程和背后的原因。2.1 用容器化方式拉起中间件服务我的习惯是把MySQL、Redis、MinIO、向量数据库这些中间件全部用Docker Compose统一管理因为它们的配置项相对固定容器化之后方便内网迁移。项目源码里给了一份docker-compose.yml我结合实际环境做了修改version: 3.8 services: mysql: image: mysql:8.0 container_name: ai-interview-mysql environment: MYSQL_ROOT_PASSWORD: 这里替换成自己的强密码 MYSQL_DATABASE: ai_interview ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql - ./init-sql:/docker-entrypoint-initdb.d command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci - --max_connections500 redis: image: redis:7.2 container_name: ai-interview-redis ports: - 6379:6379 command: redis-server --appendonly yes --requirepass 这里替换成自己的Redis密码 minio: image: minio/minio container_name: ai-interview-minio environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: 这里替换成自己的MinIO密码 ports: - 9000:9000 - 9001:9001 command: server /data --console-address :9001 vector-db: image: vector-db-server:latest container_name: ai-interview-vector ports: - 19530:19530 volumes: - ./vector-data:/var/lib/vector-db这里有两个细节很容易忽略。第一个是MySQL的字符集必须显式指定utf8mb4简历内容里有各种生僻字、特殊符号不用这个字符集在解析和存取时会报乱码或截断错误。第二个是Redis必须开启appendonly持久化AI面试过程中产生的会话数据如果只存在内存里服务一重启就全部丢了。初始化数据库时项目通常自带SQL脚本放到init-sql目录下首次启动会自动执行。我检查了核心表设计主要涉及四类用户与权限表、岗位与简历表、面试会话表、题目与评分表。面试会话表是最关键的一张表记录了候选人从进入面试间到结束全过程的会话ID、题目列表、答案内容和评分结果后续所有统计都围绕它展开。2.2 大模型API接入配置从Key到模型参数的完整映射这个AI面试系统的核心逻辑都建立在外部大模型API之上所以配置的准确性直接决定系统能不能用。我用一个独立配置文件来承载所有外部模型相关参数ai: model: provider: custom-openai-compatible api-base: https://api.example-llm.com/v1 api-key: ${LLM_API_KEY} chat-model: interview-chat-model embedding-model: text-embedding-model temperature: 0.7 max-tokens: 2048 request-timeout-ms: 60000 stream-enabled: true这里用环境变量LLM_API_KEY注入密钥不直接写在配置文件里。大模型API对外提供的接口协议大同小异基本上都兼容/v1/chat/completions风格的调用方式项目源码里已经封装了统一的HTTP调用层我只需要把base地址、模型名和Key填对就行。但有两个参数必须根据自己的场景调整request-timeout-ms我默认配置的是60000毫秒也就是60秒stream-enabled强制开启流式输出。为什么这两个参数这么关键后面故障排查部分我会详细展开。先埋个结论大模型生成一段完整的面试追问在内容较长时耗时可能达到20到30秒如果超时时间按常规HTTP请求的5秒去设置面试流程会频繁中断而流式输出可以让候选人看到文字逐字出现体验上不会觉得系统卡死了。模型参数也需要针对面试场景做限定。temperature不宜太高我调过0.9和0.7两个版本0.9版本生成的追问明显发散容易出现重复提问和逻辑跳跃0.7是相对平衡的值既要让提问风格有些多样性又不能脱离简历事实和岗位要求。2.3 Embedding与向量库简历语义检索的关键环节简历解析之后系统会把文本按段落或语义切片每条切片通过Embedding模型转成向量写入向量数据库。这个设计解决的是一个很具体的问题面试官或AI提问时系统需要从候选人简历里找到最相关的片段作为参考而不是让大模型凭空发挥。比如候选人简历里写了“熟悉微服务治理”AI追问时就得从向量库里检索出这段描述结合岗位要求做针对性提问。部署阶段需要跑一次全量初始化脚本把示例岗位的JD模板和示例简历向量化写入向量库。初始化完成后要验证一下检索结果用一个简单问题去查询确认返回的内容和简历语义一致。这一步如果没验证到面试环节就会发现AI提问的内容和简历无关问题排查起来更加痛苦。3. 前后端构建部署的完整操作链路中间件就绪后开始部署应用本体。这个阶段我按“后端服务 → 前端静态资源 → 反向代理 → 全链路联调”的顺序来做每一步都验证通过再进下一步。3.1 后端服务从配置到启动的完整流程后端工程是标准的Maven项目JDK环境确认无误后直接打包# 安装JDK17后检查版本 java -version # 在项目根目录执行Maven打包跳过测试 mvn clean package -DskipTests构建产物是target/目录下的一个可执行JAR包。这里有一个经验不要直接用java -jar裸跑我把启动命令封装成带JVM调优参数的脚本#!/bin/bash export JAVA_HOME/usr/local/jdk-17 export LLM_API_KEY你的大模型密钥 export MYSQL_HOST192.168.10.10 export MYSQL_PASSWORD你的数据库密码 export REDIS_HOST192.168.10.10 export REDIS_PASSWORD你的Redis密码 java -Xms2g -Xmx4g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -jar ai-interview-server.jar \ --spring.profiles.activeprod \ --server.port8080-Xmx4g是我实际调整过的参数。这个AI面试系统在并发面试场景下每个候选人的会话要同时保持上下文缓存和部分中间数据内存吃紧时会频繁触发Full GC导致接口响应变慢所以堆内存给到4G起步比较稳。如果服务器内存只有16G建议给JVM留4G其余留给MySQL、Redis和向量数据库。后端启动时先看日志关键输出正常启动会在最后出现端口监听和“Started Application”信息。再验证健康检查接口curl -X GET http://127.0.0.1:8080/actuator/health返回{status:UP}就说明后端基础运行没问题。这一步不要跳过它能快速区分“后端启动失败”和“业务接口报错”两个层次的故障。3.2 前端构建产物与Nginx站点配置前端是标准的Vue3工程依赖安装和构建的命令已固化在package.json里# 安装依赖推荐用npm ci而不是npm install保证依赖版本和lock文件一致 npm ci # 环境变量配置VITE_API_BASE需要指向后端的访问域名或反向代理地址 # .env.production # VITE_API_BASE/api # 构建生产包 npm run builddist目录就是最终产物把它拷贝到Nginx的静态站点目录下。Nginx在这里不只是托管静态文件它还承担了反向代理的角色解决前端的跨域问题。下面是我用过的、经过验证的Nginx配置server { listen 80; server_name interview.local; root /usr/share/nginx/html; index index.html; # 前端路由需要回退到index.html否则刷新页面会404 location / { try_files $uri $uri/ /index.html; } # API请求统一反向代理到后端服务 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 大模型流式响应关键配置 proxy_buffering off; proxy_cache off; proxy_read_timeout 120s; proxy_http_version 1.1; proxy_set_header Connection ; } }这里有一个最容易被忽略的配置proxy_buffering off。大模型流式接口走的是SSE如果Nginx开了缓冲会把流式数据攒到一定量才返回候选人看回答时会出现长时间无响应然后突然冒出一大段的现象体验很糟糕。关闭缓冲后每一块生成内容都能立刻转给前端。刷新404的问题也要提前处理。Vue前端默认是history路由模式用户在面试过程中刷新页面Nginx如果没配置try_files回退就会报404。加上try_files $uri $uri/ /index.html这行后所有不存在的路径都由前端路由接管。3.3 联调验证用一条真实请求串起全链路前后端都启动后我习惯用几个curl请求完整走一遍接口链路而不是直接打开浏览器。第一次联调重点验证四件事登录鉴权、简历上传、面试会话创建、大模型生成题目。# 1. 登录获取token curl -X POST http://interview.local/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123} # 2. 上传简历文件用PDF测试样本 curl -X POST http://interview.local/api/resume/upload \ -H Authorization: Bearer 刚才拿到的token \ -F file/tmp/sample-resume.pdf \ -F positionId1 # 3. 创建面试会话 curl -X POST http://interview.local/api/interview/start \ -H Authorization: Bearer 刚才拿到的token \ -H Content-Type: application/json \ -d {resumeId:1,positionId:1}第三步创建面试会话后后端日志里会出现大模型API的调用记录包括请求的Prompt摘要和返回的题目JSON。看到日志说明整条链路已经通了前端请求 → Nginx → 后端 → 大模型API → 数据库存储。接下来才是真正的功能验证我会打开浏览器进入候选人面试端实际答几道题确认全流程没有遗漏。4. 部署现场最容易翻车的三类故障与完整排查过程框架跑通只是开始真正的“部署过程”是从能运行到能稳定运行的跨越。以下三个问题是我这次部署中真实遇到过、并且都有完整排查链路的写出来供大家遇到类似情况时参考。4.1 大模型接口响应超时的根因分析现象描述候选人进入面试间点击“开始面试”后前端一直转圈大约10秒左右接口直接报500错误。查看后端日志发现大量Read timed out异常堆栈信息指向HTTP客户端调用大模型API时超时。我的排查链路是这样的第一步先绕过系统直接测上游。用curl手动调用大模型API带上相同的Prompt用curl -w统计耗时curl -X POST https://api.example-llm.com/v1/chat/completions \ -H Authorization: Bearer $LLM_API_KEY \ -H Content-Type: application/json \ -d {model:interview-chat-model,messages:[...],stream:false} \ -w \n耗时: %{time_total}s\n实测结果完整生成一组面试题耗时约22秒。这就证实了根因不在上游而在后端的HTTP客户端超时配置。第二步检查系统内部HTTP客户端的连接超时和读取超时配置。发现默认配置的是5秒读取超时——这个值对普通API调用够用但大模型生成内容动辄10秒以上必然触发超时。第三步修改配置。超时时间放宽到60秒同时按预期方案开启流式输出让前端通过SSE逐段接收内容。修改后重新测试同一组题目的完整对话从“前端10秒报错”变成“约1秒开始出现文字18秒内完整展示”用户体感提升非常明显。这里总结了一个经验所有涉及大模型API的HTTP客户端读取超时不要低于60秒只改超时不改流式体验依然是“等待20秒一次性弹出”并不会让用户觉得系统快。4.2 简历解析中文乱码与文件格式兼容问题现象描述上传一份中文PDF简历后前端预览正常但系统解析出来的文本里大量中文变成乱码AI生成的面试题甚至出现了对乱码字符的“强行解读”。这次的排查过程稍微曲折。第一反应是编码设置问题但检查了后端解析链路发现调用解析服务时没有显式指定文档编码。第二步是看日志中解析出的原始文本发现PDF里的中文内容全部变成了类似å¼Â的UTF-8变形乱码这其实是典型的“文件内嵌字体无法被解析器正确提取”问题。第三步对照测试不同文件类型。我分别用.docx、.txt、.pdf三种简历样本上传发现.txt和.docx均正常唯独部分PDF出错。进一步确认出错的那批PDF在生成时使用了非标准的内嵌字体子集而默认解析器在处理这种字体时使用了错误的字符映射。修复方案分两层上传入口层增加文件类型校验和原文件预览后端解析层对PDF文件走专用解析分支并在解析时关闭字体回退、强制使用Unicode映射// 伪代码示意示意PDF解析时的关键配置 PDFParserConfig config new PDFParserConfig(); config.setExtractTextFromUnknownFonts(true); config.setNormalizeWhitespace(true); config.setExtractReadOnlyPdf(true);配置之后重新上传同批PDF解析文本恢复正常。此外我还做了个防御性补充解析之后增加一轮文本清洗过滤不可见字符和异常替换符避免脏数据进入后续Prompt导致大模型生成跑偏。4.3 首次并发面试时的内存与GC事故现象描述内网试用阶段同时有5个候选人进入面试流程运行约10分钟后后端服务突然无响应。查看监控JVM堆内存接近上限GC日志显示FULL GC连续发生每次耗时超过3秒。这个故障发生在部署后第一次小规模并发验证时根因有三个叠加因素。第一个因素是我第3节提到的JVM堆设置当时还在用默认的-Xmx256m跑测试根本没考虑业务峰值。第二个因素是没有控制大模型请求的并发度。候选人提交答案后后端会同步调用大模型生成追问每个请求占用一个Tomcat工作线程且请求期间保持着上下文相关的内存对象。5个并发面试同时触发追问时线程池被占满新请求全部排队。第三个因素是Redis会话缓存没有做过期控制。闲聊式的测试会话堆积了大量状态数据在内存里挤占了大量堆空间。修复过程记录如下第一步JVM堆内存调整到4G并开启G1收集器设置最大GC停顿目标为200毫秒。第二步后端加入信号量限流对大模型调用做全局并发控制private final Semaphore modelSemaphore new Semaphore(4); public String callModel(String prompt) { try { modelSemaphore.acquire(); return doCallModel(prompt); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(模型调用被中断, e); } finally { modelSemaphore.release(); } }这样做的意义在于同时保护两方外部大模型API不会被突发流量打爆后端的线程池也不会因为长耗时请求被全部占满。因为大模型调用本身耗时较长全局控制在4个并发能保证即使有大量候选人同时面试系统也始终有可用线程处理其他请求。第三步给Redis会话设置合理的过期时间面试会话超过60分钟自动清理避免测试数据堆积。调整之后重新执行同样规模的并发验证5个并发面试全部正常走完单次追问响应时间从18~22秒缩短到15秒左右GC停顿稳定在100毫秒级别。5. 部署完成后的自测方案与性能调优记录到这里系统已经能稳定运行了但还不能直接宣布“部署完成”。如果没有针对AI面试场景做完整自测上线后很可能出现功能上“能跑”但效果上“不能用”的尴尬。5.1 用真实面试流程跑通全链路自测我的自测思路是模拟三种不同类型的候选人分别上传三种完全不同风格的简历应届生无工作经验型、有3年工作经验的技术型、转行型。然后全程走完一遍面试记录以下几个关键指标自测项预期结果实测结果简历上传与解析耗时3秒内完成2.5秒PDF/ 0.8秒Word首题生成耗时20秒内出现文字5秒出现首字流式多轮追问相关性追问内容与简历片段相关良好可溯源到简历片段评分报告生成2分钟内输出40秒输出会话中途刷新不丢会话刷新后从Redis恢复上下文自测过程中我额外发现一个前端问题候选人在答完一道题后点击“提交”按钮没有立即置灰快速双击会提交两次答案。后端虽然在接口层有幂等校验但用户体验仍然不好最后前端加了个防止连点的标志位解决。评分稳定性测试也要做。同一个面试者的同一次回答记录我重复调用评分接口3次发现评分结果的偏差在5分以内属于可接受范围。这里的问题是如果偏差过大说明评分Prompt设计有缺陷需要加入更明确的评分量规约束。5.2 响应延迟与并发压力的实测调优压测我用的是内网工具模拟面试请求单机后端做了一轮阶梯式并发测试1、5、10、20并发用户同时活跃面试。从5并发到10并发时虽然限流机制生效系统没有崩溃但首字响应时间从1.5秒涨到了3.2秒追问间隔明显变长。分析发现瓶颈不在后端CPU而在外部大模型API的吞吐上限。也就是说这时候继续加机器也没用因为上游是被共享的同一套外部模型服务。优化的方向就变成了系统层面的资源调度。我在系统配置里增加了针对不同模型用途的调用优先级题目生成属于关键链路请求优先占用并发名额评分报告属于异步任务放在空闲时段执行通过消息队列解耦。这样调整后候选人等待追问感受到的延迟明显下降而评分报告延后几十秒交付完全不影响体验。部署完成后的监控确认也是必不可少的一环。我写了一个简单的健康检查脚本每30秒探测后端健康接口、数据库连接数、Redis可用性异常时推送告警同时开启后端日志的GC日志输出每隔一段时间分析一次GC停顿数据。不要在这件事上省力AI面试系统的故障往往是渐进的——请求量上来后内存水位缓慢上升等真正出问题的时候再查就晚了。6. 个人复盘与后续可扩展的部署方向这次AI智能面试项目部署下来我最深刻的体会是部署大模型应用本质上是在跟“不确定的延迟”和“有限的内存”做博弈。外部大模型API不可控就要在后端把超时、重试、限流、降级做好会话数据不能丢就要在Redis和数据库的配合上想清楚并发上了量以后瓶颈很可能不在自己的服务器而在上游API这个认知要有否则会把调优方向带偏。还想补充一个小技巧整个部署过程中我给每个中间件和JAR包都做了镜像和安装包的版本备份放在内网私有仓库里。后续系统升级或节点扩容时直接拉取相同版本完全避开“测试环境能跑、生产环境装不上”的版本偏差问题。这个项目后续如果要扩展我会优先加两个方向一是面试记录的音视频留存对接音频处理后把候选人语音转写成文字再喂给大模型形成更完整的面试评价链二是把评分报告做成可配置化的模板让不同岗位用不同的评分维度和权重。部署架构上加一个消息队列把简历解析、评分这些耗时任务全部异步化整个系统的并发能力和稳定性还能再上一个台阶。