这次我们来看一个和市场观点有关的话题：AI 市场被低估了。这个观点的来源是 Eric Vishria。公开资料显示，Eric Vishria 是 Benchmark Capital 的普通合伙人，也是 Confluent 的联合创始人，长期关注企业软件、开源基础设施和开发者工具。从标题本身能把握到的核心判断是：当前市场对 AI 的定价，没有完全反映它即将释放的生产力空间。
这篇文章不会只停留在观点层面。我会把“AI 市场被低估”拆成几个可以验证的技术变量：推理成本、模型能力、开发者采用率、部署门槛、批量任务效率和 API 可集成性。如果你正在做 AI 应用开发，或者正在评估要不要在 AI 基础设施上做预算投入，这套分析框架可以直接拿去做判断依据。先讲能不能用、门槛高不高，再讲怎么验证、怎么落地。
先说结论性信息：“AI 市场被低估”不是一句口号，背后至少有四个可观察的信号——模型能力还在快速上升，推理成本在持续下降，开发者工具链在快速成熟，企业级应用正在从“试点”进入“批量生产”。这篇文章会从基础设施、模型层、应用层三个维度展开分析，然后给出一套面向技术团队的 AI 工程化落地路径，包括本地部署、API 调用、批量任务、资源占用观察和常见问题排查。
1. 核心观点速览
先把“AI 市场被低估”这个观点涉及的关键维度整理成一张表，方便快速对照。这张表不是投资建议，而是一份技术视角的观察清单。
| 观察维度 | 当前信号 | 对“被低估”判断的意义 |
|---|---|---|
| 模型能力 | 开源模型与闭源模型差距缩小，多模态能力进入主流 | 市场用旧能力曲线给新模型定价 |
| 推理成本 | API 价格持续下降，本地推理工具链成熟 | 成本下降会释放更多应用需求 |
| 开发者采用率 | AI 编程工具、AI Agent 框架使用量快速增长 | 真实需求比表面估值更活跃 |
| 基础设施成熟度 | 支持量化、批量推理、流式输出的部署工具增多 | 部署门槛降低，增量市场变大 |
| 企业落地阶段 | 从单个功能试点走向业务流程改造 | 市场规模不再局限于“插件”式需求 |
| 开源生态 | 模型权重、微调工具、部署方案不断出现 | 自建成本可预测，催生新的预算池 |
从这张表可以看到，“AI 市场被低估”本质上是一个关于预期差的判断：市场用线性外推的方式看待 AI 的短期收入，但 AI 的成本曲线和能力曲线是非线性的。技术团队真正需要关注的是，这种非线性变化能不能在你自己的业务场景里复现。
2. AI 市场被低估的三个层面
“AI 市场”不是一个整体，至少可以拆成基础设施、模型层、应用层三个层面。每个层面被低估的逻辑不同，验证方法也不同。
2.1 基础设施层：规模化需求还没完全释放
基础设施层包括 GPU 集群、数据中心、推理引擎、向量数据库、模型服务框架等。这部分被低估的原因在于：很多人用当前 GPU 的“供给量”去估算市场空间，但忽略了推理成本下降对需求弹性的影响。当一次 AI 调用的成本从几毛钱降到几分钱，调用量会成倍增长，基础设施的总需求不是线性增长，而是被压缩后反弹的曲线。
从工程视角看，基础设施层的验证指标很明确：
- 推理引擎的吞吐量，比如每秒处理的 Token 数。
- 单位 Token 的推理成本，包括电费、卡时和运维成本。
- 显存利用率和批处理效率。
- 模型量化后精度损失与性能提升的平衡点。
如果你的团队在做模型服务，建议建立一套成本基线：记录每百万 Token 的推理成本、平均延迟、首 Token 延迟、并发上限。这套基线就是判断“AI 基础设施是否被低估”的第一手数据。
2.2 模型层：开源与闭源的竞争正在重塑定价权
模型层被低估，主要体现在能力进步的速度上。两年前，企业要获得高质量模型只能依赖少数闭源 API；现在，开源模型在数学、代码、多模态理解等任务上已经接近闭源模型。这种竞争直接压低了 API 价格，也让本地部署成为一个现实选项。
模型层的技术观察点包括：
- 模型榜单上的得分变化，尤其是新模型发布后的提升幅度。
- 上下文窗口长度和长文本处理稳定性。
- 指令遵循能力，也就是模型能不能按照约束条件完成任务。
- 微调和量化的可操作性，能不能在消费级显卡上跑起来。
“被低估”在这里的含义是：模型能力的提升速度，超过了市场对模型价值的重估速度。对于技术团队来说，这意味着今天不需要立刻绑定某个闭源生态，可以保持“模型可替换”的架构，哪个模型效果好、成本低就切到哪个。
2.3 应用层：AI Agent 和编程工具是增量最大的部分
应用层是目前最容易被低估的部分。原因很简单：AI 应用刚开始时都以“聊天助手”“内容生成”的形态出现，市场容易用“工具软件”的估值方式去衡量。但 AI 真正有想象力的地方在于任务自动化，也就是 AI Agent。当一个 Agent 能够自主完成多步骤任务，比如查数据、写代码、跑测试、生成报告，它的定价模式就从“按软件收费”变成了“按结果收费”。
应用层的技术验证维度：
- 任务完成率：AI Agent 在真实业务任务中能否稳定跑通。
- 多轮交互能力：在复杂流程中能否保持状态一致。
- 工具调用能力：能否正确调用搜索、代码执行、数据库查询等外部工具。
- 批量处理效率：大量任务并发时，稳定性如何。
从开发者的角度看，AI 编程工具、AI Agent 框架、AI 工作流引擎是当前增长最明显的赛道。这类工具的用户增长数据，比任何估值模型都更接近真实市场热度。
3. 适用人群与技术边界
“AI 市场被低估”这个判断框架，不是对所有人都适用。不同角色的关注点完全不同。
3.1 适合谁
- AI 应用开发者：需要判断现在投入 AI 开发是不是太早，能不能回本。
- 大模型部署团队：需要决定是继续用商业 API，还是自建推理服务。
- 技术管理者：需要规划明年的 AI 预算，是扩张还是收缩。
- 开源项目维护者：想了解 AI 开源生态的趋势和机会。
- 技术投资者：想用更技术化的指标辅助判断 AI 领域的真实热度。
3.2 不适合谁
- 没有实际业务场景支撑，只想“追风口”的团队。
- 没有算力预算，但以为“免费开源模型”可以解决一切的小团队。
- 想靠套壳 API 赚快钱、不愿意做场景深耕的个人开发者。
- 把市场分析当成投资指令、不考虑风险控制的人。
3.3 技术边界与合规提醒
无论观点多么乐观，工程落地必须遵守几个边界：
- 涉及人脸、声音、肖像、版权素材时，必须获得明确授权。
- 数据处理要遵守隐私合规要求，个人信息不能随意进入模型训练或 API 调用。
- 本地部署能降低数据外泄风险，但不代表绝对安全，需要做好访问控制和审计。
- AI 生成内容要经过人工复核，避免错误信息对外发布。
- 本文只是技术分析框架，不构成任何投资建议。
4. 判断 AI 市场是否被低估：技术指标验证
与其争论观点，不如建立一套可观测的技术指标。下面这四个指标，是判断 AI 市场真实热度的关键。
4.1 推理成本曲线
推理成本是 AI 市场规模最重要的先行指标。价格下降会带来需求增长，而需求增长又会带动基础设施投入。建议每季度记录一次主流大模型 API 的价格，以每百万 Token 为口径，同时记录开源模型在同等硬件上的推理成本。
4.2 开发者采用率
开发者社区的数据比新闻稿可靠。关注 GitHub 上 AI 相关项目的 Star 增长、PyPI 和 npm 上 AI SDK 的下载量、技术社区里 AI 工具的使用讨论频次。尤其要关注 AI 编程助手的渗透率，因为程序员是最早实践 AI 工具的群体。
4.3 开源社区活跃度
开源模型的发布频率、微调工具链的完善程度、社区贡献者数量，这些都能反映 AI 生态的底层活力。一个活跃的开源生态意味着自建成本会持续下降，应用层的利润空间会被打开。
4.4 用代码做指标记录
下面给一个简单的通用脚本，用来定期抓取某个 API 服务的价格并保存到本地。实际接口需要按你使用的服务商文档调整，这里只展示思路。
import json import time import requests from pathlib import Path # 监控大模型 API 推理成本的示例脚本 # 实际接口结构以服务商文档为准，这里只是一个通用模板 def fetch_price(api_url: str, model: str, api_key: str) -> float: headers = {"Authorization": f"Bearer {api_key}"} response = requests.get(api_url, headers=headers, timeout=10) response.raise_for_status() data = response.json() # 假设返回字段中包含模型每百万 Token 的价格，字段名需要按实际情况调整 return float(data.get(model, {}).get("price_per_million_tokens", 0.0)) def append_record(csv_path: Path, model: str, price: float) -> None: timestamp = time.strftime("%Y-%m-%d %H:%M:%S") record = f"{timestamp},{model},{price}\n" with open(csv_path, "a", encoding="utf-8") as f: f.write(record) if __name__ == "__main__": # 替换为真实的 API 地址、模型名和密钥 api_url = "https://example.com/v1/pricing" model_name = "your-model-name" api_key = "your-api-key" price = fetch_price(api_url, model_name, api_key) append_record(Path("./price_history.csv"), model_name, price) print(f"{model_name} current price: {price}")这个脚本的价值在于建立自己的数据记录。不要只依赖新闻上的“AI 市场有多大”的预测，把每季度成本数据拉出来，比抽象讨论更有说服力。
5. 从观点到工程落地：AI 应用部署的现实门槛
判断 AI 市场是否被低估，最终要落在“你自己的 AI 应用能不能跑起来、能不能用得起、能不能规模化”。
5.1 自建推理 vs 使用商业 API
先做一次基础选型对比。这个表格适合每个技术团队在立项时参考：
| 对比项 | 商业 API | 本地自建推理 |
|---|---|---|
| 启动成本 | 低，按调用付费 | 高，需要 GPU 和运维投入 |
| 数据隐私 | 依赖服务商的数据条款 | 数据留在本地，可控性更强 |
| 单次调用成本 | 随调用量线性增加 | 固定成本，规模化后降低 |
| 技术门槛 | 低 | 高，需要处理显存、量化、并发 |
| 可定制性 | 受模型和服务限制 | 可微调、可换模型、可改推理参数 |
| 稳定性 | 取决于服务商 SLA | 取决于自身运维能力 |
对于验证市场观点的技术团队，建议先走 API 做小规模 PoC，验证业务场景确实成立后，再考虑自建。这样可以避免一开始就陷入算力成本的陷阱。
5.2 本地部署环境准备
如果选择自建，需要准备以下基础环境：
- 操作系统：Linux 优先，Windows 和 macOS 也可以做小规模测试。
- GPU 驱动和 CUDA 环境，版本要匹配模型推理框架。
- Python 环境，建议用独立的虚拟环境隔离依赖。
- 模型推理框架，例如 vLLM、Ollama、llama.cpp 等。
- 模型权重文件，从可信渠道下载，注意许可证要求。
- 磁盘空间：模型权重文件通常会占用数 GB 到数十 GB 空间。
- 端口：服务默认启动端口需要保证不被占用。
注意：具体显存需求和依赖版本以你选用的模型和框架为准，不同模型差异很大，不要照搬网上的固定参数。建议先跑最小测试，记录实际占用。
5.3 启动服务示例
下面给一套通用启动命令。具体的模型路径和端口需要按项目环境调整。
# 以 vLLM 为例，启动一个 OpenAI 兼容的本地推理服务 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --host 127.0.0.1 \ --port 8000 \ --tensor-parallel-size 1 # 如果端口被占用，可以换一个端口 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --host 127.0.0.1 \ --port 8001 \ --tensor-parallel-size 1也可以使用更轻量的 Ollama 做本地测试：
# 使用 Ollama 一键拉取并运行模型 ollama run <model-name>启动成功后，可以通过浏览器或命令行工具访问服务地址。如果是 vLLM，默认会提供/v1/models等 OpenAI 风格接口，可以直接用兼容的 SDK 做测试。
5.4 资源占用观察方法
本地部署时，要重点观察三个指标：
- 显存占用：用
nvidia-smi -l 1实时查看。 - CPU 和内存占用：批量推理时，CPU 可能成为瓶颈。
- 每秒生成 Token 数：这个指标直接影响用户体验和成本。
观察方法是：先启动模型服务，然后逐个增大并发请求数，记录显存、延迟和吞吐量的变化。如果你在 8GB 显存的环境下跑大模型，需要考虑量化方案或者选择更小的模型。
6. 接口 API 与批量任务验证
AI 市场能不能真正规模化，取决于 API 能力和批量任务能力。单独调用一次模型，说明不了任何问题；只有批量任务稳定跑完，才证明这个场景可以投入生产。
6.1 API 调用示例
本地服务启动后，可以用 curl 做一次快速验证：
curl -X POST http://127.0.0.1:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "your-model-name", "prompt": "用一句话解释 AI Agent", "max_tokens": 100, "temperature": 0.3 }'注意：这里的接口路径是 vLLM 等框架常见的 OpenAI 兼容格式。如果使用其他推理框架，接口路径可能不同，要以项目文档为准。
6.2 批量任务脚本
下面是一个通用的批量任务脚本模板，用来读取多行任务、调用本地 API、把结果写入输出文件。实际生产环境还要加入限流、任务队列和失败重试。
import json import time import requests from pathlib import Path API_URL = "http://127.0.0.1:8000/v1/completions" INPUT_FILE = Path("./tasks.jsonl") OUTPUT_FILE = Path("./results.jsonl") MAX_RETRY = 3 def call_api(prompt: str, max_tokens: int = 512) -> dict: payload = { "model": "your-model-name", "prompt": prompt, "max_tokens": max_tokens, "temperature": 0.2, } for attempt in range(MAX_RETRY): try: resp = requests.post(API_URL, json=payload, timeout=60) resp.raise_for_status() return resp.json() except Exception as exc: print(f"attempt {attempt + 1} failed: {exc}") time.sleep(2 ** attempt) return {"error": "failed after retries"} def process_batch(input_file: Path, output_file: Path) -> None: with open(input_file, "r", encoding="utf-8") as fin, \ open(output_file, "a", encoding="utf-8") as fout: for line in fin: line = line.strip() if not line: continue task = json.loads(line) result = call_api(task.get("prompt", "")) record = { "id": task.get("id"), "result": result, "timestamp": time.time(), } fout.write(json.dumps(record, ensure_ascii=False) + "\n") fout.flush() if __name__ == "__main__": process_batch(INPUT_FILE, OUTPUT_FILE)这个脚本的核心价值在于：通过批量处理，你能测量出单位任务的实际耗时和成本。这是判断一个 AI 场景是否值得投入的最直接数据。
6.3 批量任务的生产化建议
批量任务跑通后，还需要考虑工程化问题：
- 记录每次调用的输入输出，方便复盘。
- 加入失败重试和死信队列，避免任务卡死。
- 控制并发数，避免把显存打满导致服务崩溃。
- 增加日志，记录每次调用的延迟、Token 数和错误码。
- 对输出做长度限制和格式校验，防止脏数据污染后续流程。
这些工作看起来不性感，但决定了一个 AI 应用能不能从演示变成生产服务。
7. 资源占用与性能观察方法论
谈到 AI 市场，很多人只关注模型效果，但真正决定市场能不能落地的，是资源占用和性能。如果你的模型效果很好，但每秒钟只能处理一个请求，那它只能停留在实验室。
7.1 显存和内存观察
启动推理服务后，用nvidia-smi查看显存占用。第一次加载模型时显存占用会上升，然后趋于稳定。如果并发请求数上来后出现out of memory，说明需要降低并发数，或者换用量化模型。
7.2 影响性能的因素
以下几个参数会直接影响推理性能：
- 上下文长度：输入越长，显存占用和计算量越大。
- 最大生成长度：输出 Token 数越多，单请求耗时越长。
- 并发数：并发提高吞吐，但会增大显存压力。
- 量化等级：INT4 比 FP16 省显存，但可能牺牲少量精度。
- 批处理大小：合理设置批处理能提升 GPU 利用率。
7.3 降低资源占用的通用手段
如果你的硬件资源有限，优先尝试：
- 使用量化版本模型。
- 缩小上下文窗口，只保留必要信息。
- 限制单次生成的最大 Token 数。
- 用流式输出提升用户感知速度。
- 在非高峰时段跑批量任务。
实际能省多少资源，需要以你本机测试为准。不同模型、不同框架的差异很大，不要轻信网上的“通吃配置”。
8. 常见认知陷阱与问题排查
在讨论“AI 市场被低估”的过程中，技术团队容易陷入几个认知陷阱。这里整理成表格，方便对照排查。
| 问题表现 | 可能原因 | 排查方式 | 处理思路 |
|---|---|---|---|
| 模型效果很好，但成本压不住 | 没有建立成本基线 | 记录每百万 Token 的成本 | 改用更小的模型或量化版本 |
| API 调用经常失败 | 网络超时或并发过高 | 查看服务日志和错误码 | 增加重试和退避策略 |
| 本地部署后显存不够 | 模型过大或上下文过长 | 监控 nvidia-smi | 换量化模型或减少并发 |
| 批量任务跑到一半卡住 | 单条请求超时 | 检查任务日志 | 拆分任务，增加超时控制 |
| 输出质量不稳定 | 提示词不够结构化 | 对比不同提示词的输出 | 沉淀一套稳定的提示词模板 |
| 团队觉得“AI 没有用” | 选错了验证场景 | 复盘任务完成率 | 换一个高频、可量化的场景 |
| 生成内容包含错误信息 | 模型幻觉 | 人工抽样复核 | 增加外部知识库做检索增强 |
“AI 市场被低估”不代表每个场景都能赚钱。很多团队失败，不是因为 AI 不行，而是因为没有选对场景、没有建立可度量的指标、没有做好成本控制。
9. 最佳实践与合规边界
如果要把“AI 市场被低估”这个判断转化为实际项目收益，建议遵循以下最佳实践。
9.1 工程实践建议
- 先跑通最小闭环：不要一上来就搭复杂架构，先用 API 或一个小模型验证核心逻辑。
- 建立成本基线：从第一天开始记录调用量、Token 数、耗时和成本。
- 保留模型可替换性：架构上抽象模型接口，避免绑定单一厂商。
- 分层管理数据：原始数据、提示词模板、模型输出分开存放，方便回溯。
- 批量任务要加日志和失败重试，保证任务可持续执行。
- 接口服务要限制访问范围，本地部署时不要暴露公网，避免被滥用。
9.2 合规与安全边界
- 涉及人脸、声音、肖像、版权素材时，必须获得明确授权。
- 个人信息处理要符合隐私合规要求，谨慎用于模型调用。
- 生成式 AI 的输出需要人工复核，避免错误信息对外发布。
- 不要利用 AI 生成器制造虚假信息、绕过安全限制或进行违法违规活动。
- 本文内容不构成投资建议，请结合自身风险承受能力独立判断。
这些边界不是空话。AI 市场要健康发展，前提是每个使用 AI 的人都在合规框架内做事。技术能力越强，越要守住底线。
10. 总结：AI 市场低估与否，最终要看技术账
“AI 市场被低估了”这个观点，在 Eric Vishria 的表达里是一个投资判断；但放在技术社区里，它更像一道计算题。你需要回答：模型能力提升了多少、推理成本下降了多少、你的业务场景能不能用 AI 跑出正向收益。
这篇文章给出的分析框架，可以总结成一句话：用工程数据追踪 AI 市场的真实温度，而不是用情绪判断热度。先记录成本曲线，再验证开发者采用率，然后跑通批量任务，最后再决定是不是要加码投入。
建议把这个判断框架收藏备用。三个月后、半年后，翻出你记录的成本数据和模型效果对比，重新看一眼“AI 市场被低估了”这个观点。到时候，数据会比任何观点都更有说服力。下一次如果你看到一个 AI 项目宣称“效率提升数倍”，你就可以用这套方法，在本地跑一个最小验证，看看数字能不能复现。
