1.1 Linux发行版选择与AI开发场景适配
我刚开始搞Linux AI开发的时候，第一个纠结就是选哪个发行版。Ubuntu用的人多，教程一搜一大把，NVIDIA驱动和CUDA的文档也最全。我的笔记本装的是Ubuntu 22.04，台式机试过Fedora，服务器上跑的是CentOS Stream。每种发行版都有自己的脾气，Ubuntu的apt源里NVIDIA驱动版本更新快，Fedora的dnf也能装，但有些CUDA版本要手动处理依赖。团队里有人偏爱Arch，滚动更新，内核新，对最新显卡支持好，可稳定性得自己多操心。
从AI开发场景看，个人学习、小团队实验、公司生产环境需求不一样。个人学习选Ubuntu LTS最省心，遇到问题社区答案多。公司生产环境可能用RHEL或Ubuntu Server，长期支持，安全更新有保障。我见过有人用Debian，稳定是稳定，但NVIDIA驱动得用官方runfile，麻烦一点。云服务器上，很多厂商提供预装好CUDA的Ubuntu镜像，开箱即用，省去很多折腾。
我的建议是，新手从Ubuntu 22.04或24.04 LTS开始。别一上来就追求极简或最新，AI开发环境依赖多，发行版太偏门会浪费大量时间在编译和找包上。等熟悉了，再根据团队规范或硬件特性换别的。我自己的主力开发机就是Ubuntu，远程服务器也是Ubuntu Server，统一起来，脚本和文档都能复用。
1.2 硬件检查、NVIDIA驱动、CUDA与cuDNN安装配置
装驱动前，我习惯先跑一遍硬件检查。lspci | grep -i nvidia看看显卡认没认出来，nvidia-smi看驱动有没有。新机器装完Ubuntu，默认开源驱动nouveau会挡着NVIDIA驱动。我一般直接进BIOS关Secure Boot，省得签名麻烦。加Graphics Drivers PPA，apt install nvidia-driver-535或者更新的版本。装完重启，nvidia-smi能出表格，显示显卡型号、驱动版本、CUDA版本，这步成了，后面就顺了。
CUDA和cuDNN的安装，我踩过不少坑。官方推荐用runfile，但我觉得apt更干净。Ubuntu的NVIDIA CUDA源里，cuda-toolkit-12-3这种包，安装后要配PATH和LD_LIBRARY_PATH。cuDNN现在可以用apt装，libcudnn8和libcudnn8-dev，版本要和CUDA对应。我试过用conda装cudatoolkit，方便但版本可能滞后。生产环境我还是用系统级安装，稳定，Docker里也容易复现。
从多用户服务器角度看，驱动和CUDA最好全局装一次，别每个用户自己折腾。我用过一台8卡A100的服务器，系统装好Ubuntu Server，NVIDIA驱动用官方的.run文件，CUDA用runfile装到/usr/local/cuda-12.2，做个软链接/usr/local/cuda。cuDNN解压复制到CUDA目录。这样所有用户都能用，环境变量在/etc/profile.d里设好。注意驱动版本和CUDA版本有兼容矩阵，别乱配，否则nvidia-smi能跑，但PyTorch报错找不到CUDA。
1.3 Python、Conda、pip与虚拟环境管理
Python版本管理，我强烈推荐Miniconda。系统自带的Python别动，AI项目依赖复杂，用conda建独立环境最干净。我一般装Miniconda3到用户目录，conda create -n ai python=3.10。为什么是3.10？PyTorch和TensorFlow对3.10支持好，3.11、3.12有些包还没跟上。conda环境里，pip和conda混用要小心，我习惯先用conda装大包，比如pytorch、cudatoolkit，再用pip装剩下的。
虚拟环境管理，有人喜欢venv加pip，轻量。我试过，但遇到需要特定CUDA版本时，conda能直接装cudatoolkit，省去系统CUDA依赖。团队协作时，我导出environment.yml，别人conda env create -f就能复现。pip的requirements.txt也重要，但遇到版本冲突，conda的解析器更强。我现在的做法是，conda管Python和CUDA相关，pip管纯Python包，两个都记录。
从CI/CD角度，虚拟环境要可自动化创建。我在GitHub Actions里用conda-incubator/setup-miniconda，指定environment.yml，跑测试。本地开发用conda，部署用Docker，Dockerfile里也用Miniconda。注意conda的base环境别乱装东西，保持干净。我见过有人把base搞崩，所有环境都受影响。还有pip的缓存，国内用清华源或阿里源，速度飞快。conda也换国内源，不然下载大包能等到睡着。
1.4 PyTorch、TensorFlow等AI框架安装与验证
PyTorch安装，我认准官方命令。去pytorch.org，选好CUDA版本，复制conda install命令。比如conda install pytorch torchvision torchaudio pytorch-cuda=12.1 -c pytorch -c nvidia。装完进Python，import torch，torch.cuda.is_available()返回True，torch.cuda.get_device_name(0)显示显卡型号，这就算成了。我还会跑个小测试，torch.randn(3,3).cuda()，看能不能正常运算。TensorFlow 2.x用pip install tensorflow[and-cuda]，但版本和CUDA对应严格，我一般用conda装，省心。
从多框架共存角度，一个环境里同时装PyTorch和TensorFlow容易打架。我习惯分开建环境，pytorch-env和tf-env。如果非要一起，注意CUDA和cuDNN版本要同时满足两者，通常很难。我试过用Docker，每个框架一个容器，互不干扰。验证安装时，除了import，还要看版本号，torch.version，tf.version。有时候pip装完，numpy版本不兼容，报一堆错，降级numpy就好。
从源码编译角度，有些新显卡或特殊算子需要自己编译PyTorch。我编译过一次，花了两个小时，还得配好CUDA、cuDNN、NCCL。编译完的wheel可以团队共享。普通用户别折腾，直接用官方预编译包。TensorFlow也有nightly版，但生产环境用稳定版。验证时，我还会跑一个简单的MNIST训练，看loss能不能降，GPU利用率有没有上去。这比单纯import更靠谱。
1.5 Docker、NVIDIA Container Toolkit与容器化开发环境
Docker彻底改变了我的AI开发方式。以前每台机器都要装驱动、CUDA、cuDNN、Python、框架，现在只要装好NVIDIA驱动，Docker里跑一切。NVIDIA Container Toolkit是桥梁，让容器能访问GPU。安装很简单，加NVIDIA的apt源，apt install nvidia-container-toolkit，nvidia-ctk runtime configure --runtime=docker，重启docker。跑个nvidia/cuda:12.3.0-base-ubuntu22.04，里面nvidia-smi能出结果，就通了。
容器化开发环境，我一般用Dockerfile定义。基础镜像选nvidia/cuda，装Miniconda、PyTorch、项目依赖。构建一次，到处运行。团队里每个人用同一个镜像，环境差异没了。开发时，用-v挂载代码目录，-p映射Jupyter端口，--gpus all分配GPU。我习惯用docker compose，把JupyterLab、TensorBoard、数据库都编排好。生产部署也用容器，Kubernetes调度，方便扩缩容。
从多用户服务器角度，Docker加NVIDIA Container Toolkit让资源隔离更简单。每个用户跑自己的容器，指定GPU，互不干扰。管理员装好驱动和toolkit，用户不用sudo就能跑GPU容器。注意容器里别装驱动，用宿主机的。我见过有人在容器里装驱动，导致冲突。还有共享内存，PyTorch的DataLoader多进程需要--shm-size调大，不然报错。这些细节在Docker run时加上就好。
1.6 VS Code Remote、JupyterLab、SSH与远程开发配置
我大部分AI开发在远程服务器上，本地笔记本只是终端。SSH是基础，配好免密登录，ssh-keygen生成密钥，ssh-copy-id到服务器。VS Code Remote-SSH插件让我在本地编辑远程代码，就像本地一样。装好Remote-SSH，连上服务器，打开项目目录，装Python插件、Jupyter插件，直接调试。这个体验比vim好太多，代码补全、跳转、git都方便。我还会在远程跑JupyterLab，本地浏览器访问，适合做数据探索和可视化。
JupyterLab的配置，我一般用--ip=0.0.0.0 --port=8888 --no-browser，SSH端口转发到本地。这样不用暴露公网端口，安全。VS Code里也能直接连Jupyter内核，选远程服务器的conda环境。团队协作时，我把JupyterLab跑在Docker容器里，每人一个实例，通过JupyterHub管理。SSH隧道加VS Code Remote，是我最常用的组合，写代码、跑实验、看结果一气呵成。
从安全角度，SSH别用密码登录，用密钥。改默认端口，装fail2ban。JupyterLab设token或密码，别裸奔。我见过有人把Jupyter开到公网，被挖矿。VS Code Remote走SSH，本身安全。如果服务器在云上，安全组只开需要的端口。本地开发机连公司内网服务器，用VPN或跳板机。这些配置一次，后面省心。我还会把常用的SSH config写下来，Host别名，方便切换。
1.7 GPU资源监控、性能测试与常见故障排查
日常监控GPU，nvidia-smi最常用。watch -n 1 nvidia-smi，看显存、利用率、温度、功耗。nvtop更直观，像htop一样。gpustat轻量，适合脚本里用。我还会用nvidia-smi --query-gpu=... --format=csv定时采集，存到文件，画图分析。多卡机器，nvidia-smi topo -m看卡间互联，NVLink还是PCIe，对分布式训练影响大。显存泄漏时，nvidia-smi看不到进程，用fuser -v /dev/nvidia*查。
性能测试，我跑PyTorch的benchmark，比如torch.utils.benchmark，测矩阵乘、卷积。还会跑一个实际模型，ResNet50，看每秒处理多少图片。GPU利用率低，可能是数据加载瓶颈，用nvidia-smi dmon看。或者CPU瓶颈，用htop看。常见故障：CUDA out of memory，减小batch size，或者用torch.cuda.empty_cache()。驱动版本不匹配，nvidia-smi和nvcc --version不一致，重装驱动。cuDNN报错，版本不对，换对应版本。
从故障排查角度，我习惯先看日志。PyTorch报错会提示CUDA error，具体到哪一行。TensorFlow有TF_CPP_MIN_LOG_LEVEL控制日志级别。Docker里跑，nvidia-container-cli -k -n list看GPU挂载。我遇到过容器里nvidia-smi正常，但PyTorch找不到GPU，原因是容器里没装nvidia-container-toolkit的runtime，或者--gpus没指定。还有NCCL错误，多卡通信超时，调NCCL_DEBUG=INFO看详情。这些坑踩多了，就有经验了。
1.8 环境备份、依赖锁定与可复现实验实践
环境备份，我定期导出conda环境。conda env export > environment.yml，但注意里面包含conda和pip的包，有时平台相关。更干净的做法是conda list --explicit > spec-file.txt，或者pip freeze > requirements.txt。Docker镜像本身就是最好的备份，docker save -o myimage.tar。我还会把重要的数据集、模型权重备份到NAS或云存储。实验代码用git管理，每次实验打tag，记录commit hash。
依赖锁定，我推荐用pip-tools或者poetry。pip-compile生成requirements.txt，带哈希。conda-lock也能锁定跨平台。团队协作时，大家用同一个锁文件，环境一致。我见过numpy小版本不同，实验结果对不上。可复现实验，除了代码和依赖，还要固定随机种子，torch.manual_seed，numpy.random.seed，cudnn.deterministic=True。记录硬件型号、驱动版本、CUDA版本，这些都会影响结果。
从论文复现角度，很多AI论文提供代码和requirements，但没锁版本。我一般先建个干净环境，按requirements装，跑不通就调版本。用Docker复现最省事，作者如果提供Dockerfile，直接构建。我自己的项目，除了Dockerfile，还会写个Makefile，一键搭环境、跑实验、出结果。实验记录用MLflow或Weights & Biases，记录超参数、指标、模型。这样半年后回头看，还能复现。
2.1 本地部署硬件需求、显存预算与成本评估
我折腾本地大模型，第一件事就是看显存。7B模型量化到4bit，大概占4到6GB显存，13B要8到12GB，70B没40GB以上根本跑不动。我手头有张RTX 3090，24GB显存，跑Qwen 7B的GPTQ版本很轻松，跑13B的AWQ也够。内存也不能小，模型加载时要把权重读进RAM，我一般配64GB。硬盘用NVMe，加载速度比SATA快很多，尤其是第一次读模型文件。
成本这块我算过账。买一张4090要一万多，租云GPU每小时几块钱，短期试验租划算，长期跑还是自己买。电费别忽略，3090满载350W，一天跑十小时，一个月电费不少。二手卡便宜但有风险，我买过一张矿卡，跑了一个月就花屏。团队里用多卡服务器，成本分摊，管理也方便。个人学习用Ollama跑小模型，显存要求低，先玩起来再说。
从不同场景看，个人开发者用消费级卡加量化模型，完全能跑通本地问答。公司生产环境要考虑并发，显存预算得翻倍，vLLM部署70B模型至少两张A100 80GB。显存不够时，llama.cpp能用CPU加GPU混合推理，速度慢但能跑。量化是省显存的核心手段，后面会细说。我建议先明确自己的模型大小和并发量，再决定硬件。
2.2 开源大模型选择、许可证确认与模型下载加速
选模型我一般看任务和语言。中文场景优先Qwen、ChatGLM、Baichuan，英文用Llama 3、Mistral、Gemma。代码生成用DeepSeek Coder或CodeLlama。许可证得仔细看，Apache 2.0最省心，商用没限制。Llama的社区许可证有月活门槛，公司用要确认合规。我见过有人拿了非商用模型做产品，被法务叫停。下载模型去Hugging Face，国内网络经常断，得用镜像。
下载加速我常用几种办法。Hugging Face加环境变量HF_ENDPOINT=https://hf-mirror.com，速度能上来。或者用modelscope的snapshot_download，国内节点快。git lfs也能拉，但大模型文件几十GB，容易中断。我习惯用huggingface-cli download，支持断点续传。团队内网可以建个缓存服务器，一次下载大家用。下载完记得校验文件哈希，防止损坏。
许可证确认不是小事。我每次下模型前看model card，找License那一栏。有些模型写着“仅供研究”，那就别商用。公司项目我会把许可证截图存档，法务过一遍。个人学习随便用，但分享微调后的模型也要注意原许可证。开源社区有些模型训练数据来源不明，商用风险自己担。我一般选许可证清晰的模型，省得后面麻烦。
2.3 模型格式、量化原理与GGUF、GPTQ、AWQ转换
模型格式我接触过好几种。PyTorch的bin文件加载慢，safetensors更安全更快。GGUF是llama.cpp专用格式，CPU推理友好。GPTQ和AWQ是GPU量化格式，显存占用低。我下载模型时先看有没有现成的GGUF或GPTQ，没有就自己转。safetensors是现在的主流，Hugging Face上大部分模型都提供。
量化原理说简单点，就是把FP16的权重压成INT4或INT8，减少显存和计算量。GGUF有Q4_K_M、Q5_K_S等多种量化等级，数字越小压缩越狠，精度损失越大。GPTQ用校准数据集来最小化量化误差，AWQ考虑激活值分布，效果通常更好。我转过Qwen 7B的GGUF，用llama.cpp的convert脚本先转FP16，再quantize成Q4_K_M。GPTQ用AutoGPTQ，需要准备校准文本。
转换实践里，校准集很关键。我用中文维基或自己领域的文本做校准，效果比随机文本好。AWQ转换用AutoAWQ，速度比GPTQ快。转换后一定要测试，跑几个问题看回答质量。我对比过Q4_K_M和Q5_K_M，后者显存多1GB，但回答更稳。量化不是越狠越好，得在显存和效果之间找平衡。转换脚本网上都有，跟着做就行。
2.4 llama.cpp、Ollama、vLLM等推理引擎对比与部署
llama.cpp是我最早玩的推理引擎。它用C++写的，编译简单，make一下就行。支持CPU和GPU混合，GGUF模型直接加载。我拿它跑Qwen 7B Q4，速度能接受。Ollama把llama.cpp封装得更友好，curl安装，ollama run qwen，自动下载模型。新手用Ollama最省事，不用管编译和依赖。我给我朋友推荐Ollama，他十分钟就跑起来了。
vLLM是另一个路子，专注GPU高并发。它用PagedAttention管理显存，吞吐量比Hugging Face的generate高好几倍。部署也简单，pip install vllm，然后起个API服务。我压测过vLLM跑Llama 3 8B，并发10路请求，延迟很低。生产环境我首选vLLM，配合Kubernetes做扩缩容。TGI也是类似定位，但vLLM社区更活跃，更新快。
选哪个看场景。个人玩模型，Ollama够了。开发调试，llama.cpp灵活，能改参数。公司生产，vLLM或TGI，要的是吞吐和稳定。我团队里统一用vLLM，模型格式用GPTQ或AWQ，部署在Docker里。llama.cpp偶尔用来做CPU fallback。别纠结哪个最好，先跑起来，再根据瓶颈换。
2.5 本地WebUI、OpenAI兼容API与客户端接入
本地WebUI我用过几个。text-generation-webui功能全，但配置略复杂。Open WebUI界面像ChatGPT，连Ollama很方便。SillyTavern适合角色扮演。我日常用Open WebUI，Docker起一个，连上本地Ollama，浏览器就能聊天。团队里给非技术同事用，他们很快上手。WebUI的好处是可视化调参数，温度、top_p、最大长度都能改。
OpenAI兼容API是集成的关键。vLLM自带openai接口，起服务后base_url填http://localhost:8000/v1。Ollama也有兼容层，端口11434。我写个小脚本，用openai库调用本地模型，代码和调GPT一样。LangChain、LlamaIndex都支持自定义base_url。这样本地模型能接入各种客户端，比如ChatGPT-Next-Web、Continue、沉浸式翻译。
从团队角度看，统一API网关很重要。我们用一个Nginx做反向代理，加API key鉴权，再路由到不同模型。WebUI给产品经理试玩，API给开发调。客户端接入时注意流式输出，vLLM默认支持。我配过Continue插件，写代码时自动补全，用本地模型，数据不出内网。这些集成让本地大模型真正用起来。
2.6 私有知识库RAG、向量数据库与文档问答集成
私有知识库RAG是我觉得最实用的方向。把公司文档切块，用embedding模型转成向量，存进向量数据库。问问题时，先检索最相关的块，拼进prompt让大模型回答。向量数据库我用过Chroma、Milvus、Qdrant。Chroma最轻量，pip装完就能用，适合个人和小团队。Milvus功能强，但部署复杂。Qdrant性能好，Rust写的。
集成用LangChain或LlamaIndex。我习惯用LlamaIndex，文档加载器多，切块策略灵活。embedding模型用BGE或M3E，中文效果好。生成模型用本地Qwen 7B，Ollama跑。问答时，检索top 3块，拼接历史对话，发给模型。效果好坏看切块大小，我一般设512字符，重叠50。检索用余弦相似度。
我搭过公司内部文档问答。文档是PDF和Word，用Unstructured解析，Chroma存向量。前端用Open WebUI加知识库插件。权限控制要小心，不同部门只能看自己的文档。更新文档时重新embedding。RAG不是万能，复杂推理问题回答不好。但事实性问答很准，比直接问模型可靠。
2.7 LoRA微调、模型合并与效果验证
LoRA微调让我能在单卡上定制模型。原理是冻结基座权重，只训练低秩矩阵。我用peft和transformers，7B模型微调，24GB显存够用。数据集准备成指令格式，比如“问题：... 回答：...”。LLaMA-Factory有Web界面，点几下就能开始。我微调过Qwen 7B，让它懂我们行业的术语。训练几小时，loss降到合理值。
微调完，把LoRA权重合并回基座。用merge_and_unload，保存成完整模型。合并后模型可以直接用vLLM加载。效果验证分自动和人工。自动跑测试集，看准确率、BLEU。人工看回答是否自然、是否符合领域。我对比过微调前后，领域问答准确率从60%提到85%。过拟合要注意，验证集loss上升就停。
从项目角度看，LoRA让模型快速适配。我们团队用LLaMA-Factory，非算法同事也能微调。数据集质量决定上限，我花很多时间清洗数据。合并后的模型可以量化，再部署。微调不是必须，通用模型加RAG也能解决很多问题。先试RAG，不够再微调。
2.8 并发性能优化、安全加固与长期运维
并发优化我主要调vLLM参数。gpu_memory_utilization设0.9，max_num_seqs设256，吞吐能上去。批处理大小根据显存调。量化模型比FP16快，显存也省。我压测用Locust，模拟多用户请求，看QPS和延迟。瓶颈常在KV cache，PagedAttention帮忙。多卡用张量并行，vLLM支持。我试过两张3090跑70B量化，速度勉强可用。
安全加固不能马虎。API加鉴权，用API key或JWT。HTTPS加密，Nginx配证书。限制访问IP，只内网。防提示注入，输入过滤。日志审计，记录谁问了什么。我见过本地模型被扫到公网，被人用来挖矿。防火墙设好，端口别乱开。模型权重也要保护，别放公开目录。
长期运维靠监控。Prometheus加Grafana，采集GPU利用率、显存、请求延迟。日志用Loki。模型更新要测试，别直接上生产。备份配置和向量库。团队值班，出问题能响应。我每月检查一次驱动和CUDA版本，看有没有安全更新。本地部署不是一劳永逸，得持续看着。
