001、开篇：为什么选择Flask搭建大模型API？上周深夜调试一个生产环境的问题，客户的大模型接口在并发请求时频繁超时。团队里有人提议上异步框架，有人建议加负载均衡，我盯着日志里那几行熟悉的Werkzeug输出，突然意识到——问题不在框架，而在我们怎么用它。这让我想起很多刚入行的工程师，一提到大模型部署就想到复杂架构，却忽略了最简单直接的解决方案往往最有效。今天我们就聊聊，为什么Flask这个看似“轻量”的框架，反而是很多老手搭建大模型API的首选。一、从真实场景说起去年给金融客户部署一个百亿参数模型时，我们最初选了某个热门异步框架。结果在预处理模块里，因为一个阻塞的文件解析操作，整个事件循环卡了足足三秒。后来换回Flask配合Gunicorn多进程，配合简单的线程池处理阻塞操作，吞吐量反而上去了。这不是说Flask多强大，而是它足够“诚实”——它不会假装自己能解决所有并发问题，这种诚实逼着开发者去真正理解业务瓶颈在哪里。大模型API有个特点：单次请求处理时间长，CPU/GPU计算密集，但真正的并发压力往往不在模型推理本身，而在前后处理、队列管理、状态维护这些“边缘环节”。用过于复杂的框架，就像用手术刀切西瓜，不是不行，但得多花三倍时间研究怎么握刀。二、Flask的“刚好够用”哲学# 这是你从文档里看到的经典示例from