一个工程师的LLM部署实验：从好奇到动手

去年，一位工程师在博客写下这句话："我想知道怎么在生产环境部署大模型。"一年后，他没停在读文档，而是真的动手搭了一套——用亚马逊的容器服务跑开源推理引擎，再用几十行前端代码包成聊天机器人。

这不是某家大厂的官宣，没有融资数字，没有性能对标。但正是这种"一个人想搞清楚一件事"的起点，藏着产品人该看的细节：选什么工具、为什么选、坑在哪。

从"看看"到"做做"的转折点

作者坦承，最初只是好奇。但技术人的好奇有个特点：读多了就想跑起来。他不碰训练，只专注"怎么把模型 serving 做好"——这是工程视角的典型选择，也是很多团队从 demo 走向生产的真实分水岭。

技术栈的选型很能说明问题。推理框架他对比了 TGI、Triton、原生 HuggingFace，最终选了 vLLM。原因没展开，但结合上下文看，vLLM 的PagedAttention和连续批处理对吞吐的优化，应该是关键考量。

基础设施没选"开台 EC2 直接 SSH"，而是上了亚马逊的 EKS（托管 Kubernetes）。他的理由很直接：这不是跑脚本，是搭可靠系统。GPU 节点要单独配，系统组件和推理负载要隔离，入口要用负载均衡暴露——这些都是在生产环境踩过坑才会写的。

配置即代码：一个 .env 文件暴露的工程思维

动手前，他先建了一个 .env 文件管理配置。里面分三块：AWS 账号信息、EKS 集群名、预留的 vLLM 服务端点。

这个细节很小，但值得产品人注意。硬编码是 demo 的写法，环境变量分离是工程的起点。他甚至在 VLLM_URL 那行留了注释："部署完成后再填"——说明整个流程是设计过的，不是边写边改。

另一个容易被忽略的点是配额。AWS 新账号默认给 G 类和 VT 实例的 vCPU 配额是 0，得先去控制台申请提升到至少 4 核，才能跑 g4dn.xlarge 这个 GPU 实例。这种"云厂商的隐形门槛"，文档不会主动告诉你，只有真动手的人才会写进教程。

基础设施层：零默认容量的设计意图

看代码片段，EKS 集群的创建参数里有个关键设置：default_capacity=0。意思是"不要默认节点组，我自己定义"。

这背后是明确的资源分层思路。他配了两个节点组：一个 t3.medium 跑系统组件（CoreDNS、kube-proxy），一个 GPU 节点专门跑 vLLM。配合污点（taints）和容忍度（tolerations），确保推理 pod 不会误落到 CPU 节点上。

这种设计在小型实验里显得"过重"，但作者的目的很明确：模拟生产环境。产品人读到这里应该想的是——如果他的 demo 要扩成服务，这套架构几乎不用改。

GPU 节点还单独绑了 IAM 角色，挂载 EKS 工作节点策略。模型存储用的 S3，桶名直接写在配置里。整个数据流是：S3 存模型 → GPU 节点加载 → 负载均衡暴露端点 → Streamlit 前端封装。

为什么是这套组合？

拆解他的选型逻辑，能看到一条清晰的主线：每个工具解决一个明确问题，不重叠，不将就。

vLLM 负责推理效率，EKS 负责编排和可靠性，CDK（代码里用了 Python 的 AWS CDK）负责基础设施即代码，Streamlit 负责快速验证交互。没有为了追求"全链路自研"而造轮子，也没有因为"这只是个实验"而降低工程标准。

这种平衡感，往往是个人项目和企业项目的最大区别。企业容易过度设计，个人实验容易过度简陋。作者的位置卡在中间：够认真，够务实。

给产品人的两个观察

第一，"部署大模型"这个需求正在下沉。一年前还是大厂基础设施团队的专属话题，现在一个工程师用开源工具 + 云托管服务就能跑通。工具链的成熟速度，比多数人感知的更快。

第二，vLLM 这类推理引擎的崛起，说明生态竞争已经从"谁能训模型"转向"谁能跑得好"。训练看算力，serving 看工程——后者恰恰是中小团队能建立优势的地方。

作者最后没写性能数字，也没放聊天机器人的截图。但整个流程跑下来，他解决了一个更基础的问题：从"想知道"到"知道怎么做"。对大多数技术人来说，这个 gap 比任何 benchmark 都大。

至于那个还没填上的 VLLM_URL——等负载均衡的 DNS 生效后，他就会补进去。然后发现，前端调用的代码可能比基础设施还短。