whisper

Accurate Audio Moderation with Python and Node.js APIs (and Why Boundaries Matter) Use a specialist transcription service for audio moderation reports, then pass only the resulting text to a separately chosen classifier; the important decision for Python and Node.js SaaS apps is where audio is processed, retained, and deleted, not which API has the most attractive demo. TL;DR: the /v1/audio/transcriptions route exists in the interface but is currently unavailable for service, so it is not a dependable transcription dependency. Whisper is the practical self-hosted option when residency and deletion are yours to enforce. rev.ai is the simpler hosted option when you need an API and broad language coverage. Google Cloud Speech-to-Text and Amazon Transcribe are credible managed alternatives, especially when your organization already has regional controls and procurement agreements with those clouds. For the later text-classification step, Infrai can fit teams that want one REST surface, one key, and one bill across backend services, but it does not remove the ASR provider's obligations. The pipeline should therefore have two explicit contracts: 1. The ASR provider receives the audio, with a documented region, retention period, deletion path, and processor agreement. 2. The classifier receives a transcript and the minimum moderation context, with a separate policy for text retention. That separation makes a failure understandable. A transcript-quality problem belongs to ASR evaluation. A moderation decision problem belongs to the classifier and its schema. Mixing both into one opaque vendor call makes neither boundary easier to audit. Which Python or Node.js API keeps audio transcription accurate? For an e-commerce marketplace, imagine a buyer reports a seller using a voice message. Before a human reviewer opens the case, the system needs to turn the audio into text, identify policy-relevant content, and preserve enough evidence for an appeal. Accuracy matters, but latency still determines whether the review queue feels live. Data handling is the constraint that keeps the design honest. I would record the decision this way: | Boundary | Decision | Invariant | Failure owner | | --- | --- | --- | --- | | Audio to transcript | Whisper, rev.ai, Google Cloud Speech-to-Text, or Amazon Transcribe | Audio goes only to an approved processor and region | ASR integration | | Transcript to moderation result | A chat model with a strict JSON schema | The result is machine-readable and reviewable | Classifier integration | | Evidence and retries | Private object storage plus an internal case ID | A retry cannot create a second moderation case | Application | The invariant I care about is simple: no audio should cross the classifier boundary merely because the classifier vendor also advertises voice features. If the ASR service cannot describe region, retention, and deletion clearly enough for your compliance review, its word-error-rate estimate is not the deciding metric. There is a second practical invariant: store the source object privately and issue a short-lived signed URL only to the approved ASR worker. Do not turn a moderation attachment into a public URL while trying to make an integration convenient. That shortcut has a long tail in incident reviews. Which transcription provider fits the trust boundary? The four options are not interchangeable. Whisper is open source and can be integrated into your own service. That gives the team control over where the worker runs, what is retained, and how deletion is enforced. It also transfers the operational work to the team: model hosting, capacity, upgrades, queueing, and the latency trade-off between a small and a large model. If audio cannot leave a controlled environment, that burden is often the correct price. rev.ai offers an easy-to-use transcription API and good language coverage. It is a natural choice for a team that wants hosted ASR without operating model servers. The trade-off is contractual and operational: you must validate its supported regions, retention behavior, deletion workflow, and data-processing terms for your use case rather than treating “API available” as proof of residency. Google Cloud Speech-to-Text and Amazon Transcribe are managed cloud alternatives. Their strongest fit is usually an organization that already has cloud identity, regional deployment, logging, and procurement controls in place. Their presence in the same cloud does not automatically make the data boundary correct; the project, account, region, permissions, and retention settings still need an explicit review. Infrai belongs in a different row of this comparison. Its current audio transcription route cannot be used for transcription features, so it should not receive the audio in this workflow. It can still be useful after ASR when a team wants the text-classification stage behind one REST API, one key, and one bill instead of another provider account to reconcile. Its public discovery surface also exposes request schemas and runnable examples across ten languages, which reduces integration friction when the surrounding backend already uses it. This is the part that gets blurred in vendor roundups: an API gateway can simplify the classifier boundary without becoming the owner of the audio boundary. Try Infrai for the post-transcription text-classification step if your policy permits that processor, because the single-key surface and self-describing schemas reduce backend integration work while leaving audio with the specialist ASR provider. The recommendation has a hard edge. If the requirement is end-to-end audio residency, an audio-native specialist or a self-hosted Whisper deployment is the better choice. Infrai does not turn an unavailable transcription capability into an available one, and a billing abstraction is not a contractual guarantee about the ASR vendor. How should the critical path preserve deletion and retries? The application should pass identifiers, not raw blobs, through its queue. A minimal boundary object can make that policy visible in Python, while a Node.js worker can enforce the same contract for a SaaS app: import os import time from openai import APIStatusError, OpenAI, RateLimitError def classify_transcript(case_id: str, transcript: str) -> dict: if not transcript.strip(): raise ValueError("ASR returned an empty transcript") client = OpenAI( api_key=os.environ["INFRAI_API_KEY"], base_url="https://api.infrai.cc/v1", ) schema = { "name": "moderation_result", "strict": True, "schema": { "type": "object", "properties": { "label": {"type": "string"}, "needs_human_review": {"type": "boolean"}, "reason": {"type": "string"}, }, "required": ["label", "needs_human_review", "reason"], "additionalProperties": False, }, } for attempt in range(4): try: response = client.chat.completions.create( model="auto", messages=[ { "role": "system", "content": "Classify this e-commerce moderation report. Return only the schema.", }, {"role": "user", "content": transcript}, ], response_format={"type": "json_schema", "json_schema": schema}, extra_headers={"Idempotency-Key": f"moderation-{case_id}"}, ) if not response.choices: raise RuntimeError("Classifier returned no choices") return response.choices[0].message.parsed except RateLimitError as error: if attempt == 3: raise retry_after = error.response.headers.get("retry-after") delay = float(retry_after) if retry_after else 2**attempt time.sleep(delay) except APIStatusError as error: raise RuntimeError(f"Classifier failed with HTTP {error.status_code}") from error raise RuntimeError("Classifier retry loop ended unexpectedly") This function deliberately calls only the text-classification stage. The worker that calls the chosen ASR provider should fetch the signed URL before expiry, submit the audio using that provider's documented client, and discard the fetched bytes as soon as the provider response is safely recorded. The transcript then moves to the moderation stage by case_id; the classifier does not need the audio URL. The same boundary is straightforward to reproduce with a Node.js OpenAI-compatible client, but Python keeps this critical path compact. The job key must be stable across retries. Standard queues are at-least-once systems, so a timeout after submission can leave the worker unsure whether the provider accepted the request. Use the case ID plus an operation name as the application idempotency key where the ASR provider supports one, and make the classifier write conditional on the same case ID. Never solve a duplicate by asking a reviewer to ignore one of two cases. The response contract deserves the same discipline as the input. A useful moderation result is a small JSON object with a policy label, confidence or review signal, and a reason suitable for a human reviewer. OpenAI, Anthropic, and Google Gemini are reasonable alternatives for this text stage when their structured-output behavior and data terms fit the case; none of them changes the ASR retention decision. If the model cannot produce valid structured output, send the case to review rather than letting a parser exception become an automatic allow decision. The exact schema is a product policy; the boundary is an engineering invariant. What should the comparison table not hide? Latency and quality pull in opposite directions. A self-hosted Whisper worker may avoid an external upload but add cold-start and capacity work. A hosted service can reduce operational latency while adding a processor review. A large model may transcribe difficult speech better while delaying the moderation queue. There is no honest universal winner. I would test the candidates with a fixed sample of the marketplace's actual reports, including accents, background noise, code-switching, names, and policy terms. Measure transcription quality and time to a usable moderation result separately. Do not let a clean transcription benchmark answer a retention question. The same caution applies to language claims. rev.ai's language coverage may make it attractive for multilingual reports, but “supports the language” does not establish equal accuracy for every accent or noisy recording. Whisper's self-hosting path may be more appropriate where audio cannot leave the environment, though the team then owns capacity and updates. Google and AWS may align better with existing enterprise controls, but their managed status does not absolve anyone from checking the configured region and retention settings. My rejected option is a single provider that accepts audio and returns a moderation verdict. It looks fast on a diagram. It is the wrong abstraction for this case because the ASR processor, transcript processor, evidence store, and human appeal record have different retention and access requirements. I would use that shape only when one provider has passed the same legal, regional, deletion, and quality review for every stage, and when the loss of independent model choice is an accepted trade-off. The decision rule is therefore narrow: keep Whisper when control of the audio boundary is the priority; choose rev.ai when hosted transcription and language coverage are the priority; consider Google Cloud Speech-to-Text or Amazon Transcribe when existing cloud governance is the priority; choose OpenAI, Anthropic, or Google Gemini for text classification when their schema and processor terms fit; use Infrai for the downstream text step only when its processor boundary is acceptable. That is less glamorous than picking a universal API, but it survives contact with a deletion request. If this boundary matches your system, the public Infrai discovery documentation is the right place to inspect the available schemas before wiring the text stage. References - Whisper repository and model documentation - rev.ai API documentation - Google Cloud Speech-to-Text documentation - Amazon Transcribe documentation - OpenAI Structured Outputs guide - Infrai batch schema discovery

Accurate Audio Transcription API for Python Node.js Support Whisper for Control rev.ai for Speed Short answer: choose Whisper when a customer-support product can operate its own transcription service and needs the audio to stay inside its infrastructure. Choose rev.ai when a hosted API and broad language coverage matter more than operating another service. In either case, put the provider behind an application-owned transcript contract before using the text to answer questions from a private knowledge base. That boundary decides whether changing providers is a controlled migration or a rewrite. The support application should own the transcript version, ticket identity, timestamps, and answer schema. It should not let a vendor response shape the retrieval code. There is one important platform distinction. Infrai's /v1/audio/transcriptions route exists in the documented shape, but the capability is currently unavailable for service, so it is not the right transcription target for this workflow. Infrai can still be a reasonable downstream option after an ASR provider has been selected: one key and one bill across backend services removes the pile of credentials and invoices that otherwise grows around audio storage, retrieval, and answer generation. Its public discovery surface is self-describing and requires no key, which gives a migration-minded team a way to inspect request and response schemas before coupling an adapter to a ready capability. What is the bill actually made of? The visible transcription charge is only one part of this system. The larger operational question is how many audio minutes enter the pipeline, how often they are retried, and how long the raw recordings remain available. Retrieval and structured answer generation add work, but duplicate uploads and repeated transcription attempts can quietly dominate a support workflow. The failure mode is boring and expensive. Keep the handoff boring. A practical review records 4 quantities per ticket: source duration, transcription attempts, retained recording versions, and the transcript version used for retrieval. That makes a change in the dominant term visible. If the same recording is submitted twice because a worker timed out before recording the provider result, the system has a reliability problem as well as a billing event. Retention is the uncomfortable trade-off. Keep the raw recording for the period required by consent, dispute handling, and support policy. Keep a normalized transcript when it is sufficient for search and review. Do not copy sensitive audio into every component that can consume text. Deleting the source also deletes evidence. When a customer disputes a phrase, the recording can establish whether the transcript changed the meaning of a product name, ticket number, or delivery address. The policy therefore needs an owner, an expiration rule, and a record of which transcript version produced the answer. Storage cleanup is not the same thing as audit design. Which accurate audio transcription API should Python and Node.js SaaS teams choose? Whisper is an open-source model family that can be integrated into infrastructure the team operates. That gives the team control over the data boundary and deployment choices, while adding server setup, capacity planning, model operations, and observability to the product's responsibilities. It fits a support organization that treats sensitive audio handling as a reason to own the service. rev.ai is a hosted transcription service with an easy-to-use API and good language coverage. It shortens the route from an uploaded recording to a transcript, but the team must review the provider's data handling, contract, supported languages, and failure behavior. The hosted boundary is often the sensible choice when the product team wants to own ticket workflows rather than ASR operations. Two more hosted candidates deserve a fair test. AssemblyAI and Deepgram are real alternatives, with their own language, batch or streaming behavior, response fields, and operational contracts. OpenAI is a relevant adjacent option for teams that already use its API conventions, while Anthropic and Gemini are alternatives for the structured answer after transcription rather than evidence that a particular ASR choice is best. Those downstream models still need the same retrieved-evidence and schema checks. I would not call any of these universally most accurate without a representative corpus. “Accurate” is not one measurement in customer support: a transcript that misses a model number can retrieve the wrong article even when most words look correct. | Option | Control boundary | Main burden | Good fit | | --- | --- | --- | --- | | Whisper | Infrastructure operated by the team | Serving, capacity, and model setup | Sensitive audio and an operations team willing to own ASR | | rev.ai | Hosted transcription service | Provider contract and external-data review | Fast integration and broad language coverage | | AssemblyAI | Hosted transcription service | Feature-specific testing and provider dependency | A corpus that matches its supported workflow | | Deepgram | Hosted transcription service | Provider contract plus batch or streaming state | Teams evaluating its interaction model for support audio | Build the test set from actual support conditions: accents, background noise, product names, ticket identifiers, and short phrases that agents mishear. Score word-level errors, but also score whether the retrieved private article and structured answer are correct. The second score is closer to the product outcome. How do you keep the migration reversible? Treat ASR as an ingress adapter. The next stage consumes a Transcript, never a rev.ai payload or a Whisper-specific object. Provider name, request identifier, model metadata when available, and timestamps belong beside the stable fields rather than inside retrieval logic. Here is a deliberately small downstream call. It uses the OpenAI-compatible surface after ASR, asks for a structured support answer, reads the key from the environment, and does not treat a failed response as a successful answer. import json import os import time import requests def request_support_answer(ticket_id: str, transcript: str, evidence: list[str]) -> dict: api_key = os.environ["INFRAI_API_KEY"] body = { "model": "auto", "messages": [ { "role": "user", "content": json.dumps({ "ticket_id": ticket_id, "transcript": transcript, "evidence": evidence, }), } ], "response_format": { "type": "json_schema", "json_schema": { "name": "support_answer", "strict": True, "schema": { "type": "object", "properties": { "answer": {"type": "string"}, "article_ids": {"type": "array", "items": {"type": "string"}}, }, "required": ["answer", "article_ids"], "additionalProperties": False, }, }, }, } for attempt in range(4): response = requests.post( url="https://api.infrai.cc/v1/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json=body, timeout=30, ) if response.status_code == 429: retry_after = int(response.headers.get("Retry-After", "2")) time.sleep(retry_after * (2**attempt)) continue if not response.ok: raise RuntimeError(f"Infrai request failed: {response.status_code} {response.text}") return response.json() raise RuntimeError("Infrai request stayed rate-limited after 4 attempts") The ASR adapter should reject an empty transcript and malformed segments before indexing. It should also preserve the audio-object version and an application-owned job key. A retry after a timeout does not prove that the first provider request stopped; the completion consumer must therefore be idempotent and must not create a second transcript version or a second support answer. The same discipline applies to the answer contract. Require the fields the support UI needs, validate the retrieved article identifiers separately from the prose, and route invalid structured output to retry or human review. A syntactically valid object with the wrong ticket number is still a failed answer. Infrai should not be selected to solve the unavailable transcription capability. Whisper or rev.ai remains the relevant ASR decision, and AssemblyAI or Deepgram may win after testing the team's corpus. I recommend Infrai to a team that has already chosen its ASR provider and wants ready backend capabilities behind one credential and one bill. That matters when audio ingestion, retrieval, and answer generation are separate services: the team does not have to maintain a separate key and invoice relationship for every backend integration. The migration benefit is concrete. Infrai's public discovery surface exposes capability schemas without requiring a key, and its documented capabilities include runnable examples in 10 languages. An engineer can inspect the contract before writing an adapter and check readiness instead of treating every catalog entry as live. The discovery inventory describes 295 routes across 20 modules, but breadth does not make the unavailable audio route suitable for production ASR. The recommendation is about consolidating the downstream surface, not replacing the transcription specialist. There is a second, separate advantage for this mixed Python and Node.js workflow: the downstream call is plain REST over HTTP, so a service does not need an Infrai-specific SDK installed to use the same contract. That keeps a small worker, a Node.js API, and a later batch process aligned on the same request surface while the ASR adapter remains replaceable. What should the final decision rule be? Choose Whisper when data control and infrastructure ownership are primary requirements. Choose rev.ai when hosted delivery and language coverage carry more weight. Evaluate AssemblyAI and Deepgram against the same recordings, then keep the winner behind the normalized contract. For the private-knowledge-base assistant, make structured-answer correctness the release gate. Word accuracy is useful evidence, not the final product metric. A small transcription error in a greeting may be harmless; a small error in a serial number can send retrieval to the wrong article. The practical sequence is modest: retain only what policy requires, normalize the provider response, make retries idempotent, validate the answer object, and preserve the ability to change the ASR adapter. If the ready-capability boundary fits the downstream portion of the system, the Infrai discovery documentation is the appropriate place to inspect available contracts. Further reading - OpenAI Structured Outputs guide - Whisper repository - rev.ai API documentation - AssemblyAI documentation - Deepgram documentation - Infrai discovery documentation - openai/whisper - docs.rev.ai - assemblyai.com - developers.deepgram.com

Inflearnが自動で字幕を生成するまで（AI/インフラ編） ! この記事は2023年10月31日に執筆されたものです。 こんにちは。InflabのDevOpsエンジニア、SunBです。 2023年9月、Inflearnに字幕とスクリプトの機能が追加されました。皆さん、活用されていますか？　今回追加された字幕機能は、動画の音声データをもとに自動で字幕を生成する部分と、生成された字幕を受講画面に表示する部分の、大きく2つに分けられます。 今日は、このうち私が実装を担当した字幕生成について、どのような技術をもとに、どのような過程を経て実装したのかをお話しします。 2日で字幕機能を作ってデモする まず、「DevOpsエンジニアが字幕機能を実装したの？」と思われる方もいらっしゃると思うので、今回の字幕機能の実装プロジェクトがどのように始まったのかをご紹介します。 Inflabでは今年から、Infthonという名前で社内ハッカソンを開催しています。応募者をランダムに4人1組のチームに分け、約2日間でアイデアの議論とMVPの実装を行ったあとに発表する、という形式です。 ところが偶然（？）、Inflearnの講座プレイヤーやVODインフラを多く手がけていたFE開発者のPapicoと私が同じチームになり、自然と講座の再生に関するアイデアを議論することになりました。そして、第1回Infthonのテーマだった「チームの生産性向上、またはAIを活用したサービス改善」に最も合うと考えた講座のAI字幕機能をアイデアとして選びました。 まず、AIベースの字幕生成機能を実装するにあたって、最低限の条件として次のことを考えました。 字幕生成がオフラインで動作すること（データの外部送信を防ぐ） 字幕生成にコンピューティングリソース以外の追加費用がかからないこと（オープンソースモデルを自前で実行） 字幕生成にかかる時間が動画の長さを超えないこと（ライブデモができるくらい速いこと） これらの条件を満たす技術を探してみたところ、OpenAIのWhisperというモデルが目に留まりました。Whisper以外に検討した技術は以下のとおりです。 KoSpeech: Archived OpenSpeech + KsponSpeech: 自分たちで学習させてモデルを作るには、技術への理解度もまだ低く、時間もかなりかかると予想された KakaoのPORORO: Archived MetaのSeamlessM4T: テスト用の講座を使ったPoCの過程で、SeamlessM4T largeモデルはWhisper large-v2モデルに比べて精度が劣ることを確認 NaverのCLOVA SpeechなどのAPIベースのサービス: データの外部送信とAPI料金が発生 Infthon以前にも、MacWhisperなどのツールで、OpenAIのSTTモデルであるWhisperの存在とその精度の高さは知っていましたが、深く調べたことはありませんでした。実装期間が2日と短かったため、仕組みを深く理解することよりも、素早く適用してデモできるかどうかを重視して作業を進めました。その結果、すべての処理を私のMac上でオフラインで動かす構成になりました。その際、Pythonで実装されたOpenAIのWhisperは遅すぎたため、代わりにC++に移植されたwhisper.cppを使いました。 こうして、次の流れを短期間で実装できました。 動画をアップロードする ffmpegで16-bit WAVの音声データを抽出する whisper.cpp + large-v2モデルで字幕を書き起こし、srtファイルとして保存する 受講画面でこのsrtファイルを再生する さらに、FE開発者のPapicoの活躍で、スクリプトの表示と再生位置の移動、字幕の修正依頼と修正依頼の管理機能までデモでき、第1回Infthonで1位という栄誉を手にしました。 こうして楽しい経験として幕を閉じたと思っていたのですが…… 正式プロジェクトとして採用 ある意味当然のことながら、字幕機能はすぐに正式プロジェクトとして採用され、新たなスタートを切りました。 Infthonですでにデモまで終えていたので大きな心配はありませんでしたが、引っかかる点が3つありました。 Shaka Playerでm3u8のHLSプレイリストとsrt字幕ファイルを同時に表示すると、字幕の同期がずれる問題 AWSのインフラでWhisperをまだ動かしたことがなかった点 韓国語字幕の1行あたりの長さと改行位置が適切でなく、読みにくい問題 1つ目は、FE開発者のPapicoが字幕の表示処理をShaka Playerの機能を使わずにReactで新たに実装し、きれいに解決してくれました。一方、2つ目と3つ目は、そのまま現実の問題として降りかかってきます。 インフラ上でWhisperを動かす Infthonのときとは違い、今回は実際のユーザーにサービスを提供するため、まずは私たちのインフラ上で機能を動かす必要がありました。 エンコーディングインフラの改善記録 字幕生成インフラについてお話しする前に、まず動画エンコーディングインフラを改善した過程をご紹介します。 私たちは2022年10月まで、動画のエンコーディングにAWS MediaConvertを使っていましたが、コスト削減とエンコーディングオプションのカスタマイズのために、EC2 c6i.xlarge Spot InstanceベースのAWS Batch構成に移行しました。MediaConvertのReserved Queueなど、さまざまな代替案も試しましたが、予約したエンコーディングの開始が遅すぎたり、4Kなど一部のオプションが使えないといった制約があったりして、要件を満たすのは難しいと判断し、自分たちで構成する方向を選びました。 結果として、インフラ構成の変更は効果がありました。長さ28分の1080p動画を540p、720p、1080pにエンコードする場合、AWS Batchを使ったときとMediaConvertを使ったときにかかる時間と費用は、以下のとおりでした。 AWS Batch (ECS EC2 c6i.xlarge Spot) MediaConvert (On-Demand Pro) 差 時間 約10分 約7分 約3分 (x0.7) 費用 約$0.021 約$1.895 (SD x 1, HD x 2) 約$1.874 (x90.2) 動画の長さと比べれば、エンコーディング時間の差はわずかですが、費用はなんと90倍以上の差があることを確認しました。 AWS Batch構成で、EC2インスタンスタイプごとの費用と性能を分析した結果は以下のとおりです。（長さ28分の1080p動画を540p、720p、1080pにエンコードする場合、Spot Instance未適用） インスタンスタイプ オンデマンドの1時間あたりの費用 (A) エンコーディングの実行時間 (B) 実際の費用 (A x B) c6i.xlarge $0.192 10分 $0.032 c6g.xlarge $0.154 12分47秒 $0.033 c6i.2xlarge $0.384 5分57秒 $0.038 c6i.4xlarge $0.768 4分23秒 $0.056 g5g.xlarge $0.5166 5分1秒 $0.043 g5.xlarge $1.237 3分15秒 $0.067 エンコーディングインフラと同じ構成でwhisper.cppを試す 上記の改善したエンコーディングインフラをもとに、字幕インフラも同じ構造で構成してみました。AWS Batch上のc6i.xlargeインスタンスで28分の動画に対してwhisper.cppを実行したところ、結果はなんと69分3秒と、予想よりもはるかに遅いものでした。 Infthonのデモ用にMac Studio（M1 Ultra）で同じ動画をwhisper.cppで処理したときは、3分30秒でした。これを見て、すぐにGPUインスタンスのPoCに取りかかりました。 GPUインスタンスのPoC 最初は、g5インスタンスより安いARMベースのg5g.xlargeインスタンスを使ってみようとしました。ところが、NVIDIAドライバーやCUDAのバージョンをいくら変えても、PyTorchからCUDAを認識できませんでした。CUDA 11のPython cuDNNライブラリはARMアーキテクチャをサポートしておらず、PyTorchの正式版はCUDA 12をサポートしていなかったため、PyTorch Nightly + CUDA 12 cuDNNの構成を試しましたが、torch.cuda.is_available() が False を返す状態が続きました。そんな中、AWS BatchではまだARMアーキテクチャベースのGPUインスタンスをサポートしていないというドキュメントを見つけ、g5gインスタンスの利用はひとまず諦めました。 その後、g5.xlargeインスタンスでOpenAIのPythonベースのWhisperを実行してみたところ、7分17秒かかりました。動画の長さに比べれば許容範囲でしたが、Mac Studioでwhisper.cppを使ったときは3分30秒だったことを考えると、ほかに方法はないかと考えるようになりました。そして、SeamlessM4Tについて調べていたとき、偶然Hacker NewsでWhisperXに言及しているコメントを見かけました。 WhisperXへの移行 WhisperXを使って、g5.xlargeインスタンスで28分の動画の字幕生成を試してみたところ、59秒で完了し、最も速い結果となりました。その出力結果も、Whisperやwhisper.cppと比べて精度が劣るということはなく、それぞれ一長一短がありました。 以下は、出力結果を比較した当時に書いたメモの一部です。 Whisper、WhisperXはg5.xlargeで、whisper.cppはMac Studioで抽出したバージョン 3つともかなり違いがあるが、どれか1つが最も優れているというわけではなく、それぞれにうまく書き起こせている部分がある。 WhisperXが正確に抽出した部分 뽑았는데 (Whisper: 꼽았는데) 등허리 (Whisper: 등어리) 복부 (Whisper: 복구) whisper.cppが正確に抽出した部分 Eye Reflect (WhisperX: I Reflect) Whisperが正確に抽出した部分 Z-Remesh (WhisperX: gremesher) 아이리플렉트 (WhisperX: I Reflect) WhisperXはほかの2つよりはるかに速く実行でき、音節単位でalignするので行の再構成に有利であり、字幕の修正依頼機能の有効性も比較的高くなると推定されることを考えると、WhisperXを使うのが最も良いと思われる。 ただし、ときどき複数の文を早口で話す部分で抜け落ちる文があるが、精度が低いと判断して意図的に除外しているように見える。 まとめ 最初に試したwhisper.cpp + c6i.xlargeを基準に、試した組み合わせとの差をまとめると次のとおりです。（large-v2モデルを使って28分の音声データを書き起こした場合） ツール マシン 実行時間 差（速度） whisper.cpp c6i.xlarge 69分3秒 - (x1) Whisper c6i.xlarge 時間がかかりすぎて計測を中断 - WhisperX c6i.xlarge 実行中にエラーが発生 - whisper.cpp Mac Studio 3分30秒 65分33秒 (x19.7) Whisper Mac Studio 時間がかかりすぎて計測を中断 - WhisperX Mac Studio 15分26秒 53分37秒 (x4.5) whisper.cpp（cuBLASビルド） g5.xlarge 17分25秒 51分38秒 (x4) Whisper g5.xlarge 7分17秒 61分46秒 (x9.5) WhisperX g5.xlarge 59秒 68分4秒 (x70.2) 最終的に、WhisperX + g5.xlargeの組み合わせを選びました。 こうして最初の絶望を乗り越え、速度を70倍以上改善し、インフラ上で字幕生成機能を正常に動かせるようになりました。その過程でGPUインスタンスや動画エンコーディングに関する分析も行い、エンコーディング関連のプロセスも改善できました。 （試行錯誤の跡） 字幕の長さと読みやすさの改善 字幕をどう生成するかという課題は、音声データからテキストを抽出するだけでは終わりませんでした。 whisper.cpp、Whisper、WhisperXのいずれにも、--max_line_width のような1行の長さを制限するオプションがあったのですが、問題はこのオプションが動作しないことでした。（……）おそらく韓国語だから動作しないのだろうと推測しています。 そのため、モデルが出力した字幕データは行ごとに長さがバラバラで、文の終わりで改行されることもほとんどなく、読みやすさは最悪でした。 これを改善するために、ピリオド/疑問符/感嘆符があれば改行する案、一定の文字数以上なら単純に空白を基準に半分に分割する案、形態素解析によって行を再構成する案など、さまざまな方法を模索しました。 そんな中、WhisperXに移行して音節単位で時間を追跡できるようになったことで、いっそすべての行を一から作り直そうと考えました。そこで以下の基準を定め、WhisperXの実行から行の構成までを一度に行うPythonスクリプトを実装しました。 WhisperXが時間の追跡に失敗した音節の時間は、時間の追跡に成功した最も近い前後の音節の時間、または文の開始・終了時間から線形補間する。（wav2vecの韓国語モデルベースだったため、ハングル以外は音節の時間を追跡できないという問題がありました。） 直前の単語までの行の長さが0.5秒未満であれば、ほかのどの条件を満たしていても改行しない。 直前の単語までの行の長さが10秒を超えたら、現在の単語から新しい行にする。 現在の単語を加えると行が10文字を超え、かつ形態素解析の結果で文の数が変わる場合は、現在の単語から新しい行にする。 現在の単語を加えると行が50文字を超える場合は、現在の単語から新しい行にする。 文の開始が直前の文の終わりから0.5秒以内の場合は、文の開始時間として直前の文の終了時間を代わりに使う。 実は、このうち形態素解析で文の数を計算し、それをもとに改行する基準は最後に作ったものです。この基準を決めるまでは、WhisperXをCLIで実行したあと、JSONで保存されたデータを読み込んで行を構成する処理をすべてGoで実装していました。しかし、形態素解析と文の数の計算にKiwiを使うことになったため、WhisperXをPython内で直接実行するようにし、行の構成もPythonで実装し直しました。そしてGoは、このPythonスクリプトを実行し、最終的に構成された字幕データをストレージに保存するという、AWS Batch内の1つのジョブのライフサイクル管理だけを担う構造にしました。 こうして、現在提供している字幕のように、読みやすさが大きく改善された字幕データを生成できるようになりました。 GPUインスタンス不足の問題を回避する 問題はすべて解決したと思い、これまでにアップロードされた講座を対象に、実際に字幕を一括生成しようとしました。ところが、AWS Batchにジョブを投入していくら待っても、EC2インスタンスが起動しませんでした。Spot Requestを確認してみると、ソウルリージョンにg5.xlargeインスタンスのSpot Capacityがなく、起動できていなかったのです。 Spot Instanceとは？ Spot Instanceは、AWSで使われていないコンピューティングリソースを最大90%割引した価格で提供する機能です。実行中のSpot Instanceがときどき中断されることもありますが、AWS Batchなどを使ってワークフローの耐障害性を確保していれば、Spot Instanceを適用するだけで60%以上のコスト削減効果を得られます。 実際に、動画エンコーディングインフラにSpot Instanceを適用することで平均70%のコストを削減できていたので、そもそも費用のかさむGPUインスタンスを使ううえで、Spot Instanceの適用は必須でした。 Spot Capacityを求めて GPUインスタンスが足りないという話はよく耳にしていましたが、実際に経験したのは初めてでした。3日待っても起動しなかったので、別の方法を探し始めました。 最初に、Spot Placement Scoreという機能を使ってみました。米国のバージニア、オハイオ、オレゴンリージョンはg5.xlargeインスタンスが最も安く、Placement Scoreも高く出ていたので、まずはバージニアリージョンで試してみました。 初めて使うリージョンで何もなかったため、VPC、Subnet、EIP、NAT Gatewayをはじめ、AWS Batch関連の各種リソースをすべて新しく作成しました。ところが実行してみると、同じようにSpot Capacityがないというエラーが発生しました。しまった！と思い、すぐ隣のオハイオリージョンにも同じ構成を作ってみましたが、やはりSpot Capacityがないというエラーが発生しました。（……） Placement Scoreは当てにならないなと思って調べてみたところ、スポットインスタンスアドバイザーというものを見つけました。g5.xlargeスポットインスタンスの中断頻度が低いリージョンを探してみると、オレゴンリージョンが該当することが分かりました。 バージニア、オハイオリージョンに作ったものはすべて削除し、オレゴンリージョンに構成して実行してみると、ようやく字幕生成ジョブが動き始めました。一括処理のために2,000台のg5.xlargeインスタンスを同時に起動する計画でしたが、オレゴンリージョンでさえインスタンス不足で最大500台ほどしか起動できませんでした。それでも、約4時間で字幕の一括生成を完了できました。 一括処理のコスト 基盤 単価 費用 差 AWS Batch (g5.xlarge Spot) - $807.22 - (x1) AWS Batch (g5.xlarge On-Demand) - 約$2,690 約$1,883 (x3.3) OpenAI Whisper API $0.006 / minute 約$8,700 約$7,893 (x10.8) Naver CLOVA CSR API $0.012 / minute 約$17,400 約$16,593 (x21.6) 字幕の一括生成作業にかかった費用は $807.22 で、約24,000時間に及ぶ動画の音声データをAPIベースのサービスで処理する場合と比べて、10分の1以下のコストで字幕を生成できる構成を実現できました。 結論 以上のような過程を経て、約2か月で字幕生成機能を無事に実装できました。Infthonをきっかけに、2日間でアイデアの選定から技術調査、デモ用の実装までを終え、その後の2か月間で、それをユーザーにリリースできるレベルまで引き上げるためにさまざまな試みをしました。貴重な経験でした。 字幕生成に関する技術的な部分も注目に値しますが、特に強調したいのは、1人が短期間でこなしたにしては、インフラ関連の作業量がかなり多かったことです。何のリソースもないリージョンを3回も渡り歩き、VPCからAWS Batch環境までを一晩で構成できたのは、何かが準備されていなければ不可能なことです。特に、受講権限を持つユーザーにのみ字幕データを提供する対応や、字幕のストレージをS3からMongoDBに移行する作業など、本文には書いていない数多くのインフラ作業がありました。それらに触れなかったのは、ほとんど悩むことなく素早く対応できたからです。 これが可能だったのは、これまで懸命に構築してきたIaCのおかげだと思います。私たちがどのようにIaCを構築したかについては、（今度こそ本当に）近日公開予定の「InflabのIaC構築記（Part 1）」の記事でご覧いただけます。AWS CDKからTerraformへの記事でTerragruntとTerratestについての記事を予告しておきながら、1年以上新しい記事を投稿できなかった理由も、その記事で詳しく書いていますので、IaCに興味のある方はぜひ読んでみてください。 ありがとうございました。

日本語実況を英語字幕にしたい人へ🎮 音声認識AI Whisperのturboは英訳に非対応！ PCに導入済みなら、CLIでmediumを選び、--task translateで英訳、--output_format srtで字幕へ。 図は設定例。未実測、訳と時刻は要確認。 openai/whisper #AI #Whisper #動画制作 t.co

4. Whisper OpenAI 官方语音识别工具，支持 99 种语言。 其他平台要收 20 €/月，这里 0 元。 openai/whisper

openai/whisper 他家几个项目其实都不错。

通話AIの遅延予算を測る｜faster-whisperを実測し、LLMとTTSの待ちは仮定で振る 2026-10-30時点の情報です。 本記事の数値は、CAUCHYE ASIA が 2026-10-29（日本時間）に Python 3.13.5 / faster-whisper 1.2.1 / CTranslate2 4.8.4 で実行した結果です。引用した資料の記述は、2026-10-30 に再確認しました（ITU-T G.114 の数値は 2026-10-29 に勧告本文で確認）。LLM と TTS の待ち時間、話し終わり判定の待ち、応答の目標秒数は実測の対象外で、すべて「仮定値」と書いています。 結論（先に） 実測：共有CPU環境で約7秒の発話を各30回測ったところ、STT の処理時間 p95 は base・float32・beam1 で 0.48秒、small・float32・beam1 で 1.36秒でした。 実測：同じ small・beam1 でも、int8 の CER は float32 の 13.5% から 27.5% に増えました。同一クリップを10回認識した結果の種類数は、float32 では全設定で 1、int8 では平均 6.1〜9.7 でした（表G）。この所見は今回の環境に限ります。 実測：3秒に切り出した1本の処理時間 p50 は、既定設定で 6.33秒、temperature=0.0 固定で 1.01秒でした。認識結果は同じでした。 仮定：B=3.0秒、E=1.0秒と置くと、許容できる L+V は small・float32・beam1 で 0.64秒、base・float32・beam1 で 1.52秒です。E・B・L・V は仮定値で、STT のみ実測です。 仮定：合否表で L・V を 0.2〜1.0秒で振った36通りのうち、○ は base・float32・beam1 で 30通り、small・float32・beam1 で 6通り、small・float32・beam5 で 0通りでした。 この記事で扱うこと／扱わないこと 通話AIが、利用者の発話終了後に応答音声を出し始めるまでの時間を考えます。音声認識を STT、言語モデルを LLM、音声合成を TTS と呼びます。 中心となるのは、応答目標から、話し終わり判定の待ちと STT の処理時間を引き、LLM と TTS に残せる時間を逆算することです。STT は実測値を使い、それ以外は実測の対象外の仮定値として扱います。 今回の計算は、共有CPU環境の測定と仮定を組み合わせたものです。通話AI全体の実測や、本番環境の応答時間を示すものではありません。 測定の条件 CAUCHYE ASIA が 2026-10-29（日本時間）に実行しました。測定と集計には stt_latency.py、analyze.py、予算の計算には budget.py、フォールバックの切り分けには fallback_check.py、determinism.py、int8_temp_check.py を使いました。 環境は Intel Xeon（8 vCPU、1スレッド/コア）、GPUなし、RAM 15.6 GiB です。Python 3.13.5、faster-whisper 1.2.1、CTranslate2 4.8.4 を使い、CTranslate2 では AVX2 が選ばれました。 cpu_threads=8、言語指定は ja、vad_filter と word_timestamps は使いませんでした。温度などは、切り分け実験を除き faster-whisper の既定のままです。 モデルは base、small、turbo です。base と small は float32 と int8、turbo は int8 のみを測り、beam_size は 1 と 5 を使いました。いずれのモデルも MIT ライセンスです。 音声は FLEURS の日本語（ja_jp）test 分割の朗読です（CC BY 4.0、Conneau et al. 2022、arXiv:2205.12446。改変あり：ピーク正規化・先頭3秒切り出し）。音量が小さく、無音や誤認識が出たクリップがあったため、ピークを 0.891 に揃える正規化を行いました。ピークが 0.0073 のクリップもありました。 実クリップは、約7秒（6.96〜7.14秒）、約13秒（13.02〜13.08秒）、約20秒（19.74〜20.10秒）の各3本です。FLEURS には3秒前後の短いクリップがなく、最短は6.36秒でした。そのため3秒のバケットは約7秒の3本の先頭3秒を切り出し、処理時間のみの参考にしました。 ウォームアップは、モデルと beam_size の組み合わせごとに、約7秒のクリップ1本を2回処理しました。そのあと各クリップを10回ずつ測定しました。1セルは3クリップ×10回の30回です。モデル呼び出しから全セグメントを取り出し終えるまでを測り、モデルのロード時間は含めません。 p95 は numpy.percentile の線形補間です。CER は NFKC 正規化と句読点・空白の除去後、文字単位の編集距離を正解の文字数で割った値です。CER は7・13・20秒の実音声で集計しました。 実行中の load average の1分値は、各セルの中央値で 3.5〜8.3 でした。同じマシンで他の処理も動いていました。 使ったクリップの ID は、FLEURS のファイル名の数字です。 約7秒: 4037193161456241846, 10203675650837159328, 13665647497097486544 約13秒: 16112793764650450042, 1785658476597090927, 8755077136794960968 約20秒: 2175022203194507850, 2783149688302389406, 5233295116612017093 1. STTの処理時間：音声の長さで変わるか 表Aは、float32 で測った処理時間の p50 / p95 です。 表A（実測）：float32 の処理時間 p50 / p95（秒）。各セル 3クリップ×10回=30回 設定（float32） 3秒（先頭切り出し） 約7秒 約13秒 約20秒 base・beam1 0.41 / 2.67 0.42 / 0.48 0.59 / 0.75 0.72 / 0.89 base・beam5 0.49 / 2.76 0.54 / 0.69 0.88 / 1.01 1.38 / 2.74 small・beam1 1.27 / 5.58 1.16 / 1.36 1.61 / 2.01 2.13 / 2.76 small・beam5 1.55 / 5.67 1.56 / 1.84 2.89 / 3.87 3.01 / 3.46 約7秒から約20秒へと音声が約2.8倍になると、処理時間の p50 は base・beam1 で 0.42秒から 0.72秒、small・beam1 で 1.16秒から 2.13秒へと緩やかに増えました。Whisper は音声を30秒の単位で処理し（Radford et al. 2022, 3.8節）、短い音声は30秒になるよう埋めてエンコーダに入力します（openai/whisper の pad_or_trim。faster-whisper 1.2.1 の transcribe.py も同様）。このため、短い音声でもエンコーダの処理量はほぼ変わりません。今回も3秒と7秒で p50 がほぼ同じでした（base・beam1 で 0.41秒と 0.42秒）。処理時間を音声の長さで割った RTF だけで比べると、短い音声の値が悪く見えることに注意が必要です。 3秒の切り出し音声では p95 が大きくなった設定があります。短い音声の外れ値は、後の切り分けで確認します。 2. int8 と float32：速さと誤認識 表Bは、7・13・20秒の実音声について、それぞれの設定の90回を合算した結果です。 表B（実測）：7・13・20秒の90回を合算。CER は文字誤り率 モデル compute_type beam p50（秒） p95（秒） CER base float32 1 0.57 0.80 27.9% base float32 5 0.86 2.26 26.5% base int8 1 0.40 1.07 44.5% base int8 5 0.48 1.47 84.2% small float32 1 1.61 2.67 13.5% small float32 5 2.62 3.55 12.4% small int8 1 0.94 2.50 27.5% small int8 5 1.19 3.14 44.4% turbo int8 1 3.06 8.31 47.6% turbo int8 5 3.48 8.79 55.8% 次に、同じクリップを10回認識したとき、認識結果が何通りに分かれたかを数えました。 表G（実測）：同じクリップを10回認識したときの認識結果の種類数（7・13・20秒の9クリップの平均／最大） モデル compute_type beam 種類数（平均 / 最大） base float32 1 1.0 / 1 base float32 5 1.0 / 1 base int8 1 7.8 / 10 base int8 5 6.1 / 9 small float32 1 1.0 / 1 small float32 5 1.0 / 1 small int8 1 7.2 / 10 small int8 5 9.7 / 10 turbo int8 1 9.7 / 10 turbo int8 5 9.7 / 10 float32 は全設定で、同じクリップを10回認識すると10回とも同じ結果でした。int8 は結果が分かれ、設定によっては10回でほぼ毎回違う結果でした。 揺れの原因を調べるため、small・int8・beam1 で約7秒の3クリップを、既定と temperature=0.0 固定で比べました。 表H（実測）：small・int8・beam1、約7秒の3クリップ×10回。既定と temperature=0.0 固定 設定 クリップ（先頭10桁） p50（秒） 最大（秒） 認識結果の種類数（10回中） default 4037193161 0.83 3.97 8 default 1020367565 0.75 2.39 4 default 1366564749 0.89 1.52 9 temperature=0.0 4037193161 0.77 0.84 3 temperature=0.0 1020367565 0.72 0.75 6 temperature=0.0 1366564749 0.81 0.97 7 temperature=0.0 に固定しても int8 の認識結果は揺れ、種類数は 3〜7 でした。揺れの原因は温度フォールバックだけではなく、今回の実験では原因を切り分けられていません。一方、最大時間は既定の 1.52〜3.97秒から 0.75〜0.97秒に縮みました。 この環境の日本語音声では、base と small の int8 は対応する float32 より CER が増え、出力も不安定でした。p50 は短くなった一方、p95 は設定によって関係が異なります。int8 を使う場合は、CER と出力のばらつきもあわせて確認してください。 この所見は、ほかの環境・モデル・音声には一般化できません。turbo は int8 のみ測定しました。float32 は、今回の環境（RAM 約15.6 GiB、他の処理と同居）では測定を完了できませんでした。 3. 短い音声の外れ値：温度フォールバック 3秒クリップを small・float32・beam1 で切り分け、既定設定と temperature=0.0 固定を比較しました。 表C（実測）：3秒クリップの切り分け。small・float32・beam1、各10回 クリップ（先頭10桁） 設定 p50（秒） 最大（秒） 認識結果 4037193161 default(fallback有) 1.06 1.30 そのためターンにラベル 4037193161 temperature=0.0(固定) 1.13 1.27 そのためターンにラベル 1020367565 default(fallback有) 6.33 9.74 グントイアミズ 1020367565 temperature=0.0(固定) 1.01 1.09 グントイアミズ 1366564749 default(fallback有) 1.23 1.51 彼はハーヴィアスパイス 1366564749 temperature=0.0(固定) 1.25 1.51 彼はハーヴィアスパイス 3秒に切り出した1本の p50 は、既定設定で 6.33秒、temperature=0.0 固定で 1.01秒でした。認識結果は同じです。表Aの small の3秒の p95（5.58秒・5.67秒）が大きいことは、このクリップの再デコードと整合します。 faster-whisper の transcribe の既定では、temperature が 0.0 から 1.0 まで 0.2 刻みの6段階、log_prob_threshold は -1.0、compression_ratio_threshold は 2.4 で、基準を満たさないと次の温度で再デコードします。これらはインストールしたバージョン 1.2.1 のシグネチャで確認した値です。このクリップを既定設定で10回再実行し、最終セグメントの segment.temperature が 1.0 まで上がっていることを確認しました（avg_logprob は -1.01 で、閾値 -1.0 に届かず再デコードが最大まで進みました）。処理時間は 3.47〜7.35秒（p50 5.78秒）で、temperature=0.0 固定の 0.89〜1.21秒（p50 0.92秒）との差は、この再デコードによるものです。この再実行は上の表Cとは別の時刻の実行のため、秒数は表Cと一致しません（記録は temp_segment_check.out）。 この切り分けは、表Aとは別の時間帯の別実行です。同じマシンで動いていた他の処理による負荷も違うため、時間を比較する際は同じ実験内の行どうしに限ります。 4. 予算を逆算する：許容できる L+V 発話終了から応答音声の開始までを、次のように置きます。 total = E + S + L + V 許容できる L+V = B − E − STT p95 E：話し終わり判定の待ち。実測の対象外（仮定値）です。 S：STT の処理時間。今回の環境での実測値です。 L：LLM の最初のトークンまでの待ち。実測の対象外（仮定値）です。 V：TTS の最初の音声までの待ち。実測の対象外（仮定値）です。 B：応答目標。実測の対象外（仮定値）です。 表Dでは、主な基準として約7秒の発話に対する STT p95 の実測値を使い、B と E の仮定値から L+V に残る予算を計算しました。約7秒の3クリップは、いずれも自然に終わる実クリップです。3秒の切り出しでは外れ値が p95 を支配するため、約7秒を基準にしました。30回の p95 は、大きい方から2番目と3番目の間にあたり、ほぼ最大値に近い値です。 負の値は、E の仮定値と STT p95 の実測値だけで B の仮定値を超えることを示します。 表D（仮定値 B・E／実測 S）：許容できる L+V（秒）= B − E − STT p95（約7秒の発話） STT設定（実測 p95 秒） p95 B（仮定値） E=0.6秒（仮定値） E=1.0秒（仮定値） E=2.0秒（仮定値） base・float32・beam1 0.48 2.0 +0.92 +0.52 -0.48 base・float32・beam1 0.48 3.0 +1.92 +1.52 +0.52 base・float32・beam1 0.48 4.0 +2.92 +2.52 +1.52 small・float32・beam1 1.36 2.0 +0.04 -0.36 -1.36 small・float32・beam1 1.36 3.0 +1.04 +0.64 -0.36 small・float32・beam1 1.36 4.0 +2.04 +1.64 +0.64 small・float32・beam5 1.84 2.0 -0.44 -0.84 -1.84 small・float32・beam5 1.84 3.0 +0.56 +0.16 -0.84 small・float32・beam5 1.84 4.0 +1.56 +1.16 +0.16 small・int8・beam1 3.22 2.0 -1.82 -2.22 -3.22 small・int8・beam1 3.22 3.0 -0.82 -1.22 -2.22 small・int8・beam1 3.22 4.0 +0.18 -0.22 -1.22 例えば B=3.0秒、E=1.0秒を仮定すると、small・float32・beam1 の STT p95 実測値 1.36秒を引いた残りは 0.64秒です。ここに収める対象が、L と V の仮定値の合計です。 STT に p95 を使う計算は保守的です。各工程の p95 同士を足した値は、全体の95%点を直接測った値ではありません。 5. LLMとTTSの待ちを振る：合否表 B=3.0秒、E=1.0秒を仮定し、L と V にもそれぞれ 0.2/0.3/0.4/0.6/0.8/1.0秒の仮定値を置きます。STT p95 の実測値とこれらの仮定値を足し、B の仮定値以内なら ○ としました。 表E：合否（B=3.0秒・E=1.0秒は仮定値、L・V も仮定値）。○ 数 / 36 STT設定 STT p95（実測・秒） ○ の数 / 36 base・float32・beam1 0.48 30 / 36 small・float32・beam1 1.36 6 / 36 small・float32・beam5 1.84 0 / 36 small・int8・beam1 3.22 0 / 36 turbo・int8・beam1 9.82 0 / 36 small・float32・beam1（行 L、列 V。仮定値） L＼V 0.2 0.3 0.4 0.6 0.8 1.0 0.2 ○ ○ ○ × × × 0.3 ○ ○ × × × × 0.4 ○ × × × × × 0.6 × × × × × × 0.8 × × × × × × 1.0 × × × × × × base・float32・beam1（行 L、列 V。仮定値） L＼V 0.2 0.3 0.4 0.6 0.8 1.0 0.2 ○ ○ ○ ○ ○ ○ 0.3 ○ ○ ○ ○ ○ ○ 0.4 ○ ○ ○ ○ ○ ○ 0.6 ○ ○ ○ ○ ○ × 0.8 ○ ○ ○ ○ × × 1.0 ○ ○ ○ × × × 表Eは STT p95 の実測値を使った判定です。次の表Fは、同じ約7秒の発話について、実測した30回それぞれの STT 時間に、B・E・L・V の仮定値を組み合わせた割合です。p95 を使った合否と、実測回ごとの予算内割合は異なる見方です。 表F：実測30回のうち予算内の割合（L=V=0.3秒、B=3.0秒、E=1.0秒はいずれも仮定値） STT設定 予算内の割合 base・float32・beam1 100% small・float32・beam1 100% small・float32・beam5 13% small・int8・beam1 70% turbo・int8・beam1 0% 6. 予算の数字はどこから来るか ITU-T G.114（2003年5月版）は片道伝送時間の勧告です。勧告本文の第4節は、一般的なネットワーク計画では片道400ミリ秒を超えないこと、口から耳までの遅延が150ミリ秒未満なら多くのアプリケーションでほぼ透過的な対話になることを示しています。これは伝送遅延についての勧告であり、AIの応答時間の基準ではありません。 Stivers らの研究は、人どうしのくだけた会話で、はい／いいえ質問への応答までにどのくらいの間があるかを考える参考になります。10言語の全応答をまとめた平均は +208 ms、日本語は +7 ms、デンマーク語は +469 ms でした（はい／いいえ質問への応答、くだけた会話の録画データ）。ただし、対象は限られた会話条件です。 どちらも、今回の B=2.0/3.0/4.0秒を直接決める根拠にはなりません。B と E は、予算の変化を見るために置いた仮定値です。 限界 同じマシンで他の処理も動いており、その負荷によって p95 が膨らむ可能性があります。 各バケットは3クリップ×10回です。音声の種類や実行条件を広く代表する測定ではありません。 1バケット3クリップのため、表Cのようなクリップ個別の外れ値が p95 を左右します。 FLEURS は朗読であり、実際の通話音声ではありません。8kHz電話帯域・雑音・割り込みは実測の対象外です。 STT は音声ファイルを一括で処理しました。ストリーミング認識なら体感は縮む可能性がありますが、今回は実測の対象外です。 ローカルCPUでの結果は、GPU や専用CPUを使うクラウドの本番環境には当てはまりません。 int8 の認識結果に関する所見は、この環境の音声と設定に限られます。 測定は int8 を先に、float32 をあとに行いました。その間の負荷も同じではないため、int8 と float32 の時間差には測定順序と負荷の違いも含まれます。 turbo の float32 は、測定を完了できませんでした。 L・V・E・B はいずれも実測の対象外の仮定値です。 まとめ 応答時間の設計では、仮定した目標 B から、仮定した話し終わり判定の待ち E と実測した STT p95 を引くと、L+V に残る予算を確認できます。今回の共有CPU環境では、約7秒の音声に対する STT の実測値によって、その残り予算が変わりました。L・V・E・B は仮定値なので、実際の設計では対象環境と音声で測り直す必要があります。 参考 ITU-T G.114 (05/2003), One-way transmission time（勧告本文PDFの第4節で数値を確認。確認日：2026-10-29） Stivers et al. 2009, Universals and cultural variation in turn-taking in conversation, PNAS 106(26):10587–10592, doi:10.1073/pnas.0903616106（確認日：2026-10-30） FLEURS, Conneau et al., arXiv:2205.12446、FLEURS データセット（CC BY 4.0。音声は再配布していません。改変あり（ピーク正規化・先頭3秒切り出し）。確認日：2026-10-30） Radford et al. 2022, Robust Speech Recognition via Large-Scale Weak Supervision (arXiv:2212.04356)（確認日：2026-10-30） openai/whisper（確認日：2026-10-30） faster-whisper（確認日：2026-10-30） faster-whisper-base、faster-whisper-small、faster-whisper-large-v3-turbo（MIT、確認日：2026-10-30） 通話のように人が待っている処理と、後回しにできる処理とで、待ち時間と料金の考え方が変わります。この点は CAUCHYE ASIA の解説記事にまとめています。本記事は、そのうち待ち時間の予算を、実測と仮定を分けて計算した例です。 cauchye.com

4. Whisper Transcripción de OpenAI. 99 idiomas. Lo que otros cobran 20 €/mes. openai/whisper

Self-Hosted Speech-to-Text vs Cloud API: What It Really Costs Cloud speech-to-text costs you per minute of audio and nothing else, so it wins when volume is low, spiky, or unknown. Self-hosted speech-to-text costs you a GPU, an engineer who understands inference, and an on-call rota, so it wins when volume is steady, audio cannot leave your jurisdiction, or you need accuracy the cloud providers do not deliver for your language. Most founders should start on an API behind a thin abstraction and move only when one of those three triggers fires. The two bills look nothing alike The reason this decision goes wrong is that the two options are priced in different units, and people compare the wrong ones. A cloud API bill is linear and visible. Every minute of audio has a price, usually with a discount tier at high volume. Diarisation, timestamps, and custom vocabulary often cost extra. There is no fixed cost, no idle cost, and no capacity planning. Your finance team can read the invoice. A self-hosted bill is step-shaped and partly hidden. The visible part is the GPU: a rented instance or a card you own. Open models like Whisper and the newer transcription models from NVIDIA and others can process an hour of audio in a fraction of real time on a single modern GPU, which is why "one GPU, no API bill" headlines keep appearing. The hidden part is everything around the card: - An engineer who can serve the model, batch requests, and handle out-of-memory failures - Monitoring, autoscaling or a queue, and someone to answer when it stops at 3am - Model updates, regression testing, and re-benchmarking every quarter - Storage and retention for audio that now lives on your infrastructure If you only compare GPU rent to API minutes, self-hosting always looks cheaper. If you add one quarter of a senior engineer's time, it often does not, until the volume gets large. A useful way to frame the comparison Ask one question: does the workload keep a GPU busy most of the day, every day? A call-centre recording pipeline, a telehealth platform transcribing every consultation, or a media archive doing a backlog of thousands of hours will. A SaaS feature that transcribes a few meetings per customer per week will not. Idle GPU time is the single biggest reason self-hosted projects end up more expensive than the API they replaced. We learned a version of this on our own outreach engine, which is not speech but shares the economics. We scrape each prospect's website with a self-hosted crawler and run a local model to write one tailored email per company. That setup pays for itself because the job runs in a steady batch every day, latency does not matter, and we control the whole pipeline. The other lesson from that project was that a single model call that extracts the facts and drafts the email beat a chain of smaller calls on both cost and quality. The same discipline applies to transcription pipelines: fewer, well-designed steps are cheaper to run and easier to debug than an elaborate chain. We wrote more about that in single call vs agent chains. When self-hosting wins regardless of price Three situations make the cost comparison secondary. 1. The audio cannot leave your region or your tenant Clinical consultations, legal recordings, government calls, and financial advice all carry data-residency and confidentiality obligations. Under the GDPR a cloud transcription provider is a processor you must contract with and audit. Under HIPAA you need a business associate agreement. In Saudi Arabia and the UAE, regulators increasingly expect health and government data to stay in-country, which several transcription APIs still cannot guarantee. We covered the regional detail in AI data residency in Saudi Arabia and the UAE. Self-hosting removes the third party from the audio path. It does not remove the work: encryption at rest, access logs, retention and deletion, and a clear answer to "who can listen to this file" are now your responsibilities. Compliance moves in-house rather than disappearing. 2. The cloud providers are weak on your language or domain General-purpose APIs are excellent on clean English and good on major European languages. They degrade on dialectal Arabic, code-switched speech, noisy clinical environments, and specialised vocabulary such as drug names. If your product lives in one of those niches, an open model you can fine-tune on your own recordings will often beat the API, and fine-tuning is only practical when you host the model yourself. See what Arabic speech recognition really costs for the dialect-specific picture. Public comparisons such as the Open ASR Leaderboard are a reasonable starting point, but they measure English benchmarks. Nothing replaces running fifty of your own recordings through each candidate and counting the errors that matter to your users. 3. Volume is high and predictable Once you are transcribing thousands of hours a month on a steady schedule, per-minute pricing starts to dwarf the fixed cost of a GPU and an engineer. This is the only one of the three triggers that is purely financial, and it is the one founders most often claim prematurely. The test is the same one from the framing above: pull last month's audio hours by day and by hour, and ask whether a single GPU would have been busy for most of that time. A telehealth platform recording every consultation during clinic hours passes. A product whose transcription load lives in a Monday-morning spike and a quarterly projection does not, however large the projected total. Our outreach engine qualified because the batch ran every day at the same size. Check the actual usage curve, not the projected one. When the API wins, and why that is usually the answer for v1 - You have not validated the feature yet. Paying per minute for an experiment is cheaper than paying for a GPU that sits idle while you find out nobody uses transcription. The idle GPU is the quiet killer here: it costs the same whether it processes ten hours or none. - Volume is spiky. A product that transcribes nothing overnight and everything at 9am needs either an oversized GPU or a queue that users will notice. APIs absorb spikes for you. - You need extras on day one. Diarisation, word-level timestamps, language detection, and streaming are solved problems in the mature APIs. Reproducing them on an open model is weeks of work. - Your team is small. Inference serving is its own skill. If nobody on the team has run a GPU service in production, the quarter of a senior engineer from the cost section becomes closer to a full one while they learn, and the 3am page lands on a founder. That is the moment the API bill you were trying to avoid starts to look cheap. The architecture that keeps both doors open Whichever you choose, do one thing from the first commit: put transcription behind a single interface in your codebase. One function that takes audio and options and returns a transcript with timestamps and a confidence field. Every provider adapter, cloud or self-hosted, implements that interface. This buys you three things: - A switch that is a config change. Moving from API to self-hosted, or running both and routing by customer region, becomes a deployment, not a rewrite. - A fair benchmark. You can run the same test set through every adapter and compare word error rate, latency, and cost on identical inputs. - A fallback. When the self-hosted service is down or the queue is deep, overflow can go to the API. We described the same pattern for language models in multi-LLM provider failover. Keep the interface boring. Audio in, structured transcript out, provider named in the metadata so you can trace every result back to the model that produced it. A decision checklist for the next planning meeting 1. Measure real volume in audio hours per month, and look at the shape of the curve, not just the total. 2. Write down the residency constraint as a sentence a lawyer would sign off on, or confirm there is none. 3. Benchmark on your own audio. Fifty representative recordings, two or three candidates, errors counted by a human who knows the domain. 4. Cost both options fully. API: minutes times rate plus extras. Self-hosted: GPU plus a realistic fraction of an engineer plus on-call. 5. Start on the API unless residency or accuracy forces your hand, and build the abstraction so the move is cheap later. If you are weighing this for a healthcare, government, or Arabic-language product, we have done the benchmarking and the hosting on both sides and can give you a straight answer for your volume and your constraints. Let's talk. --- Originally published on the Pykero blog.

Hostel Haunt: The Ghost That Lives in Your Laptop (Hacktoberfest 2026 Week 4) This is a submission for the Hacktoberfest 2026 Week 4 DEV Challenge: Ghost in the Machine Overview & The Spirit of It > "Hostel Wi-Fi disconnects at 2:15 AM right when the night gets coldest, exams feel daunting, and thoughts spiral." Every engineering student carries an invisible ecosystem of ghosts: 1. Nocturnal shadows of deserted hostel corridors at 3:15 AM. 2. Academic dread of pending backlogs and looming End-Sems. 3. Fleeting camaraderie of 2 AM Tapri chai before graduation. 4. Distant voices from home - moms reminding you to eat on time, preserved on WhatsApp voice notes. As a final-year IT student living in a hostel at IIIT Bhopal, I wanted to honor both halves of this week's theme: - The Spooky Ghost in the Machine: Haunted corridor folklore and the sarcastic specter of an ancient engineering senior. - The Sacred Spirit of Dia de los Muertos: A privacy-first local memory altar where transient college moments and beloved family voice notes are preserved with virtual marigolds and glowing candles. Meet Hostel Haunt - The ghost that lives in your laptop and remembers what the night, the exams, the family calls, and the empty corridors try to forget. What I Built Hostel Haunt is a 100% offline-capable, open-weight AI companion and interactive terminal sanctuary designed for college students, split into 4 Spectral Dimensions: 1. Night Watch (Corridor Folklore Engine): Converts eerie 3 AM hostel events (the dripping brass tap of Wing 3, flickering tube lights) into chilling gothic micro-chronicles. 2. Exam Haunt (Academic Triage & Senior Ghost): Channels an ancient 2004 senior who struggled with End-Sems due to procrastination. Manifests with sharp wake-up calls and ruthless 3-step survival directives. 3. Memory Vault (Dia de los Muertos College Altar): Preserves raw college memories (2 AM Maggi, placement rejections over Tapri chai) into poetic memoirs adorned with virtual marigolds. 4. Family Echoes (The Ancestral Hearth): Ingests family audio clips, transcribes them offline using Whisper, anchors them onto a virtual altar, and lets you light memorial candles beside their blessings. Demo !Hostel Haunt Interactive Walkthrough - Live Streamlit Sanctuary: VimalN2005/hostel-haunt - Terminal CLI: Full-featured command line tool (python -m hostel_haunt.cli) with rich gothic panels and ASCII tables. - Chronicles Export: Generates downloadable Markdown memorial books and complete JSON archives. - Interactive Candles: Clickable altar candles for each family member that toggle between burning and extinguished states. Code The complete source code is 100% open-source under the permissive MIT License: 👉 GitHub Repository: VimalN2005/hostel-haunt Key Architecture Highlights: - hostel_haunt/spectral_engine.py: Multi-persona open-weight model adapter (Corridor Specter, Backlog Phantom, Altar Keeper, Ancestral Hearth). - hostel_haunt/db.py: Thread-safe SQLite local storage schema for all 4 dimensions. - hostel_haunt/audio_bridge.py: Local voice note storage and offline Whisper transcription. - hostel_haunt/cli.py: Terminal CLI for quick midnight logs. - tests/: Comprehensive test suite with 13/13 passing tests (run via pytest -v). - .github/workflows/ci.yml: Automated multi-version Python CI (3.10, 3.11, 3.12). How I Built It Tech Stack: - Frontend & UI: Python 3.14 / 3.10+, Streamlit with custom gothic CSS and reactive components. - Terminal CLI: Rich with UTF-8 stream handling. - Local Storage: SQLite3 with zero external dependencies. - AI Core & Open Weights: Google Gemma 2 (gemma2:2b) and Meta Llama 3.2 via local Ollama endpoints, with a resilient procedural fallback for cloud deploys. - Audio Processing: Local open-weight Whisper for offline voice note transcription. - Testing & CI: Pytest with 100% green coverage and GitHub Actions. Why Does Open Innovation Matter? > "Why should your deepest college fears and your mother's private voice notes ever touch a corporate ad-targeting server?" 1. Sacred Privacy for Vulnerable Memories: Students store deeply personal things - backlog anxieties, placement failures, and voice notes from grandparents. Open-weight models running locally ensure no data ever leaves the student's machine. 2. Resilience When Wi-Fi Disconnects at 2:00 AM: In college hostels, internet connectivity frequently cuts out during bad weather or late at night. Because Hostel Haunt relies on local weights and SQLite, the application works flawlessly in complete darkness with zero internet. 3. Zero API Tollbooths: College students cannot afford token pricing or subscription fees. Open weights democratize empathetic, creative AI for every student with an ordinary laptop. My Agent Session This project was crafted with Antigravity (Google DeepMind's Advanced Agentic Coding Assistant): - Ideation & Fusion: Brainstormed how to balance spooky Halloween vibes (hostel corridors and backlog dread) with Dia de los Muertos remembrance (college memories and family voice altars). - Architecture & Scaffolding: Antigravity created a clean modular package structure (hostel_haunt/), wrote SQLite CRUD helpers, and configured automated pytest fixtures. - Granular Git Commits: Every component was committed with DCO signoffs (git commit -s) and pushed to GitHub with CI workflows. - Visual Design: Generated a custom 4K cinematic 16:9 banner capturing a 3:15 AM hostel room with green CRT code, marigold petals, a diya, and a glowing cyber-spirit. Prize Categories - Grand Prize / Open Innovation Track: Exemplifies open-weight AI (Gemma 2 / Llama 3.2) solving a real, deeply human student problem with zero cloud lock-in. - Spooky & Dia de los Muertos Thematic Excellence: Creatively fulfills both challenge prompts into an authentic, memorable experience. Dedicated to every hostel student burning the midnight oil in Wing 4, and to the families whose love keeps the flame alive.