1. 从救火队员到造模型的人一次被迫的转身两年前我的日常还是盯着监控大屏处理磁盘告警、排查网络抖动、写Shell脚本做批量巡检。那时候我对开发的理解停留在能写个Ansible Playbook把配置推下去就算不错了。转折点出现在公司决定把一套内部知识库系统接入大模型能力——领导在会议上问了一句咱们谁能把模型跑起来再做个接口给业务方用会议室里没人接话我鬼使神差地举了手。举手容易落地难。我当时的Python水平大概就是能看懂脚本、能改改别人的代码对FastAPI、模型推理、向量检索这些概念几乎一无所知。但运维出身的人有个特点不怕折腾环境不怕看日志不怕从零搭一套东西。这两年里我从在Linux上装Python开始一路踩到模型微调、接口并发、日志丢失、打包部署最后能独立交付一套带前端交互的大模型应用。这篇文章不讲虚的就把我走过的路、踩过的坑、以及如果重来一次我会怎么做完整摊开。如果你也是运维、测试、或者传统后端出身想往大模型全栈方向转这篇内容应该能帮你少走至少半年的弯路。我会从技术栈选型、环境搭建、接口开发、模型接入、微调入门、部署运维这几个维度把每个阶段的核心逻辑和实操细节讲清楚。关键词里提到的Python、FastAPI、Ollama、大模型部署、微调这些都会落到具体操作上不玩概念。2. 运维转开发的第一道坎Python不是会写脚本就够了2.1 为什么我建议从Python 3.10起步而不是3.8我最初在CentOS上装的是系统自带的Python 3.6后来发现大量大模型相关的库已经不支持了。transformers新版本要求3.8FastAPI的某些依赖在3.7以下会有兼容问题而Ollama的Python客户端干脆要求3.8以上。更关键的是Python 3.10开始支持结构化模式匹配match-case写配置解析和路由分发时代码可读性提升明显。我的建议很直接新项目一律用Python 3.10或3.11。3.12虽然更新但部分科学计算库的预编译轮子还没跟上在服务器上源码编译numpy会让你等到怀疑人生。安装方式上别用系统包管理器直接升级系统Python那会把yum/apt搞崩。正确做法是源码编译或者用pyenv管理多版本。源码编译的完整流程我贴一下这是我在Ubuntu 22.04上验证过的# 安装编译依赖 sudo apt update sudo apt install -y build-essential zlib1g-dev libncurses5-dev \ libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev \ libsqlite3-dev libbz2-dev liblzma-dev # 下载并编译Python 3.11 wget https://www.python.org/ftp/python/3.11.9/Python-3.11.9.tgz tar -xf Python-3.11.9.tgz cd Python-3.11.9 ./configure --enable-optimizations --with-lto --prefix/usr/local make -j$(nproc) sudo make altinstall注意最后用的是altinstall而不是install这样不会覆盖系统的python3命令。装完之后python3.11和pip3.11就可以直接用了。提示--enable-optimizations会让编译时间翻倍但运行性能提升大约10%到20%。如果只是开发环境可以去掉这个参数省时间。2.2 虚拟环境这件事运维思维必须切换运维习惯是全局装一个所有脚本共用。但Python项目里不同项目依赖版本冲突是家常便饭。我吃过一次亏一个项目需要pydantic 1.x另一个需要pydantic 2.x全局环境直接炸了排查了半天才发现是版本打架。现在我的标准动作是每个项目一个venv绝不例外。python3.11 -m venv venv source venv/bin/activate pip install --upgrade pipWindows上就是venv\Scripts\activate。装依赖的时候我习惯先写requirements.txt再批量装而不是一个个pip install。这样换机器、重建环境的时候一条命令搞定pip install -r requirements.txtrequirements.txt里我会锁定版本号比如fastapi0.110.0而不是fastapi。原因很简单不锁版本三个月后重建环境可能就装出一个不兼容的新版本这种问题在服务器上排查起来极其痛苦。2.3 numpy、cv2这些库的安装坑关键词里有人搜python安装numpy库的方法和python下载cv2这两个我单独说一下。numpy现在基本pip install numpy就能搞定但如果你的机器没有预编译轮子匹配会触发源码编译需要Fortran编译器。解决办法是升级pip到最新版它会优先拉取manylinux轮子。cv2的包名不是cv2而是opencv-pythonpip install opencv-python # 如果需要GUI功能imshow等 pip install opencv-python-headless # 服务器无桌面环境用这个服务器上千万别装带GUI的版本会拖一堆X11依赖还容易出问题。这个细节很多教程不讲但实际部署时经常卡在这里。3. FastAPI为什么成了我做大模型接口的首选3.1 Flask和FastAPI的真实对比不是谁更好而是场景不同我早期用Flask写过几个小接口后来全面转向FastAPI。不是说Flask不好而是大模型场景有几个硬需求Flask满足得不够优雅。对比维度FlaskFastAPI异步支持需额外配置原生不支持async原生async/await数据校验手写或依赖插件Pydantic自动校验接口文档需装flask-swagger自带Swagger UI和ReDoc性能同步阻塞并发靠多进程ASGI异步单进程高并发类型提示无强制深度集成类型提示大模型推理是典型的IO密集型场景——请求发出去等模型返回这期间CPU是闲着的。用Flask的话每个请求占一个线程并发一高就排队。FastAPI的async能让单进程同时处理几十个等待中的请求这对调用外部模型API或者本地推理服务来说吞吐量提升非常明显。3.2 一个能直接跑的最小项目结构我现在的FastAPI项目目录结构基本固定成这样project/ ├── app/ │ ├── __init__.py │ ├── main.py # 入口创建app实例 │ ├── config.py # 配置管理 │ ├── models/ # Pydantic数据模型 │ │ └── schemas.py │ ├── routers/ # 路由分组 │ │ ├── chat.py │ │ └── health.py │ ├── services/ # 业务逻辑 │ │ └── llm_service.py │ └── utils/ # 工具函数 ├── requirements.txt ├── .env └── run.py这个结构的好处是职责清晰routers只管接收请求和返回响应services管具体调用模型的逻辑models管数据校验。后期加功能的时候改哪一层很明确不会出现一个文件几千行的情况。main.py的核心内容from fastapi import FastAPI from app.routers import chat, health app FastAPI(titleLLM Service, version1.0.0) app.include_router(health.router, prefix/api) app.include_router(chat.router, prefix/api)chat.py里定义一个对话接口from fastapi import APIRouter from pydantic import BaseModel from app.services.llm_service import chat_with_model router APIRouter() class ChatRequest(BaseModel): prompt: str max_tokens: int 512 temperature: float 0.7 class ChatResponse(BaseModel): answer: str tokens_used: int router.post(/chat, response_modelChatResponse) async def chat(req: ChatRequest): result await chat_with_model(req.prompt, req.max_tokens, req.temperature) return ChatResponse(answerresult[text], tokens_usedresult[tokens])启动命令uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload--reload只在开发时用生产环境必须去掉否则文件变动会触发重启请求直接断掉。3.3 uvicorn日志丢失问题我排查了整整一个下午关键词里有人搜uvicorn fastapi 日志丢失问题这个坑我踩得刻骨铭心。现象是本地print和logging都正常输出一放到服务器上用systemd托管日志就只剩uvicorn的访问日志应用自己的日志全没了。根因是Python的logging模块和uvicorn的日志配置冲突。uvicorn启动时会重新配置root logger把已有的handler清掉。解决办法是在应用启动时显式配置日志并且禁用uvicorn的默认日志配置import logging from logging.config import dictConfig dictConfig({ version: 1, disable_existing_loggers: False, formatters: { default: { format: %(asctime)s - %(name)s - %(levelname)s - %(message)s } }, handlers: { console: { class: logging.StreamHandler, formatter: default }, file: { class: logging.handlers.RotatingFileHandler, filename: app.log, maxBytes: 10485760, backupCount: 5, formatter: default } }, root: { level: INFO, handlers: [console, file] } })启动时加--no-use-colors和显式指定log config或者干脆在代码里配置好让uvicorn别插手。这个问题的关键是理解谁最后配置root logger谁说了算。4. 大模型接入从调API到自己部署4.1 先用免费API跑通链路别一上来就折腾部署我见过太多人一上来就想本地部署大模型结果卡在显卡驱动、CUDA版本、显存不足上热情直接耗尽。我的建议是先用现成的API把整个业务链路跑通确认接口设计、前端交互、数据处理都没问题再考虑本地化部署。调用API的代码非常简单以OpenAI兼容接口为例import httpx async def chat_with_model(prompt: str, max_tokens: int, temperature: float): async with httpx.AsyncClient(timeout60.0) as client: resp await client.post( https://api.example.com/v1/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: your-model-name, messages: [{role: user, content: prompt}], max_tokens: max_tokens, temperature: temperature } ) data resp.json() return { text: data[choices][0][message][content], tokens: data[usage][total_tokens] }这里用httpx而不是requests因为httpx原生支持async和FastAPI的异步体系匹配。用requests的话会把事件循环阻塞住并发能力直接归零。4.2 Ollama本地部署消费级显卡也能跑起来链路跑通之后如果数据敏感或者想省API费用就可以考虑本地部署。Ollama是目前门槛最低的方案Windows、Linux、Mac都有安装包装完一条命令就能拉模型ollama pull qwen2.5:7b ollama run qwen2.5:7b7B参数的模型量化后大概占4到5GB显存一张RTX 3060 12G就能跑。如果显存更小可以选3B或1.5B的版本。Ollama默认在11434端口提供HTTP服务FastAPI调用它和调用云端API几乎一样async def chat_with_ollama(prompt: str): async with httpx.AsyncClient(timeout120.0) as client: resp await client.post( http://localhost:11434/api/generate, json{ model: qwen2.5:7b, prompt: prompt, stream: False } ) return resp.json()[response]注意Ollama的接口格式和OpenAI不兼容字段名不一样。如果想让代码统一可以在Ollama前面套一层OpenAI兼容的代理或者自己在service层做适配。提示Ollama首次加载模型会比较慢之后会常驻内存。如果服务器内存紧张可以设置OLLAMA_KEEP_ALIVE环境变量控制模型卸载时间。4.3 企业私有化部署要考虑的三件事如果是要在企业内网部署光跑起来不够还得考虑第一并发能力。单张显卡同时处理多个请求会排队需要做请求队列或者多实例负载均衡。我一般会在FastAPI层加一个信号量控制并发数超过就返回繁忙而不是让请求堆积。第二模型版本管理。不同业务可能用不同模型需要一个模型注册表来管理模型名称、路径、显存占用、加载状态。我见过有人把模型路径硬编码在代码里换模型要改代码重新部署非常低效。第三监控和限流。大模型推理是重资源操作必须有token级别的用量统计和限流。我通常会在service层记录每次请求的输入输出token数写入数据库方便后续做成本核算和容量规划。5. 微调入门不是所有场景都需要微调5.1 先搞清楚提示词工程、RAG、微调的边界很多人一上来就问怎么微调但实际上大部分需求用提示词工程或者RAG就能解决。我整理了一个判断标准场景特征推荐方案原因模型不懂你的业务术语提示词工程在prompt里给定义即可需要引用大量文档RAG检索增强无需改模型输出格式总是不对提示词few-shot给几个例子就能纠正特定领域风格差异大微调需要改变模型行为模式数据不能出内网本地部署RAG微调成本高RAG更灵活我的经验是先试提示词再试RAG最后才考虑微调。微调需要准备高质量数据集、租用GPU、调参、评估周期通常以周计而且效果不一定比RAG好。5.2 微调数据准备质量远比数量重要如果确定要微调数据准备是决定成败的关键。我做过一次客服对话风格的微调最初准备了5000条数据效果很差。后来精简到800条高质量对话效果反而明显提升。数据格式一般是JSONL每行一条{instruction: 用户问如何重置密码, input: , output: 您可以在登录页点击忘记密码输入注册邮箱后会收到重置链接。}数据清洗的要点去掉重复、去掉格式错误的、去掉答案明显有问题的。我一般会写个脚本做基础校验比如检查output字段长度是否合理、是否包含乱码、是否和instruction明显不匹配。5.3 LoRA微调的实际操作现在主流做法是LoRA低秩适配只训练一小部分参数显存需求大幅降低。用peft库配合transformers一张24G显卡就能微调7B模型。核心代码框架from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments model AutoModelForCausalLM.from_pretrained(qwen2.5:7b, device_mapauto) tokenizer AutoTokenizer.from_pretrained(qwen2.5:7b) lora_config LoraConfig( r8, lora_alpha32, target_modules[qwen_proj, v_proj], lora_dropout0.1, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config)r是秩越大拟合能力越强但越容易过拟合一般4到16之间。lora_alpha通常设为r的2到4倍。target_modules指定要加LoRA的层不同模型名字不一样需要看模型结构。训练参数里learning_rate我一般用2e-4num_train_epochs用3到5batch_size根据显存调整。训练过程中要盯着loss曲线如果训练loss下降但验证loss上升就是过拟合了要减少epoch或者加dropout。6. 部署与打包让服务真正跑在生产环境6.1 Windows打包的坑关键词里有fastapi windows 打包我踩过这个坑。Windows上打包Python服务常见方案是PyInstaller但它对FastAPIuvicorn的支持不算完美经常出现找不到模块或者启动参数丢失的问题。我的做法是Windows上不打包成exe而是用NSSM把Python脚本注册成Windows服务。这样升级只需要替换代码文件不用重新打包。nssm install LLMService C:\Python311\python.exe -m uvicorn app.main:app --host 0.0.0.0 --port 8000 nssm set LLMService AppDirectory C:\projects\llm-service nssm start LLMService如果非要打包用--hidden-import把uvicorn的worker模块显式加进去否则运行时会报找不到模块。6.2 Linux生产部署systemd nginxLinux上我标准用systemd托管配置文件[Unit] DescriptionLLM FastAPI Service Afternetwork.target [Service] Userappuser WorkingDirectory/opt/llm-service ExecStart/opt/llm-service/venv/bin/uvicorn app.main:app --host 127.0.0.1 --port 8000 --workers 2 Restartalways RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target--workers 2开两个进程配合nginx做反向代理和静态文件服务。nginx配置里要注意proxy_read_timeout要设大一点大模型推理可能几十秒才返回默认60秒容易超时。location /api/ { proxy_pass http://127.0.0.1:8000; proxy_read_timeout 300s; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }6.3 我踩过的部署坑清单端口占用重启服务时旧进程没退干净新进程起不来。用lsof -i:8000查一下或者systemd配置里加KillModemixed。环境变量丢失systemd不会继承shell的环境变量.env文件要在代码里用python-dotenv显式加载。文件权限服务以appuser运行模型文件如果放在root目录下会读不到权限要提前设好。显存泄漏长时间运行后显存不释放一般是推理代码里有循环引用。定期重启服务是最简单的缓解方案。7. 这两年的几点真实体会从运维转到大模型全栈最大的变化不是技术栈而是思维方式。运维追求的是稳定、可预测、不出意外而大模型开发充满了不确定性——同样的输入模型可能给出不同输出这在运维思维里是不可接受的但在AI应用里是常态。你得学会和这种不确定性共处用评估指标、日志、用户反馈来持续迭代而不是指望一次上线就完美。另一个体会是别追求把每个环节都学透再动手。我一开始想先把深度学习理论学明白再写代码结果看了两周论文就放弃了。后来改成先跑通一个最小demo遇到问题再补理论效率高得多。比如我不懂attention机制但我知道怎么调API我不懂LoRA的数学原理但我知道怎么配参数。理论可以慢慢补但动手不能停。最后说个实际的这两年我最大的收获不是某个具体技术而是建立了一套从需求到上线的完整闭环能力。能自己搭环境、写接口、接模型、做部署、看监控这种全栈能力在团队里非常稀缺。如果你也在转型路上别怕起点低运维出身的人对系统和部署的理解恰恰是很多纯算法背景的人欠缺的。把这块优势发挥出来路会越走越宽。