联想这波转型方向其实已经写得很直白从“卖 PC、卖服务器的硬件厂商”逐步往“AI 基础设施公司”靠拢。这里最值得关注的点不是口号而是它要把哪一层做厚、做深。如果只看产品名称容易把这件事理解成“联想多卖了几款 AI 服务器”那实际意义就被低估了。真正要拆的是AI 基础设施到底包含哪些层联想在每一层的布局方式是什么对企业采购、私有化部署、开发测试和运维意味着什么。这篇文章就从技术架构视角把“联想向 AI 基础设施公司靠拢”这件事拆开看内容包括AI 基础设施的典型分层和核心组件联想围绕 AI 算力、存储、网络、平台软件的产品与技术路径面向企业私有化部署的混合 AI 架构思路从开发、测试、运维角度需要关注的关键技术点对比同类厂商时的判断维度落地过程中最容易踩的坑和合规边界。如果你正在做企业 AI 选型、私有化大模型部署或者关注基础设施层的机会这篇文章建议直接收藏。1. 核心能力速览AI基础设施到底包含什么先把概念对齐。所谓 AI 基础设施不是单指“一台带 GPU 的服务器”而是一整套支撑 AI 训练、微调、推理、数据流转和应用交付的技术栈。层级核心组件典型问题底层硬件GPU 服务器、AI 加速卡、存储阵列、高速网络、液冷散热算力够不够、显存容不下模型怎么办平台层容器平台、GPU 调度、资源池化、统一运维多卡训练如何分配、推理服务如何弹性伸缩模型层基础模型、微调框架、推理引擎、量化工具用什么模型、怎么压缩、怎么保证输出质量数据层数据清洗、向量数据库、知识库、RAG 检索私有数据怎么接入、效果如何溯源应用层AI Agent、智能体编排、业务系统对接场景是否真的跑通、ROI 是否为正联想向 AI 基础设施公司靠拢本质上是想把这张表里的“硬件 平台 数据 应用”串起来而不是停留在最底层的服务器整机销售。从公开信息看联想目前的核心叙事是“混合 AI”架构公共 AI、私有 AI 和个人 AI 的组合。对技术人来说这句话翻译过来就是——企业既可以使用公共大模型服务也能在本地部署私有化模型还能让终端设备AI PC / AI 工作站承担部分端侧推理任务。三种模式并存是当前企业级 AI 落地最现实的路径。2. 为什么硬件厂商都在往 AI 基础设施转过去十年服务器厂商的核心竞争力是“整机交付能力”CPU 选型、内存配置、硬盘组合、RAID 策略、散热设计。但 AI 时代改变了需求结构。2.1 客户不再只买硬件今天的客户问的问题变了这台服务器能跑多大参数的模型推理延迟是多少能不能满足生产环境能不能支持多机多卡分布式训练模型微调和数据怎么管出了问题谁来兜底这些问题里硬件只占 30%剩下 70% 是平台、模型工程和数据工程。如果厂商只卖裸机客户很难独立完成从采购到上线的全链路厂商的利润空间也会被软件和服务层蚕食。2.2 AI 算力需求从训练转向推理早期 AI 建设以训练为主客户买的是大规模 GPU 集群。但到了应用落地阶段推理需求增长更快。推理场景的特点是并发波动大、延迟要求严格、成本敏感。这对基础设施提出的要求是弹性调度推理服务能根据请求量扩展和缩容多模型共存一台机器同时服务多个轻量模型混合精度与量化用 FP16、INT8 等降低显存占用和推理成本冷热数据分层高频数据放缓存低频数据进对象存储。这些能力不能靠单机硬件完成必须有平台层软件支撑。这就是联想这类厂商必须往上走的原因。2.3 软硬一体化更容易交付客户要的不是“最好的 GPU 服务器”而是“能跑大模型的 AI 系统”。软硬一体化的好处是开箱即用预装驱动、容器运行时、推理引擎稳定性可控硬件、固件、驱动、平台版本统一验证运维闭环一套监控体系覆盖硬件和模型服务。所以“AI 基础设施公司”的本质是把交付物从“硬件”升级为“系统”。这一点对联想来说是转型方向对整个行业来说也是趋势。3. AI 基础设施的技术栈拆解这一节把 AI 基础设施按技术栈拆开每一层看技术选型和工程要点。这样对照联想的布局就能判断它真做了什么哪些环节仍然是短板。3.1 算力层GPU 服务器与集群设计算力层是联想最传统的强项。AI 服务器要关注的核心参数包括GPU 卡型与数量单机 4 卡、8 卡是主流配置高速互联NVLink 或同类卡间互联影响多卡训练效率机内拓扑CPU 与 GPU 之间的 PCIe 通道分配散热方案高密度 GPU 机柜必须考虑风冷还是液冷供电与机房承重AI 机柜单柜功率密度通常是传统机柜的数倍。工程上部署 AI 服务器时建议先做一次基础巡检# 查看 GPU 状态 nvidia-smi # 查看 GPU 卡间拓扑 nvidia-smi topo -m # 查看驱动与 CUDA 版本 nvidia-smi | grep CUDA Version如果发现 GPU 利用率低但显存占用高优先排查数据加载和 CPU 预处理是否成为瓶颈。3.2 平台层资源调度与容器化企业级 AI 基础设施平台层一般基于 Kubernetes 构建。核心工作是 GPU 资源调度。典型需求多团队共享 GPU 集群按任务优先级分配算力推理服务根据并发自动扩缩容训练任务支持多机多卡。Kubernetes 下调度 GPU 的常见做法# 声明需要 2 张 GPU 的 Pod 示例 apiVersion: v1 kind: Pod metadata: name: gpu-pod spec: containers: - name: gpu-container image: nvidia/cuda:12.2.0-base resources: limits: nvidia.com/gpu: 2如果平台层做得好用户只需要提交任务不需要关心具体跑在哪台机器上。这也是“AI 基础设施公司”和“AI 服务器厂商”最明显的分界点。3.3 模型层推理引擎与量化模型层是 AI 基础设施的差异化所在。联想在这块的思路是提供“经过验证的模型栈”企业拿到后能直接微调、部署而不是从零搭建。推理服务的关键指标指标含义建议观察方式首 Token 延迟用户发起请求到收到第一个 token 的时间API 返回耗时拆解Token 吞吐每秒生成的 token 数压测工具统计显存占用模型权重 KV Cache 激活值nvidia-smi 持续采样并发上限同时间服务的请求数压力测试确定降低推理成本的主流方案是量化如 INT8、FP8和 KV Cache 优化。要注意的是量化后必须做效果对比测试不能只看显存下降还要确认输出质量是否满足业务要求。3.4 数据层知识库与 RAG企业私有化 AI 落地的关键不是大模型本身而是“模型如何读到企业的私有知识”。RAG检索增强生成是目前最稳妥的方案上传文档PDF、Word、Markdown 等文本切分按章节或固定长度切片向量化Embedding 模型把文本转为向量存入向量库Milvus、FAISS、pgvector 等召回与重排根据用户问题检索相关内容生成回答把检索结果拼入提示词交给大模型生成。这里有一个容易忽略的工程点向量化结果的质量直接决定回答准确率。建议在正式上线前用业务常见问题集做一轮召回率测试而不是只测“能不能回答”。4. 企业私有化部署混合 AI 架构的落地路径联想给出的路线是混合 AI公共 AI、私有 AI、个人 AI 协同工作。这句话落到企业部署层面实际上对应三种部署模式。4.1 公共 AI按需调用外部大模型 API适合场景非敏感数据、通用问答、内容生成、短期验证。优点部署成本低按量付费模型迭代由服务方负责上手快无需 GPU 资源。缺点数据出域存在合规风险无法深度定制模型长期成本随调用量增长不可控。4.2 私有 AI本地部署推理服务适合场景研发代码、客户数据、财务信息、内部知识库等敏感内容。部署架构一般分为三部分推理服务部署开源模型或微调后的模型对外提供 OpenAI 兼容接口向量库与检索服务支撑 RAG 流程管理平台负责模型版本管理、服务监控、日志审计。启动一个本地推理服务的通用示例# 启动 OpenAI 兼容的推理服务以 vLLM 为例命令需按实际环境调整 python -m vllm.entrypoints.openai.api_server \ --model /models/your-chat-model \ --served-model-name local-chat \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --host 0.0.0.0 \ --port 8000启动后用 curl 验证服务是否可用curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local-chat, messages: [{role: user, content: 你好做一下自我介绍}] }4.3 个人 AI端侧推理这就是联想 AI PC 的定位。端侧推理的价值在于数据不出终端隐私性最强无需网络离线可用低延迟适合交互型场景。限制也很明显终端算力有限只能跑小参数模型通常是量化后的 7B 级别或更小复杂任务仍需云端协同。个人 AI 的典型使用方式是把端侧模型作为“入口”初步处理用户指令判断什么任务本地解决、什么任务上送云端。这种混合调度体验比“全拉上云”更符合企业办公场景。5. 面向企业内部测试环境一套验证流程不管联想的产品矩阵如何演进企业在决定采用前都需要用自己的业务数据做一轮验证。下面给出一套适合在私有化环境执行的验证流程重点观察“部署是否顺利、效果是否达标、资源是否可控”。5.1 环境准备清单检查项说明GPU 驱动按显卡型号安装对应版本驱动nvidia-smi能正常输出CUDA / 推理框架按模型要求安装注意 CUDA 版本与 PyTorch 的兼容关系磁盘空间模型权重 数据集 日志预留至少 100GB端口规划推理服务端口、向量库端口、管理平台端口避免冲突网络策略内网服务不建议直接绑定 0.0.0.0如需远程访问控制访问来源5.2 推理效果测试用例建议至少准备三类测试数据通用问答验证基础对话能力业务场景问答从真实业务文档中抽取问题敏感性测试确认模型不会泄露提示词之外的训练数据也不会生成越权内容。每一类准备 20 条以上测试问题逐条记录回答质量。判断标准包括回答是否准确是否忠于给定的业务文档遇到不确定问题是否坦率说明而不是编造回答是否稳定相同问题多次提问是否一致。5.3 资源占用观察方法持续采集 GPU 指标建议用如下命令周期采样# 每 5 秒记录一次 GPU 状态 watch -n 5 nvidia-smi # 或者保存到文件便于后续分析 nvidia-smi --query-gputimestamp,utilization.gpu,utilization.memory,memory.used \ --formatcsv -l 5 gpu_usage.log重点观察单请求峰值显存并发请求时显存是否溢出长时间运行后显存是否持续增长可能存在内存泄漏推理延迟是否随并发增加急剧恶化。5.4 批量任务与接口测试企业场景经常需要批量处理文档批量总结、批量提取、批量审核。这就涉及接口压测。用 Python 写一个简单的并发请求模板import requests from concurrent.futures import ThreadPoolExecutor url http://127.0.0.1:8000/v1/chat/completions def call_model(prompt): payload { model: local-chat, messages: [{role: user, content: prompt}], temperature: 0.7 } resp requests.post(url, jsonpayload, timeout120) return resp.json() # 示例并发 10 个请求观察耗时和成功率 prompts [f用一句话总结第{i}段内容 for i in range(10)] with ThreadPoolExecutor(max_workers10) as executor: results list(executor.map(call_model, prompts)) for r in results: if choices in r: print(r[choices][0][message][content][:80]) else: print(调用失败:, r)批量任务在正式生产前一定要加上任务队列和重试机制单条任务超时控制失败任务日志记录结果校验环节。6. 联想 AI 基础设施布局的观察维度回到标题本身联想不断向 AI 基础设施公司靠拢。作为技术读者我们不需要过度关注公司战略话术而应该关注四个观察维度。6.1 硬件产品线是否完整AI 基础设施需要的不只是 GPU 服务器还需要存储、网络、边缘设备和终端算力。联想本身有服务器、存储、工作站、PC 等产品线具备“全栈硬件”的基因。这一点与只做服务器的厂商有很大差异。6.2 软件和平台能力是否补齐硬件基因强不代表软件能力强。AI 基础设施的软件栈复杂度远高于传统 ITGPU 调度、模型生命周期管理、推理服务观测、数据安全管控每一块都需要长时间积累。判断联想是否“真的转型”要看它在平台层和模型层的投入能否形成可复制的交付能力。6.3 生态绑定深度AI 基础设施离不开芯片厂商和模型厂商的生态。联想与芯片厂商的合作深度、对开源模型生态的适配程度、对客户私有化环境的支持力度都会影响实际交付体验。6.4 客户成功案例是否可复制最直接的判断方式是看案例联想服务的客户是停留在“采购硬件”层面还是真正在它提供的基础设施上跑通了业务 AI 场景后者的比例越高说明基础设施公司的成色越足。7. 与同类厂商对比时的判断框架做技术选型时需要横向对比多家厂商。这里给一套不是结论、但可复用的对比框架对比维度关注点交付形态是纯硬件、软硬一体机还是云化服务模型支持是否覆盖主流开源模型是否支持私有模型接入部署方式是否支持本地私有化、混合云、纯公有云扩展性从单机到集群的扩展方式是否平滑运维复杂度日常监控、升级、扩容由谁负责合规能力数据主权、审计日志、访问控制是否完善服务边界是否包含模型微调、效果调优、人员培训这套框架同样适用于评估联想之外的任何 AI 基础设施供应商。对技术负责人来说最忌讳的是被“算力参数”带偏而忽略平台层和运维层的成熟度。8. 关键挑战与风险联想向 AI 基础设施转型方向明确但落地挑战不小。客观说几个风险点。8.1 软件生态的积累需要时间AI 基础设施的软件复杂度远超传统 IT。GPU 调度、推理优化、模型服务化、数据安全等能力需要大量真实客户场景打磨。软件能力的差距不是靠发布会可以抹平的需要持续迭代。8.2 大模型迭代节奏带来不确定性模型架构、推理引擎、量化方案都在快速变化。基础设施厂商的产品如果绑定某一代模型架构过深迭代周期跟不上很容易被新方案替代。这要求厂商对模型生态保持足够的敏感度。8.3 客户数据安全与合规压力企业私有化部署 AI 基础设施核心诉求是数据不出域。但这背后涉及模型训推过程中的数据审计、访问控制、操作日志、密钥管理等大量合规工程。做得不细致客户不敢把真实业务数据放上去。8.4 高端算力供应限制AI 基础设施对高端 GPU 的依赖度非常高。供应链的不确定性会影响交付周期和价格这也是所有相关厂商共同面对的约束。企业采购时要有 Plan B不能把所有算力需求绑定在单一芯片型号上。9. 对企业与技术团队的最佳实践建议结合上面的分析给企业和技术团队几条务实建议。9.1 先业务场景再硬件投入不要在还没有明确业务场景时就采购大批 GPU 服务器。正确顺序是选择 1 到 2 个高价值业务场景用云端 API 或小规模本地部署验证效果验证成功后再规划正式的算力投入根据推理负载特征决定采购规模。9.2 私有化部署不只有 GPU很多团队以为私有化部署就是买 A100/H20 这类 GPU其实数据层、平台层和运维体系才是更容易被低估的部分。建议在预算中给平台软件、监控系统、安全审计留出空间。9.3 保留统一的模型接口无论是接入公共模型还是私有模型最好统一走 OpenAI 兼容接口。这样模型可以随时切换业务系统不需要改动。这是目前工程成本最低、生态最成熟的方案。# 统一封装模型客户端示例 class LLMClient: def __init__(self, base_url, api_key, model): self.base_url base_url self.api_key api_key self.model model def chat(self, messages, temperature0.7): import requests url f{self.base_url}/v1/chat/completions payload { model: self.model, messages: messages, temperature: temperature } headers {Authorization: fBearer {self.api_key}} resp requests.post(url, jsonpayload, headersheaders, timeout120) return resp.json()9.4 建立效果评估基线任何模型上线前先建立一套效果评估集涵盖准确率、格式合规、响应时间、资源消耗四类指标。每次更换模型、调整参数、升级版本都跑同一套评估集避免“凭感觉判断哪版更好”。9.5 数据与权限合规是底线涉及企业内部数据、客户数据、个人信息的场景必须遵守数据保护要求。私有化部署不等于可以随意处理数据以下环节都需要确认数据采集是否有授权模型训练和推理过程中的数据流向是否可控日志中是否包含敏感信息模型生成的输出是否需要进行内容审核涉及人脸、声音、版权素材的功能必须有明确的授权记录。AI 基础设施是工具真正决定价值的是如何使用。合规能力建设要放在与算力建设同等重要的位置。10. 总结与后续关注方向联想向 AI 基础设施公司靠拢最值得关注的不是某款服务器或某款 PC而是它能否完成从“卖硬件”到“交付系统”的转变。从技术栈来看算力层它已经有积累平台层、模型层、数据层才是真正的考验。如果你在做企业 AI 选型建议优先验证四个问题它的平台软件是否支持多模型、多场景的统一管理它的私有化部署是否经得起生产环境的并发和稳定性考验它的服务链是否覆盖从算力到应用而不只是设备交付它的合规能力是否能满足你的数据安全要求对普通开发者来说这件事的实用提示是本地部署和私有化推理的工程技能正在变得重要。vLLM、Ollama、Kubernetes GPU 调度、RAG 流水线、模型量化、接口统一封装这些技术栈值得提前熟悉。联想这步棋的效果最终要看它在真实客户环境中的交付能力。未来一年可以重点观察它在 AI 服务器、AI 平台软件、混合 AI 落地案例三个方向的进展。方向已经明确接下来的关键是执行速度和技术厚度。对正在做 AI 基础设施选型的技术团队建议保持关注但所有决策都以自己业务场景的实测结果为准。 联想向AI基础设施公司转型：技术架构与私有化部署解析
联想这波转型方向其实已经写得很直白从“卖 PC、卖服务器的硬件厂商”逐步往“AI 基础设施公司”靠拢。这里最值得关注的点不是口号而是它要把哪一层做厚、做深。如果只看产品名称容易把这件事理解成“联想多卖了几款 AI 服务器”那实际意义就被低估了。真正要拆的是AI 基础设施到底包含哪些层联想在每一层的布局方式是什么对企业采购、私有化部署、开发测试和运维意味着什么。这篇文章就从技术架构视角把“联想向 AI 基础设施公司靠拢”这件事拆开看内容包括AI 基础设施的典型分层和核心组件联想围绕 AI 算力、存储、网络、平台软件的产品与技术路径面向企业私有化部署的混合 AI 架构思路从开发、测试、运维角度需要关注的关键技术点对比同类厂商时的判断维度落地过程中最容易踩的坑和合规边界。如果你正在做企业 AI 选型、私有化大模型部署或者关注基础设施层的机会这篇文章建议直接收藏。1. 核心能力速览AI基础设施到底包含什么先把概念对齐。所谓 AI 基础设施不是单指“一台带 GPU 的服务器”而是一整套支撑 AI 训练、微调、推理、数据流转和应用交付的技术栈。层级核心组件典型问题底层硬件GPU 服务器、AI 加速卡、存储阵列、高速网络、液冷散热算力够不够、显存容不下模型怎么办平台层容器平台、GPU 调度、资源池化、统一运维多卡训练如何分配、推理服务如何弹性伸缩模型层基础模型、微调框架、推理引擎、量化工具用什么模型、怎么压缩、怎么保证输出质量数据层数据清洗、向量数据库、知识库、RAG 检索私有数据怎么接入、效果如何溯源应用层AI Agent、智能体编排、业务系统对接场景是否真的跑通、ROI 是否为正联想向 AI 基础设施公司靠拢本质上是想把这张表里的“硬件 平台 数据 应用”串起来而不是停留在最底层的服务器整机销售。从公开信息看联想目前的核心叙事是“混合 AI”架构公共 AI、私有 AI 和个人 AI 的组合。对技术人来说这句话翻译过来就是——企业既可以使用公共大模型服务也能在本地部署私有化模型还能让终端设备AI PC / AI 工作站承担部分端侧推理任务。三种模式并存是当前企业级 AI 落地最现实的路径。2. 为什么硬件厂商都在往 AI 基础设施转过去十年服务器厂商的核心竞争力是“整机交付能力”CPU 选型、内存配置、硬盘组合、RAID 策略、散热设计。但 AI 时代改变了需求结构。2.1 客户不再只买硬件今天的客户问的问题变了这台服务器能跑多大参数的模型推理延迟是多少能不能满足生产环境能不能支持多机多卡分布式训练模型微调和数据怎么管出了问题谁来兜底这些问题里硬件只占 30%剩下 70% 是平台、模型工程和数据工程。如果厂商只卖裸机客户很难独立完成从采购到上线的全链路厂商的利润空间也会被软件和服务层蚕食。2.2 AI 算力需求从训练转向推理早期 AI 建设以训练为主客户买的是大规模 GPU 集群。但到了应用落地阶段推理需求增长更快。推理场景的特点是并发波动大、延迟要求严格、成本敏感。这对基础设施提出的要求是弹性调度推理服务能根据请求量扩展和缩容多模型共存一台机器同时服务多个轻量模型混合精度与量化用 FP16、INT8 等降低显存占用和推理成本冷热数据分层高频数据放缓存低频数据进对象存储。这些能力不能靠单机硬件完成必须有平台层软件支撑。这就是联想这类厂商必须往上走的原因。2.3 软硬一体化更容易交付客户要的不是“最好的 GPU 服务器”而是“能跑大模型的 AI 系统”。软硬一体化的好处是开箱即用预装驱动、容器运行时、推理引擎稳定性可控硬件、固件、驱动、平台版本统一验证运维闭环一套监控体系覆盖硬件和模型服务。所以“AI 基础设施公司”的本质是把交付物从“硬件”升级为“系统”。这一点对联想来说是转型方向对整个行业来说也是趋势。3. AI 基础设施的技术栈拆解这一节把 AI 基础设施按技术栈拆开每一层看技术选型和工程要点。这样对照联想的布局就能判断它真做了什么哪些环节仍然是短板。3.1 算力层GPU 服务器与集群设计算力层是联想最传统的强项。AI 服务器要关注的核心参数包括GPU 卡型与数量单机 4 卡、8 卡是主流配置高速互联NVLink 或同类卡间互联影响多卡训练效率机内拓扑CPU 与 GPU 之间的 PCIe 通道分配散热方案高密度 GPU 机柜必须考虑风冷还是液冷供电与机房承重AI 机柜单柜功率密度通常是传统机柜的数倍。工程上部署 AI 服务器时建议先做一次基础巡检# 查看 GPU 状态 nvidia-smi # 查看 GPU 卡间拓扑 nvidia-smi topo -m # 查看驱动与 CUDA 版本 nvidia-smi | grep CUDA Version如果发现 GPU 利用率低但显存占用高优先排查数据加载和 CPU 预处理是否成为瓶颈。3.2 平台层资源调度与容器化企业级 AI 基础设施平台层一般基于 Kubernetes 构建。核心工作是 GPU 资源调度。典型需求多团队共享 GPU 集群按任务优先级分配算力推理服务根据并发自动扩缩容训练任务支持多机多卡。Kubernetes 下调度 GPU 的常见做法# 声明需要 2 张 GPU 的 Pod 示例 apiVersion: v1 kind: Pod metadata: name: gpu-pod spec: containers: - name: gpu-container image: nvidia/cuda:12.2.0-base resources: limits: nvidia.com/gpu: 2如果平台层做得好用户只需要提交任务不需要关心具体跑在哪台机器上。这也是“AI 基础设施公司”和“AI 服务器厂商”最明显的分界点。3.3 模型层推理引擎与量化模型层是 AI 基础设施的差异化所在。联想在这块的思路是提供“经过验证的模型栈”企业拿到后能直接微调、部署而不是从零搭建。推理服务的关键指标指标含义建议观察方式首 Token 延迟用户发起请求到收到第一个 token 的时间API 返回耗时拆解Token 吞吐每秒生成的 token 数压测工具统计显存占用模型权重 KV Cache 激活值nvidia-smi 持续采样并发上限同时间服务的请求数压力测试确定降低推理成本的主流方案是量化如 INT8、FP8和 KV Cache 优化。要注意的是量化后必须做效果对比测试不能只看显存下降还要确认输出质量是否满足业务要求。3.4 数据层知识库与 RAG企业私有化 AI 落地的关键不是大模型本身而是“模型如何读到企业的私有知识”。RAG检索增强生成是目前最稳妥的方案上传文档PDF、Word、Markdown 等文本切分按章节或固定长度切片向量化Embedding 模型把文本转为向量存入向量库Milvus、FAISS、pgvector 等召回与重排根据用户问题检索相关内容生成回答把检索结果拼入提示词交给大模型生成。这里有一个容易忽略的工程点向量化结果的质量直接决定回答准确率。建议在正式上线前用业务常见问题集做一轮召回率测试而不是只测“能不能回答”。4. 企业私有化部署混合 AI 架构的落地路径联想给出的路线是混合 AI公共 AI、私有 AI、个人 AI 协同工作。这句话落到企业部署层面实际上对应三种部署模式。4.1 公共 AI按需调用外部大模型 API适合场景非敏感数据、通用问答、内容生成、短期验证。优点部署成本低按量付费模型迭代由服务方负责上手快无需 GPU 资源。缺点数据出域存在合规风险无法深度定制模型长期成本随调用量增长不可控。4.2 私有 AI本地部署推理服务适合场景研发代码、客户数据、财务信息、内部知识库等敏感内容。部署架构一般分为三部分推理服务部署开源模型或微调后的模型对外提供 OpenAI 兼容接口向量库与检索服务支撑 RAG 流程管理平台负责模型版本管理、服务监控、日志审计。启动一个本地推理服务的通用示例# 启动 OpenAI 兼容的推理服务以 vLLM 为例命令需按实际环境调整 python -m vllm.entrypoints.openai.api_server \ --model /models/your-chat-model \ --served-model-name local-chat \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --host 0.0.0.0 \ --port 8000启动后用 curl 验证服务是否可用curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local-chat, messages: [{role: user, content: 你好做一下自我介绍}] }4.3 个人 AI端侧推理这就是联想 AI PC 的定位。端侧推理的价值在于数据不出终端隐私性最强无需网络离线可用低延迟适合交互型场景。限制也很明显终端算力有限只能跑小参数模型通常是量化后的 7B 级别或更小复杂任务仍需云端协同。个人 AI 的典型使用方式是把端侧模型作为“入口”初步处理用户指令判断什么任务本地解决、什么任务上送云端。这种混合调度体验比“全拉上云”更符合企业办公场景。5. 面向企业内部测试环境一套验证流程不管联想的产品矩阵如何演进企业在决定采用前都需要用自己的业务数据做一轮验证。下面给出一套适合在私有化环境执行的验证流程重点观察“部署是否顺利、效果是否达标、资源是否可控”。5.1 环境准备清单检查项说明GPU 驱动按显卡型号安装对应版本驱动nvidia-smi能正常输出CUDA / 推理框架按模型要求安装注意 CUDA 版本与 PyTorch 的兼容关系磁盘空间模型权重 数据集 日志预留至少 100GB端口规划推理服务端口、向量库端口、管理平台端口避免冲突网络策略内网服务不建议直接绑定 0.0.0.0如需远程访问控制访问来源5.2 推理效果测试用例建议至少准备三类测试数据通用问答验证基础对话能力业务场景问答从真实业务文档中抽取问题敏感性测试确认模型不会泄露提示词之外的训练数据也不会生成越权内容。每一类准备 20 条以上测试问题逐条记录回答质量。判断标准包括回答是否准确是否忠于给定的业务文档遇到不确定问题是否坦率说明而不是编造回答是否稳定相同问题多次提问是否一致。5.3 资源占用观察方法持续采集 GPU 指标建议用如下命令周期采样# 每 5 秒记录一次 GPU 状态 watch -n 5 nvidia-smi # 或者保存到文件便于后续分析 nvidia-smi --query-gputimestamp,utilization.gpu,utilization.memory,memory.used \ --formatcsv -l 5 gpu_usage.log重点观察单请求峰值显存并发请求时显存是否溢出长时间运行后显存是否持续增长可能存在内存泄漏推理延迟是否随并发增加急剧恶化。5.4 批量任务与接口测试企业场景经常需要批量处理文档批量总结、批量提取、批量审核。这就涉及接口压测。用 Python 写一个简单的并发请求模板import requests from concurrent.futures import ThreadPoolExecutor url http://127.0.0.1:8000/v1/chat/completions def call_model(prompt): payload { model: local-chat, messages: [{role: user, content: prompt}], temperature: 0.7 } resp requests.post(url, jsonpayload, timeout120) return resp.json() # 示例并发 10 个请求观察耗时和成功率 prompts [f用一句话总结第{i}段内容 for i in range(10)] with ThreadPoolExecutor(max_workers10) as executor: results list(executor.map(call_model, prompts)) for r in results: if choices in r: print(r[choices][0][message][content][:80]) else: print(调用失败:, r)批量任务在正式生产前一定要加上任务队列和重试机制单条任务超时控制失败任务日志记录结果校验环节。6. 联想 AI 基础设施布局的观察维度回到标题本身联想不断向 AI 基础设施公司靠拢。作为技术读者我们不需要过度关注公司战略话术而应该关注四个观察维度。6.1 硬件产品线是否完整AI 基础设施需要的不只是 GPU 服务器还需要存储、网络、边缘设备和终端算力。联想本身有服务器、存储、工作站、PC 等产品线具备“全栈硬件”的基因。这一点与只做服务器的厂商有很大差异。6.2 软件和平台能力是否补齐硬件基因强不代表软件能力强。AI 基础设施的软件栈复杂度远高于传统 ITGPU 调度、模型生命周期管理、推理服务观测、数据安全管控每一块都需要长时间积累。判断联想是否“真的转型”要看它在平台层和模型层的投入能否形成可复制的交付能力。6.3 生态绑定深度AI 基础设施离不开芯片厂商和模型厂商的生态。联想与芯片厂商的合作深度、对开源模型生态的适配程度、对客户私有化环境的支持力度都会影响实际交付体验。6.4 客户成功案例是否可复制最直接的判断方式是看案例联想服务的客户是停留在“采购硬件”层面还是真正在它提供的基础设施上跑通了业务 AI 场景后者的比例越高说明基础设施公司的成色越足。7. 与同类厂商对比时的判断框架做技术选型时需要横向对比多家厂商。这里给一套不是结论、但可复用的对比框架对比维度关注点交付形态是纯硬件、软硬一体机还是云化服务模型支持是否覆盖主流开源模型是否支持私有模型接入部署方式是否支持本地私有化、混合云、纯公有云扩展性从单机到集群的扩展方式是否平滑运维复杂度日常监控、升级、扩容由谁负责合规能力数据主权、审计日志、访问控制是否完善服务边界是否包含模型微调、效果调优、人员培训这套框架同样适用于评估联想之外的任何 AI 基础设施供应商。对技术负责人来说最忌讳的是被“算力参数”带偏而忽略平台层和运维层的成熟度。8. 关键挑战与风险联想向 AI 基础设施转型方向明确但落地挑战不小。客观说几个风险点。8.1 软件生态的积累需要时间AI 基础设施的软件复杂度远超传统 IT。GPU 调度、推理优化、模型服务化、数据安全等能力需要大量真实客户场景打磨。软件能力的差距不是靠发布会可以抹平的需要持续迭代。8.2 大模型迭代节奏带来不确定性模型架构、推理引擎、量化方案都在快速变化。基础设施厂商的产品如果绑定某一代模型架构过深迭代周期跟不上很容易被新方案替代。这要求厂商对模型生态保持足够的敏感度。8.3 客户数据安全与合规压力企业私有化部署 AI 基础设施核心诉求是数据不出域。但这背后涉及模型训推过程中的数据审计、访问控制、操作日志、密钥管理等大量合规工程。做得不细致客户不敢把真实业务数据放上去。8.4 高端算力供应限制AI 基础设施对高端 GPU 的依赖度非常高。供应链的不确定性会影响交付周期和价格这也是所有相关厂商共同面对的约束。企业采购时要有 Plan B不能把所有算力需求绑定在单一芯片型号上。9. 对企业与技术团队的最佳实践建议结合上面的分析给企业和技术团队几条务实建议。9.1 先业务场景再硬件投入不要在还没有明确业务场景时就采购大批 GPU 服务器。正确顺序是选择 1 到 2 个高价值业务场景用云端 API 或小规模本地部署验证效果验证成功后再规划正式的算力投入根据推理负载特征决定采购规模。9.2 私有化部署不只有 GPU很多团队以为私有化部署就是买 A100/H20 这类 GPU其实数据层、平台层和运维体系才是更容易被低估的部分。建议在预算中给平台软件、监控系统、安全审计留出空间。9.3 保留统一的模型接口无论是接入公共模型还是私有模型最好统一走 OpenAI 兼容接口。这样模型可以随时切换业务系统不需要改动。这是目前工程成本最低、生态最成熟的方案。# 统一封装模型客户端示例 class LLMClient: def __init__(self, base_url, api_key, model): self.base_url base_url self.api_key api_key self.model model def chat(self, messages, temperature0.7): import requests url f{self.base_url}/v1/chat/completions payload { model: self.model, messages: messages, temperature: temperature } headers {Authorization: fBearer {self.api_key}} resp requests.post(url, jsonpayload, headersheaders, timeout120) return resp.json()9.4 建立效果评估基线任何模型上线前先建立一套效果评估集涵盖准确率、格式合规、响应时间、资源消耗四类指标。每次更换模型、调整参数、升级版本都跑同一套评估集避免“凭感觉判断哪版更好”。9.5 数据与权限合规是底线涉及企业内部数据、客户数据、个人信息的场景必须遵守数据保护要求。私有化部署不等于可以随意处理数据以下环节都需要确认数据采集是否有授权模型训练和推理过程中的数据流向是否可控日志中是否包含敏感信息模型生成的输出是否需要进行内容审核涉及人脸、声音、版权素材的功能必须有明确的授权记录。AI 基础设施是工具真正决定价值的是如何使用。合规能力建设要放在与算力建设同等重要的位置。10. 总结与后续关注方向联想向 AI 基础设施公司靠拢最值得关注的不是某款服务器或某款 PC而是它能否完成从“卖硬件”到“交付系统”的转变。从技术栈来看算力层它已经有积累平台层、模型层、数据层才是真正的考验。如果你在做企业 AI 选型建议优先验证四个问题它的平台软件是否支持多模型、多场景的统一管理它的私有化部署是否经得起生产环境的并发和稳定性考验它的服务链是否覆盖从算力到应用而不只是设备交付它的合规能力是否能满足你的数据安全要求对普通开发者来说这件事的实用提示是本地部署和私有化推理的工程技能正在变得重要。vLLM、Ollama、Kubernetes GPU 调度、RAG 流水线、模型量化、接口统一封装这些技术栈值得提前熟悉。联想这步棋的效果最终要看它在真实客户环境中的交付能力。未来一年可以重点观察它在 AI 服务器、AI 平台软件、混合 AI 落地案例三个方向的进展。方向已经明确接下来的关键是执行速度和技术厚度。对正在做 AI 基础设施选型的技术团队建议保持关注但所有决策都以自己业务场景的实测结果为准。