为什么要在本地部署 InternLM
InternLM 是面向中文场景优化的大模型系列，广泛应用于知识问答、文本生成、代码辅助、智能客服原型构建以及企业内部文档检索等任务。相比调用在线接口，本地安装的核心优势在于数据可控、网络依赖低、便于二次开发，尤其适合教学机房、实验室服务器和企业内网环境。需要明确的是，本地部署并非开箱即用，显卡驱动、CUDA 版本、Python 依赖、模型权重以及服务权限都可能影响最终效果，尤其在多人共用一台服务器时，权限边界和资源管理比单用户安装更为关键。
安装前的硬件与系统准备
部署前需确认服务器配置。基础推理建议使用 Linux 系统，常见发行版均可；CPU 推荐多核心，内存至少 32 GB，显卡显存则取决于模型规模与量化方式。较小模型可在单卡上运行，较大模型需要更高显存或多卡并行。磁盘方面，模型文件、缓存和日志会持续增长，建议预留 100 GB 以上空间，并将模型目录放置在容量充足的独立数据盘中。
软件层面需确保显卡驱动正常，可通过 nvidia-smi 查看显卡状态、驱动版本和显存占用情况。Python 建议使用 3.10 左右的稳定版本，通过 Conda 或 Miniconda 管理环境，避免与系统 Python 混用。若服务器已存在多个 AI 项目，强烈建议为 InternLM 单独创建环境，例如环境名设为 internlm-env，后续升级、回滚和排查会更加清晰。
创建运行环境与安装依赖
第一步是创建独立环境。执行 conda create -n internlm-env python=3.10，然后使用 conda activate internlm-env 进入环境。第二步安装 PyTorch，版本需与本机 CUDA 环境匹配。不要盲目复制他人安装命令，应参考 PyTorch 官方页面给出的组合，确保 torch 能识别 GPU。安装后可通过 python -c "import torch;print(torch.cuda.is_available())" 检查是否可用。
第三步获取 InternLM 相关代码与依赖。从官方代码仓库拉取项目，再进入目录安装 requirements。若仅做推理服务，通常还会用到 transformers、accelerate、sentencepiece、einops 等依赖；若需高性能推理，可能还需要配置 vLLM、LMDeploy 或其他推理框架。安装过程中若出现编译失败，优先检查 Python 版本、CUDA 版本、gcc 版本以及 pip 源，而不是反复强制重装。
模型文件下载与目录规划
模型权重应从可信来源获取，并核对模型名称、版本、授权说明和文件完整性。建议建立统一目录，例如 /data/models/internlm 用于存放权重，/data/apps/internlm 用于存放代码，/data/logs/internlm 用于存放日志。不要把大模型文件放在个人主目录下，否则多人使用时容易出现路径混乱、误删和容量不可控的问题。
下载完成后，可用最小脚本进行加载测试。测试目标并非追求速度，而是确认模型路径、依赖版本、显存占用和基础问答是否正常。若加载时报显存不足，可尝试更小模型、量化版本、降低上下文长度，或改用支持张量并行的推理框架。若报找不到配置文件，通常是模型目录层级不正确或下载不完整。
单用户推理服务配置思路
在单用户场景中，可先使用命令行推理验证模型，再封装为 HTTP 服务。服务启动参数通常包括模型路径、监听地址、端口、最大上下文长度、并发数、显存利用率等。测试阶段建议仅监听本机地址，确认接口稳定后再开放给内网调用。日志必须开启，至少记录启动参数、错误堆栈、请求耗时和显存异常，便于后续定位问题。
若采用 systemd 托管服务，可创建专用启动文件，指定工作目录、环境变量和启动命令。这样服务器重启后服务可自动恢复，也能统一用 systemctl start、stop、restart 管理。生产或准生产环境不建议直接在终端中长期运行命令，一旦会话中断，服务可能退出，排查也不方便。
多用户权限配置的核心原则
多人共用 InternLM 时，权限配置应遵循三条原则：模型文件集中管理、运行服务使用专用账号、普通用户只获得必要权限。不要让所有人都使用 root，也不要把模型目录设置为任何人可写。推荐创建一个服务账号，例如 internlm-svc，用于启动推理服务；创建一个用户组，例如 internlm-users，用于允许指定成员读取模型和调用工具。
目录权限可按用途区分。模型目录建议属主为服务账号，属组为 internlm-users，权限设为 750 或 755，普通成员只读，避免误改权重文件。日志目录可由服务账号写入，运维人员读取。上传数据、临时文件和个人实验结果应放在用户自己的工作目录或单独的共享实验目录中，不应混放在模型目录内。
参考权限配置步骤
可先创建用户组：groupadd internlm-users。再创建服务账号：useradd -r -m -s /usr/sbin/nologin internlm-svc。将需要使用服务的成员加入用户组，例如 usermod -aG internlm-users user01。随后设置目录归属：chown -R internlm-svc:internlm-users /data/models/internlm /data/apps/internlm。模型目录可执行 chmod -R 750 /data/models/internlm，应用目录可根据是否允许协作开发设为 750 或 770。
若普通成员只需要调用接口，无需进入服务器操作模型文件，就不必授予模型目录读取权限，只需在业务系统层面分配访问凭据。若成员需要运行自己的实验环境，应要求其在个人 Conda 环境中安装依赖，不要直接修改公共环境。公共环境只用于稳定服务，实验环境用于测试新版本，两者分开能显著降低故障扩散。
资源隔离与并发管理
多用户环境中最常见的问题不是安装失败，而是显存被抢占。建议约定显卡使用规则，例如通过 CUDA_VISIBLE_DEVICES 指定可见显卡，或在任务提交平台中分配资源。若没有统一调度系统，也应建立使用登记和空闲检查流程，避免多个大模型同时加载导致服务崩溃。
对于长期服务，建议固定使用指定 GPU，并限制最大并发、最大输入长度和单次生成长度。对临时实验任务，可设置运行时长和日志保留策略。不要允许普通用户随意启动占满全部显卡的服务，也不要将对外接口直接暴露在不可信网络中。接口层应增加鉴权、限流和访问日志，防止资源被异常消耗。
升级、回滚与版本管理
InternLM 及其推理框架迭代较快，升级前要先记录当前版本，包括代码提交号、Python 包列表、模型版本、启动参数和配置文件。推荐用独立目录保存新版本，例如 internlm-v1、internlm-v2，通过软链接 current 指向当前线上版本。升级时先在测试端口启动新服务，完成基础问答、长文本、并发和异常输入测试后，再切换正式服务。
回滚方案必须提前准备。最简单的方法是保留旧环境和旧模型路径，切换软链接后重启服务。如果使用 Conda，可导出环境依赖清单，出现兼容性问题时快速恢复。不要在正式环境中直接 pip install -U 大量依赖，这类操作看似省事，实则容易引入不可预期的版本冲突。
常见问题排查
一是 torch 无法识别 GPU。优先检查驱动、CUDA 匹配关系和环境变量，确认当前终端已进入正确 Conda 环境。二是加载模型时报内存或显存不足。可降低上下文长度、减少并发、使用量化模型，或选择更小参数规模。三是接口能启动但回答很慢。需要检查是否实际使用 GPU、是否启用了低效精度、磁盘是否过慢，以及是否有其他进程占用显存。
四是多人使用时权限报错。通常是目录属主、属组或执行权限设置不完整。Linux 目录需具备执行权限才能进入，即使文件有读权限也可能无法访问。五是服务重启后找不到模型。多半是 systemd 中的工作目录、环境变量或用户权限与手动启动时不同，应查看服务日志而不是只看终端测试结果。
安全边界与实用建议
InternLM 可用于提升文本处理效率，但不应把未审核的敏感业务数据随意导入测试环境。企业内部使用时，应明确数据保存周期、日志脱敏规则和访问人员范围。模型输出也需要人工复核，特别是涉及合同、医疗建议、财务分析、合规说明等高风险内容时，不能把生成结果直接当作最终结论。
实际落地时，建议采用“先单机验证、再服务化、再多人开放”的节奏。第一阶段只验证模型能否稳定运行；第二阶段固定启动脚本、日志和端口；第三阶段再引入用户组、服务账号、限流、监控和回滚机制。这样既能减少安装门槛，也能避免多人环境中因权限混乱、版本漂移和资源争用造成的反复故障。
