企业官网建设流程全解析

如果只看新闻标题，很多人会把“联想向AI基础设施公司靠拢”理解成一次常规的战略改名：联想想多卖点服务器，所以给自己贴一个更时髦的标签。

这个判断只对了一半。

过去一年，我们看到了大量和AI基础设施相关的讨论：智算中心建设、GPU集群调度、AI一体机、大模型推理优化、RAG知识库落地。大多数讨论聚焦在算力芯片和模型层，很少有人认真回答一个问题：当企业真正要落地AI应用时，除了买显卡，还需要什么？

答案是一整套基础设施：怎么把异构算力管理起来，怎么让大模型稳定跑在集群上，怎么处理存储、网络、调度、运维、安全，以及怎么把模型变成业务系统里可靠调用的一项服务。

联想正在做的，就是把自己重新定义为提供这套东西的公司。这篇文章不讨论股价，也不讨论品牌定位，而是从技术视角拆解“AI基础设施”这个概念在联想身上到底意味着什么，以及这件事对开发者、架构师和企业的实际影响。

读完你会有三个收获：第一，搞清楚AI基础设施的技术边界是什么；第二，看明白联想在AI基础设施上的核心布局和实际产品落点；第三，知道在企业落地AI时，基础设施层到底有哪些坑，以及哪些技术栈值得你提前储备。

1. AI基础设施到底是什么：先厘清边界

AI基础设施这个概念，在过去一年被用得越来越频繁，但边界非常模糊。很多人把它等同于“GPU服务器”，也有人把它理解成“云计算平台”，还有人觉得，只要买了几台带显卡的机器，基础设施就到位了。

从技术视角看，AI基础设施不是一个单点产品，而是一整套支撑AI应用全生命周期的技术栈。它可以分成五个层次。

第一层是算力层，包括CPU、GPU、NPU、各类加速卡，以及把它们组合成服务器、集群的硬件平台。

第二层是网络层，负责把多台机器高速连接起来，涉及InfiniBand、RoCE、高速以太网等方案。大模型训练是高度并行的任务，网络带宽和延迟直接决定集群能否有效工作。

第三层是存储层，包括高性能并行文件系统、对象存储、向量数据库等。训练数据、模型权重、检查点文件、推理日志，都需要在不同阶段被高速读写。

第四层是调度与开发平台层，解决“有了算力怎么用起来”的问题。包括资源调度、容器编排、训练任务管理、模型推理服务、模型微调工具等。Kubernetes、Docker、vLLM、KServe、Ray等是这一层的典型技术。

第五层是服务与安全层，包括模型上线后的监控、权限管理、数据安全、日志审计，以及可持续运维能力。

所以，把“AI基础设施公司”理解成“卖GPU服务器的公司”，是明显窄化了。真正难做的，从来不是把硬件堆起来，而是把上五层能力做成标准化产品，让企业的AI应用能低门槛、高稳定地跑起来。

这也解释了为什么联想这件事值得关注。联想本身有服务器、存储、网络终端等硬件产品线，如果只是继续卖盒子，它不需要反复强调“AI基础设施”。它真正在做的，是把从算力到平台再到服务的整条链路整合起来，形成一套可交付的解决方案。

2. 联想为什么要靠拢AI基础设施：卖盒子逻辑的天花板已经出现

理解联想向AI基础设施转型，要先理解传统服务器生意发生了什么变化。

过去十年，企业采购服务器，核心诉求是“稳定、兼容、性价比”。采购方通常是IT部门，选型时看CPU核数、内存大小、扩展槽位、厂商服务。硬件交付后，企业自己装虚拟化、搭数据库、部署应用，厂商的职责到交付就基本结束。

但AI时代改变了这个模式。

企业采购AI算力时，面对的是一堆自己很难独立解决的问题：显卡驱动和CUDA环境怎么配？多机多卡训练的网络怎么调？推理服务怎么做到高并发低延迟？模型和数据的安全边界怎么划？故障出现时怎么快速定位？这些问题，大多数企业IT团队并没有完整的知识储备。

换句话说，企业要的不是一台服务器，而是“能跑AI应用”的结果。谁能把结果打包成产品，谁就掌握了这波需求。

从联想近期公开的信息来看，它已经明确提出了混合式AI的战略框架：既有公共AI大模型，也有私有AI大模型，两者并行。这个战略背后的技术判断是，绝大多数企业的AI落地不会完全跑在公有云上，出于数据安全、成本和合规考虑，本地化部署是刚需。

本地化部署恰恰是联想这类硬件厂商的主场。它有服务器、存储、网络设备，有成熟的供应链和交付渠道。如果在这上面叠加上智算平台、推理优化和AI应用一体机，它就不再是单纯的硬件供应商，而是输出整套AI基础设施能力。

这就是“向AI基础设施公司靠拢”真正要表达的东西：从卖硬件，转向卖“AI就绪”的完整交付能力。

3. 联想AI基础设施布局的核心落点：三条赛道与一个平台

从公开信息看，联想在AI基础设施上的布局可以从三个维度来看。

第一个维度是AI服务器。联想在这个领域已经有明确的市场地位。从公开报道的口径看，联想AI服务器连续多季度位居全球前三、中国第一。这个排名的意义不在于数字本身，而在于它证明了供应链和交付能力。AI服务器和传统服务器最大的区别在于对异构算力的支持，比如GPU、NPU、DPU的混插，以及液冷等高功耗散热方案的成熟度。

第二个维度是AI存储与数据管理。大模型训练和推理对存储的要求比传统数据库高很多。训练阶段的检查点文件动不动就是几十GB甚至上百GB，推理阶段要支持高并发读取知识库中的向量数据，这些都需要高性能存储和对应的数据管理方案。

第三个维度是AI网络。多机训练时，网络就是集群的命脉。联想作为老牌网络设备厂商，在这块有积累。从万兆以太网到RoCE，再到InfiniBand的组网支持，是AI基础设施里不可缺的一环。

支撑这三条赛道的，是一个叫联想万全异构智算平台的产品。这个名字里有两个关键词值得拆解。

“异构”说明它面对的不是单一GPU，而是不同厂商、不同型号的芯片混合环境。这在实际项目中非常常见：企业可能既有NVIDIA的卡，也有国产加速卡，还可能混用新旧两代GPU。如果没有统一调度层，这些算力很难被高效利用。“智算平台”说明它不只是一套管理系统，而是覆盖算力调度、任务分发、监控运维、资源优化的综合平台。

从联想公开介绍看，万全异构智算平台实现了算力集群的智能调度与统一管理。这句话翻译成开发者能理解的语言就是：当你有一批异构GPU机器时，平台能帮你把它们变成统一分配的算力池，跑模型训练时合理分发任务，跑推理时自动负载均衡，而不是靠人工去安排哪台机器上跑什么任务。

对很多企业来说，这一步才是真正的门槛。

4. 万全异构智算平台背后的技术逻辑：调度、优化与服务化

不从平台概念本身出发，而从一个具体场景来看联想万全异构智算平台存在的意义。

假设企业购买了8台GPU服务器，每台8卡，总共64张加速卡。传统做法是，运维手工给服务器装驱动、配环境，然后在上面部署容器平台，再逐台指定任务。训练任务开始后，GPU利用率没人监控，某张卡掉线了要等任务失败才发现。这个模式在单机场景下还能忍受，在集群规模扩大后就变得不可维护。

异构智算平台要解决的，正是这个集群管理问题。它做的事情可以归纳为三个方向。

第一个方向是算力资源池化。把所有GPU服务器抽象成统一的算力资源，按需分配给训练和推理任务。某一组机器的卡被占满后，新任务自动调度到空闲机器，而不是卡死在资源不足的状态。

第二个方向是任务调度与优化。大模型训练是多机多卡协作，节点之间通信频繁，任务调度算法直接影响训练效率。平台需要根据网络拓扑、GPU型号、显存大小，为每个任务选择最优的分配策略。同时，推理任务需要更细粒度的资源管理，比如一个服务要几张卡，这几个服务能不能共享一张卡。

第三个方向是服务化能力。光有调度还不够，开发者需要的是一套标准的接入方式。最好能像用云平台一样，提交一个训练任务，平台自动分配资源、启动环境、监控状态、交付结果。这背后涉及Kubernetes生态、镜像管理、日志采集、监控告警等一系列工作。

从联想公开介绍中可以看到，它强调通过平台联动，实现资源利用率最大化，同时降低AI基础设施的部署复杂度。此外还提到了AI基础设施领域的八大维度：互联、算力、存储、软件栈、部署、服务、可持续发展与安全。这个框架的价值在于，它把AI基础设施从一张显卡扩展到了完整的工程链条。

另外，方案中还提到了比传统方式降低40%的AI基础设施部署时间，并在大模型推理方面实现超过15%的优化和20%以上的性能提升。这些数据可以作为方案效果参考，具体表现还是和实际硬件配置、模型规模、业务负载相关。

5. 面向开发者的AI基础设施技术栈：从Kubernetes到推理框架

前面讲的是厂商战略，现在回到开发者视角。无论联想还是其他厂商在AI基础设施上怎么做，最终落到企业系统里，开发者接触到的还是一套具体的技术栈。

如果你所在的企业准备采购AI服务器并搭建本地推理环境，你大概率会接触到下面这些组件。

第一类，资源调度层。目前事实标准还是Kubernetes配合GPU设备插件。通过Device Plugin，K8s可以感知节点上有多少张GPU卡，并在容器调度时精准分配。你写的YAML里通过resources.limits声明需要的显卡数量，调度器就会把Pod部署到有空闲卡的节点上。

第二类，推理服务框架。现在比较主流的是vLLM。它通过PagedAttention等技术，把显存利用率大幅度提升，同时支持高并发推理。如果企业要部署一个开源大模型的API服务，vLLM是绕不开的选择。

第三类，模型微调与训练框架。常见的如PyTorch配合DeepSpeed、Megatron-LM等分布式训练框架。模型规模到了百亿参数以上，单卡已经装不下，必须用张量并行、流水线并行、数据并行等手段把模型拆到多卡上训练或微调。

第四类，数据与检索组件。企业做知识库问答时，还需要向量数据库。数据先被切分成chunk，然后通过嵌入模型转成向量，存进向量库。用户提问时，系统把问题向量化后召回最相似的文档片段，再送给大模型生成回答。

这一整套从K8s到推理框架再到向量库的技术栈，才是AI基础设施真正的软件面。联想万全异构智算平台这类产品要做的，就是把这些组件整合起来，让企业不需要从零搭建全套系统。

当然，作为开发者你仍然值得自己去理解这些组件，原因很简单：完全托管不代表你不会遇到问题，当平台出故障时，懂底层的人才能快速定位。

6. 从零跑通一套本地AI推理环境的配置示例

前面的概念讲再多，不如给一个能直接参考的最小示例。假设你所在的企业准备用开源模型做内部知识库问答，需要部署一个基础环境。这个示例不针对某一家厂商的硬件，而是展示典型的AI基础设施部署思路。

6.1 硬件层配置示例

AI服务器选型时，需要关注CPU、内存、GPU、存储和网络五个维度。以下是一个典型的单机推理节点配置参考：

这个配置只适合小规模推理场景。如果要做70B以上参数模型，需要多机多卡部署，网络和存储要求会高很多。

6.2 部署推理服务的核心命令

在GPU服务器上部署vLLM服务，通常需要先安装CUDA和Python环境，然后通过pip安装vLLM。下面是典型流程：

# 安装vLLM（建议使用Python 3.10+） pip install vllm # 下载模型（以Qwen2.5-7B-Instruct为例） pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /data/models/qwen2.5-7b # 启动OpenAI兼容的推理服务 python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-7b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000

其中--tensor-parallel-size表示张量并行使用的GPU数量。单卡24GB可以尝试跑7B模型，如果跑14B模型，建议设为2，也就是用两张卡并行加载。

启动成功后，可以通过curl验证服务是否正常：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/data/models/qwen2.5-7b", "messages": [{"role": "user", "content": "用一句话解释什么是AI基础设施"}] }'

响应中会返回模型生成的文本。如果这一步跑通了，说明你的服务器已经具备基础的AI推理能力。

6.3 Kubernetes调度GPU的配置示例

如果企业打算让多个团队共享这几张GPU卡，就需要Kubernetes。先用NVIDIA设备插件让K8s识别GPU资源，然后在Pod里声明显卡需求：

apiVersion: v1 kind: Pod metadata: name: vllm-inference spec: containers: - name: vllm image: vllm/vllm-openai:latest command: ["python", "-m", "vllm.entrypoints.openai.api_server"] args: - --model=/data/models/qwen2.5-7b - --tensor-parallel-size=1 - --host=0.0.0.0 - --port=8000 resources: limits: nvidia.com/gpu: 1 ports: - containerPort: 8000

关键点是resources.limits.nvidia.com/gpu。设备插件会把这个值映射为节点上的实际GPU资源。调度器看到这个声明后，会把Pod调度到有可用GPU的节点。

这一步做完，你的GPU服务器已经初步具备了“AI基础设施”的形态：硬件、驱动、调度、推理服务都就位了。

7. AI基础设施落地中的常见误区与避坑指南

在实际项目实施中，AI基础设施的坑往往不在技术本身，而在技术选型和预期管理上。下面这些误区非常有代表性。

第一个误区是重硬件轻集群。采购时把预算全部花在GPU上，网络和存储选最便宜方案。等真的开始多机训练，发现跨节点通信带宽不够，训练效率还不如单机。正确的做法是在项目初期就规划好网络拓扑和存储性能，因为后续替换成本极高。

第二个误区是重训练轻推理。很多团队把注意力放在训练模型上，忽略了推理部署的难度。实际业务中，训练是一次性投入，推理是长期持续运行。推理服务的稳定性、并发能力、延迟指标，才是真正影响用户体验的因素。这也是vLLM这类推理框架变得越来越重要的原因。

第三个误区是忽视模型与硬件的匹配。同一个模型在不同GPU上的表现差异很大，显存不够可能导致模型量化甚至无法加载。选型时不能只看显存大小，还要看显存带宽、算力精度支持（FP16、BF16、FP8）、卡间通信方式。不同厂商的卡，其驱动和生态成熟度差别很大，这直接决定了你后续开发的顺畅程度。

第四个误区是低估运维成本。GPU集群的故障率比普通CPU服务器高，驱动升级、容器镜像管理、监控告警、日志采集都要求专门的技能。如果团队中没有熟悉基础设施的人，即使硬件采购到位，项目推进也会很慢。

第五个误区是认为“买了平台就万事大吉”。无论是联想万全异构智算平台，还是其他私有化AI平台，本质上都是工具。工具能降低使用门槛，但不能替代对AI应用本身的合理设计。你的数据质量、提示词设计、评测流程、业务逻辑，仍然需要自己做好。

AI基础设施还有一个容易被忽视的维度是安全与合规。私有化部署虽然规避了数据出域问题，但权限管理、数据分类分级、模型输出审计、日志留存这些工作反而更依赖企业自己。特别是金融、政务、医疗等领域，模型回答如果涉及敏感信息，会产生严重的合规风险。使用相关工具时，需要在充分理解安全风险并确认合规要求的前提下操作，设置合适的访问控制、内容过滤和操作审计机制。

8. AI基础设施的最佳实践与工程建议

结合前面这些内容，我整理了一份可以在实际项目中直接参考的最佳实践清单。

第一，最小可行集群先跑通。不要一步到位买了上百台GPU服务器再开始。先搭一个两台机器的小集群，把网络、存储、调度、推理服务完整跑一遍，确认整个链路没有断点，再按需扩容。这个思路和软件开发里的MVP（最小可行产品）一脉相承。

第二，选择开放的软件栈。尽量选择Kubernetes、vLLM、PyTorch等有活跃社区的开源组件。开放生态意味着更多文档、更多踩坑案例、更多的可选方案。避免绑定闭源和自定义API太强的组件，否则后续排障会很被动。

第三，监控与日志从第一天开始做。GPU利用率、显存占用、温度、功耗、网络流量、推理延迟、请求成功率，这些指标都要提前接入监控系统。首次部署时可能看不出问题，但上线后出故障时，这些数据是唯一能快速定位问题的线索。

第四，建立模型版本和评测机制。模型更新不是简单替换文件，需要做回归测试。准备一套固定的评测集，每次模型升级后跑一下，确认效果没有回退再上线。推理服务建议采用蓝绿部署或金丝雀发布，降低模型更新带来的业务风险。

第五，提前规划安全边界。AI基础设施涉及模型文件、训练数据、业务数据、用户对话记录等多类敏感资产。生产环境应遵循最小权限原则，明确谁能访问GPU节点、谁能部署模型、谁能查看日志。敏感操作需要权限审批和审计记录。

第六，把基础设施成本纳入模型选型。很多团队只关心模型准确率，不看推理成本。一个准确率只高0.5%但推理成本翻倍的模型，未必是最优选择。精度、延迟、成本三个指标需要放在一起权衡。

9. 对开发者和架构师的影响：需要提前储备哪些技术

联想向AI基础设施公司靠拢，表面上是厂商战略调整，实际上反映了一个大趋势：AI基础设施正在从“极客自建”走向“企业标准化交付”。这意味着，未来几年会有大量企业采购AI硬件和平台，但真正能把这套系统用好的人才，目前非常稀缺。

对开发者而言，现在值得在以下几个方向做技术储备。

第一，容器化和Kubernetes。无论哪家厂商的AI平台，底层大概率是Kubernetes。学会用K8s管理GPU资源，是最基础的能力。

第二，推理优化。理解模型量化、批处理、连续批处理、KV Cache管理等概念，能够帮助你在不升级硬件的情况下，提高现有资源的服务能力。

第三，模型微调与评测。掌握LoRA等高效的模型微调方法，以及一套可靠的模型评测流程，是支撑业务AI落地的关键能力。

第四，大模型应用开发。掌握RAG（检索增强生成）、Agent、Function Calling等应用层技术，能让大模型真正进入业务流程，而不只是做一个聊天机器人。

对架构师而言，更重要的是建立“端到端成本”思维：从训练成本、数据标注、推理算力、运维人力、安全合规等全链路做技术决策。AI基础设施已经不再是简单的采购问题，而是系统工程。

10. 总结与后续方向

回到开头的问题：联想不断向AI基础设施公司靠拢，意味着什么？

它意味着AI基础设施的竞争已经进入了新的阶段。第一阶段的竞争是芯片和单机性能，第二阶段是集群管理和软件平台，第三阶段则是生态和服务能力。联想拥有服务器、存储、网络、供应链、服务体系，把这些能力和万全异构智算平台、AI一体机等方案结合起来，它的确是在朝一家真正的AI基础设施公司转型。

不过，对于技术人来说，比关注某家公司动向更重要的，是理解AI基础设施本身的演进逻辑：算力池化、平台化、服务化。这条路是确定的，无论哪一家厂商最终胜出，围绕AI基础设施的技术需求都会持续增长。

建议你在读完这篇文章后，先做两件小事。第一，用一台带有GPU的服务器，按文中的命令部署一个vLLM推理服务，跑通一次完整的对话请求。第二，画出你的企业如果采购AI服务器，从硬件选型到推理上线需要经过哪些环节，每个环节有哪些角色参与。做完这两件事，你对AI基础设施的理解会比大多数只刷新闻的人深入得多。

后续值得继续关注的几个方向包括：国产算力芯片的软件生态成熟度、AI一体机在企业知识库场景的实际落地效果、大模型推理成本随硬件和算法进步下降的曲线，以及AI基础设施安全合规标准的演进。这些方向会直接影响你在未来一到两年里的技术选型和职业竞争力。